Alex Bligh <alex(a)alex.org.uk> writes:
This patch series 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-...
however, rather than patching statically (and breaking inbound
migration on existing machine types), I have added a new machine
parameter (qemu-kvm-migration) which when turned on affects the pc-1.0
machine type. Usage:
-machine pc-1.0,qemu-kvm-migration=on
Forgive me if this has been discussed already: why not simply a separate
machine type "pc-1.0-qemu-kvm"?
Three aproaches are taken:
* cirrus-vga.vgamem_mb defaults to 16 rather than 8. In order to
keep -global cirrus-vga.vgamem_mb working even with
qemu-kvm-migration=on, this is monkey-patched into the default
value of the MachineState structure's compat_props list.
This part fires only for pc-1.0, because it's in
pc_early_init_pci_1_0().
* In hw/timer/i8254_common.c, the VMSTATE_UINT32_TEST macro
is used to test the version for the irq_disable flags,
allowing version 3 or more, or version 2 for an inbound
migrate from qemu-kvm (only).
* In hw/acpi/piix4.c, qemu-kvm incorrectly uses version 2 for
a version 3 structure, causing acpi_load_old to be used.
acpi_load_old detects this situation based on the machine type
and restarts the attempt to load the vmstate using a
customised VMStateDescription. The above cleaner approach is
unavailable here.
These parts apply to all machine types, don't they?
The above monkey-patching must be done between the selection of
the MachineClass and the processing of the machine parameters
(on the one hand) and the processing of the compat_props list
and the globals on the command line. To do this I have added
an earlyinit function to MachineState and QEMUMachine.
I developed this on qemu 2.0 but have forward ported it (trivially)
to master. My testing has been on a VM live-migrated-to-file from
Ubuntu Precise qemu-kvm 1.0.
I have given this a moderate degree of testing but it could do
with more.
Note that certain hardware devices (including QXL) will not
migrate properly due to a fundamental difference in their internal
state between versions.
Also note that (as expected) migration from qemu-2.x to qemu-1.0
will not work, even if the machine types are the same.
Changes since v1:
* Do not use a machine type, use a machine parameter.
Okay, it has been discussed already. I'd appreciate a brief recap all
the same.