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

[Eric Blake]

On 01/16/2012 01:59 PM, Jiri Denemark wrote:
> On Mon, Jan 16, 2012 at 13:38:00 -0700, Eric Blake wrote:
>> 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:
>>>

>>
>>> +          <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:
> 
> It depends what do you mean by guest restart :-) Restarting guest OS within
> the same qemu process certainly doesn't change anything. However, the CPU may
> change if you shut the domain down and start it again. The updated CPU is not
> persistently stored anywhere even if you ask libvirt to define the domain on
> destination. The inactive XML on destination will be the same as the one
> on source. The main benefit of host-* CPU modes is that they give you the
> semantics of "anywhere you start me, I'll use the best of your CPUs", be it
> after migration or manual copying of the XML. It is only assured not to change
> while the guest is running even after it's migrated. Those who want stability
> may use the custom mode we already support for ~2 years.
> 
> Do you suggest any changes so that it's more obvious from the docs?

How about:

custom
  In this mode, the <code>cpu</code> element describes the CPU that
should be presented to the guest. This is the default when no
<code>mode</code> attribute is specified.  This mode makes it so that a
persistent guest will see the same hardware, and thus avoid the need for
operating system reactivation, no matter what host the guest is booted on.

host-model
 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 for the running instance of the guest; but shutting down
and restarting the guest may present different hardware to the guest
according to the capabilities of the new host, and thus trigger an
operating system reactivation.

 host-passthrough
...

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>.  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.

-- 
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/f50c8a0f/attachment-0001.sig>