NuKVM/libvirt
3
0
Fork 0
mirror of https://github.com/libvirt/libvirt.git synced 2025-02-25 18:55:26 -06:00
Code Issues Packages Projects Releases Wiki Activity

docs: Update description of the host-model CPU mode

Browse Source 
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
This commit is contained in:
Jiri Denemark 2017-02-15 10:18:53 +01:00
parent 0bde051f3d
commit d2f8f3052d
1 changed files with 24 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

37
docs/formatdomain.html.in
View File

@ -1272,19 +1272,21 @@
model even if the destination host contains more capable CPUs for model even if the destination host contains more capable CPUs for
the running instance of the guest; but shutting down and restarting the running instance of the guest; but shutting down and restarting
the guest may present different hardware to the guest according to the guest may present different hardware to the guest according to
the capabilities of the new host. <strong>Beware</strong>, due to the the capabilities of the new host. Prior to libvirt 3.2.0 and QEMU
way libvirt detects host CPU and due to the fact libvirt does not 2.9.0 detection of the host CPU model via QEMU is not supported.
talk to QEMU/KVM when creating the CPU model, CPU configuration Thus the CPU configuration created using <code>host-model</code>
created using <code>host-model</code> may not work as expected. The may not work as expected.
guest CPU may differ from the configuration and it may also confuse <span class="since">Since 3.2.0 and QEMU 2.9.0</span> this mode
guest OS by using a combination of CPU features and other parameters works the way it was designed and it is indicated by the
(such as CPUID level) that don't work. Until these issues are fixed, <code>fallback</code> attribute set to <code>forbid</code> in the
it's a good idea to avoid using <code>host-model</code> and use host-model CPU definition advertised in
<code>custom</code> mode with just the CPU model from host <a href="formatdomaincaps.html#elementsCPU">domain capabilities XML</a>.
capabilities XML. When <code>fallback</code> attribute is set to <code>allow</code>
<span class="since">Since 1.2.11</span> PowerISA allows in the domain capabilities XML, it is recommended to use
processors to run VMs in binary compatibility mode supporting an <code>custom</code> mode with just the CPU model from the host
older version of ISA. Libvirt on PowerPC architecture uses the capabilities XML. <span class="since">Since 1.2.11</span> PowerISA
allows processors to run VMs in binary compatibility mode supporting
an older version of ISA. Libvirt on PowerPC architecture uses the
<code>host-model</code> to signify a guest mode CPU running in <code>host-model</code> to signify a guest mode CPU running in
binary compatibility mode. Example: binary compatibility mode. Example:
When a user needs a power7 VM to run in compatibility mode When a user needs a power7 VM to run in compatibility mode
@ -1307,6 +1309,15 @@
a migration is attempted then the guest may hang or crash upon a migration is attempted then the guest may hang or crash upon
resuming execution on the destination host.</dd> resuming execution on the destination host.</dd>
</dl> </dl>
Both <code>host-model</code> and <code>host-passthrough</code> modes
make sense when a domain can run directly on the host CPUs (for
example, domains with type <code>kvm</code>). The actual host CPU is
irrelevant for domains with emulated virtual CPUs (such as domains with
type <code>qemu</code>). However, for backward compatibility
<code>host-model</code> may be implemented even for domains running on
emulated CPUs in which case the best CPU the hypervisor is able to
emulate may be used rather then trying to mimic the host CPU model.
</dd> </dd>
<dt><code>model</code></dt> <dt><code>model</code></dt>