virsh adds automatically type='raw' to a disk session

[nerling]

Please report to https://bugzilla.redhat.com/show_bug.cgi?id=659262 for more information.
This Bug has a patch as in:
http://www.redhat.com/archives/libvir-list/2010-December/msg00103.html

Description of problem:
If you do not specify the type of the disk in the <driver> subelement of domain
xml, virsh automatically inserts type raw, without testing for the real type of
the image.

Version-Release number of selected component (if applicable):
virsh 0.8.3
( Debian-backports 0.8.3-4~bpo50+1 )

How reproducible:
Everytime

Steps to Reproduce:
1.
Create a domain from a xml which disks have no <driver> element:
(SNIP /tmp/one-7050.xml)
<disk type='file' device='disk'>
    <source file='/var/lib/one/7035/images/disk.0'/>
    <target dev='hda'/>
    <model type='virtio'/>
</disk>
(SNIP)
$ onevm create /tmp/one-7035.xml
2.
Dump the xml of the domain:
$ onevm dumpxml one-7035
(SNIP)
  <disk type='file' device='disk'>
      <driver name='qemu' type='raw'/>
      <source file='/var/lib/one/host1/images/disk.0'/>
      <target dev='hda' bus='ide'/>
      <alias name='ide0-0-0'/>
      <address type='drive' controller='0' bus='0' unit='0'/>
    </disk>
(SNIP)

Actual results:
<driver name='qemu' type='raw'/>
AND domain cannot boot from the disk
Expected results:
<driver name='qemu' type='qcow2'/> # or nothing at all
AND domain would boot as a charm.
Additional info:
This would be not a problem by manual generation of the domain xml file, since
we could simply insert it.
The problem will treat bad if we have a VMM generating this xml automatically..
as it is our fall, as we are using opennebula for this.

[James Page (james-page)]

This behavior changed in 0.8.3; automatic probing of disk formats is considered a security vulnerability and is disabled by default.

It can be re-enabled manually or you can add the required driver element into your domain xml files - see bug 656173 for more details.

[James Page (james-page)]

Please could you confirm which version of Ubuntu you are experiencing this issue on and which versions of libvirt and qemu you are running.

Thanks

[James Page (james-page)]

We'd like to figure out what's causing this bug for you, but we haven't heard back from you in a while. Could you please provide the requested information? Thanks!

[nerling (nerling)]

Version: Maverick.
ii kvm 1:84+dfsg-0ubuntu16+0.12.5+noroms+0ubuntu7.1
ii kvm-pxe 5.4.4-7ubuntu2 PXE ROM's for KVM
ii libvirt-bin 0.8.3-1ubuntu14 the programs for the libvirt library
ii libvirt0 0.8.3-1ubuntu14 library for interfacing with different virtualization systems
ii libvirtodbc0 6.1.2+dfsg1-1ubuntu4 high-performance database - ODBC libraries
ii qemu-common 0.12.5+noroms-0ubuntu7.1 qemu common functionality (bios, documentation, etc)
ii qemu-kvm 0.12.5+noroms-0ubuntu7.1 Full virtualization on i386 and amd64 hardware
ii qemu-kvm-extras 0.12.5+noroms-0ubuntu7.1 fast processor emulator binaries for non-x86 architectures

[James Page (james-page)]

Thanks for the information you provided in you last update.

The behavior you describe is the default behavior for libvirt/qemu on Maverick. Disk probing is disabled by default so libvirt will not attempt to determine what format the underlying disk is actually in and defaults to raw (I've had this issue myself). This can be re-enabled (see allow_disk_format_probing in /etc/libvirt/qemu.conf) but disk probing is considered a potential security vulnerability so I would not recommend this course of action.

Its a little unclear from the original bug report as to why you cannot specify the driver for the disk in the definition for the virtual machine using the following line:

    <driver name='qemu' type='raw'/>

Are you using opennebula to generate the virtual machine definitions? In which case we may need to re-assign this bug to that package.

Thanks again for helping to make Ubuntu better.

[nerling (nerling)]

Hallo James
No, I do not generate the definition of the vm by myself, I use opennebula (version 2.0.1, but versions 1.2 or 1.4 would be affected, too)
Opennebula allows to define the format after the version 2.0.1-1, so it is no longe a big concern.
I had configured allow_disk_format_probing in the hosts /etc/libvirt/qemu.conf, since I have read the supposicions of security vulnerability and could not agree with it.

I think we can close this as bug, but let it open as sugestion.

Thank you very much and best regards.

[James Page (james-page)]

This should not impact natty (2.0.1) but should impact lucid and maverick which both ship version 1.2.

[Jamie Strandboge (jdstrand)]

This seems to be:
http://dev.opennebula.org/issues/465

[nerling (nerling)]

Yes, it is it.