Re: [Qemu-devel] [RFC PATCH] pc: change default machine model and versions

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2089 bytes --]

On 04/03/2012 01:38 PM, Anthony Liguori wrote:
> N.B. This is a small patch with significant implications.  Please read
> carefully.

> 
> With this patch, we will not introduce any more '-M pc-1.x' beyond 'pc-1.0'.
> We will not introduce a new 'pc-X.Y' until the QEMU 2.0 release (1Q 2014).
> Instead, we will introduce a 'pc-next' machine type that is *not* the default
> machine type.  If you omit a '-M' option, you will get '-M pc-1.0'.  However,
> if you want to test the latest and greatest, you will need to use an explicit
> '-M pc-next'.
> 
> The main motivation for this change is to provide stronger migration
> compatibility statements.  Namely, our migration policy would be:
> 
> 1) '-M pc-1.0' will be fully supported for all QEMU 1.x and QEMU 2.x releases.
>    Migrating when using '-M pc-1.0' will work across any version of 1.x or 2.x.
>    Failures here would be treated as a release blocker.
> 
> 2) '-M pc-2.0' will be introduced in QEMU 2.0, and supported throughout the 2.x
>     and 3.x release cycles.  New machine types are introduced only every two
>     years and migration is supported for an additional two years for a total
>     of four years.
> 
> 3) '-M pc-next' will be fully supported for all QEMU releases.  Migrating
>    between QEMU versions using '-M pc-next' is guaranteed to either succeed or
>    fail gracefully.  Not failing gracefully would be considered a release
>    blocker.  In general, only power users should consider using '-M pc-next'.

Sounds reasonable from my point of view on libvirt's perspective.  We
may have a minor bit of work to make it all happen, but as long as there
is an advertisement of the name pc-next as a valid machine name, it
should be enough for us to key off of when deciding whether we are
talking to old or new qemu and adjust our command line generation
accordingly.  CC'ing Jiri Denemark, as the libvirt engineer most closely
tied to machine name issues.

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 620 bytes --]