Re: [libvirt] virsh capabilities vs. domcapabilities
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 top level > element from the domain XML or the 'type' attribute found within each > 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 XML, and uses the parameters it found to pass to the virConnectGetDomainCapabilities call - virsh domcapabilities --xml $file takes $file which contains either or 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 with the user input XML not listing an , 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 XML file without an explicit , 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 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 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 signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] virsh capabilities vs. domcapabilities
On 17.07.2014 11:11, Daniel P. Berrange wrote: On Thu, Jul 17, 2014 at 11:05:08AM +0200, Michal Privoznik wrote: # tools/virsh domcapabilities --virttype kvm error: failed to get emulator capabilities error: invalid argument: at least one of emulatorbin or architecture fields must be present Would it be nicer to behave the same as 'virsh capabilities' and give the details of the default binary in this case? Sure, but in order to get default binary we must know architecture (consider the case where you have both /usr/bin/qemu-system-x86_64 and /usr/bin/qemu-system-i686). Although, having only one qemu binary on the system makes it easy to find the default, doesn't it? Patch on the way. IMHO it would be preferrable to always default to virArchFromHost() if arch is none, since that gives a predictable default value, as opposed to probing emulators which is unpredictable Yep, that's exactly what I've done in my patch: https://www.redhat.com/archives/libvir-list/2014-July/msg00884.html Michal -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] virsh capabilities vs. domcapabilities
On Thu, Jul 17, 2014 at 11:05:08AM +0200, Michal Privoznik wrote: > ># tools/virsh domcapabilities --virttype kvm > >error: failed to get emulator capabilities > >error: invalid argument: at least one of emulatorbin or architecture > >fields must be present > > > >Would it be nicer to behave the same as 'virsh capabilities' and give > >the details of the default binary in this case? > > Sure, but in order to get default binary we must know architecture (consider > the case where you have both /usr/bin/qemu-system-x86_64 and > /usr/bin/qemu-system-i686). Although, having only one qemu binary on the > system makes it easy to find the default, doesn't it? Patch on the way. IMHO it would be preferrable to always default to virArchFromHost() if arch is none, since that gives a predictable default value, as opposed to probing emulators which is unpredictable Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] virsh capabilities vs. domcapabilities
On 16.07.2014 21:00, Eric Blake wrote:
We have some inconsistencies in the node capabilities (which shows guest
capabilities for some default binaries) and domcapabilities (which shows
guest capabilities for a specified binary). It might be nicer for
client applications if the two XML components share a common schema and
output layout, so that the same client code can be used to parse either
(sub-tree of) XML, modulo the name of the top-most element containing
the tree.
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).
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.
So my suggestion is to come up with yet another section and put
arbitrary strings there to represent features like active commit. For
instance:
...
active-commit
{some ordinary commit}
Since virConnectGetDomainCapabilities is brand new to 1.2.7, we still
have time to change its XML. But I want consensus on whether we need
things to match, or whether we intentionally want people to rely only on
the newer XML format of the new API call (that is, don't bloat 'virsh
capabilities'/virConnectGetCapabilities any further, and learning
whether active commit is supported will have to be done via 'virsh
domcapabilities'/virConnectGetDomainCapabilities). That is, I'm
wondering if should use / as
its starting point, rather than completely inventing new XML.
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 top level
element from the domain XML or the 'type' attribute found within each
element from the virsh capabilities output.
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 ...
# tools/virsh domcapabilities --virttype kvm
error: failed to get emulator capabilities
error: invalid argument: at least one of emulatorbin or architecture
fields must be present
Would it be nicer to behave the same as 'virsh capabilities' and give
the details of the default binary in this case?
Sure, but in order to get default binary we must know architecture
(consider the case where you have both /usr/bin/qemu-system-x86_64 and
/usr/bin/qemu-system-i686). Although, having only one qemu binary on the
system makes it easy to find the default, doesn't it? Patch on the way.
Now, for a comparison between the two XML per binary:
'virsh capabilities' gives me this segment:
hvm
64
/usr/bin/qemu-system-alpha
clipper
while 'virsh domcapabilities --emulatorbin /usr/bin/qemu-system-alpha
--virttype kvm' gives this:
/usr/bin/qemu-system-alpha
kvm
clipper
alpha
disk
cdrom
floppy
lun
ide
fdc
scsi
virtio
usb
subsystem
default
mandatory
requisite
optional
usb
pci
scsi
I'm okay that the domcapabilites output is longer, and don't think we
need to backport any of the new stuff to the older API. But any
information present in the old API should be easily retrieved using the
new API, so that the information isn't lost, and so that a client can
learn the same amount of detail about a non-default binary as they can
about the defaults.
Look at the difference in XPath to get to some of the same information:
/guest/os_type vs. ? - where is os_type in domcapabilities?
nowhere yet.
/guest/arch@name vs. /domainCapabilities/arch - why is one an attribute
and the other an element?
/
Re: [libvirt] virsh capabilities vs. domcapabilities
On Wed, Jul 16, 2014 at 01:00:30PM -0600, Eric Blake 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'. My view is that now we have dom capabilities, we shouldn't add anything more to the old capabilities that is related to guest emulators. The main motivation is that the old capabilities is not scalable given the sheer volume of data we need to report per QEMU. > Since virConnectGetDomainCapabilities is brand new to 1.2.7, we still > have time to change its XML. But I want consensus on whether we need > things to match, or whether we intentionally want people to rely only on > the newer XML format of the new API call (that is, don't bloat 'virsh > capabilities'/virConnectGetCapabilities any further, and learning > whether active commit is supported will have to be done via 'virsh > domcapabilities'/virConnectGetDomainCapabilities). That is, I'm > wondering if should use / as > its starting point, rather than completely inventing new XML. I don't think there's really anything of value in the old capabilities XML schema that needs preserving as-is. > 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? Hmm, I'm pretty sure we agreed virt type was going to be optional and would jsut get a sensible default. So we should fix that. > > # tools/virsh domcapabilities --virttype kvm > error: failed to get emulator capabilities > error: invalid argument: at least one of emulatorbin or architecture > fields must be present > > Would it be nicer to behave the same as 'virsh capabilities' and give > the details of the default binary in this case? My original idea was that either emulator or arch would be required. If we wanted to allow just virtype on its own, I guess we could just default to the current host arch. > Now, for a comparison between the two XML per binary: > > 'virsh capabilities' gives me this segment: > > > hvm > > 64 > /usr/bin/qemu-system-alpha > clipper > > > > > > > > > > while 'virsh domcapabilities --emulatorbin /usr/bin/qemu-system-alpha > --virttype kvm' gives this: > > > /usr/bin/qemu-system-alpha > kvm > clipper > alpha > > > > > disk > cdrom > floppy > lun > > > ide > fdc > scsi > virtio > usb > > > > > subsystem > > > default > mandatory > requisite > optional > > > usb > pci > scsi > > > > > > > > I'm okay that the domcapabilites output is longer, and don't think we > need to backport any of the new stuff to the older API. But any > information present in the old API should be easily retrieved using the > new API, so that the information isn't lost, and so that a client can > learn the same amount of detail about a non-default binary as they can > about the defaults. > > Look at the difference in XPath to get to some of the same information: > > /guest/os_type vs. ? - where is os_type in domcapabilities? Yep, that's an oversight really. > /guest/arch@name vs. /domainCapabilities/arch - why is one an attribute > and the other an element? > > /guest/arch/wordsize vs. nothing - where is wordsize in domcapabilities? > > /guest/arch/emulator vs. /domainCapabilities/path - why 3 levels vs. 2, > and different naming? > > /guest/arch/machine@maxCpus vs. /domainCapabilities/vcpu@max - why 3 > levels vs. 2, with different naming? > > /guest/arch/machine vs. /domainCapabilities/machine - why 3 levels vs. 2? This is just a reflection of the fact that we're doing a different XML schema. We had the extra '/guest' level in the original XML because we were reporting on multiple guest types. I see no reason to make the new XML have this uneccessary extra level of nesting. > /guest/arch/domain@type vs. /domainCapabilities/domain - why attribute > of 3 levels vs. element at 2 levels? And did I expose an error when I > passed --virrtype kvm, even though qemu-system-alpha is only a qemu > emulator on my machine (since kvm emulators is only for hardware-assit > emulation, which is not possible when I'm doing cross architecture)? > > /guest/features vs. ? - where ar
[libvirt] virsh capabilities vs. domcapabilities
We have some inconsistencies in the node capabilities (which shows guest capabilities for some default binaries) and domcapabilities (which shows guest capabilities for a specified binary). It might be nicer for client applications if the two XML components share a common schema and output layout, so that the same client code can be used to parse either (sub-tree of) XML, modulo the name of the top-most element containing the tree. 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'. Since virConnectGetDomainCapabilities is brand new to 1.2.7, we still have time to change its XML. But I want consensus on whether we need things to match, or whether we intentionally want people to rely only on the newer XML format of the new API call (that is, don't bloat 'virsh capabilities'/virConnectGetCapabilities any further, and learning whether active commit is supported will have to be done via 'virsh domcapabilities'/virConnectGetDomainCapabilities). That is, I'm wondering if should use / as its starting point, rather than completely inventing new XML. 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? # tools/virsh domcapabilities --virttype kvm error: failed to get emulator capabilities error: invalid argument: at least one of emulatorbin or architecture fields must be present Would it be nicer to behave the same as 'virsh capabilities' and give the details of the default binary in this case? Now, for a comparison between the two XML per binary: 'virsh capabilities' gives me this segment: hvm 64 /usr/bin/qemu-system-alpha clipper while 'virsh domcapabilities --emulatorbin /usr/bin/qemu-system-alpha --virttype kvm' gives this: /usr/bin/qemu-system-alpha kvm clipper alpha disk cdrom floppy lun ide fdc scsi virtio usb subsystem default mandatory requisite optional usb pci scsi I'm okay that the domcapabilites output is longer, and don't think we need to backport any of the new stuff to the older API. But any information present in the old API should be easily retrieved using the new API, so that the information isn't lost, and so that a client can learn the same amount of detail about a non-default binary as they can about the defaults. Look at the difference in XPath to get to some of the same information: /guest/os_type vs. ? - where is os_type in domcapabilities? /guest/arch@name vs. /domainCapabilities/arch - why is one an attribute and the other an element? /guest/arch/wordsize vs. nothing - where is wordsize in domcapabilities? /guest/arch/emulator vs. /domainCapabilities/path - why 3 levels vs. 2, and different naming? /guest/arch/machine@maxCpus vs. /domainCapabilities/vcpu@max - why 3 levels vs. 2, with different naming? /guest/arch/machine vs. /domainCapabilities/machine - why 3 levels vs. 2? /guest/arch/domain@type vs. /domainCapabilities/domain - why attribute of 3 levels vs. element at 2 levels? And did I expose an error when I passed --virrtype kvm, even though qemu-system-alpha is only a qemu emulator on my machine (since kvm emulators is only for hardware-assit emulation, which is not possible when I'm doing cross architecture)? /guest/features vs. ? - where are the features in domcapabilities? -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
