In EC2 the only way to create a bootable EBS volume with Windows on it is by starting with an EBS-based instance and using the API tools to create a new image from that instance – there’s no way to create a snapshot and then register it as a Windows AMI. I’m not familiar with how Eucalyptus does Windows, but I imagine it might have the same limitation.

This was really useful.

I am trying to use a bootable windows ebs volume with eucalyptus but I am not able to figure out how to make the boot ami point to the windows ebs volume.

Any help is appreciated.

Thanks

Great tutorial. I used the pesky Ubuntu Lucid EBS ami-ab4d67df as a base in eu-west-1 region and had a few issues. The first was the dreaded ssh connection refused when the time came to launch and log into the new instance, even after explicitly adding the ephemeral storage as per comment in No. 25. The second, after figuring out that I stumbled by just copying the directions instead of checking where the ephemeral storage is in m1.large instance (they go to /dev/sdb and /dev/sdc – instead of /dev/sda2 and /dev/sda3 ) was when I stopped the new instant and restarted again, to be refused entry, again!

What finally worked for me is detailed below. As always YMMW.

Before rsynching to /vol (or even after, you need to rsynch again) edit the etc/fstab so that the ephemeral drives are correctly mounted and root is specified as xfs.

Example:

# /etc/fstab: static file system information.
#
proc /proc proc nodev,noexec,nosuid 0 0
/dev/sda1 / xfs defaults 0 0
/dev/sdb /mnt auto defaults,comment=cloudconfig 0 0
/dev/sdc /log auto defaults,comment=cloudconfig 0 0


Then, change the ec2-register instructions so that the root device, /dev/sda1, has its DeleteOnTermination flag set to false. This should be automatic given its an EBS volume and also we are not terminating, but simply stopping and restarting, but for some reason it appears that without this flag explicitly set, weird things happen to /etc/fstab and the ephemeral storage devices, which in turn affect services such as ssh.

This is the command I used for the Lucid ami-ab4d67df . Replace the XXXXX with your unique information and change the size (30) immediately after the snap-xxxxxxx: again reflect the size of your own snapshot or a number bigger than your snapshot. If you specify a number smaller than the your snapshot, register AMI will fail.


ec2-register --kernel aki-cb4d67bf --region xx-xxxx-x '--description=Ubuntu 10 Lucid formatted with XFS' --name=ubuntu-10.4-64-bit-ami-ab4d67df-xfs --architecture x86_64 --root-device-name /dev/sda1 -b /dev/sda1=snap-xxxxxxx:30:false --block-device-mapping /dev/sdb=ephemeral0:false --block-device-mapping /dev/sdc=ephemeral1:false


/dev/sda2 /mnt auto defaults,comment=cloudconfig 0 0
/dev/sda3 /mnt auto defaults,comment=cloudconfig 0 0

With this, the following works very well for EBS booted 64 bit Lucid image ami-ab4d67df.
Please substitute where I have XXXXX.


ec2-register --snapshot snap-XXXXXXXX --kernel aki-cb4d67bf --region XXXXXX '--description=Ubuntu 10 Lucid formatted with XFS' --name=ubuntu-10.4-64-bit-ami-ab4d67df-xfs --architecture x86_64 --root-device-name /dev/sda1 --block-device-mapping /dev/sda2=ephemeral0 --block-device-mapping /dev/sda3=ephemeral1


Many thanks and much appreciated.

Using the Lucid EBS boot ami-ab4d67df (the latest 64bit from Canonical) and copying Shlomo´s directions exactly, I still get the issue with ssh and connection is refused. As a second step, I added the extra block device sda3 as shown in Michael´s hint.

This was my code to register the AMI


ec2-register --snapshot snap-90b07bf9 --kernel aki-cb4d67bf --region eu-west-1 '--description=Ubuntu 10 Lucid formatted with XFS' --name=ubuntu-10.4-64-bit-ami-ab4d67df-xfs --architecture x86_64 --root-device-name /dev/sda1 --block-device-mapping /dev/sda2=ephemeral0 --block-device-mapping /dev/sda3=ephemeral1


Note that I had to add the region as well as my instances are in eu-west. There was no issue with the AMI (ami-43103a37 – its private, not sure how to make it public!).

I attached an Elastic IP to the running instance and attempted to connect.

Here is the output from my terminal:


ssh -i /Users/aruna/mykeys/mysecurity ubuntu@79.xxx.xxx.xxx
ssh: connect to host 79.xxx.xxx.xxx port 22: Connection refused


Here is the final lines from the console


[ 1.523075] Filesystem "sda1": Disabling barriers, trial barrier write failed
[ 1.569026] XFS mounting filesystem sda1
[ 1.845787] VFS: Mounted root (xfs filesystem) readonly on device 8:1.
[ 1.846784] devtmpfs: mounted
[ 1.846899] Freeing unused kernel memory: 228k freed
[ 1.847008] Write protecting the kernel read-only data: 6416k
init: console-setup main process (81) terminated with status 1
%Ginit: plymouth main process (63) killed by SEGV signal
init: plymouth-splash main process (233) terminated with status 2
Generating locales...
en_GB.UTF-8... up-to-date
Generation complete.
mountall: Disconnected from Plymouth


These two lines indicate that its mounted on an xfs volume (Hurrah!) but is yet read-only

1.569026] XFS mounting filesystem sda1
1.845787] VFS: Mounted root (xfs filesystem) readonly on device 8:1.


I have refreshed the console a few times to see whether it would change status – no luck. Also rebooted the instance – same status.
What am I doing wrong here…
Grateful for any leads!

Unfortunately I haven’t put together all the scripts to make those techniques easy. I will, but I can’t be sure when – unless I find a sponsor for the work.

cheers,

-H

Thanks for your encouraging words.

The good Eric Hammond has you covered. Here’s his article about resizing a root volume before the AMI is launched, and here’s his article about resizing the root volume of an already-running instance.