[Libvir] [RFC] Host and guest capabilities
I've been looking into the parts of virtinst which try to probe the capabilities of the host directly, rather than being abstracted through libvirt (for example, opening and parsing /sys/hypervisor/properties/capabilities directly). Attached is a proposed API for probing the capabilities and supported guest architectures of the hypervisor / driver. I've implemented the virCapabilities part already. My original implementation of the guest architectures had virCapabilities containing a list of supported architectures, but that doesn't nearly cover the richness of what the underlying drivers could support, so I'm currently separating that out into a separate virConnectGetGuestArchitectures call. Let me know your opinions of this API. As an aside, the current virt-manager "choose paravirt / fullvirt" screen doesn't really capture the full, shall I say, ugliness of the possible choices for architecture, particularly when we add qemu, kqemu, and emulation in the mix. I suspect that presenting a list of architectures here, perhaps with some options to show only paravirt, show only fullvirt, show only accelerated ... Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 "[Negative numbers] darken the very whole doctrines of the equations and make dark of the things which are in their nature excessively obvious and simple" (Francis Maseres FRS, mathematician, 1759)
Some additional comments on what these mean:
+int virCapabilitiesGetHostSupportsHVM (virCapabilitiesPtr caps);
Would return true if the host supports HVM ...
+int virCapabilitiesGetHostHVMDisabledByBIOS (virCapabilitiesPtr caps);
... but this would return true if the HVM isn't available to Xen, indicating that it's disabled in the BIOS. Virt-manager could use this to present some sort of message about how to enable in the BIOS.
+int virGuestArchitecturesGetCount (virGuestArchitecturesPtr archs); +char *virGuestArchitecturesGetName (virGuestArchitecturesPtr archs, int n); +int virGuestArchitecturesGetIsHVM (virGuestArchitecturesPtr archs, int n);
If this architecture supports full virt.
+int virGuestArchitecturesGetIsAccelerated (virGuestArchitecturesPtr archs, int n);
If this architecture is accelerated (eg. all Xen architectures, and qemu architectures using kqemu).
+int virGuestArchitecturesGetIsEmulated (virGuestArchitecturesPtr archs, int n);
eg. qemu emulating a completely different architecture.
+int virGuestArchitecturesGetIsBigEndian (virGuestArchitecturesPtr archs, int n);
Xen on IA64 allows guests to be big endian. It's not clear if the IA64 HV is always little endian though.
+int virGuestArchitecturesGetBits (virGuestArchitecturesPtr archs, int n);
Returns 32 or 64.
+int virGuestArchitecturesGetIsPAE (virGuestArchitecturesPtr archs, int n);
Xen on x86 allows guests to be PAE or non-PAE. Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 "[Negative numbers] darken the very whole doctrines of the equations and make dark of the things which are in their nature excessively obvious and simple" (Francis Maseres FRS, mathematician, 1759)
On Wed, Mar 07, 2007 at 12:35:20PM +0000, Richard W.M. Jones wrote:
I've been looking into the parts of virtinst which try to probe the capabilities of the host directly, rather than being abstracted through libvirt (for example, opening and parsing /sys/hypervisor/properties/capabilities directly).
Attached is a proposed API for probing the capabilities and supported guest architectures of the hypervisor / driver.
I've implemented the virCapabilities part already. My original implementation of the guest architectures had virCapabilities containing a list of supported architectures, but that doesn't nearly cover the richness of what the underlying drivers could support, so I'm currently separating that out into a separate virConnectGetGuestArchitectures call.
Let me know your opinions of this API.
This sounds too variable, adding an entry point per capability of some of the hypervisor available will lead to just too many entry points once the set of virtualization engines and associated benefits increase. That's one of the places where I feel wy more comfortable returning an XML description which can then be augmented as more features are added.
As an aside, the current virt-manager "choose paravirt / fullvirt" screen doesn't really capture the full, shall I say, ugliness of the possible choices for architecture, particularly when we add qemu, kqemu, and emulation in the mix. I suspect that presenting a list of architectures here, perhaps with some options to show only paravirt, show only fullvirt, show only accelerated ...
I'm not sure we should directly add something like the Architectures to the API (I mean the structure), it's very hard to guess now if we know all the informations which would be useful to return, and again, I would feel way better if this was provided as an XML blob, possibly embedded in the host capacities one. Basically just turning the current virtinst lookups into libvirt APIs sounds a bit premature to me, I would prefer something more versatile and hence future-proof. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Daniel Veillard wrote:
This sounds too variable, adding an entry point per capability of some of the hypervisor available will lead to just too many entry points once the set of virtualization engines and associated benefits increase. That's one of the places where I feel wy more comfortable returning an XML description which can then be augmented as more features are added.
But this API is _precisely_ designed to be extensible. The virCapabilities structure is not accessible to callers (unlike, say, virNodeInfo), except through accessor functions. We can add accessor functions in future. Returning XML just punts the problem elsewhere. Now clients need to worry about parsing the XML, and there's no real guarantee that the XML won't change in a way which is incompatible with the clients. Whereas by using ordinary functions we have that guarantee. Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 "[Negative numbers] darken the very whole doctrines of the equations and make dark of the things which are in their nature excessively obvious and simple" (Francis Maseres FRS, mathematician, 1759)
On Wed, Mar 07, 2007 at 02:56:47PM +0000, Richard W.M. Jones wrote:
Daniel Veillard wrote:
This sounds too variable, adding an entry point per capability of some of the hypervisor available will lead to just too many entry points once the set of virtualization engines and associated benefits increase. That's one of the places where I feel wy more comfortable returning an XML description which can then be augmented as more features are added.
But this API is _precisely_ designed to be extensible. The virCapabilities structure is not accessible to callers (unlike, say, virNodeInfo), except through accessor functions. We can add accessor functions in future.
Returning XML just punts the problem elsewhere. Now clients need to worry about parsing the XML, and there's no real guarantee that the XML won't change in a way which is incompatible with the clients. Whereas by using ordinary functions we have that guarantee.
It's easier to make that garantee at the XML level in my opinion. And adding pile of accessor functions for a struct that you don't feel you can define well enough to export is not the way I like to define APIs. Sorry, we disagree. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Daniel Veillard wrote:
On Wed, Mar 07, 2007 at 02:56:47PM +0000, Richard W.M. Jones wrote:
Daniel Veillard wrote:
This sounds too variable, adding an entry point per capability of some of the hypervisor available will lead to just too many entry points once the set of virtualization engines and associated benefits increase. That's one of the places where I feel wy more comfortable returning an XML description which can then be augmented as more features are added. But this API is _precisely_ designed to be extensible. The virCapabilities structure is not accessible to callers (unlike, say, virNodeInfo), except through accessor functions. We can add accessor functions in future.
Returning XML just punts the problem elsewhere. Now clients need to worry about parsing the XML, and there's no real guarantee that the XML won't change in a way which is incompatible with the clients. Whereas by using ordinary functions we have that guarantee.
It's easier to make that garantee at the XML level in my opinion.
Well one can certainly be careful about future changes to the XML, but there is no guarantee for clients, not even the (very minimal) guarantees that C linking makes. After all "char *getXMLBlob ()" will still link perfectly fine no matter what's in the XML.
And adding pile of accessor functions for a struct that you don't feel you can define well enough to export is not the way I like to define APIs.
I would gladly make the structure public. The original proposal which unfortunately didn't make it beyond some private chat was to prototype the call so it would be called as: struct virCapabilities caps; virConnectGetCapabilities (conn, &caps, sizeof caps); This provides forwards compatibility because libvirt can add further fields to the structure, and libvirt can always tell which version of the structure that the client was linked against through the size field. Future elements of the structure can even override earlier elements, for future clients which understand this. The participants in the chat decided they preferred accessor functions instead, and since those are still type-safe I did not demur. Anyway, to be honest I'm not that bothered. If you think XML is better, I'm quite happy to return XML blobs. My main concern is to get virt-manager working sensibly in the remote case. Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 "[Negative numbers] darken the very whole doctrines of the equations and make dark of the things which are in their nature excessively obvious and simple" (Francis Maseres FRS, mathematician, 1759)
On Wed, Mar 07, 2007 at 09:35:58AM -0500, Daniel Veillard wrote:
On Wed, Mar 07, 2007 at 12:35:20PM +0000, Richard W.M. Jones wrote:
I've been looking into the parts of virtinst which try to probe the capabilities of the host directly, rather than being abstracted through libvirt (for example, opening and parsing /sys/hypervisor/properties/capabilities directly).
Attached is a proposed API for probing the capabilities and supported guest architectures of the hypervisor / driver.
I've implemented the virCapabilities part already. My original implementation of the guest architectures had virCapabilities containing a list of supported architectures, but that doesn't nearly cover the richness of what the underlying drivers could support, so I'm currently separating that out into a separate virConnectGetGuestArchitectures call.
Let me know your opinions of this API.
This sounds too variable, adding an entry point per capability of some of the hypervisor available will lead to just too many entry points once the set of virtualization engines and associated benefits increase. That's one of the places where I feel wy more comfortable returning an XML description which can then be augmented as more features are added.
As an aside, the current virt-manager "choose paravirt / fullvirt" screen doesn't really capture the full, shall I say, ugliness of the possible choices for architecture, particularly when we add qemu, kqemu, and emulation in the mix. I suspect that presenting a list of architectures here, perhaps with some options to show only paravirt, show only fullvirt, show only accelerated ...
I'm not sure we should directly add something like the Architectures to the API (I mean the structure), it's very hard to guess now if we know all the informations which would be useful to return, and again, I would feel way better if this was provided as an XML blob, possibly embedded in the host capacities one.
Basically just turning the current virtinst lookups into libvirt APIs sounds a bit premature to me, I would prefer something more versatile and hence future-proof.
For those new to the list, we had a (short) thread on this same subject of APIs for host capabilities last year http://www.redhat.com/archives/libvir-list/2006-November/msg00066.html I'm personally still of the opinion we should consider a XML blob describing the host capabilities. This gives API parity with the way we describe VM hardware. Looking back at the extensions we've made to the VM XML over the past year, I think the XML has been very succesful at allowing us to extend the information returned without breaking clients. Some of the major additions we've made thus far: - New <graphics> device for HVM. - More info in <os> block to suppport HVM. - Ability to choose driver for virtual disks - Attribute to distinguish floppy, cdrom & harddisks - Support for IP addr in VIFs to support routed networking - Machine type & architecture in <os> block for QEMU/KVM While we could certainly maintain compatability by using an opaque struct and accessor methods, this will lead to a huge number of APIs over time. To be able to have be able to do this with accessors, we'd need to go for a finest grain, one-accessor per attribute, and introduce many opaque nested sub-objects to give flexibility to add new objects / attributes whereever needed. In terms of the virt-manager code, I don't think there's any significant difference in complexity between using XML vs formal APIs & accessors. C is a different matter because of its horrible string handling & the libxml APIs are fairly low level. Even then its possible to make convenience wrappers around the libxml APIs[1] to turn extracting info from XML into a single method call providing an XPATH expression & returning a char *. Regards, Dan. [1] This is a todo item to cleanup the XML handling inside xend_internal.c and the test.c drivers. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
participants (3)
-
Daniel P. Berrange -
Daniel Veillard -
Richard W.M. Jones