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