[libvirt] [PATCH v2 0/2] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm
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-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. The existing pc-1.0 machine type is renamed to pc-1.0-qemu-git, with pc-1.0 becoming an alias for one or another, as selected by a configure option (defaulting to pc-1.0-qemu-git, IE no change). This requires 'hot patching' the VMStateDescription in a couple of places, which in turn is less than obvious as there may be (indeed are for i8259) derived classes. Whilst pretty nausea-inducing, this approach has the benefit of being entirely self-contained. 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) migratino from qemu-2.x to qemu-1.0 will not work, even if the machine types are the same. Alex Bligh (2): Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm Add configure option --enable-pc-1-0-qemu-kvm configure | 12 ++++++++++++ hw/acpi/piix4.c | 49 ++++++++++++++++++++++++++++++++++++++++++++-- hw/i386/pc_piix.c | 39 +++++++++++++++++++++++++++++++++++- hw/timer/i8254_common.c | 41 ++++++++++++++++++++++++++++++++++++++ include/hw/acpi/piix4.h | 1 + include/hw/timer/i8254.h | 2 ++ 6 files changed, 141 insertions(+), 3 deletions(-) -- 1.7.9.5
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(-) diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c index b72b34e..708db79 100644 --- a/hw/acpi/piix4.c +++ b/hw/acpi/piix4.c @@ -267,8 +267,9 @@ static const VMStateDescription vmstate_memhp_state = { }; /* qemu-kvm 1.2 uses version 3 but advertised as 2 - * To support incoming qemu-kvm 1.2 migration, change version_id - * and minimum_version_id to 2 below (which breaks migration from + * To support incoming qemu-kvm 1.2 migration, we support + * via a command line option a change to minimum_version_id + * of 2 in a _compat structure (which breaks migration from * qemu 1.2). * */ @@ -307,6 +308,34 @@ static const VMStateDescription vmstate_acpi = { } }; +static const VMStateDescription vmstate_acpi_compat = { + .name = "piix4_pm", + .version_id = 3, + .minimum_version_id = 2, + .minimum_version_id_old = 1, + .load_state_old = acpi_load_old, + .post_load = vmstate_acpi_post_load, + .fields = (VMStateField[]) { + VMSTATE_PCI_DEVICE(parent_obj, PIIX4PMState), + VMSTATE_UINT16(ar.pm1.evt.sts, PIIX4PMState), + VMSTATE_UINT16(ar.pm1.evt.en, PIIX4PMState), + VMSTATE_UINT16(ar.pm1.cnt.cnt, PIIX4PMState), + VMSTATE_STRUCT(apm, PIIX4PMState, 0, vmstate_apm, APMState), + VMSTATE_TIMER(ar.tmr.timer, PIIX4PMState), + VMSTATE_INT64(ar.tmr.overflow_time, PIIX4PMState), + VMSTATE_STRUCT(ar.gpe, PIIX4PMState, 2, vmstate_gpe, ACPIGPE), + VMSTATE_STRUCT_TEST( + acpi_pci_hotplug.acpi_pcihp_pci_status[ACPI_PCIHP_BSEL_DEFAULT], + PIIX4PMState, + vmstate_test_no_use_acpi_pci_hotplug, + 2, vmstate_pci_status, + struct AcpiPciHpPciStatus), + VMSTATE_PCI_HOTPLUG(acpi_pci_hotplug, PIIX4PMState, + vmstate_test_use_acpi_pci_hotplug), + VMSTATE_END_OF_LIST() + } +}; + static void piix4_reset(void *opaque) { PIIX4PMState *s = opaque; @@ -619,6 +648,22 @@ static void piix4_pm_class_init(ObjectClass *klass, void *data) adevc->ospm_status = piix4_ospm_status; } +void piix4_pm_class_fix_compat(void) +{ + GSList *el, *devices = object_class_get_list(TYPE_DEVICE, false); + /* + * Change the vmstate field in this class and any derived classes + * if not overriden. As no other classes should be using this + * vmstate, we can simply iterate the class list + */ + for (el = devices; el; el = el->next) { + DeviceClass *dc = el->data; + if (dc->vmsd == &vmstate_acpi) { + dc->vmsd = &vmstate_acpi_compat; + } + } +} + static const TypeInfo piix4_pm_info = { .name = TYPE_PIIX4_PM, .parent = TYPE_PCI_DEVICE, diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c index 7081c08..e400ea6 100644 --- a/hw/i386/pc_piix.c +++ b/hw/i386/pc_piix.c @@ -49,6 +49,8 @@ #include "hw/acpi/acpi.h" #include "cpu.h" #include "qemu/error-report.h" +#include "hw/acpi/piix4.h" +#include "hw/timer/i8254.h" #ifdef CONFIG_XEN # include <xen/hvm/hvm_info_table.h> #endif @@ -386,6 +388,15 @@ static void pc_init_pci_1_2(MachineState *machine) pc_init_pci(machine); } +/* PC machine init function for qemu-kvm 1.0 */ +static void pc_init_pci_1_2_qemu_kvm(MachineState *machine) +{ + piix4_pm_class_fix_compat(); + pit_common_class_fix_compat(); + pc_compat_1_2(machine); + pc_init_pci(machine); +} + /* PC init function for pc-0.10 to pc-0.13 */ static void pc_init_pci_no_kvmclock(MachineState *machine) { @@ -644,6 +655,25 @@ static QEMUMachine pc_machine_v1_0 = { .hw_version = "1.0", }; +#define PC_COMPAT_1_0_QEMU_KVM \ + PC_COMPAT_1_0,\ + {\ + .driver = "cirrus-vga",\ + .property = "vgamem_mb",\ + .value = stringify(16),\ + } + +static QEMUMachine pc_machine_v1_0_qemu_kvm = { + PC_I440FX_1_2_MACHINE_OPTIONS, + .name = "pc-1.0-qemu-kvm", + .init = pc_init_pci_1_2_qemu_kvm, + .compat_props = (GlobalProperty[]) { + PC_COMPAT_1_0_QEMU_KVM, + { /* end of list */ } + }, + .hw_version = "1.0", +}; + #define PC_COMPAT_0_15 \ PC_COMPAT_1_0 @@ -886,6 +916,7 @@ static void pc_machine_init(void) qemu_register_pc_machine(&pc_machine_v1_2); qemu_register_pc_machine(&pc_machine_v1_1); qemu_register_pc_machine(&pc_machine_v1_0); + qemu_register_pc_machine(&pc_machine_v1_0_qemu_kvm); qemu_register_pc_machine(&pc_machine_v0_15); qemu_register_pc_machine(&pc_machine_v0_14); qemu_register_pc_machine(&pc_machine_v0_13); diff --git a/hw/timer/i8254_common.c b/hw/timer/i8254_common.c index 07345f6..511ea05 100644 --- a/hw/timer/i8254_common.c +++ b/hw/timer/i8254_common.c @@ -275,6 +275,29 @@ static const VMStateDescription vmstate_pit_common = { } }; +static const VMStateDescription vmstate_pit_common_compat = { + .name = "i8254", + .version_id = 3, + .minimum_version_id = 2, + .minimum_version_id_old = 1, + .load_state_old = pit_load_old, + .pre_save = pit_dispatch_pre_save, + .post_load = pit_dispatch_post_load, + .fields = (VMStateField[]) { + /* qemu-kvm version_id=2 had 'flags' here which is equivalent + * This fixes incoming migration from qemu-kvm 1.0, but breaks + * incoming migration from qemu < 1.1 + */ + /* VMSTATE_UINT32_V(channels[0].irq_disabled, PITCommonState, 3), */ + VMSTATE_UINT32(channels[0].irq_disabled, PITCommonState), + VMSTATE_STRUCT_ARRAY(channels, PITCommonState, 3, 2, + vmstate_pit_channel, PITChannelState), + VMSTATE_INT64(channels[0].next_transition_time, + PITCommonState), /* formerly irq_timer */ + VMSTATE_END_OF_LIST() + } +}; + static void pit_common_class_init(ObjectClass *klass, void *data) { DeviceClass *dc = DEVICE_CLASS(klass); @@ -289,6 +312,24 @@ static void pit_common_class_init(ObjectClass *klass, void *data) dc->cannot_instantiate_with_device_add_yet = true; } +void pit_common_class_fix_compat(void) +{ + GSList *el, *devices = object_class_get_list(TYPE_DEVICE, false); + /* + * Change the vmstate field in this class and any derived classes + * if not overriden. As no other classes should be using this + * vmstate, we can simply iterate the class list + */ + for (el = devices; el; el = el->next) { + DeviceClass *dc = el->data; + if (dc->vmsd == &vmstate_pit_common) { + dc->vmsd = &vmstate_pit_common_compat; + } + } + + g_slist_free(devices); +} + static const TypeInfo pit_common_type = { .name = TYPE_PIT_COMMON, .parent = TYPE_ISA_DEVICE, diff --git a/include/hw/acpi/piix4.h b/include/hw/acpi/piix4.h index 65e6fd7..811d88f 100644 --- a/include/hw/acpi/piix4.h +++ b/include/hw/acpi/piix4.h @@ -4,5 +4,6 @@ #include "qemu/typedefs.h" Object *piix4_pm_find(void); +void piix4_pm_class_fix_compat(void); #endif diff --git a/include/hw/timer/i8254.h b/include/hw/timer/i8254.h index 4349033..0126424 100644 --- a/include/hw/timer/i8254.h +++ b/include/hw/timer/i8254.h @@ -72,4 +72,6 @@ static inline ISADevice *kvm_pit_init(ISABus *bus, int base) void pit_set_gate(ISADevice *dev, int channel, int val); void pit_get_channel_info(ISADevice *dev, int channel, PITChannelInfo *info); +void pit_common_class_fix_compat(void); + #endif /* !HW_I8254_H */ -- 1.7.9.5
Add a configure option --enable-pc-1-0-qemu-kvm and the corresponding --disable-pc-1-0-qemu-kvm, defaulting to disabled. Rename machine type pc-1.0 to pc-1.0-qemu-git. Make pc-1.0 machine type an alias of either pc-1.0-qemu-kvm or pc-1.0-qemu-git depending on the value of the config option. Signed-off-by: Alex Bligh <alex@alex.org.uk> --- configure | 12 ++++++++++++ hw/i386/pc_piix.c | 8 +++++++- 2 files changed, 19 insertions(+), 1 deletion(-) diff --git a/configure b/configure index f7685b5..b143302 100755 --- a/configure +++ b/configure @@ -335,6 +335,7 @@ libssh2="" vhdx="" quorum="" numa="" +pc_1_0_qemu_kvm="no" # parse CC options first for opt do @@ -1125,6 +1126,10 @@ for opt do ;; --enable-numa) numa="yes" ;; + --disable-pc-1-0-qemu-kvm) pc_1_0_qemu_kvm="no" + ;; + --enable-pc-1-0-qemu-kvm) pc_1_0_qemu_kvm="yes" + ;; *) echo "ERROR: unknown option $opt" echo "Try '$0 --help' for more information" @@ -1394,6 +1399,8 @@ Advanced options (experts only): --enable-quorum enable quorum block filter support --disable-numa disable libnuma support --enable-numa enable libnuma support + --disable-pc-1-0-qemu-kvm disable pc-1.0 machine type reflecting qemu-kvm + --enable-pc-1-0-qemu-kvm enable pc-1.0 machine type reflecting qemu-kvm NOTE: The object files are built at the place where configure is launched EOF @@ -4262,6 +4269,7 @@ echo "Quorum $quorum" echo "lzo support $lzo" echo "snappy support $snappy" echo "NUMA host support $numa" +echo "pc-1.0 qemu-kvm $pc_1_0_qemu_kvm" if test "$sdl_too_old" = "yes"; then echo "-> Your SDL version is too old - please upgrade to have SDL support" @@ -5241,6 +5249,10 @@ if test "$numa" = "yes"; then echo "CONFIG_NUMA=y" >> $config_host_mak fi +if test "$pc_1_0_qemu_kvm" = "yes"; then + echo "CONFIG_PC_1_0_QEMU_KVM=y" >> $config_host_mak +fi + # build tree in object directory in case the source is not in the current directory DIRS="tests tests/tcg tests/tcg/cris tests/tcg/lm32 tests/libqos tests/qapi-schema tests/tcg/xtensa tests/qemu-iotests" DIRS="$DIRS fsdev" diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c index e400ea6..7a3db34 100644 --- a/hw/i386/pc_piix.c +++ b/hw/i386/pc_piix.c @@ -647,7 +647,10 @@ static QEMUMachine pc_machine_v1_1 = { static QEMUMachine pc_machine_v1_0 = { PC_I440FX_1_2_MACHINE_OPTIONS, - .name = "pc-1.0", + .name = "pc-1.0-qemu-git", +#ifndef CONFIG_PC_1_0_QEMU_KVM + .alias = "pc-1.0", +#endif .compat_props = (GlobalProperty[]) { PC_COMPAT_1_0, { /* end of list */ } @@ -666,6 +669,9 @@ static QEMUMachine pc_machine_v1_0 = { static QEMUMachine pc_machine_v1_0_qemu_kvm = { PC_I440FX_1_2_MACHINE_OPTIONS, .name = "pc-1.0-qemu-kvm", +#ifdef CONFIG_PC_1_0_QEMU_KVM + .alias = "pc-1.0", +#endif .init = pc_init_pci_1_2_qemu_kvm, .compat_props = (GlobalProperty[]) { PC_COMPAT_1_0_QEMU_KVM, -- 1.7.9.5
On Fri, Aug 01, 2014 at 08:12:13PM +0100, Alex Bligh wrote:
Add a configure option --enable-pc-1-0-qemu-kvm and the corresponding --disable-pc-1-0-qemu-kvm, defaulting to disabled.
Rename machine type pc-1.0 to pc-1.0-qemu-git.
Make pc-1.0 machine type an alias of either pc-1.0-qemu-kvm or pc-1.0-qemu-git depending on the value of the config option.
Signed-off-by: Alex Bligh <alex@alex.org.uk>
Nah that's too messy. qemu-kvm should have used a different machine type, it didn't but we should not perpetuate this mistake. Please add a work around for this in management.
--- configure | 12 ++++++++++++ hw/i386/pc_piix.c | 8 +++++++- 2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/configure b/configure index f7685b5..b143302 100755 --- a/configure +++ b/configure @@ -335,6 +335,7 @@ libssh2="" vhdx="" quorum="" numa="" +pc_1_0_qemu_kvm="no"
# parse CC options first for opt do @@ -1125,6 +1126,10 @@ for opt do ;; --enable-numa) numa="yes" ;; + --disable-pc-1-0-qemu-kvm) pc_1_0_qemu_kvm="no" + ;; + --enable-pc-1-0-qemu-kvm) pc_1_0_qemu_kvm="yes" + ;; *) echo "ERROR: unknown option $opt" echo "Try '$0 --help' for more information" @@ -1394,6 +1399,8 @@ Advanced options (experts only): --enable-quorum enable quorum block filter support --disable-numa disable libnuma support --enable-numa enable libnuma support + --disable-pc-1-0-qemu-kvm disable pc-1.0 machine type reflecting qemu-kvm + --enable-pc-1-0-qemu-kvm enable pc-1.0 machine type reflecting qemu-kvm
NOTE: The object files are built at the place where configure is launched EOF @@ -4262,6 +4269,7 @@ echo "Quorum $quorum" echo "lzo support $lzo" echo "snappy support $snappy" echo "NUMA host support $numa" +echo "pc-1.0 qemu-kvm $pc_1_0_qemu_kvm"
if test "$sdl_too_old" = "yes"; then echo "-> Your SDL version is too old - please upgrade to have SDL support" @@ -5241,6 +5249,10 @@ if test "$numa" = "yes"; then echo "CONFIG_NUMA=y" >> $config_host_mak fi
+if test "$pc_1_0_qemu_kvm" = "yes"; then + echo "CONFIG_PC_1_0_QEMU_KVM=y" >> $config_host_mak +fi + # build tree in object directory in case the source is not in the current directory DIRS="tests tests/tcg tests/tcg/cris tests/tcg/lm32 tests/libqos tests/qapi-schema tests/tcg/xtensa tests/qemu-iotests" DIRS="$DIRS fsdev" diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c index e400ea6..7a3db34 100644 --- a/hw/i386/pc_piix.c +++ b/hw/i386/pc_piix.c @@ -647,7 +647,10 @@ static QEMUMachine pc_machine_v1_1 = {
static QEMUMachine pc_machine_v1_0 = { PC_I440FX_1_2_MACHINE_OPTIONS, - .name = "pc-1.0", + .name = "pc-1.0-qemu-git", +#ifndef CONFIG_PC_1_0_QEMU_KVM + .alias = "pc-1.0", +#endif .compat_props = (GlobalProperty[]) { PC_COMPAT_1_0, { /* end of list */ } @@ -666,6 +669,9 @@ static QEMUMachine pc_machine_v1_0 = { static QEMUMachine pc_machine_v1_0_qemu_kvm = { PC_I440FX_1_2_MACHINE_OPTIONS, .name = "pc-1.0-qemu-kvm", +#ifdef CONFIG_PC_1_0_QEMU_KVM + .alias = "pc-1.0", +#endif .init = pc_init_pci_1_2_qemu_kvm, .compat_props = (GlobalProperty[]) { PC_COMPAT_1_0_QEMU_KVM, -- 1.7.9.5
On Fri, Aug 01, 2014 at 08:12:11PM +0100, Alex Bligh wrote:
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-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. The existing pc-1.0 machine type is renamed to pc-1.0-qemu-git, with pc-1.0 becoming an alias for one or another, as selected by a configure option (defaulting to pc-1.0-qemu-git, IE no change).
This requires 'hot patching' the VMStateDescription in a couple of places, which in turn is less than obvious as there may be (indeed are for i8259) derived classes. Whilst pretty nausea-inducing, this approach has the benefit of being entirely self-contained.
Ow come on. Just add a flag and select the appropriate format based on it, using field_exists.
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) migratino from qemu-2.x to qemu-1.0 will not work, even if the machine types are the same.
Alex Bligh (2): Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm Add configure option --enable-pc-1-0-qemu-kvm
configure | 12 ++++++++++++ hw/acpi/piix4.c | 49 ++++++++++++++++++++++++++++++++++++++++++++-- hw/i386/pc_piix.c | 39 +++++++++++++++++++++++++++++++++++- hw/timer/i8254_common.c | 41 ++++++++++++++++++++++++++++++++++++++ include/hw/acpi/piix4.h | 1 + include/hw/timer/i8254.h | 2 ++ 6 files changed, 141 insertions(+), 3 deletions(-)
-- 1.7.9.5
On 4 Aug 2014, at 14:31, Michael S. Tsirkin <mst@redhat.com> wrote:
On Fri, Aug 01, 2014 at 08:12:11PM +0100, Alex Bligh wrote:
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-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. The existing pc-1.0 machine type is renamed to pc-1.0-qemu-git, with pc-1.0 becoming an alias for one or another, as selected by a configure option (defaulting to pc-1.0-qemu-git, IE no change).
This requires 'hot patching' the VMStateDescription in a couple of places, which in turn is less than obvious as there may be (indeed are for i8259) derived classes. Whilst pretty nausea-inducing, this approach has the benefit of being entirely self-contained.
Ow come on. Just add a flag and select the appropriate format based on it, using field_exists.
I don't think it is that simple. All those things are initialised well before the command line is parsed. Unless I'm missing what you are saying? -- Alex Bligh
On Mon, Aug 04, 2014 at 02:51:01PM +0100, Alex Bligh wrote:
On 4 Aug 2014, at 14:31, Michael S. Tsirkin <mst@redhat.com> wrote:
On Fri, Aug 01, 2014 at 08:12:11PM +0100, Alex Bligh wrote:
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-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. The existing pc-1.0 machine type is renamed to pc-1.0-qemu-git, with pc-1.0 becoming an alias for one or another, as selected by a configure option (defaulting to pc-1.0-qemu-git, IE no change).
This requires 'hot patching' the VMStateDescription in a couple of places, which in turn is less than obvious as there may be (indeed are for i8259) derived classes. Whilst pretty nausea-inducing, this approach has the benefit of being entirely self-contained.
Ow come on. Just add a flag and select the appropriate format based on it, using field_exists.
I don't think it is that simple. All those things are initialised well before the command line is parsed.
You initialize both and select the correct one at migration time.
Unless I'm missing what you are saying?
I think you are: check how vmstate_test_use_acpi_pci_hotplug and vmstate_test_no_use_acpi_pci_hotplug are used in vmstate_acpi.
-- Alex Bligh
Michael, On 4 Aug 2014, at 15:26, Michael S. Tsirkin <mst@redhat.com> wrote:
Unless I'm missing what you are saying?
I think you are: check how vmstate_test_use_acpi_pci_hotplug and vmstate_test_no_use_acpi_pci_hotplug are used in vmstate_acpi.
I /think/ you are talking about using the VMSTATE_FOO_TEST macros. These are capable of modifying fields within the VMStateDescription of the relevant object. However, the PIIX4 change modifies the minimum_version_id (outside fields); I don't quite see how that would work. Can you help here? The i8254 change modifies a field which is marked with a minimum version to be a field with no versioning; I guess the route there would be a test function that (somehow) accesses the version of the inbound migration inside it, does the comparison manually, and returns 1 if EITHER the inbound version >=3 or the compatibility thing is set. Is that what you meant? I'm rather new to this so you may have to lead me a little - apologies. I was trying to produce code which would be 'obviously correct' in the sense of not breaking the existing pc-1.0 migrations; if playing around with the existing vmstate fields is permissible then clearly I have a few more degrees of freedom. I did try modifying the objects live after the command line has been parsed; this doesn't work because the QOM inheritance memcpy's the structs for classes derived from i8254 etc. -- Alex Bligh
On Mon, Aug 04, 2014 at 05:11:11PM +0100, Alex Bligh wrote:
Michael,
On 4 Aug 2014, at 15:26, Michael S. Tsirkin <mst@redhat.com> wrote:
Unless I'm missing what you are saying?
I think you are: check how vmstate_test_use_acpi_pci_hotplug and vmstate_test_no_use_acpi_pci_hotplug are used in vmstate_acpi.
I /think/ you are talking about using the VMSTATE_FOO_TEST macros.
These use field_exists internally.
These are capable of modifying fields within the VMStateDescription of the relevant object.
However, the PIIX4 change modifies the minimum_version_id (outside fields); I don't quite see how that would work. Can you help here?
If you want to support lower version IDs, you can just decrease minimum_version_id. field_exists gets the version ID so you can parse different fields depending on the version.
The i8254 change modifies a field which is marked with a minimum version to be a field with no versioning; I guess the route there would be a test function that (somehow) accesses the version of the inbound migration inside it,
Yes, field_exists gets the version value so no problem here.
does the comparison manually, and returns 1 if EITHER the inbound version >=3 or the compatibility thing is set.
Is that what you meant?
I think so, yes.
I'm rather new to this so you may have to lead me a little - apologies.
I was trying to produce code which would be 'obviously correct' in the sense of not breaking the existing pc-1.0 migrations; if playing around with the existing vmstate fields is permissible then clearly I have a few more degrees of freedom.
Yes I think is should be simple but not to the exclusion of maintainability.
I did try modifying the objects live after the command line has been parsed; this doesn't work because the QOM inheritance memcpy's the structs for classes derived from i8254 etc.
Right, just add a new flag for this thing.
-- Alex Bligh
Michael, On 4 Aug 2014, at 17:22, Michael S. Tsirkin <mst@redhat.com> wrote:
These are capable of modifying fields within the VMStateDescription of the relevant object.
However, the PIIX4 change modifies the minimum_version_id (outside fields); I don't quite see how that would work. Can you help here?
If you want to support lower version IDs, you can just decrease minimum_version_id.
field_exists gets the version ID so you can parse different fields depending on the version.
The issue is that qemu-kvm 1.0 used version ID 2 but is actually sending a version 3 structure. I don't think I can just reduce the minimum version ID. As per the comment in the original patch from Cole Robinson: http://pkgs.fedoraproject.org/cgit/qemu.git/tree/0001-Fix-migration-from-qem... --- a/hw/acpi/piix4.c +++ b/hw/acpi/piix4.c @@ -289,7 +289,13 @@ static int acpi_load_old(QEMUFile *f, void *opaque, int version_id) static const VMStateDescription vmstate_acpi = { .name = "piix4_pm", .version_id = 3, - .minimum_version_id = 3, + /* + * qemu-kvm 1.2 uses qemu.git version 3 format, but advertised as 2. + * This allows incoming migration from qemu-kvm, but breaks incoming + * migration from qemu < 1.3. + */ + //minimum_version_id = 3, + .minimum_version_id = 2, .minimum_version_id_old = 1, .load_state_old = acpi_load_old, .post_load = vmstate_acpi_post_load, An inbound migration from qemu-1.0-git, qemu-1.1 or qemu-1.2 will have version ID 2 and actually mean version 2; currently (i.e. with minimum_version_id = 3), these use the minimum_version_id_old field (1) and acpi_load_old routine. If I decrease minimum_version_id to 2, as far as I can tell this will break inbound migration from the 'good' earlier versions, whilst fixing qemu-1.0-kvm (which uses version 2 to mean version 3). So as far as I can tell, the minimum version ID needs to be dependent upon inbound machine type (or machine parameters). By the time the command line is parsed, these structures have already been built. That's why I took the approach I did, but again I'm new to this so may be missing something. Or were you suggesting I introduced a test_force_use_new_load_vm_state type field into VMStateDescription so it can dynamically choose not to use the load_state_old but rather to use the new method, irrespective of the minimum version mismatch? -- Alex Bligh
On Mon, Aug 04, 2014 at 05:46:58PM +0100, Alex Bligh wrote:
Michael,
On 4 Aug 2014, at 17:22, Michael S. Tsirkin <mst@redhat.com> wrote:
These are capable of modifying fields within the VMStateDescription of the relevant object.
However, the PIIX4 change modifies the minimum_version_id (outside fields); I don't quite see how that would work. Can you help here?
If you want to support lower version IDs, you can just decrease minimum_version_id.
field_exists gets the version ID so you can parse different fields depending on the version.
The issue is that qemu-kvm 1.0 used version ID 2 but is actually sending a version 3 structure.
I don't think I can just reduce the minimum version ID.
As per the comment in the original patch from Cole Robinson:
http://pkgs.fedoraproject.org/cgit/qemu.git/tree/0001-Fix-migration-from-qem...
--- a/hw/acpi/piix4.c +++ b/hw/acpi/piix4.c @@ -289,7 +289,13 @@ static int acpi_load_old(QEMUFile *f, void *opaque, int version_id) static const VMStateDescription vmstate_acpi = { .name = "piix4_pm", .version_id = 3, - .minimum_version_id = 3, + /* + * qemu-kvm 1.2 uses qemu.git version 3 format, but advertised as 2. + * This allows incoming migration from qemu-kvm, but breaks incoming + * migration from qemu < 1.3. + */ + //minimum_version_id = 3, + .minimum_version_id = 2, .minimum_version_id_old = 1, .load_state_old = acpi_load_old, .post_load = vmstate_acpi_post_load,
An inbound migration from qemu-1.0-git, qemu-1.1 or qemu-1.2 will have version ID 2 and actually mean version 2; currently (i.e. with minimum_version_id = 3), these use the minimum_version_id_old field (1) and acpi_load_old routine.
If I decrease minimum_version_id to 2, as far as I can tell this will break inbound migration from the 'good' earlier versions, whilst fixing qemu-1.0-kvm (which uses version 2 to mean version 3).
So as far as I can tell, the minimum version ID needs to be dependent upon inbound machine type (or machine parameters). By the time the command line is parsed, these structures have already been built. That's why I took the approach I did, but again I'm new to this so may be missing something.
Or were you suggesting I introduced a test_force_use_new_load_vm_state type field into VMStateDescription so it can dynamically choose not to use the load_state_old but rather to use the new method, irrespective of the minimum version mismatch?
I was merely suggesting changing acpi_load_old to detect the new flag and parse the qemu-kvm format.
-- Alex Bligh
On 4 Aug 2014, at 17:59, Michael S. Tsirkin <mst@redhat.com> wrote:
I was merely suggesting changing acpi_load_old to detect the new flag and parse the qemu-kvm format.
Oh OK - far simpler. If the machine is subsequently migrated to another qemu-2.x device, I take it that will still write out a proper version 3 object? -- Alex Bligh
On Mon, Aug 04, 2014 at 06:08:05PM +0100, Alex Bligh wrote:
On 4 Aug 2014, at 17:59, Michael S. Tsirkin <mst@redhat.com> wrote:
I was merely suggesting changing acpi_load_old to detect the new flag and parse the qemu-kvm format.
Oh OK - far simpler.
If the machine is subsequently migrated to another qemu-2.x device, I take it that will still write out a proper version 3 object?
I think so, yes.
-- Alex Bligh
Quoting Alex Bligh (alex@alex.org.uk):
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-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. The existing pc-1.0 machine type is renamed to pc-1.0-qemu-git, with pc-1.0 becoming an alias for one or another, as selected by a configure option (defaulting to pc-1.0-qemu-git, IE no change).
This requires 'hot patching' the VMStateDescription in a couple of places, which in turn is less than obvious as there may be (indeed are for i8259) derived classes. Whilst pretty nausea-inducing, this approach has the benefit of being entirely self-contained.
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) migratino from qemu-2.x to qemu-1.0 will not work, even if the machine types are the same.
Alex Bligh (2): Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm Add configure option --enable-pc-1-0-qemu-kvm
Thanks, Alex, I hope to set up a test of this this afternoon.
configure | 12 ++++++++++++ hw/acpi/piix4.c | 49 ++++++++++++++++++++++++++++++++++++++++++++-- hw/i386/pc_piix.c | 39 +++++++++++++++++++++++++++++++++++- hw/timer/i8254_common.c | 41 ++++++++++++++++++++++++++++++++++++++ include/hw/acpi/piix4.h | 1 + include/hw/timer/i8254.h | 2 ++ 6 files changed, 141 insertions(+), 3 deletions(-)
-- 1.7.9.5
This worked for me when migrating by hand. I'm trying to make it work through libvirt, using the following patch. (So whether to have pc-1.0 be treated as qemu's or qemu-kvm's pc-1.0 is specifed using a boolean in /etc/libvirt/qemu.conf) Qemu starts with decent looking args, but for some reason the the migration is failing - still looking through the logfile to figure out why. Now sadly my tests are being further slowed down by qcow corruption on my host, but I don't think that was the cause of my failure. Index: libvirt-1.2.6/src/qemu/qemu_conf.c =================================================================== --- libvirt-1.2.6.orig/src/qemu/qemu_conf.c +++ libvirt-1.2.6/src/qemu/qemu_conf.c @@ -230,6 +230,8 @@ virQEMUDriverConfigPtr virQEMUDriverConf cfg->migrationPortMin = QEMU_MIGRATION_PORT_MIN; cfg->migrationPortMax = QEMU_MIGRATION_PORT_MAX; + cfg->incoming_assume_qemukvm = false; + #if defined HAVE_MNTENT_H && defined HAVE_GETMNTENT_R /* For privileged driver, try and find hugepage mount automatically. * Non-privileged driver requires admin to create a dir for the @@ -355,6 +357,7 @@ int virQEMUDriverConfigLoadFile(virQEMUD goto cleanup; \ } + GET_VALUE_BOOL("incoming_assume_qemukvm", cfg->incoming_assume_qemukvm); GET_VALUE_BOOL("vnc_auto_unix_socket", cfg->vncAutoUnixSocket); GET_VALUE_BOOL("vnc_tls", cfg->vncTLS); GET_VALUE_BOOL("vnc_tls_x509_verify", cfg->vncTLSx509verify); Index: libvirt-1.2.6/src/qemu/qemu_conf.h =================================================================== --- libvirt-1.2.6.orig/src/qemu/qemu_conf.h +++ libvirt-1.2.6/src/qemu/qemu_conf.h @@ -168,6 +168,8 @@ struct _virQEMUDriverConfig { char *migrationAddress; int migrationPortMin; int migrationPortMax; + /* Whether incoming pc-1.0 migration should come from qemu-kvm */ + bool incoming_assume_qemukvm; bool logTimestamp; }; Index: libvirt-1.2.6/src/qemu/qemu_migration.c =================================================================== --- libvirt-1.2.6.orig/src/qemu/qemu_migration.c +++ libvirt-1.2.6/src/qemu/qemu_migration.c @@ -2131,6 +2131,16 @@ static char if (!qemuDomainDefCheckABIStability(driver, vm->def, def)) goto cleanup; + if (driver->config->incoming_assume_qemukvm) { + if (STREQ_NULLABLE(vm->def->os.machine, "pc-1.0")) { + VIR_FREE(vm->def->os.machine); + VIR_FREE(def->os.machine); + if (VIR_STRDUP(vm->def->os.machine, "pc-1.0-qemu-kvm") < 0 || + VIR_STRDUP(def->os.machine, "pc-1.0-qemu-kvm") < 0) + goto cleanup; + } + } + rv = qemuDomainDefFormatLive(driver, def, false, true); } else { rv = qemuDomainDefFormatLive(driver, vm->def, false, true); @@ -2461,6 +2471,13 @@ qemuMigrationPrepareAny(virQEMUDriverPtr goto endjob; } + if (driver->config->incoming_assume_qemukvm) { + if (STREQ_NULLABLE(vm->def->os.machine, "pc-1.0")) { + VIR_FREE(vm->def->os.machine); + if (VIR_STRDUP(vm->def->os.machine, "pc-1.0-qemu-kvm") < 0) + goto endjob; + } + } /* Start the QEMU daemon, with the same command-line arguments plus * -incoming $migrateFrom */ Index: libvirt-1.2.6/src/qemu/qemu_command.c =================================================================== --- libvirt-1.2.6.orig/src/qemu/qemu_command.c +++ libvirt-1.2.6/src/qemu/qemu_command.c @@ -7093,6 +7093,7 @@ qemuBuildCommandLine(virConnectPtr conn, virArch hostarch = virArchFromHost(); virQEMUDriverConfigPtr cfg = virQEMUDriverGetConfig(driver); + VIR_DEBUG("conn=%p driver=%p def=%p mon=%p json=%d " "qemuCaps=%p migrateFrom=%s migrateFD=%d " "snapshot=%p vmop=%d", @@ -7172,6 +7173,11 @@ qemuBuildCommandLine(virConnectPtr conn, if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_ENABLE_FIPS)) virCommandAddArg(cmd, "-enable-fips"); + VIR_DEBUG("qemu_command: os.machine is %s\n", def->os.machine); + if (STREQ_NULLABLE(def->os.machine, "pc-1.0-qemu-kvm")) { + virCommandAddArgList(cmd, "-global", + "virtio-net-pci.romfile=pxe-virtio.rom.12.04", NULL); + } if (qemuBuildMachineArgStr(cmd, def, qemuCaps) < 0) goto error;
Serge, On 7 Aug 2014, at 03:50, Serge Hallyn <serge.hallyn@ubuntu.com> wrote:
This worked for me when migrating by hand. I'm trying to make it work through libvirt, using the following patch. (So whether to have pc-1.0 be treated as qemu's or qemu-kvm's pc-1.0 is specifed using a boolean in /etc/libvirt/qemu.conf) Qemu starts with decent looking args, but for some reason the the migration is failing - still looking through the logfile to figure out why.
Are you using exactly the same arguments by hand and with libvirt? Also, on reflection, given one of the changes between 1.0 and 2.0 is ACPI, I should probably have done some testing with an ACPI enabled image, rather than just cirros (which not ACPI enabled); any chance this is ACPI related?
Now sadly my tests are being further slowed down by qcow corruption on my host, but I don't think that was the cause of my failure.
Whilst getting the patch right in the first place I tend to cp from a known good image. Obviously once it works, qcow2 corruption should not happen. But failed migrations (with or without my patch) do appear to cause this relatively frequently. -- Alex Bligh
Quoting Alex Bligh (alex@alex.org.uk):
Serge,
On 7 Aug 2014, at 03:50, Serge Hallyn <serge.hallyn@ubuntu.com> wrote:
This worked for me when migrating by hand. I'm trying to make it work through libvirt, using the following patch. (So whether to have pc-1.0 be treated as qemu's or qemu-kvm's pc-1.0 is specifed using a boolean in /etc/libvirt/qemu.conf) Qemu starts with decent looking args, but for some reason the the migration is failing - still looking through the logfile to figure out why.
Are you using exactly the same arguments by hand and with libvirt?
Also, on reflection, given one of the changes between 1.0 and 2.0 is ACPI, I should probably have done some testing with an ACPI enabled image, rather than just cirros (which not ACPI enabled); any chance this is ACPI related?
Turning off acpi (well, commenting it out in the xml, which I'm assuming dtrt) doesn't help: =============================================== LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=none /usr/bin/kvm -name cirros -S -global virtio-net-pci.romfile=pxe-virtio.rom.12.04 -machine pc-1.0-qemu-kvm,accel=kvm,usb=off -m 512 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 2542c328-6842-33ef-d30e-866c3f3189a8 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/cirros.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -no-acpi -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/var/lib/libvirt/images/cirros.img,if=none,id=drive-ide0-0-0,format=raw -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1 -netdev tap,fd=26,id=hostnet0 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:be:d8:99,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -vnc 127.0.0.1:0 -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device AC97,id=sound0,bus=pci.0,addr=0x4 -incoming fd:23 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -msg timestamp=on 2014-08-07 12:51:02.400+0000: 1539: debug : virFileClose:99 : Closed fd 25 2014-08-07 12:51:02.401+0000: 1539: debug : virFileClose:99 : Closed fd 31 2014-08-07 12:51:02.401+0000: 1539: debug : virFileClose:99 : Closed fd 3 2014-08-07 12:51:02.401+0000: 1540: debug : virExec:616 : Run hook 0x7f25cb17bca0 0x7f25d3aedf20 2014-08-07 12:51:02.401+0000: 1540: debug : qemuProcessHook:2719 : Obtaining domain lock 2014-08-07 12:51:02.401+0000: 1540: debug : virDomainLockProcessStart:175 : plugin=0x7f25c4170290 dom=0x7f25c4186510 paused=1 fd=0x7f25d3aedb44 2014-08-07 12:51:02.401+0000: 1540: debug : virDomainLockManagerNew:133 : plugin=0x7f25c4170290 dom=0x7f25c4186510 withResources=1 2014-08-07 12:51:02.401+0000: 1540: debug : virLockManagerPluginGetDriver:281 : plugin=0x7f25c4170290 2014-08-07 12:51:02.401+0000: 1540: debug : virLockManagerNew:305 : driver=0x7f25da723580 type=0 nparams=5 params=0x7f25d3aeda30 flags=0 2014-08-07 12:51:02.401+0000: 1540: debug : virLockManagerLogParams:98 : key=uuid type=uuid value=2542c328-6842-33ef-d30e-866c3f3189a8 2014-08-07 12:51:02.401+0000: 1540: debug : virLockManagerLogParams:91 : key=name type=string value=cirros 2014-08-07 12:51:02.401+0000: 1540: debug : virLockManagerLogParams:79 : key=id type=uint value=2 2014-08-07 12:51:02.401+0000: 1540: debug : virLockManagerLogParams:79 : key=pid type=uint value=1540 2014-08-07 12:51:02.401+0000: 1540: debug : virLockManagerLogParams:94 : key=uri type=cstring value=qemu:///system 2014-08-07 12:51:02.401+0000: 1540: debug : virDomainLockManagerNew:145 : Adding leases 2014-08-07 12:51:02.401+0000: 1540: debug : virDomainLockManagerNew:150 : Adding disks 2014-08-07 12:51:02.401+0000: 1540: debug : virDomainLockManagerAddDisk:91 : Add disk /var/lib/libvirt/images/cirros.img 2014-08-07 12:51:02.401+0000: 1540: debug : virLockManagerAddResource:332 : lock=0x7f25c417b080 type=0 name=/var/lib/libvirt/images/cirros.img nparams=0 params=(nil) flags=0 2014-08-07 12:51:02.401+0000: 1540: debug : virLockManagerAcquire:350 : lock=0x7f25c417b080 state='<null>' flags=3 action=0 fd=0x7f25d3aedb44 2014-08-07 12:51:02.401+0000: 1540: debug : virLockManagerFree:387 : lock=0x7f25c417b080 2014-08-07 12:51:02.401+0000: 1540: debug : virObjectUnref:259 : OBJECT_UNREF: obj=0x7f25c415e620 2014-08-07 12:51:02.401+0000: 1540: debug : qemuProcessHook:2746 : Hook complete ret=0 2014-08-07 12:51:02.401+0000: 1540: debug : virExec:618 : Done hook 0 2014-08-07 12:51:02.401+0000: 1540: debug : virExec:638 : Setting child AppArmor profile to libvirt-2542c328-6842-33ef-d30e-866c3f3189a8 2014-08-07 12:51:02.402+0000: 1540: debug : virExec:655 : Setting child uid:gid to 107:113 with caps 0 2014-08-07 12:51:02.402+0000: 1540: debug : virCommandHandshakeChild:358 : Notifying parent for handshake start on 28 2014-08-07 12:51:02.402+0000: 1540: debug : virCommandHandshakeChild:366 : Waiting on parent for handshake complete on 29 libvirt: error : libvirtd quit during handshake: Input/output error 2014-08-07 12:51:02.424+0000: shutting down =============================================== Perhaps the key is here: =============================================== 2014-08-07 12:51:02.416+0000: 1119: debug : virEventPollDispatchHandles:508 : EVENT_POLL_DISPATCH_HANDLE: watch=7 events=1 2014-08-07 12:51:02.416+0000: 1119: debug : udevEventHandleCallback:1585 : udev action: 'add' 2014-08-07 12:51:02.416+0000: 1119: debug : udevGetDeviceProperty:125 : udev reports device 'rx-0' does not have property 'DRIVER' 2014-08-07 12:51:02.416+0000: 1119: debug : udevGetDeviceProperty:143 : Found property key 'SUBSYSTEM' value 'queues' for device with sysname 'rx-0' 2014-08-07 12:51:02.416+0000: 1119: debug : udevGetDeviceType:1279 : Could not determine device type for device with sysfs name 'rx-0' 2014-08-07 12:51:02.416+0000: 1119: debug : udevAddOneDevice:1454 : Discarding device -1 0x7f25dcb40e80 /sys/devices/virtual/net/vnet0/queues/rx-0 ===============================================
Now sadly my tests are being further slowed down by qcow corruption on my host, but I don't think that was the cause of my failure.
Whilst getting the patch right in the first place I tend to cp from a known good image. Obviously once it works, qcow2 corruption should not happen. But failed migrations (with or without my patch) do appear to cause this relatively frequently.
No no, the qcow2 corruption is nothing to do with the migration itself. I'm testing migration between two vms on my laptop which are using qcow2 snapshots for rootfs, and those are the ones getting the corruption. This is https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1319578 https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1315162 and https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1292234 which i could never reproduce before. -serge
Quoting Alex Bligh (alex@alex.org.uk):
Serge,
On 7 Aug 2014, at 03:50, Serge Hallyn <serge.hallyn@ubuntu.com> wrote:
This worked for me when migrating by hand. I'm trying to make it work through libvirt, using the following patch. (So whether to have pc-1.0 be treated as qemu's or qemu-kvm's pc-1.0 is specifed using a boolean in /etc/libvirt/qemu.conf) Qemu starts with decent looking args, but for some reason the the migration is failing - still looking through the logfile to figure out why.
Are you using exactly the same arguments by hand and with libvirt?
Also, on reflection, given one of the changes between 1.0 and 2.0 is ACPI, I should probably have done some testing with an ACPI enabled image, rather than just cirros (which not ACPI enabled); any chance this is ACPI related?
A-ha, acpi wasn't a problem. I actually had a general migration problem even when coming from other utopic hosts. With that fixed, I've got successful migration from qemu-kvm 1.0 in precise to a utopic host. -serge
On 7 Aug 2014, at 20:26, Serge E. Hallyn <serge@hallyn.com> wrote:
A-ha, acpi wasn't a problem. I actually had a general migration problem even when coming from other utopic hosts. With that fixed, I've got successful migration from qemu-kvm 1.0 in precise to a utopic host.
That's good news. You might try the 2 patches here: https://github.com/abligh/qemu/tree/livemigrate-qemu-kvm-to-qemu-2.0.0-test-... and see if you can get Precise to Trusty migration working (as well as Precise to Utopic) -- Alex Bligh
Quoting Alex Bligh (alex@alex.org.uk):
On 7 Aug 2014, at 20:26, Serge E. Hallyn <serge@hallyn.com> wrote:
A-ha, acpi wasn't a problem. I actually had a general migration problem even when coming from other utopic hosts. With that fixed, I've got successful migration from qemu-kvm 1.0 in precise to a utopic host.
That's good news. You might try the 2 patches here:
https://github.com/abligh/qemu/tree/livemigrate-qemu-kvm-to-qemu-2.0.0-test-...
and see if you can get Precise to Trusty migration working (as well as Precise to Utopic)
These have built at https://launchpad.net/~serge-hallyn/+archive/ubuntu/qemu-p-migration
participants (4)
-
Alex Bligh -
Michael S. Tsirkin -
Serge E. Hallyn -
Serge Hallyn