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@maxCpus vs. /domainCapabilities/vcpu@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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list