[libvirt] [PATCH v6 02/13] qemu: Detect support for vxhs

Peter Krempa pkrempa at redhat.com
Mon Sep 11 11:44:30 UTC 2017


On Fri, Sep 01, 2017 at 11:36:14 -0400, Jeff Cody wrote:
> On Fri, Sep 01, 2017 at 10:20:43AM +0200, Peter Krempa wrote:
> > On Thu, Aug 31, 2017 at 12:59:59 -0400, John Ferlan wrote:
> > > On 08/31/2017 11:34 AM, Peter Krempa wrote:

[...]

> > I agree. We can keep this and I'll ask whether qemu can't do something
> > about that.
> > 
> > I only want to make sure, that the capability stuff is not dragged into
> > the json struct generator.
> 
> I take it the issue with introspection is that the BlockdevDriver enum in
> the QEMU QAPI includes all driver formats, regardless of whether they were
> enabled or not?  If so, I guess this is an issue for other protocol formats
> (e.g. gluster) as well.
> 
> Marc-André's  "qapi: add 'if' condition on top-level schema elements" series
> for QEMU may provide a way to fix this, but of course that wouldn't be until
> at least QEMU 2.11.

That will be cool. The only limitation is that we can't use that to
reject the config until that lands. We could do some trickery to clear
the capabilities though, once qemu 2.11 lands and add them for all older
ones even if it's not supported.

> 
> A bit hacky, but if needed in the interim, libvirt could parse 'qemu-img
> --help', in particular the "Supported formats:" line:
> 
> With vxhs enabled:
> Supported formats: [...] sheepdog ssh vdi vhdx vmdk vpc vvfat vxhs
> 
> Without vxhs enabled:
> Supported formats: [...] sheepdog ssh vdi vhdx vmdk vpc vvfat
> 
> 
> (as I said, a bit hacky...)

Hacky and wrong. You can't guarantee that qemu-img was compiled with the
same options as the qemu binary provided in the <emulator> tag in the
domain XML, and thus we can't infer the support matrix of the qemu
binary from it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20170911/2516820c/attachment-0001.sig>


More information about the libvir-list mailing list