[libvirt] Qemu only support VHDx disk format, but libvirt force use VHD format

[Martin Kletzander]

On Wed, Aug 09, 2017 at 04:07:14PM +0000, Komeiji Kuroko wrote:
>Hello all,
>
>I am trying to use a VHDx format disk on libvirt.
>
>According to https://en.wikibooks.org/wiki/QEMU/Images, Qemu supports
>VHDx but not VHD.
>
>But when I set disk format to 'vhdx' in virt-manager, it prompts "Error
>changing VM configuration: Expected a wrapped C Object but got <type
>'NoneType'>"
>
>    Traceback (most recent call last):
>       File "/usr/share/virt-manager/virtManager/addhardware.py", line
>    765, in change_config_helper
>         define_func(devobj=devobj, do_hotplug=False, **define_args)
>       File "/usr/share/virt-manager/virtManager/domain.py", line 847,
>    in define_disk
>         self._redefine_xmlobj(xmlobj)
>       File "/usr/share/virt-manager/virtManager/libvirtobject.py", line
>    389, in _redefine_xmlobj
>         self._define(newxml)
>       File "/usr/share/virt-manager/virtManager/domain.py", line 1156,
>    in _define
>         self.conn.define_domain(newxml)
>       File "/usr/share/virt-manager/virtManager/connection.py", line
>    678, in define_domain
>         return self._backend.defineXML(xml)
>       File "/usr/lib/python2.7/dist-packages/libvirt.py", line 3622, in
>    defineXML
>         __tmp = virDomain(self,_obj=ret)
>       File "/usr/lib/python2.7/dist-packages/libvirt.py", line 453, in
>    __init__
>         raise Exception("Expected a wrapped C Object but got %s" %
>    type(_obj))
>    Exception: Expected a wrapped C Object but got <type 'NoneType'>
>

This ^^ is bug in virt-manager, feel free to report it.

>Then I use `virsh edit MyDOM` to edit my domain XML, change disk format
>to "vhdx" then I get error:
>
>"Unable to validate doc against /usr/share/libvirt/schemas/domain.rng".
>

You can press "i" to ignore the error and skip schema validations.

>So I edit /usr/share/libvirt/schemas/storagecommon.rng, change
>"<value>vhd</value>" to "<value>vhdx</value>" in  <define
>name='storageFormat'>. But it still not works, and virsh tells me
>`error: unsupported configuration: unknown driver format value 'vhdx' `.
>I choice ignore , but then same error and I can't ignore: only Yes to
>re-edit or No to give up.
>

You cannot choose to ignore the error from libvirt, only the validation
can be skipped

>Then I suppose "vhd" in libvirt means "vhdx", so I change disk format to
>"vhd". But then when I run domain, Qemu get error: " Unknown driver
>'vhd' ". It seems libvirt pass "vhd" to Qemu, but Qemu only support "vhdx"
>

No, vhd means VHD.  While it is not supported by QEMU, but it is
supported by libxl and some other drivers.

>At last, I use Qemu paramaters: ` -drive
>file=/Path/To/File.vhdx,format=vhdx,if=none,id=drive-sata0-0-3 `, and it
>works. When I use `-drive format=vhd` , Qemu gives me same error: "
>Unknown driver 'vhd' ".
>

That's because QEMU doesn't support VHD, but does support VHDx

>So I think it maybe a bug that libvirt forcely demand format is "vhd"
>and I find no way to change it, but in same time Qemu only accept format
>"vhdx" as paramater. I try to edit
>`/usr/lib/python2.7/dist-packages/libvirt.py` but I have no idea how to
>modify it. And it seems only changing of storagecommon.rng is not enough.
>
>My libvirt version is 3.6.0 and Qemu version is 2.8.1.
>

The problem is, as written, does not really support VHDx yet.  The
deeper problem is that in order to properly support it, we need to be
able to probe the format and get its size and so on.  And VHDx is not as
simple as other formats and our probing code needs to be modified in
order for us to be able to add that new format.

Patches are welcome! ;)

Martin

>Regards,
>
>Mitori
>
>
>--
>libvir-list mailing list
>libvir-list at redhat.com
>https://www.redhat.com/mailman/listinfo/libvir-list
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20170810/86bf995e/attachment-0001.sig>