mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2024-12-26 03:21:44 +03:00
f1f28611f1
If we ensure that virNodeSuspendGetTargetMask always resets *bitmask to zero upon failure, there is no need for the powerMgmt_valid field. * src/util/virnodesuspend.c: Ensure *bitmask is zero upon failure * src/conf/capabilities.c, src/conf/capabilities.h: Remove powerMgmt_valid field * src/qemu/qemu_capabilities.c: Remove powerMgmt_valid
95 lines
3.9 KiB
HTML
95 lines
3.9 KiB
HTML
<html>
|
|
<body>
|
|
<h1>Driver capabilities XML format</h1>
|
|
|
|
<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>
|
|
<pre> char * virConnectGetCapabilities (virConnectPtr conn);</pre>
|
|
<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. For example in the case of a 64 bits
|
|
machine with hardware virtualization capabilities enabled in the chip and
|
|
BIOS you will see</p>
|
|
<pre><capabilities>
|
|
<span style="color: #E50000"><host>
|
|
<cpu>
|
|
<arch>x86_64</arch>
|
|
<features>
|
|
<vmx/>
|
|
</features>
|
|
<model>core2duo</model>
|
|
<vendor>Intel</vendor>
|
|
<topology sockets="1" cores="2" threads="1"/>
|
|
<feature name="lahf_lm"/>
|
|
<feature name='xtpr'/>
|
|
...
|
|
</cpu>
|
|
<power_management>
|
|
<suspend_mem/>
|
|
<suspend_disk/>
|
|
<suspend_hybrid/>
|
|
<power_management/>
|
|
</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>
|
|
<cpuselection/>
|
|
<deviceboot/>
|
|
</features>
|
|
</guest></span>
|
|
...
|
|
</capabilities></pre>
|
|
<p>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. </p>
|
|
<p>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.</p>
|
|
<p>The third block (in green) gives similar information but
|
|
when running a 32 bit OS fully virtualized with Xen using
|
|
the hvm support.</p>
|
|
<p>This section is likely to be updated and augmented in the
|
|
future,
|
|
see <a href="https://www.redhat.com/archives/libvir-list/2007-March/msg00215.html">the
|
|
discussion</a> which led to the capabilities format in the
|
|
mailing-list archives.</p>
|
|
|
|
</body>
|
|
</html>
|