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.