[libvirt] [PATCH v2 3/6] Add support for cpu mode attribute

[Eric Blake]

On 01/12/2012 04:02 AM, Jiri Denemark wrote:
> The mode can be either of "custom" (default), "host-model",
> "host-passthrough". The semantics of each mode is described in the
> following examples:
> 

> ---
> Notes:
>     Version 2:
>     - added documentation
>     - fixed XML examples and schema
> 

Thanks, that's what I was waiting for in v1.

> +++ b/docs/formatdomain.html.in

> +          <dt><code>host-model</code></dt>
> +          <dd>The <code>host-model</code> mode is essentially a shortcut to
> +          copying host CPU definition from capabilities XML into domain XML.
> +          Since the CPU definition is copied just before starting a domain,
> +          exactly the same XML can be used on different hosts while still
> +          providing the best guest CPU each host supports. Neither
> +          <code>match</code> attribute nor any <code>feature</code> elements
> +          can be used in this mode. Specifying CPU model is not supported
> +          either, but <code>model</code>'s <code>fallback</code> attribute may
> +          still be used. Libvirt does not model every aspect of each CPU so
> +          the guest CPU will not match the host CPU exactly. On the other
> +          hand, the ABI provided to the guest is reproducible. During
> +          migration, complete CPU model definition is transferred to the
> +          destination host so the migrated guest will see exactly the same CPU
> +          model even if the destination host contains more capable CPUs.</dd>

Question - if I start on a less-powerful CPU, then live migrate to a
more powerful CPU, then restart the guest, did the migration lock me in
to the less-powerful capabilities, or does restarting the guest then
pick up on the more-powerful capabilities?  I'm guessing the former
(once you migrate, you want to be locked in), because otherwise, the act
of migration followed by guest reboot would make Windows guests
susceptible to reactivation.  In which case, I think rewording the last
sentence might help:

During migration, or after using the VIR_DOMAIN_XML_UPDATE_CPU flag to
virDomainGetXMLDesc, the XML is persistently rewritten to the CPU model
definition that was in use when the guest was started, so that
subsequent boots of the guest, even when migrated to a destination host
with a more capable CPU, will see the same CPU features as on the first
boot.

Then again, you mention this flag later on, so maybe it is sufficient to
use:

Upon migration, the XML is persistently rewritten to the CPU model
definition that was in use when the guest was started, so that
subsequent boots of the guest, even where the destination has a more
capable CPU, will see the same CPU features as on the first boot.

> +          <dt><code>host-passthrough</code></dt>
> +          <dd>With this mode, the CPU visible to the guest should be exactly
> +          the same as the host CPU even in the aspects that libvirt does not
> +          understand. Though the downside of this mode is that the guest

s/Though the/The/

> +          environment cannot be reproduced on different hardware. Thus, if you
> +          hit any bugs, you are on your own. Neither <code>model</code> nor
> +          <code>feature</code> elements are allowed in this mode.</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.

ACK with the doc nits addressed.

-- 
Eric Blake   eblake at redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 620 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20120116/d94d1809/attachment-0001.sig>