[libvirt] [Qemu-devel] [PATCH v4] Add machine parameter qemu-kvm-migration for live migrate compatibility with qemu-kvm
Alex Bligh
alex at alex.org.uk
Wed Sep 24 08:29:41 UTC 2014
Markus,
On 24 Sep 2014, at 09:05, Markus Armbruster <armbru at redhat.com> wrote:
> Alex Bligh <alex at 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-qemu-kvm.patch?h=f20
>> 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"?
That's what v2 of the patch set does (and I prefer v2). However, mst
wanted it done this way.
>
>> 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().
Yes, intentional. I should have noted that. That's because
qemu-kvm-migration=on the VRAM change was designed to
work only with pc-1.0. I haven't looked at trying to make
other (older) qemu-kvm machine migrations work, but (with the stuff
below), I would guess it would work with the appropriate
command line options for VRAM size.
Obviously I could put early init elsewhere.
>> * 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?
They apply only when qemu-kvm-migration=on is selected, but to
any machine type; however machine types newer than pc-1.0 will
be exporting v3 I think anyway.
>> 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.
See above. I preferred the machine type. But I got to learn more about
QOM on the way :-)
--
Alex Bligh
More information about the libvir-list
mailing list