Re: [libvirt] [Qemu-devel] [PATCH] [RFC] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm
Hi Alex, + quintela, mst, libvirt Am 22.07.2014 20:43, schrieb Alex Bligh:
Add a machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm version 1.0.
Signed-off-by: Alex Bligh <alex@alex.org.uk> --- hw/acpi/piix4.c | 49 ++++++++++++++++++++++++++++++++++++++++++++-- hw/i386/pc_piix.c | 31 +++++++++++++++++++++++++++++ hw/timer/i8254_common.c | 41 ++++++++++++++++++++++++++++++++++++++ include/hw/acpi/piix4.h | 1 + include/hw/timer/i8254.h | 2 ++ 5 files changed, 122 insertions(+), 2 deletions(-)
This RFC patch adds inbound migrate capability from qemu-kvm version 1.0. The main ideas are those set out in Cole Robinson's patch here: http://pkgs.fedoraproject.org/cgit/qemu.git/tree/0001-Fix-migration-from-qem... however, rather than patching statically (and breaking inbound migration on existing machine types), I have added a new machine type (pc-1.0-qemu-kvm) without affecting any other machine types.
This sounds like a really cool feature that SUSE would probably be interested in extending back to 0.14 and 0.15, but I see a fundamental flaw: libvirt on those old source systems does not know it should use a different machine name on the destination side and would still use pc-1.0, wouldn't it? After all, it needs to be able to migrate to other old qemu-kvm machines, so it can't just be updated to use the new name. Minor bikeshedding: I would ask to keep the package name in front of the machine version, e.g. qemu-kvm-pc-1.0. Or just kvm-pc-1.0 since this is a QEMU parameter anyway. Haven't reviewed the code in detail yet. Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Andreas, On 27 Jul 2014, at 15:10, Andreas Färber <afaerber@suse.de> wrote:
Hi Alex,
+ quintela, mst, libvirt
Thanks for your comments!
This sounds like a really cool feature that SUSE would probably be interested in extending back to 0.14 and 0.15, but I see a fundamental flaw: libvirt on those old source systems does not know it should use a different machine name on the destination side and would still use pc-1.0, wouldn't it? After all, it needs to be able to migrate to other old qemu-kvm machines, so it can't just be updated to use the new name.
Right. I'm not using libvirt but face a similar problem. The destination libvirt (or equivalent) now has two 'pc-1.0' machine types. One (allegedly) use by qemu-git 1.0, and one used by qemu-kvm 1.0. The name 'pc-1.0' needs to refer to exactly one of these (obviously), and it currently refers to qemu-git 1.0, so I've left it that way. In a distribution environment where qemu-1.0 was never used, one might want to make my new machine type called 'pc-1.0' and the existing qemu.git pc-1.0 called 'pc-1.0-qemu-git' or similar. Why don't I just change it? Well, imagine someone running Ubuntu 13.04 (say) which shipped with an early post merge qemu made a machine with machine type pc-1.0. Despite the fact that Ubuntu 12.04 was shipped with qemu-kvm (and hence -m pc-1.0 there meant qemu-kvm's pc-1.0), on 13.04, this would mean qemu-git's pc-1.0, and changing the name would break the migration of an Ubuntu 13.04 pc-1.0 machine, whilst fixing migration of a 12.04 pc-1.0 machine. Let no one say this isn't a mess. So, I'm expect whatever generates the qemu command line to know (from the other end) whether to use the different version. Perhaps a slightly nicer fix, if somewhat rococo, would be: * Use pc-1.0-qemu-kvm as one machine name * Use pc-1.0-qemu-git as another machine name * Make pc-1.0 an alias of either one or the other, configurable at the command line, and subject to a build-time default. This would let distributions / users simply decide which kind of pc-1.0 migration they'd like by working by default, and which they'd like broken; the broken one is a second class citizen which can only handle migration by changing the qemu command line appropriately. This would perhaps make things more transparent by default. BTW I would agree this is a significant issue, having spent quite a lot of today playing with stuff that (mis)parses "qemu -version" Also BTW, I did wonder whether I could autodetect this from the stream. However, as it has to be read serially, by the time you know it's wrong, you are too late AFAICT. Useful suggestion in case of future accidental breakage: put the qemu version in a section right up top.
Minor bikeshedding: I would ask to keep the package name in front of the machine version, e.g. qemu-kvm-pc-1.0. Or just kvm-pc-1.0 since this is a QEMU parameter anyway.
Obviously not a matter of great import, but per the list below, the standard appears to be 'pc-(arch)?-version' and I'd taken this as a subversion. # qemu-system-x86_64 -machine '?' Supported machines are: pc-0.13 Standard PC (i440FX + PIIX, 1996) pc-i440fx-2.0 Standard PC (i440FX + PIIX, 1996) pc-1.0 Standard PC (i440FX + PIIX, 1996) pc-q35-1.7 Standard PC (Q35 + ICH9, 2009) pc-1.1 Standard PC (i440FX + PIIX, 1996) q35 Standard PC (Q35 + ICH9, 2009) (alias of pc-q35-2.0) pc-q35-2.0 Standard PC (Q35 + ICH9, 2009) pc-i440fx-1.4 Standard PC (i440FX + PIIX, 1996) pc-i440fx-1.5 Standard PC (i440FX + PIIX, 1996) pc-0.14 Standard PC (i440FX + PIIX, 1996) pc-0.15 Standard PC (i440FX + PIIX, 1996) xenfv Xen Fully-virtualized PC pc-q35-1.4 Standard PC (Q35 + ICH9, 2009) isapc ISA-only PC pc-0.10 Standard PC (i440FX + PIIX, 1996) pc Ubuntu 14.04 PC (i440FX + PIIX, 1996) (alias of pc-i440fx-trusty) pc-i440fx-trusty Ubuntu 14.04 PC (i440FX + PIIX, 1996) (default) pc-1.2 Standard PC (i440FX + PIIX, 1996) pc-0.11 Standard PC (i440FX + PIIX, 1996) pc-i440fx-1.7 Standard PC (i440FX + PIIX, 1996) pc-i440fx-1.6 Standard PC (i440FX + PIIX, 1996) none empty machine xenpv Xen Para-virtualized PC pc-q35-1.5 Standard PC (Q35 + ICH9, 2009) pc-1.0-qemu-kvm Standard PC (i440FX + PIIX, 1996) pc-q35-1.6 Standard PC (Q35 + ICH9, 2009) pc-0.12 Standard PC (i440FX + PIIX, 1996) pc-1.3 Standard PC (i440FX + PIIX, 1996) -- Alex Bligh
participants (2)
-
Alex Bligh -
Andreas Färber