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.
As can be seen in the example, the
capabilities XML consists of the capabilities
element which
have exactly one host
child element to report information on
host capabilities, and zero or more guest
element to express
the set of architectures the host can run at the moment.
The <host/>
element consists of the following child
elements:
uuid
cpu
power_management
migration_features
topology
sockets
value reported here is per-NUMA-node; this is in
contrast to the value given in domain definitions, which is interpreted
as a total number of sockets for the domain.secmodel
While the previous section aims at host
capabilities, this one focuses on capabilities available to a guest
using a given hypervisor. The <guest/>
element will
typically wrap up the following elements:
os_type
xen
linux
xen
xenpvh
hvm
exe
arch
wordsize
emulator
loader
machine
xenfv
for HVM, xenpv
for
PV, or xenpvh
for PVH.domain
type
attribute of
this element specifies the type of hypervisor required to run the
domain. Use in type
attribute of the domain root element.features
pae
nonpae
ia64_be
acpi
default
attribute describes whether the
hypervisor exposes ACPI to the guest by default, and
the toggle
attribute describes whether the
user can override this
default. Since 0.4.1apic
default
attribute describes whether the
hypervisor exposes APIC to the guest by default, and
the toggle
attribute describes whether the
user can override this
default. Since 0.4.1cpuselection
<cpu>
element
within a domain definition for fine-grained control over
the CPU presented to the
guest. Since 0.7.5deviceboot
<boot order='...'/>
element can
be used inside devices, rather than the older boot
specification by category. Since
0.8.8disksnapshot
default
attribute describes whether
external disk snapshots are supported. If absent,
external snapshots may still be supported, but it
requires attempting the API and checking for an error to
find out for sure. Since
1.2.3For example, in the case of a 64-bit machine with hardware virtualization capabilities enabled in the chip and BIOS you will see:
<capabilities> <host> <cpu> <arch>x86_64</arch> <features> <vmx/> </features> <model>core2duo</model> <vendor>Intel</vendor> <topology sockets="1" dies="1" cores="2" threads="1"/> <feature name="lahf_lm"/> <feature name='xtpr'/> ... </cpu> <power_management> <suspend_mem/> <suspend_disk/> <suspend_hybrid/> </power_management> </host> <!-- xen-3.0-x86_64 --> <guest> <os_type>xen</os_type> <arch name="x86_64"> <wordsize>64</wordsize> <domain type="xen"></domain> <emulator>/usr/lib64/xen/bin/qemu-dm</emulator> </arch> <features> </features> </guest> <!-- hvm-3.0-x86_32 --> <guest> <os_type>hvm</os_type> <arch name="i686"> <wordsize>32</wordsize> <domain type="xen"></domain> <emulator>/usr/lib/xen/bin/qemu-dm</emulator> <machine>pc</machine> <machine>isapc</machine> <loader>/usr/lib/xen/boot/hvmloader</loader> </arch> <features> <cpuselection/> <deviceboot/> </features> </guest> ... </capabilities>