----- 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 <mdr...@linux.vnet.ibm.com>
> Cc: Andreas Faerber <afaer...@suse.de>
> Cc: Avi Kivity <a...@redhat.com>
> Cc: Daniel P. Berrange <berra...@redhat.com>
> Cc: Eric Blake <ebl...@redhat.com>
> Cc: Ayal Baron <aba...@redhat.com>
> Signed-off-by: Anthony Liguori <aligu...@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
>
>
