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

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.