[libvirt] virsh capabilities vs. domcapabilities

[Eric Blake]

On 07/17/2014 03:05 AM, Michal Privoznik wrote:

>> Furthermore, I'm trying to figure out how to advertise whether a given
>> domain will support active commit (and similarly, Peter's patches for
>> relative backing name preservation).  Advertising the feature just
>> through 'virsh capabilities' is insufficient, because that only covers
>> the default binary; so it seems like the sort of thing that should also
>> be in 'virsh domcapabilities'.
> 
> That depends on how's active commit accepted by libvirt. IIUC it's a
> flag to an API. (Okay, you got me there, I'm not paying much attention
> to snapshot work).

You use a flag to trigger it for now (although there is a proposal to
eventually allow active commit without a flag); but the main point is
that people want to know up front if the flag even stands a chance of
working, which depends on the abilities of the qemu binary.

> 
> The best solution would be to introduce another section, where supported
> flags to APIs would be enumerated (same way that attribute values are).
> But this is sooo much more work than in attribute part (esp. without
> introspection) that the resulting code would be unmaintainable.
> 

A list of supported flags may be too hard, compared to just a list of
feature names.

>> I'm also finding 'virsh domcapabilities' a bit hard to use - even though
>> it allows all its arguments to be optional at the RPC level, the qemu
>> implementation isn't so happy:
>>
>> # tools/virsh domcapabilities
>> error: failed to get emulator capabilities
>> error: virttype_str in qemuConnectGetDomainCapabilities must not be NULL
>>
>> but how am I supposed to know what --virttype strings are valid?
> 
> By reading the documentation :P
> From the virsh manpage:
> 
> The virttype option specifies the virtualization type used. The value to
> be used is either from the 'type' attribute of the <domain/> top level
> element from the domain XML or the 'type' attribute found within each
> <guest/> element from the virsh capabilities output.

You know, I can think of a couple of UI additions that would make this
command really cool:

- virsh domcapabilities --domain $dom
uses the same name, uuid, or id as all other domain lookups, then calls
dumpxml on that domain, scrapes the <domain> XML, and uses the
parameters it found to pass to the virConnectGetDomainCapabilities call

- virsh domcapabilities --xml $file
takes $file which contains either <domain> or <guest> XML (no ambiguity,
because the top level element says which style), scrapes it for the
right parameters, and passes those parameters (or NULL for missing
parameters) to virConnectGetDomainCapabilities

Remember, it is possible to define a <domain> with the user input XML
not listing an <emulator>, where a later dumpxml will show the default
emulator that got chosen.  So the same idea applies to the virsh command
- if the user supplies a <domain> XML file without an explicit
<emulator>, then we use NULL for that parameter to
virConnectGetDomainCapabilities, and we should get results for the
default emulator that will be used to run that domain.

Also, by allowing <guest> XML (as a subset of overall 'virsh
capabilities') as the input, it is possible to easily transition from
the old API (tell me what emulator(s) will be used) to the new (tell me
what features/drivers I can use with that emulator).

> 
> I know virsh user is user unfriendly, but I think this could be solved
> by wise auto completion (if I find another student to complete it). Or
> if you have any idea meanwhile ...

There's a pending patch series (now several months old) that improves
some auto completion; I need to find time to review and revive it.


>>
>> /guest/arch/emulator vs. /domainCapabilities/path - why 3 levels vs. 2,
>> and different naming?
> 
> This is something provided by callee, so in fact it has no additional
> value.

Not true.  If you take my argument above about allowing NULL emulator to
mean "tell me the default emulator and its capabilities", then this
output parameter is essential in that case.

> 
>>
>> /guest/arch/machine at maxCpus vs. /domainCapabilities/vcpu at max - why 3
>> levels vs. 2, with different naming?
> 
> Because we may want to extend <vcpu/> fom domaincaps in the future.

Okay, so we are intentionally breaking design from the old XML, and
clients cannot share XPath code between the old style and new style.  I
can live with that; although it might be worth some documentation on the
old API how to find the same information in the new.  Maybe as simple as
just documenting all the mappings that I already identified in this
mail.  I know - patches welcome :)

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 604 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20140717/fdd17f07/attachment-0001.sig>