Re: [libvirt PATCH] docs: virConnectGetCapabilities do not provide pool types
On 7/21/20 10:14 AM, Daniel P. Berrangé wrote:
On Tue, Jul 21, 2020 at 08:46:55AM -0400, John Ferlan wrote:
>
> Upon further reflection and some memory jiggling...
>
> virsh -c storage:///system capabilities
> <capabilities>
>
> <pool>
> <enum name='type'>
> <value>dir</value>
> <value>fs</value>
> <value>netfs</value>
> <value>logical</value>
> <value>iscsi</value>
> <value>iscsi-direct</value>
> <value>scsi</value>
> <value>mpath</value>
> <value>disk</value>
> <value>rbd</value>
> <value>sheepdog</value>
> <value>gluster</value>
> <value>zfs</value>
> </enum>
> </pool>
>
> </capabilities>
>
> But yeah, without the -c storage:///system one won't see the results
> because 'npools == 0' when virCapabilitiesFormatStoragePoolXML is called
> from virCapabilitiesFormatXML unless it's the storage driver URI.
Err, don't you mean "virsh pool-capabilities".
pool-capabilities takes a different path ending in
virStoragePoolCapsFormat as opposed to capabilities which ends up in
virCapabilitiesFormatXML
The "capabilities" command is exclusively for the virt
driver usage,
not storage.
# virsh version
Compiled against library: libvirt 6.6.0
Using library: libvirt 6.6.0
Using API: QEMU 6.6.0
Running hypervisor: QEMU 5.0.50
# virsh -c storage:///system capabilities
[as above]
This work is/was done Jan/Feb 2019 - Perhaps I'm only getting asked
(again) about it now as a result of some downstream documenting :-/. Far
too long ago for me to recall why both options were done.
But separable enough in commit 05fe03505a to be undone.
John
In the new modular daemon work, "capabilities" API will never be
sent to the storage daemon.
Regards,
Daniel