[libvirt] [PATCH] libvirt no longer supports qemu format=host_device
jamie at canonical.com
Mon Nov 8 18:08:26 UTC 2010
On Mon, 2010-11-08 at 10:02 +0000, Daniel P. Berrange wrote:
> On Fri, Nov 05, 2010 at 02:04:50PM -0500, Jamie Strandboge wrote:>
> > This is confirmed as not working on 0.8.3 and 0.8.5. The attached patch
> > against 0.8.5 fixes the issue and restores host_device support.
> host_device is not a data format type, but rather a qemu driver protocol.
> As such it is not applicable for the <driver type=XXX> field, because
> the protocol is already specified at the <disk> element level with
> a combo of the type+device fields. If it happened to be possible to
> set it in the <driver> field that is just pure chance & not something
> that is supported. If we need to setup host_device anywhere, then this
> needs to be dealt with at the qemu_conf.c where we generate the CLI
Hmm... that is not clear in the documention IMHO (and the patch was
careful to only use this for the qemu driver). Eg from the qemu-img man
"Supported image file formats:
Ie, the language in the qemu-img man page has 'host_device' at the same
level as 'raw', 'qcow2', 'cow', etc as a 'file format'.
http://libvirt.org/formatdomain.html#elementsDisks only talks about a
'sub-type' for the qemu driver (but it is easy to infer that it is
looking at the qemu-img types after using libvirt for a while) and
http://libvirt.org/storage.html does not list 'host_device' as a 'format
type', but it does list all of the other ones from the same section of
the qemu-img man page (except 'vdi', which is maybe an omission in the
libvirt docs?). Finally, 'man virsh' does list 'host_device' as a 'file
format' in its 'vol-create-as' command.
By all means if this needs to be cleaned up in qemu_conf.c that seems
fine, but until then I feel that either host_device should be supported
again (preferred based on the qemu-img man page) or the documentation
made more consistent, and something probably added in
http://libvirt.org/news.html for people upgrading to 0.8.3 or later
since libvirt users are hitting this.
Jamie Strandboge | http://www.canonical.com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: This is a digitally signed message part
More information about the libvir-list