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

[Ayal Baron]

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

I agree that every 3 months seems excessive but moving from this to every 24 
months seems to me to be taking it too far (and would cause too many problems).
There is a balance to be struck here and I think it should be somewhere between 
6 and 12 months.
Take for example a qemu released 6 month before V2.0 and another one released 3 
months before V2.0, assuming the latter has some changes in it so that pc-next 
means something else, in order to be able to migrate a VM between them I'd need 
to use -M pc1.0 which would be at least 21 months old and not be able to use 
any of the features introduced during this time.  

I have little doubt this would not hold water downstream where we'd have to 
have a compatibility version per minor RHEL release.

> 
> 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 <address@hidden>
> Cc: Andreas Faerber <address@hidden>
> Cc: Avi Kivity <address@hidden>
> Cc: Daniel P. Berrange <address@hidden>
> Cc: Eric Blake <address@hidden>
> Cc: Ayal Baron <address@hidden>
> Signed-off-by: Anthony Liguori <address@hidden>
> ---
>  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
> 
>