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

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

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.