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

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

[Anthony Liguori]

N.B. This is a small patch with significant implications.  Please read
carefully.

Right now, '-M pc' is the default and, in general, this machine type has guest
visible ABI changes in each version of QEMU.  At some point in each release,
we create a '-M pc-X.Y' corresponding to the last release and attempt to make
that look like the previous QEMU version's machine.

We've accumulated a bunch of '-M pc-X.Y's at this point and if we move to a
three month release process, the problem will get much worse.

This is a proposal to change the way we do things in order to simplify
compatibility and present a very clear statement of what we support.

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

I think enables us to do a better job providing robust support while also
simplifying what we realistically have to test.

I've avoided CC'ing libvirt and vdsm lists here although I think this certainly
also affects them significantly.  I've tried to include the appropriate folks
here.  Please reach out to anyone else who may have input here as I think
figuring out what we want to support for migration is a wider community
discussion.

I would hope that the distributions would also adopt a similar policy of
avoiding introducing a large number of machine types too.  I think this is the
only practical way to achieve long term migration compatibility.

Cc: Michael Roth <mdroth@linux.vnet.ibm.com>
Cc: Andreas Faerber <afaerber@suse.de>
Cc: Avi Kivity <avi@redhat.com>
Cc: Daniel P. Berrange <berrange@redhat.com>
Cc: Eric Blake <eblake@redhat.com>
Cc: Ayal Baron <abaron@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
---
 hw/pc_piix.c |   23 ++++++++++++++++++-----
 1 files changed, 18 insertions(+), 5 deletions(-)

diff --git a/hw/pc_piix.c b/hw/pc_piix.c
index fadca4c..d6767fa 100644
--- a/hw/pc_piix.c
+++ b/hw/pc_piix.c
@@ -350,20 +350,33 @@ static void pc_xen_hvm_init(ram_addr_t ram_size,
 }
 #endif
 
-static QEMUMachine pc_machine_v1_1 = {
-    .name = "pc-1.1",
-    .alias = "pc",
+/**
+ * This is the machine type for all future changes until the 2.0 release.
+ *
+ * This machine type is not "stable" from release to release in terms of what
+ * virtual hardware is presented to the guest.  Migration from this machine
+ * among different releases is only guaranteed to succeed or fail gracefully.
+ * It's likely to fail gracefully across versions practically speaking.
+ */
+static QEMUMachine pc_machine_next = {
+    .name = "pc-next",
     .desc = "Standard PC",
     .init = pc_init_pci,
     .max_cpus = 255,
-    .is_default = 1,
 };
 
+/**
+ * This is the default machine for any release in the 1.x release series.
+ * Breaking migration from pc-1.0 between QEMU versions would be considered a
+ * release blocker up until the QEMU 3.0 release.
+ */
 static QEMUMachine pc_machine_v1_0 = {
     .name = "pc-1.0",
+    .alias = "pc",
     .desc = "Standard PC",
     .init = pc_init_pci,
     .max_cpus = 255,
+    .is_default = 1,
     .compat_props = (GlobalProperty[]) {
         {
             .driver   = "pc-sysfw",
@@ -732,7 +745,7 @@ static QEMUMachine xenfv_machine = {
 
 static void pc_machine_init(void)
 {
-    qemu_register_machine(&pc_machine_v1_1);
+    qemu_register_machine(&pc_machine_next);
     qemu_register_machine(&pc_machine_v1_0);
     qemu_register_machine(&pc_machine_v0_15);
     qemu_register_machine(&pc_machine_v0_14);
-- 
1.7.5.4

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

[Eric Blake]

[-- 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 --]