[Libvir] [PATCH] Add virConnectGetCapabilities call to return the capabilities of the driver / hypervisor

[Daniel Veillard]

On Fri, Mar 09, 2007 at 03:22:08PM +0000, Richard W.M. Jones wrote:
> This patch:
> 
> * Adds virConnectGetCapabilities which returns an XML description of the 
> capabilities of the driver or hypervisor under this connection (see 
> below for more about the XML format).
> 
> * Adds virsh capabilities command.
> 
> * Checks the Python binding works.
> 
> Caveats:
> 
> * Xen implementation (in xen_internal.c) is not tested because I don't 
> have a working Xen machine right now.  QEMU, test and remote work however.
> 
> Example:
> 
> $ virsh -c test:///default capabilities | tidy -xml -i -q
> <capabilities>
>   <domain>
>     <type>test</type>
>   </domain>
>   <host_features></host_features>
>   <guest_architectures>
>     <guest_architecture>
>       <model>i686</model>
>       <bits>32</bits>
>       <guest_features>
>         <accelerated />
>         <pae />
>       </guest_features>
>     </guest_architecture>
>   </guest_architectures>
> </capabilities>
> 
> $ virsh -c qemu:///session capabilities | tidy -xml -i -q
> <capabilities>
>   <domain>
>     <type>qemu</type>
>   </domain>
>   <guest_architectures>
>     <guest_architecture>
>       <model>i686</model>
>       <bits>32</bits>
>       <features>
>         <emulated />
>       </features>
>     </guest_architecture>
>     <guest_architecture>
>       <model>x86_64</model>
>       <bits>64</bits>
>       <features>
>         <emulated />
>       </features>
>     </guest_architecture>
> [... other archs deleted ...]
>   </guest_architectures>
> </capabilities>
> 
> XML format:
> 
> The <capabilities> node contains information about the host and a list 
> of supported architectures for guests.  About the host we return:
> 
>   <domain>
>     <type>	The default type acceptable when creating a domain.
> 
>   <host_features>
>     <hvm>	Does the host CPU support HVM?
>       <type>	Type of HVM (eg. "vmx")
>       <bios_setting>   "enabled" or "disabled"
> 
> About the guest architectures we can return:
> 
>   <guest_architecture>
>     <model>	The (virtualised) CPU
>     <bits>      Bits
>     <domain>
>       <type>	If different from the default type (eg. for kqemu)
>     <features>
>       <hvm>		Full virt guest?
>       <accelerated>	Accelerated (eg. Xen or kqemu)
>       <emulated>	Emulated (eg. qemu or bochs)
>       (and a few other esoteric flags here)

  In general I like this.
  Okay I have some comments about the implementation, I didn't really though 
much about the XML format yet, except I dislike <bits>, at the XML level you
must expose the informations, if it's just to keep them in an encoded value
you loose most of the point of going structured. So what are the bits ? And
instead expose them in a named form, either as attributes or elements
(depending on whether it is short, and the content of that value).

  I'm not too fond of the strjoin() routine, basically it makes all the XML
'flat', I'm not sure it makes things much more readable at the C level,
and it's different code from other places where we generate XML. Can you
use the same buffer routines (virBufferVSprintf, virBufferAdd) that are
used in other places like  xend_internal.c and xm_internal.c.
  Also starting to make a library of shared code is a good idea, but
well it should IMHO go into a separate lib/ subdir, probably not just into
a lib.c / lib.h file, and well I have issues with strjoin() :-)

   thanks,

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/