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

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




On 08/31/2017 11:34 AM, Peter Krempa wrote:
> On Wed, Aug 30, 2017 at 18:46:02 -0400, John Ferlan wrote:
>> Using the query-qmp-schema introspection - look for the 'vxhs'
>> blockdevOptions type
>>
>> Signed-off-by: John Ferlan <jferlan redhat com>
>> ---
>>
>>  This is new from v5, this is the way I figured out in order to
>>  use the query-qmp-schema in order to determine if 'vxhs' was
>>  possible. It sets the libvirt capability.
>>
>>  src/qemu/qemu_capabilities.c                      | 4 ++++
>>  src/qemu/qemu_capabilities.h                      | 3 +++
>>  tests/qemucapabilitiesdata/caps_2.10.0.x86_64.xml | 1 +
>>  3 files changed, 8 insertions(+)
>>
>> diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
>> index e7ea6f4..173bcf3 100644
>> --- a/src/qemu/qemu_capabilities.c
>> +++ b/src/qemu/qemu_capabilities.c
> 
> [...]
> 
>> @@ -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.

John


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