[libvirt] [PATCH v6 02/13] qemu: Detect support for vxhs
Using the query-qmp-schema introspection - look for the 'vxhs'
blockdevOptions type
Signed-off-by: John Ferlan
---
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
@@ -439,6 +439,9 @@ VIR_ENUM_IMPL(virQEMUCaps, QEMU_CAPS_LAST,
"virtio-net.tx_queue_size",
"chardev-reconnect",
"virtio-gpu.max_outputs",
+
+ /* 270 */
+ "vxhs",
);
@@ -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},
};
struct virQEMUCapsObjectTypeProps {
diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h
index f32687d..f512775 100644
--- a/src/qemu/qemu_capabilities.h
+++ b/src/qemu/qemu_capabilities.h
@@ -426,6 +426,9 @@ typedef enum {
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;
diff --git a/tests/qemucapabilitiesdata/caps_2.10.0.x86_64.xml
b/tests/qemucapabilitiesdata/caps_2.10.0.x86_64.xml
index ca0a146..057ce27 100644
--- a/tests/qemucapabilitiesdata/caps_2.10.0.x86_64.xml
+++ b/tests/qemucapabilitiesdata/caps_2.10.0.x86_64.xml
@@ -215,6 +215,7 @@
+
2009094
0
(v2.10.0-rc4-dirty)
--
2.9.5
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH v6 02/13] qemu: Detect support for vxhs
Using the query-qmp-schema introspection - look for the 'vxhs'
blockdevOptions type
Signed-off-by: John Ferlan
---
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
@@ -439,6 +439,9 @@ VIR_ENUM_IMPL(virQEMUCaps, QEMU_CAPS_LAST,
"virtio-net.tx_queue_size",
"chardev-reconnect",
"virtio-gpu.max_outputs",
+
+ /* 270 */
+ "vxhs",
);
@@ -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},
};
struct virQEMUCapsObjectTypeProps {
diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h
index f32687d..f512775 100644
--- a/src/qemu/qemu_capabilities.h
+++ b/src/qemu/qemu_capabilities.h
@@ -426,6 +426,9 @@ typedef enum {
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;
diff --git a/tests/qemucapabilitiesdata/caps_2.10.0.x86_64.xml
b/tests/qemucapabilitiesdata/caps_2.10.0.x86_64.xml
index ca0a146..057ce27 100644
--- a/tests/qemucapabilitiesdata/caps_2.10.0.x86_64.xml
+++ b/tests/qemucapabilitiesdata/caps_2.10.0.x86_64.xml
@@ -215,6 +215,7 @@
+
2009094
0
(v2.10.0-rc4-dirty)
--
2.9.5
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v6 02/13] qemu: Detect support for vxhs
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 > --- ACK signature.asc Description: PGP signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v6 02/13] qemu: Detect support for vxhs
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
> ---
>
> 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.
signature.asc
Description: PGP signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
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
>> ---
>>
>> 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
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
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.
signature.asc
Description: PGP signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v6 02/13] qemu: Detect support for vxhs
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@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v6 02/13] qemu: Detect support for vxhs
On Fri, Sep 01, 2017 at 11:36:14 -0400, Jeff Cody wrote: > 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: [...] > > 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. That will be cool. The only limitation is that we can't use that to reject the config until that lands. We could do some trickery to clear the capabilities though, once qemu 2.11 lands and add them for all older ones even if it's not supported. > > 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...) Hacky and wrong. You can't guarantee that qemu-img was compiled with the same options as the qemu binary provided in the tag in the domain XML, and thus we can't infer the support matrix of the qemu binary from it. signature.asc Description: PGP signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
