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 ...

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.

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.