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