Driver capabilities XML format

As new virtualization engine support gets added to libvirt, and to handle cases like QEmu supporting a variety of emulations, a query interface has been added in 0.2.1 allowing to list the set of supported virtualization capabilities on the host:

    char * virConnectGetCapabilities (virConnectPtr conn);

The value returned is an XML document listing the virtualization capabilities of the host and virtualization engine to which @conn is connected. One can test it using virsh command line tool command 'capabilities', it dumps the XML associated to the current connection. For example in the case of a 64 bits machine with hardware virtualization capabilities enabled in the chip and BIOS you will see

      <topology sockets="1" cores="2" threads="1"/>
      <feature name="lahf_lm"/>
      <feature name='xtpr'/>

  <!-- xen-3.0-x86_64 -->
    <arch name="x86_64">
      <domain type="xen"></domain>

  <!-- hvm-3.0-x86_32 -->
    <arch name="i686">
      <domain type="xen"></domain>

The first block (in red) indicates the host hardware capabilities, such as CPU properties and the power management features of the host platform. CPU models are shown as additional features relative to the closest base model, within a feature block (the block is similar to what you will find in a Xen fully virtualized domain description). Further, the power management features supported by the host are shown, such as Suspend-to-RAM (S3), Suspend-to-Disk (S4) and Hybrid-Suspend (a combination of S3 and S4). In case the host does not support any such feature, then an empty <power_management/> tag will be shown.

The second block (in blue) indicates the paravirtualization support of the Xen support, you will see the os_type of xen to indicate a paravirtual kernel, then architecture information and potential features.

The third block (in green) gives similar information but when running a 32 bit OS fully virtualized with Xen using the hvm support.

This section is likely to be updated and augmented in the future, see the discussion which led to the capabilities format in the mailing-list archives.