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

Peter Krempa pkrempa at redhat.com
Fri Sep 1 08:20:43 UTC 2017


On Thu, Aug 31, 2017 at 12:59:59 -0400, John Ferlan wrote:
> On 08/31/2017 11:34 AM, Peter Krempa wrote:

[...]

> >> @@ -1811,6 +1814,7 @@ static struct virQEMUCapsStringFlags virQEMUCapsObjectPropsIntelIOMMU[] = {
> >>  static struct virQEMUCapsStringFlags virQEMUCapsQMPSchemaQueries[] = {
> >>      { "blockdev-add/arg-type/options/+gluster/debug-level", QEMU_CAPS_GLUSTER_DEBUG_LEVEL},
> >>      { "blockdev-add/arg-type/+gluster/debug", QEMU_CAPS_GLUSTER_DEBUG_LEVEL},
> >> +    { "blockdev-add/arg-type/+vxhs", QEMU_CAPS_VXHS},
> > 
> > I've just noticed that this is reported by qemu even if it isn't built
> > with libvxhs, thus this is not a 100% proof that qemu in fact supports
> > such volumes.
> > 
> > So with this you still might get a failure from qemu even if libvirt
> > thinks that it's supported. For other storage protocols we don't really
> > have capabilities. I'm not sure whether it's worth adding it. It will
> > catch that your qemu is too old, but won't if it has the feature
> > disabled.
> > 
> 
> Well it's essentially in reaction to your review from v4:
> 
> https://www.redhat.com/archives/libvir-list/2017-June/msg01389.html
> 
> so the reality is there's not way to tell at all. All we can do is
> "hope" that someone successfully built qemu w/ --enable-vxhs. As seen
> from qemu commit id 'da92c3ff6'.

Yep. I think it makes sense to keep it in the end.

> 
> Kind of makes introspection a bit useless seeing as I assume it's keyed
> off the qapi/block-core.json file and furthermore that it cannot be
> built based on whether or not --enable-vxhs was successful. Thus the
> only way to really know is to run and fail. Seems like a qemu problem to
> me ;-)!  We tried at least.

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.
-------------- 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/20170901/f82c60c9/attachment-0001.sig>


More information about the libvir-list mailing list