The guest CPU definition has always been updated automatically during
migration. And currently we just transform any host-model CPU into a
custom one when a domain starts.
Signed-off-by: Jiri Denemark <jdenemar@xxxxxxxxxx>
---
docs/formatdomain.html.in | 10 ----------
1 file changed, 10 deletions(-)
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index 0a115f5dc..bc125ed63 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -1307,16 +1307,6 @@
a migration is attempted then the guest may hang or crash upon
resuming execution on the destination host.</dd>
</dl>
-
- In both <code>host-model</code> and <code>host-passthrough</code>
- mode, the real (approximate in <code>host-passthrough</code> mode) CPU
- definition which would be used on current host can be determined by
- specifying <code>VIR_DOMAIN_XML_UPDATE_CPU</code> flag when calling
- <code>virDomainGetXMLDesc</code> API. When running a guest that might
- be prone to operating system reactivation when presented with
- different hardware, and which will be migrated between hosts with
- different capabilities, you can use this output to rewrite XML to the
- <code>custom</code> mode for more robust migration.
</dd>
<dt><code>model</code></dt>
--
2.11.1
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
