External/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-11-03 20:01:16 +00:00
Code Issues Packages Projects Releases Wiki Activity
d2010be479
libvirt/docs/formatcaps.html.in

220 lines
9.0 KiB
HTML
Raw Normal View History

Fix multiple formatting problems in HTML docs The rule generating the HTML docs passing the --html flag to xsltproc. This makes it use the legacy HTML parser, which either ignores or tries to fix all sorts of broken XML tags. There's no reason why we should be writing broken XML in the first place, so removing --html and adding the XHTML doctype to all files forces us to create good XML. This adds the XHTML doc type and fixes many, many XML tag problems it exposes. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-05-03 14:25:37 +00:00
<?xml version="1.0" encoding="UTF-8"?>
docs: switch to using HTML5 doctype declaration The HTML5 doctype is simply <!DOCTYPE html> no DTD is present because HTML5 is no longer defined as an extension of SGML. XSL has no way to natively output a doctype without a public or system identifier, so we have to use an <xsl:text> hack instead. See also https://dev.w3.org/html5/html-author/#doctype-declaration Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2017-07-26 17:01:25 +00:00
<!DOCTYPE html>
Fix multiple formatting problems in HTML docs The rule generating the HTML docs passing the --html flag to xsltproc. This makes it use the legacy HTML parser, which either ignores or tries to fix all sorts of broken XML tags. There's no reason why we should be writing broken XML in the first place, so removing --html and adding the XHTML doctype to all files forces us to create good XML. This adds the XHTML doc type and fixes many, many XML tag problems it exposes. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-05-03 14:25:37 +00:00
<html xmlns="http://www.w3.org/1999/xhtml">
Split website out into one file per page. APply new layout and styling
2008-04-23 17:08:31 +00:00
<body>
<h1>Driver capabilities XML format</h1>
formatcaps: Rework and add stubs to document At the moment we are missing even basic documentation on our capabilities XML. Without demand on completeness, I'm reorganizing the document structure and adding very basic documentation to two major components of the capabilities XML. These stubs are intended to be enhanced in the future. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-06-05 11:53:17 +00:00
<ul id="toc"></ul>
docs: switch to using 'id' attribute instead of 'name' for links The 'name' attribute on <a...> elements is deprecated in favour of the 'id' attribute which is allowed on any element. HTML5 drops 'name' support entirely. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2017-07-26 14:52:42 +00:00
<h2><a id="elements">Element and attribute overview</a></h2>
formatcaps: Rework and add stubs to document At the moment we are missing even basic documentation on our capabilities XML. Without demand on completeness, I'm reorganizing the document structure and adding very basic documentation to two major components of the capabilities XML. These stubs are intended to be enhanced in the future. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-06-05 11:53:17 +00: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>
formatcaps.html.in: Kill useless spaces in <pre/> The <pre/> section is rendered as-is on the page. That is, if all the lines are prefixed with 4 spaces the rendered page will also have them. Problem is if we put a box around such <pre/> because the content might not fix into it. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2016-11-11 22:40:27 +00:00
<pre>char * virConnectGetCapabilities (virConnectPtr conn);</pre>
formatcaps: Rework and add stubs to document At the moment we are missing even basic documentation on our capabilities XML. Without demand on completeness, I'm reorganizing the document structure and adding very basic documentation to two major components of the capabilities XML. These stubs are intended to be enhanced in the future. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-06-05 11:53:17 +00: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>
Fix minor typos
2017-04-22 19:06:20 +00:00
<p>As can be seen in the <a href="#elementExamples">example</a>, the
formatcaps: Rework and add stubs to document At the moment we are missing even basic documentation on our capabilities XML. Without demand on completeness, I'm reorganizing the document structure and adding very basic documentation to two major components of the capabilities XML. These stubs are intended to be enhanced in the future. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-06-05 11:53:17 +00: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>
docs: switch to using 'id' attribute instead of 'name' for links The 'name' attribute on <a...> elements is deprecated in favour of the 'id' attribute which is allowed on any element. HTML5 drops 'name' support entirely. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2017-07-26 14:52:42 +00:00
<h3><a id="elementHost">Host capabilities</a></h3>
formatcaps: Rework and add stubs to document At the moment we are missing even basic documentation on our capabilities XML. Without demand on completeness, I'm reorganizing the document structure and adding very basic documentation to two major components of the capabilities XML. These stubs are intended to be enhanced in the future. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-06-05 11:53:17 +00:00
<p>The <code>&lt;host/&gt;</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>
docs: switch to using 'id' attribute instead of 'name' for links The 'name' attribute on <a...> elements is deprecated in favour of the 'id' attribute which is allowed on any element. HTML5 drops 'name' support entirely. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2017-07-26 14:52:42 +00:00
<h3><a id="elementGuest">Guest capabilities</a></h3>
formatcaps: Rework and add stubs to document At the moment we are missing even basic documentation on our capabilities XML. Without demand on completeness, I'm reorganizing the document structure and adding very basic documentation to two major components of the capabilities XML. These stubs are intended to be enhanced in the future. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-06-05 11:53:17 +00: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>&lt;guest/&gt;</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>
docs: Use <code> inside <dt> for symbols Most of the time, the <dt> tag is used when providing documentation for a symbol; enclose symbols in <code> tags to style them appropriately.
2016-04-21 13:23:56 +00:00
<dt><code>xen</code></dt>
libxl: add support for PVH Since this is something between PV and HVM, it makes sense to put the setting in place where domain type is specified. To enable it, use <os><type machine="xenpvh">xenpvh</type></os>. It is also included in capabilities.xml, for every supported HVM guest type - it doesn't seems to be any other requirement (besides new enough Xen). Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Reviewed-by: Jim Fehlig <jfehlig@suse.com>
2018-11-26 19:34:37 +00:00
<dd>for XEN PV</dd>
formatcaps: Rework and add stubs to document At the moment we are missing even basic documentation on our capabilities XML. Without demand on completeness, I'm reorganizing the document structure and adding very basic documentation to two major components of the capabilities XML. These stubs are intended to be enhanced in the future. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-06-05 11:53:17 +00:00
docs: Use <code> inside <dt> for symbols Most of the time, the <dt> tag is used when providing documentation for a symbol; enclose symbols in <code> tags to style them appropriately.
2016-04-21 13:23:56 +00:00
<dt><code>linux</code></dt>
formatcaps: Rework and add stubs to document At the moment we are missing even basic documentation on our capabilities XML. Without demand on completeness, I'm reorganizing the document structure and adding very basic documentation to two major components of the capabilities XML. These stubs are intended to be enhanced in the future. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-06-05 11:53:17 +00:00
<dd>legacy alias for <code>xen</code></dd>
libxl: add support for PVH Since this is something between PV and HVM, it makes sense to put the setting in place where domain type is specified. To enable it, use <os><type machine="xenpvh">xenpvh</type></os>. It is also included in capabilities.xml, for every supported HVM guest type - it doesn't seems to be any other requirement (besides new enough Xen). Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Reviewed-by: Jim Fehlig <jfehlig@suse.com>
2018-11-26 19:34:37 +00:00
<dt><code>xenpvh</code></dt>
<dd>for XEN PVH</dd>
docs: Use <code> inside <dt> for symbols Most of the time, the <dt> tag is used when providing documentation for a symbol; enclose symbols in <code> tags to style them appropriately.
2016-04-21 13:23:56 +00:00
<dt><code>hvm</code></dt>
formatcaps: Rework and add stubs to document At the moment we are missing even basic documentation on our capabilities XML. Without demand on completeness, I'm reorganizing the document structure and adding very basic documentation to two major components of the capabilities XML. These stubs are intended to be enhanced in the future. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-06-05 11:53:17 +00:00
<dd>Unmodified operating system</dd>
docs: Use <code> inside <dt> for symbols Most of the time, the <dt> tag is used when providing documentation for a symbol; enclose symbols in <code> tags to style them appropriately.
2016-04-21 13:23:56 +00:00
<dt><code>exe</code></dt>
formatcaps: Rework and add stubs to document At the moment we are missing even basic documentation on our capabilities XML. Without demand on completeness, I'm reorganizing the document structure and adding very basic documentation to two major components of the capabilities XML. These stubs are intended to be enhanced in the future. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-06-05 11:53:17 +00:00
<dd>Container based virtualization</dd>
</dl>
</dd>
<dt><code>arch</code></dt>
docs: add documentation of arch element of capabilities.xml Specifically, list sub-elements and where they can be used. In addition, describe supported machine types for Xen. Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Reviewed-by: Jim Fehlig <jfehlig@suse.com>
2018-09-19 00:50:30 +00: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
libxl: add support for PVH Since this is something between PV and HVM, it makes sense to put the setting in place where domain type is specified. To enable it, use <os><type machine="xenpvh">xenpvh</type></os>. It is also included in capabilities.xml, for every supported HVM guest type - it doesn't seems to be any other requirement (besides new enough Xen). Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Reviewed-by: Jim Fehlig <jfehlig@suse.com>
2018-11-26 19:34:37 +00:00
supports <code>xenfv</code> for HVM, <code>xenpv</code> for
PV, or <code>xenpvh</code> for PVH.</dd>
docs: add documentation of arch element of capabilities.xml Specifically, list sub-elements and where they can be used. In addition, describe supported machine types for Xen. Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Reviewed-by: Jim Fehlig <jfehlig@suse.com>
2018-09-19 00:50:30 +00: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>
formatcaps: Rework and add stubs to document At the moment we are missing even basic documentation on our capabilities XML. Without demand on completeness, I'm reorganizing the document structure and adding very basic documentation to two major components of the capabilities XML. These stubs are intended to be enhanced in the future. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-06-05 11:53:17 +00:00
<dt><code>features</code></dt>
<dd>This optional element encases possible features that can be used
docs: mention more about older capability feature bits Our documentation for features was rather sparse; this fleshes out more of the details for other existing capabilities (and cost me some time trawling git history). * docs/formatcaps.html.in: Document it feature bits. Signed-off-by: Eric Blake <eblake@redhat.com>
2014-06-23 21:59:02 +00:00
with a guest of described type. Possible subelements are:
<dl>
docs: Use <code> inside <dt> for symbols Most of the time, the <dt> tag is used when providing documentation for a symbol; enclose symbols in <code> tags to style them appropriately.
2016-04-21 13:23:56 +00:00
<dt><code>pae</code></dt><dd>If present, 32-bit guests can use PAE
docs: mention more about older capability feature bits Our documentation for features was rather sparse; this fleshes out more of the details for other existing capabilities (and cost me some time trawling git history). * docs/formatcaps.html.in: Document it feature bits. Signed-off-by: Eric Blake <eblake@redhat.com>
2014-06-23 21:59:02 +00:00
address space extensions, <span class="since">since
0.4.1</span></dd>
docs: Use <code> inside <dt> for symbols Most of the time, the <dt> tag is used when providing documentation for a symbol; enclose symbols in <code> tags to style them appropriately.
2016-04-21 13:23:56 +00:00
<dt><code>nonpae</code></dt><dd>If present, 32-bit guests can be run
docs: mention more about older capability feature bits Our documentation for features was rather sparse; this fleshes out more of the details for other existing capabilities (and cost me some time trawling git history). * docs/formatcaps.html.in: Document it feature bits. Signed-off-by: Eric Blake <eblake@redhat.com>
2014-06-23 21:59:02 +00:00
without requiring PAE, <span class="since">since
0.4.1</span></dd>
docs: Use <code> inside <dt> for symbols Most of the time, the <dt> tag is used when providing documentation for a symbol; enclose symbols in <code> tags to style them appropriately.
2016-04-21 13:23:56 +00:00
<dt><code>ia64_be</code></dt><dd>If present, IA64 guests can be run in
docs: mention more about older capability feature bits Our documentation for features was rather sparse; this fleshes out more of the details for other existing capabilities (and cost me some time trawling git history). * docs/formatcaps.html.in: Document it feature bits. Signed-off-by: Eric Blake <eblake@redhat.com>
2014-06-23 21:59:02 +00:00
big-endian mode, <span class="since">since 0.4.1</span></dd>
docs: Use <code> inside <dt> for symbols Most of the time, the <dt> tag is used when providing documentation for a symbol; enclose symbols in <code> tags to style them appropriately.
2016-04-21 13:23:56 +00:00
<dt><code>acpi</code></dt><dd>If this element is present,
docs: mention more about older capability feature bits Our documentation for features was rather sparse; this fleshes out more of the details for other existing capabilities (and cost me some time trawling git history). * docs/formatcaps.html.in: Document it feature bits. Signed-off-by: Eric Blake <eblake@redhat.com>
2014-06-23 21:59:02 +00: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>
docs: Use <code> inside <dt> for symbols Most of the time, the <dt> tag is used when providing documentation for a symbol; enclose symbols in <code> tags to style them appropriately.
2016-04-21 13:23:56 +00:00
<dt><code>apic</code></dt><dd>If this element is present,
docs: mention more about older capability feature bits Our documentation for features was rather sparse; this fleshes out more of the details for other existing capabilities (and cost me some time trawling git history). * docs/formatcaps.html.in: Document it feature bits. Signed-off-by: Eric Blake <eblake@redhat.com>
2014-06-23 21:59:02 +00: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>
docs: Use <code> inside <dt> for symbols Most of the time, the <dt> tag is used when providing documentation for a symbol; enclose symbols in <code> tags to style them appropriately.
2016-04-21 13:23:56 +00:00
<dt><code>cpuselection</code></dt><dd>If this element is present, the
docs: mention more about older capability feature bits Our documentation for features was rather sparse; this fleshes out more of the details for other existing capabilities (and cost me some time trawling git history). * docs/formatcaps.html.in: Document it feature bits. Signed-off-by: Eric Blake <eblake@redhat.com>
2014-06-23 21:59:02 +00:00
hypervisor supports the <code>&lt;cpu&gt;</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>
docs: Use <code> inside <dt> for symbols Most of the time, the <dt> tag is used when providing documentation for a symbol; enclose symbols in <code> tags to style them appropriately.
2016-04-21 13:23:56 +00:00
<dt><code>deviceboot</code></dt><dd>If this element is present,
docs: mention more about older capability feature bits Our documentation for features was rather sparse; this fleshes out more of the details for other existing capabilities (and cost me some time trawling git history). * docs/formatcaps.html.in: Document it feature bits. Signed-off-by: Eric Blake <eblake@redhat.com>
2014-06-23 21:59:02 +00:00
the <code>&lt;boot order='...'/&gt;</code> element can
be used inside devices, rather than the older boot
specification by category. <span class="since">Since
0.8.8</span></dd>
docs: Use <code> inside <dt> for symbols Most of the time, the <dt> tag is used when providing documentation for a symbol; enclose symbols in <code> tags to style them appropriately.
2016-04-21 13:23:56 +00:00
<dt><code>disksnapshot</code></dt><dd>If this element is present,
docs: mention more about older capability feature bits Our documentation for features was rather sparse; this fleshes out more of the details for other existing capabilities (and cost me some time trawling git history). * docs/formatcaps.html.in: Document it feature bits. Signed-off-by: Eric Blake <eblake@redhat.com>
2014-06-23 21:59:02 +00: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>
formatcaps: Rework and add stubs to document At the moment we are missing even basic documentation on our capabilities XML. Without demand on completeness, I'm reorganizing the document structure and adding very basic documentation to two major components of the capabilities XML. These stubs are intended to be enhanced in the future. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-06-05 11:53:17 +00:00
</dl>
docs: switch to using 'id' attribute instead of 'name' for links The 'name' attribute on <a...> elements is deprecated in favour of the 'id' attribute which is allowed on any element. HTML5 drops 'name' support entirely. Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2017-07-26 14:52:42 +00:00
<h3><a id="elementExamples">Examples</a></h3>
formatcaps: Rework and add stubs to document At the moment we are missing even basic documentation on our capabilities XML. Without demand on completeness, I'm reorganizing the document structure and adding very basic documentation to two major components of the capabilities XML. These stubs are intended to be enhanced in the future. Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-06-05 11:53:17 +00: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>&lt;capabilities&gt;
Split website out into one file per page. APply new layout and styling
2008-04-23 17:08:31 +00:00
<span style="color: #E50000">&lt;host&gt;
&lt;cpu&gt;
&lt;arch&gt;x86_64&lt;/arch&gt;
&lt;features&gt;
&lt;vmx/&gt;
&lt;/features&gt;
Document <cpu> elements in capabilities and domain XML Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2010-01-19 17:22:45 +00:00
&lt;model&gt;core2duo&lt;/model&gt;
cpu: Add support for CPU vendor By specifying <vendor> element in CPU requirements a guest can be restricted to run only on CPUs by a given vendor. Host CPU vendor is also specified in capabilities XML. The vendor is checked when migrating a guest but it's not forced, i.e., guests configured without <vendor> element can be freely migrated.
2010-07-02 15:51:59 +00:00
&lt;vendor&gt;Intel&lt;/vendor&gt;
conf: add support for specifying CPU "dies" parameter Recently CPU hardware vendors have started to support a new structure inside the CPU package topology known as a "die". Thus the hierarchy is now: sockets > dies > cores > threads This adds support for "dies" in the XML parser, with the value defaulting to 1 if not specified for backwards compatibility. For example a system with 64 logical CPUs might report <topology sockets="4" dies="2" cores="4" threads="2"/> Reviewed-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-12-16 11:16:51 +00:00
&lt;topology sockets="1" dies="1" cores="2" threads="1"/&gt;
Document <cpu> elements in capabilities and domain XML Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2010-01-19 17:22:45 +00:00
&lt;feature name="lahf_lm"/&gt;
&lt;feature name='xtpr'/&gt;
...
Split website out into one file per page. APply new layout and styling
2008-04-23 17:08:31 +00:00
&lt;/cpu&gt;
Export KVM Host Power Management capabilities This patch exports KVM Host Power Management capabilities as XML so that higher-level systems management software can make use of these features available in the host. The script "pm-is-supported" (from pm-utils package) is run to discover if Suspend-to-RAM (S3) or Suspend-to-Disk (S4) is supported by the host. If either of them are supported, then a new tag "<power_management>" is introduced in the XML under the <host> tag. However in case the query to check for power management features succeeded, but the host does not support any such feature, then the XML will contain an empty <power_management/> tag. In the event that the PM query itself failed, the XML will not contain any "power_management" tag. To use this, new APIs could be implemented in libvirt to exploit power management features such as S3/S4.
2011-11-22 03:31:22 +00:00
&lt;power_management&gt;
Fix capabilities XML to use generic terms for suspend targets The capabilities XML uses the x86 specific terms 'S3', 'S4' and 'Hybrid-Syspend'. Switch it to use the same terminology as the API constants and virsh options, eg 'suspend_mem' 'suspend_disk' and 'suspend_hybrid' * docs/formatcaps.html.in, docs/schemas/capability.rng, src/conf/capabilities.c: Rename suspend constants
2011-11-29 14:14:03 +00:00
&lt;suspend_mem/&gt;
&lt;suspend_disk/&gt;
&lt;suspend_hybrid/&gt;
Minor typo fixes in documentation Signed-off-by: Christian Loehle <cloehle@linutronix.de>
2015-09-15 09:15:06 +00:00
&lt;/power_management&gt;
Split website out into one file per page. APply new layout and styling
2008-04-23 17:08:31 +00:00
&lt;/host&gt;</span>
&lt;!-- xen-3.0-x86_64 --&gt;
<span style="color: #0000E5">&lt;guest&gt;
&lt;os_type&gt;xen&lt;/os_type&gt;
&lt;arch name="x86_64"&gt;
&lt;wordsize&gt;64&lt;/wordsize&gt;
&lt;domain type="xen"&gt;&lt;/domain&gt;
&lt;emulator&gt;/usr/lib64/xen/bin/qemu-dm&lt;/emulator&gt;
&lt;/arch&gt;
&lt;features&gt;
&lt;/features&gt;
&lt;/guest&gt;</span>
&lt;!-- hvm-3.0-x86_32 --&gt;
<span style="color: #00B200">&lt;guest&gt;
&lt;os_type&gt;hvm&lt;/os_type&gt;
&lt;arch name="i686"&gt;
&lt;wordsize&gt;32&lt;/wordsize&gt;
&lt;domain type="xen"&gt;&lt;/domain&gt;
&lt;emulator&gt;/usr/lib/xen/bin/qemu-dm&lt;/emulator&gt;
&lt;machine&gt;pc&lt;/machine&gt;
&lt;machine&gt;isapc&lt;/machine&gt;
&lt;loader&gt;/usr/lib/xen/boot/hvmloader&lt;/loader&gt;
&lt;/arch&gt;
&lt;features&gt;
Document <cpu> elements in capabilities and domain XML Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2010-01-19 17:22:45 +00:00
&lt;cpuselection/&gt;
Introduce per-device boot element Currently, boot order can be specified per device class but there is no way to specify exact disk/NIC device to boot from. This patch adds <boot order='N'/> element which can be used inside <disk/> and <interface/>. This is incompatible with the older os/boot element. Since not all hypervisors support per-device boot specification, new deviceboot flag is included in capabilities XML for hypervisors which understand the new boot element. Presence of the flag allows (but doesn't require) users to use the new style boot order specification.
2011-01-12 14:19:34 +00:00
&lt;deviceboot/&gt;
Split website out into one file per page. APply new layout and styling
2008-04-23 17:08:31 +00:00
&lt;/features&gt;
&lt;/guest&gt;</span>
...
&lt;/capabilities&gt;</pre>
</body>
</html>
Reference in New Issue Copy Permalink