nova writes libvirt xml 'driver_type' based only on FLAGS.use_cow_images

[Scott Moser]

This is just from reading code, so I could be wrong.
However, in _prepare_xml_info() of nova/virt/libvirt/connection.py you have:
        if FLAGS.use_cow_images:
            driver_type = 'qcow2'
        else:
            driver_type = 'raw'

It seems that that will be wrong in the case that the image uploaded is qcow2.

_cache_image will have done a 'cp' of the original image, and thus the image will still be in qcow format.

I've not verified whether or not libvirt/kvm care, or if this is only grammatical.

[Vish Ishaya (vishvananda)]

This is true, however uploading a qcow2 works fine so I assume that libvirt is smart enough to load it correctly anyway.

[Scott Moser (smoser)]

On Tue, 30 Aug 2011, Vish Ishaya wrote:

> This is true, however uploading a qcow2 works fine so I assume that
> libvirt is smart enough to load it correctly anyway.

Have you tried uploading a qcow2 without LFAGS.use_cow_images ?

Also, i'm not certain but looking at bug 470636 (comment 18 and 19) it
seems that this will be an issue with libvirt's apparmor support.

Scott

[Vish Ishaya (vishvananda)]

On Aug 30, 2011, at 6:50 AM, Scott Moser wrote:

> Have you tried uploading a qcow2 without LFAGS.use_cow_images ?

No, I haven't tried that, good point.
>
> Also, i'm not certain but looking at bug 470636 (comment 18 and 19) it
> seems that this will be an issue with libvirt's apparmor support.

Yes, we should probably attempt to determine the type of the image and change the xml to match.

>
> Scott
>

[Scott Moser (smoser)]

OK.
  I verified that the following fails
 - $ grep cow bin/nova.conf
   --use_cow_images=false
 - $ wget http://images.ansolabs.com/tty.tgz
 - $ tar -xvzf tty.tgz
 - $ qemu-img convert ami-tty/image -O qcow2 ami-tty/image-qcow.img
 - $ cloud-publish-image x86_64 ami-tty/image-qcow.img demo
 - $ euca-run-instances ami-0000002f --key mykey
 - there is nothing in the console looking at the console , looking at the vnc console, shows 'no bootable device'

What this means is that if you upload a qcow image, but have turned off use_qcow_images (default is on) then your instances will not boot. I would suspect that most "real world" installations will have use_qcow_images=false in flags as the run time path will be faster for raw disk imags than qcow.

I've also verified that I was wrong in suspecting that apparmour would be the issue. Apparmour doesn't affect this because the image booted would never be a qcow backed image (as it would be a copy of the uploaded image since use_qcow_images=false). However, it seems that kvm intelligently respects the argument that is passed to it via libvirt. for reference, that looks Note the 'format=raw' (like):

  -drive file=<path>,if=none,id=drive-virtio-disk0,boot=on,format=raw
  -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0

So, this is a real issue.

[Scott Moser (smoser)]

My test that I did in comment 2 above was wrong, as I did not register a kernel/ramdisk with this image.
I've re-tested with something like:
  cloud-publish-image x86_64 md-raw/image-root.img smdemo-raw \
     --kernel-file md-raw/image-kernel.img --ramdisk-file md-raw/image-ramdisk.img -v
and
  cloud-publish-image x86_64 md/image-root-qcow.img smdemo \
    --kernel-file md/image-kernel.img --ramdisk-file md/image-ramdisk.img -v

using the qcow image, I actually fail with a 'badness occurred in ramdisk' which makes no sense to me, but it failed none the less.