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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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:
> 
> [...]
> 
> > >> @@ -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.

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.

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...)

-Jeff

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]
  Powered by Linux