Using the query-qmp-schema introspection - look for the 'vxhs'
blockdevOptions type.
NB: This is a "best effort" type situation as there is not a
mechanism to determine whether the running QEMU has been
built with '--enable-vxhs'. All we can do is check if the
option to use vxhs for a blockdev-add exists in the command
infrastructure which does not take that into account when
building its table of commands and options.
Signed-off-by: John Ferlan <jferlan@redhat.com>
"virtio-net.tx_queue_size",
"chardev-reconnect",
"virtio-gpu.max_outputs",
+
+ /* 270 */
+ "vxhs",
);
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},
};
struct virQEMUCapsObjectTypeProps {
QEMU_CAPS_CHARDEV_RECONNECT, /* -chardev reconnect */
QEMU_CAPS_VIRTIO_GPU_MAX_OUTPUTS, /* -device virtio-(vga|gpu-*),max-outputs= */
+ /* 270 */
+ QEMU_CAPS_VXHS, /* -drive file.driver=vxhs via query-qmp-schema */
+
QEMU_CAPS_LAST /* this must always be the last item */
} virQEMUCapsFlags;
<flag name='virtio-net.tx_queue_size'/>
<flag name='chardev-reconnect'/>
<flag name='virtio-gpu.max_outputs'/>
+ <flag name='vxhs'/>
<version>2010000</version>
<kvmVersion>0</kvmVersion>
<package> (v2.10.0)</package>