x86_64 images should be presented a /dev/sdb, not a /dev/sda2

I can confirm this.

fstab says /dev/sdb.

But I do have /dev/sda2.

I am able to mount /dev/sda2, but it is formatted ext2.

The kvm command line on the node is:

root 9680 1 0 Oct20 ? 00:07:53 /usr/bin/kvm -S -M pc-0.11 -m 256 -smp 1 -name i-39AE0679 -uuid 8f8c4f4c-bbdb-e95a-c886-b1236ea307c1 -nographic -monitor unix:/var/run/libvirt/qemu/i-39AE0679.monitor,server,nowait -boot c -kernel /var/lib/eucalyptus/instances/admin/i-39AE0679/kernel -initrd /var/lib/eucalyptus/instances/admin/i-39AE0679/ramdisk -append root=/dev/sda1 console=ttyS0 -drive file=/var/lib/eucalyptus/instances/admin/i-39AE0679/disk,if=scsi,index=0,boot=on -net nic,macaddr=d0:0d:39:ae:06:79,vlan=0,model=e1000,name=e1000.0 -net tap,fd=17,vlan=0,name=tap.0 -serial file:/var/lib/eucalyptus/instances/admin/i-39AE0679/console.log -parallel none -usb

:-Dustin

Fixing bug 458850 is needed to work around this issue in the instance itself.

Just for informational purposes, the way that bug 458850 was fixed, if updates are done to Eucalyptus such that ephemeral storage is on /dev/sdb instead of /dev/sda2 ec2-init should correctly adjust.

fwiw this problem seems to happen with both the x86_64 and i386 images in the imagestore (oddly, the i386 one seems to be listed as x86_64 in euca-describe-images).

Lowering priority since ec2-init works around this bug for Lucid for now. The issue is still present, though not trivially solved. Might be deferred until Lucid+1, unless a contained fix can be found.

Disagree on priority - that assumes that only ubuntu karmic (or later) images will ever be used, and breaks compatibility with every other ec2-compatible image out there. (And not breaks like "annoyingly the hostname is 172 & everything works fine", but actual "firstboot scripts will fail, dogs and cats living together, twinkie 35 feet long" broken.)

This is really on the (we do our best to keep it)short-list of steps that one currently needs to perform in order to migrate images (to and from). Remember that images which are configured to run on xen will almost surely need some minor modifications (...kernel modules?) in order to boot properly in KVM (which, as you know, Eucalyptus uses on Ubuntu). As kirkland points out, this is not a trivial issue to resolve, but it is surely on the list of semantic differences that we hope to mitigate as soon as we can.

I'll point out, that at least in the lucid version of eucalyptus, there is valid data stating where the ephemeral storage is in the metadata service. So, if the image is set to query metadata service for the ephemeral device, then this will work properly.

I know, its a layer of indirection, but it does work. bug 513842 has more info (and an issue with that block-device-mapping that is provided).

This issue is now being tracked upstream at http://eucalyptus.atlassian.net/browse/EUCA-2667

Please watch that issue for further updates.