2013-05-03 18:25:37 +04:00
<?xml version="1.0" encoding="UTF-8"?>
2017-07-26 20:01:25 +03:00
<!DOCTYPE html>
2013-05-03 18:25:37 +04:00
< html xmlns = "http://www.w3.org/1999/xhtml" >
2008-04-23 21:08:31 +04:00
< body >
< h1 > Driver capabilities XML format< / h1 >
2014-06-05 15:53:17 +04:00
< ul id = "toc" > < / ul >
2017-07-26 17:52:42 +03:00
< h2 > < a id = "elements" > Element and attribute overview< / a > < / h2 >
2014-06-05 15:53:17 +04:00
< p > 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:< / p >
2016-11-12 01:40:27 +03:00
< pre > char * virConnectGetCapabilities (virConnectPtr conn);< / pre >
2014-06-05 15:53:17 +04:00
< p > The value returned is an XML document listing the virtualization
capabilities of the host and virtualization engine to which
< code > @conn< / code > is connected. One can test it using < code > virsh< / code >
command line tool command '< code > capabilities< / code > ', it dumps the XML
associated to the current connection. < / p >
2017-04-22 22:06:20 +03:00
< p > As can be seen in the < a href = "#elementExamples" > example< / a > , the
2014-06-05 15:53:17 +04:00
capabilities XML consists of the < code > capabilities< / code > element which
have exactly one < code > host< / code > child element to report information on
host capabilities, and zero or more < code > guest< / code > element to express
the set of architectures the host can run at the moment.< / p >
2017-07-26 17:52:42 +03:00
< h3 > < a id = "elementHost" > Host capabilities< / a > < / h3 >
2014-06-05 15:53:17 +04:00
< p > The < code > < host/> < / code > element consists of the following child
elements:< / p >
< dl >
< dt > < code > uuid< / code > < / dt >
< dd > The host UUID.< / dd >
< dt > < code > cpu< / code > < / dt >
< dd > The host CPU architecture and features.< / dd >
< dt > < code > power_management< / code > < / dt >
< dd > whether host is capable of memory suspend, disk hibernation, or
hybrid suspend.< / dd >
< dt > < code > migration< / code > < / dt >
< dd > This element exposes information on the hypervisor's migration
capabilities, like live migration, supported URI transports, and so
on.< / dd >
< dt > < code > topology< / code > < / dt >
< dd > This element embodies the host internal topology. Management
applications may want to learn this information when orchestrating new
guests - e.g. due to reduce inter-NUMA node transfers.< / dd >
< dt > < code > secmodel< / code > < / dt >
< dd > To find out default security labels for different security models you
need to parse this element. In contrast with the former elements, this is
repeated for each security model the libvirt daemon currently supports.
< / dd >
< / dl >
2017-07-26 17:52:42 +03:00
< h3 > < a id = "elementGuest" > Guest capabilities< / a > < / h3 >
2014-06-05 15:53:17 +04:00
< p > While the < a href = "#elementHost" > previous section< / a > aims at host
capabilities, this one focuses on capabilities available to a guest
using a given hypervisor. The < code > < guest/> < / code > element will
typically wrap up the following elements:< / p >
< dl >
< dt > < code > os_type< / code > < / dt >
< dd > This expresses what kind of operating system the hypervisor
is able to run. Possible values are:
< dl >
2016-04-21 16:23:56 +03:00
< dt > < code > xen< / code > < / dt >
2018-11-26 22:34:37 +03:00
< dd > for XEN PV< / dd >
2014-06-05 15:53:17 +04:00
2016-04-21 16:23:56 +03:00
< dt > < code > linux< / code > < / dt >
2014-06-05 15:53:17 +04:00
< dd > legacy alias for < code > xen< / code > < / dd >
2018-11-26 22:34:37 +03:00
< dt > < code > xenpvh< / code > < / dt >
< dd > for XEN PVH< / dd >
2016-04-21 16:23:56 +03:00
< dt > < code > hvm< / code > < / dt >
2014-06-05 15:53:17 +04:00
< dd > Unmodified operating system< / dd >
2016-04-21 16:23:56 +03:00
< dt > < code > exe< / code > < / dt >
2014-06-05 15:53:17 +04:00
< dd > Container based virtualization< / dd >
< / dl >
< / dd >
< dt > < code > arch< / code > < / dt >
2018-09-19 03:50:30 +03:00
< dd > This element brings some information on supported guest
architecture. Possible subelements are:
< dl >
< dt > < code > wordsize< / code > < / dt > < dd > Size of CPU word in bits, for example 64.< / dd >
< dt > < code > emulator< / code > < / dt > < dd > Emulator (device model) path, for
use in < a href = "formatdomain.html#elementEmulator" > emulator< / a >
element of domain XML.< / dd >
< dt > < code > loader< / code > < / dt > < dd > Loader path, for use in
< a href = "formatdomain.html#elementLoader" > loader< / a > element of domain
XML.< / dd >
< dt > < code > machine< / code > < / dt > < dd > Machine type, for use in
< a href = "formatdomain.html#attributeOSTypeMachine" > machine< / a >
attribute of os/type element in domain XML. For example Xen
2018-11-26 22:34:37 +03:00
supports < code > xenfv< / code > for HVM, < code > xenpv< / code > for
PV, or < code > xenpvh< / code > for PVH.< / dd >
2018-09-19 03:50:30 +03:00
< dt > < code > domain< / code > < / dt > < dd > The < code > type< / code > attribute of
this element specifies the type of hypervisor required to run the
domain. Use in < a href = "formatdomain.html#attributeDomainType" > type< / a >
attribute of the domain root element.< / dd >
< / dl >
< / dd >
2014-06-05 15:53:17 +04:00
< dt > < code > features< / code > < / dt >
< dd > This optional element encases possible features that can be used
2014-06-24 01:59:02 +04:00
with a guest of described type. Possible subelements are:
< dl >
2016-04-21 16:23:56 +03:00
< dt > < code > pae< / code > < / dt > < dd > If present, 32-bit guests can use PAE
2014-06-24 01:59:02 +04:00
address space extensions, < span class = "since" > since
0.4.1< / span > < / dd >
2016-04-21 16:23:56 +03:00
< dt > < code > nonpae< / code > < / dt > < dd > If present, 32-bit guests can be run
2014-06-24 01:59:02 +04:00
without requiring PAE, < span class = "since" > since
0.4.1< / span > < / dd >
2016-04-21 16:23:56 +03:00
< dt > < code > ia64_be< / code > < / dt > < dd > If present, IA64 guests can be run in
2014-06-24 01:59:02 +04:00
big-endian mode, < span class = "since" > since 0.4.1< / span > < / dd >
2016-04-21 16:23:56 +03:00
< dt > < code > acpi< / code > < / dt > < dd > If this element is present,
2014-06-24 01:59:02 +04:00
the < code > default< / code > attribute describes whether the
hypervisor exposes ACPI to the guest by default, and
the < code > toggle< / code > attribute describes whether the
user can override this
default. < span class = "since" > Since 0.4.1< / span > < / dd >
2016-04-21 16:23:56 +03:00
< dt > < code > apic< / code > < / dt > < dd > If this element is present,
2014-06-24 01:59:02 +04:00
the < code > default< / code > attribute describes whether the
hypervisor exposes APIC to the guest by default, and
the < code > toggle< / code > attribute describes whether the
user can override this
default. < span class = "since" > Since 0.4.1< / span > < / dd >
2016-04-21 16:23:56 +03:00
< dt > < code > cpuselection< / code > < / dt > < dd > If this element is present, the
2014-06-24 01:59:02 +04:00
hypervisor supports the < code > < cpu> < / code > element
within a domain definition for fine-grained control over
the CPU presented to the
guest. < span class = "since" > Since 0.7.5< / span > < / dd >
2016-04-21 16:23:56 +03:00
< dt > < code > deviceboot< / code > < / dt > < dd > If this element is present,
2014-06-24 01:59:02 +04:00
the < code > < boot order='...'/> < / code > element can
be used inside devices, rather than the older boot
specification by category. < span class = "since" > Since
0.8.8< / span > < / dd >
2016-04-21 16:23:56 +03:00
< dt > < code > disksnapshot< / code > < / dt > < dd > If this element is present,
2014-06-24 01:59:02 +04:00
the < code > default< / code > 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. < span class = "since" > Since
1.2.3< / span > < / dd >
< / dl >
< / dd >
2014-06-05 15:53:17 +04:00
< / dl >
2017-07-26 17:52:42 +03:00
< h3 > < a id = "elementExamples" > Examples< / a > < / h3 >
2014-06-05 15:53:17 +04:00
< p > For example, in the case of a 64-bit machine with hardware
virtualization capabilities enabled in the chip and
BIOS you will see:< / p >
< pre > < capabilities>
2008-04-23 21:08:31 +04:00
< span style = "color: #E50000" > < host>
< cpu>
< arch> x86_64< /arch>
< features>
< vmx/>
< /features>
2010-01-19 20:22:45 +03:00
< model> core2duo< /model>
2010-07-02 19:51:59 +04:00
< vendor> Intel< /vendor>
2010-01-19 20:22:45 +03:00
< topology sockets="1" cores="2" threads="1"/>
< feature name="lahf_lm"/>
< feature name='xtpr'/>
...
2008-04-23 21:08:31 +04:00
< /cpu>
2011-11-22 07:31:22 +04:00
< power_management>
2011-11-29 18:14:03 +04:00
< suspend_mem/>
< suspend_disk/>
< suspend_hybrid/>
2015-09-15 12:15:06 +03:00
< /power_management>
2008-04-23 21:08:31 +04:00
< /host> < / span >
< !-- xen-3.0-x86_64 -->
< span style = "color: #0000E5" > < 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> < / span >
< !-- hvm-3.0-x86_32 -->
< span style = "color: #00B200" > < 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>
2010-01-19 20:22:45 +03:00
< cpuselection/>
2011-01-12 17:19:34 +03:00
< deviceboot/>
2008-04-23 21:08:31 +04:00
< /features>
< /guest> < / span >
...
< /capabilities> < / pre >
< / body >
< / html >
