Re: [libvirt] [Qemu-devel] [PATCH v2 0/2] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm
Michael,
On 4 Aug 2014, at 17:22, Michael S. Tsirkin <mst(a)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-...
--- 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