[libvirt PATCH] docs: virConnectGetCapabilities do not provide pool types

[John Ferlan]

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
>