diff --git a/docs/formatcaps.html.in b/docs/formatcaps.html.in index d060a5b78bee263f7c42ad41f36e5bfc68989ccd..137af258ff42c376f3d5d2749d0ea591621c78fb 100644 --- a/docs/formatcaps.html.in +++ b/docs/formatcaps.html.in @@ -4,19 +4,107 @@
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
<capabilities> +
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 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
topology
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
arch
features
For 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>
@@ -67,30 +155,5 @@ BIOS you will see
</guest>
...
</capabilities>
- 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.
-