cloud-init does not mount ephemeral0 on /mnt in nova

So far nova lied. It is fixed by nova revision of 1400 in the repository.
Here is the example
ubuntu@ubuntu:~$ cat /proc/partitions
major minor #blocks name

 252 0 10485760 vda
 252 16 20971520 vdb
 252 32 1048576 vdc

ubuntu@ubuntu:~$ python -c 'import boto.utils; print boto.utils.get_instance_metadata()["block-device-mapping"]'
{'ami': 'vda', 'root': '/dev/vda', 'ephemeral0': '/dev/vdd'}

@Scott, could you confirm the fix ?

Just from reading comment 2, the issue is clearly not fixed correctly.

/proc/partitions shows vda, vdb, and vdc, but the block-device-mapping shows ephemeral0 mapped to vdd.

On Mon, Aug 22, 2011 at 01:42:08PM -0000, Scott Moser wrote:
> Just from reading comment 2, the issue is clearly not fixed correctly.
>
> /proc/partitions shows vda, vdb, and vdc, but the block-device-mapping
> shows ephemeral0 mapped to vdd.

Yes, you're right.
The create kvm command line that libvirt created and the created xml for
the guest is as follows. You can see that those target device is specified
correctly in the xml, but the mapping information is lost in the command line.
libvirt doesn't have any way to force the guest to use the setting in
qemu-kvm case because qemu-kvm creates pci devices for each virtio-disk
and the guests understands it sequentially from 'a'. In order to fix it,
we need to pass those mapping information to guest from nova somehow and
teach OS initialization sequence (cloud-init?/udev?) the mapping.

The command line to launch kvm guest.

/usr/bin/kvm -S -M pc-0.14 -enable-kvm -m 512 -smp 1,sockets=1,cores=1,threads=1 -name instance-000000e4 -uuid 8882f5d5-d448-29e3-e124-6739e6fd22d6 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/instance-000000e4.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=readline -rtc base=utc -boot c -kernel /var/lib/nova/instances/instance-000000e4/kernel -append root=/dev/vda console=ttyS0 -drive file=/var/lib/nova/instances/instance-000000e4/disk,if=none,id=drive-virtio-disk0,format=qcow2 -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0 -drive file=/var/lib/nova/instances/instance-000000e4/disk.eph0,if=none,id=drive-virtio-disk3, format=qcow2 -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk3, id=virtio-disk3 -drive file=/dev/mapper/nova--volumes-volume--00000040,if=none,id=drive-virtio-disk2,format=raw -device virtio-blk-pci,bus=pci.0,addr=0x6,drive=drive-virtio-disk2,id=virtio-disk2 -netdev tap,fd=18,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=02:16:3e:1e:ff:c0,bus=pci.0,addr=0x3 -chardev file, id=charserial0,path=/var/lib/nova/instances/instance-000000e4/console.log -device isa-serial,chardev=charserial0,id=serial0 -chardev pty,id=charserial1 -device isa-serial,chardev=charserial1,id=serial1 -usb -vnc 0.0.0.0:0 -k en-us -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7

the create xml for the guest
<domain type='kvm'>
    <name>instance-000000e4</name>
    <memory>524288</memory>
    <os>
            <type>hvm</type>
            <kernel>/var/lib/nova/instances/instance-000000e4/kernel</kernel>
                <cmdline>root=/dev/vda console=ttyS0</cmdline>
    </os>
    <features>
        <acpi/>
    </features>
    <vcpu>1</vcpu>
    <devices>
        <disk type='file'>
            <driver type='qcow2'/>
            <source file='/var/lib/nova/instances/instance-000000e4/disk'/>
            <target dev='vda' bus='virtio'/>
        </disk>
             <disk type='block'>
                <driver type='qcow2'/>
                <source dev='/var/lib/nova/instances/instance-000000e4/disk.eph0
'/>
                <target dev='vdd' bus='virtio'/>
             </disk>
            <disk type='block'>
                <driver type='raw'/>
                <...

I understand that actually mapping a device name from hypervisor to guest is actually impossible, but hopefully we can come up with a better guess.

Its unfortunate that libvirt doesn't even seem to be using the "dev=" as a suggestion of device ordering along the virtio bus. Instead, I'm guessing it is using order present in xml. I was hoping at very least that suggesting 'vda', 'vdb', 'vdc' would render in kvm command line to addr=0x4, addr=0x5, addr=0x6 respectively.

Since libvirt seems to be relying on order in the xml, is it possible to specify the "correct" order and also sane "dev=" attributes?

Ie, what would happen if you had xml like:

| <disk type='file'>
| <driver type='qcow2'/>
| <source file='/var/lib/nova/instances/instance-000000e4/disk'/>
| <target dev='vda' bus='virtio'/>
| </disk>
| <disk type='block'>
| <driver type='qcow2'/>
| <source dev='/var/lib/nova/instances/instance-000000e4/disk.eph0 '/>
| <target dev='vdb' bus='virtio'/>
| </disk>
| <disk type='block'>
| <driver type='raw'/>
| <source dev='/dev/mapper/nova--volumes-volume--00000040'/>
| <target dev='vdc' bus='virtio'/>
| </disk>

And then specified block device mapping like:
{
 'ami': 'vda',
 'root': '/dev/vda',
 'ephemeral0': '/dev/vdb'
 'vol0': '/dev/vdc'
}

Again, I understand, you can't force the guest to name devices in any way, but hopefully we can at least map "vda" to "first device on virtio bus", and "vdb" to "second disk on virtio bus".

With Isaku's branch this is fixed with no cloud-init changes, so I've marked those tasks as invalid.

let's do a backport for diablo

Tracked in Github Issues as https://github.com/canonical/cloud-init/issues/2198