[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] qemu-traditional: Bump piix4acpi save-record version_id



Andrew Cooper writes ("[PATCH] qemu-traditional: Bump piix4acpi save-record 
version_id"):
> Sadly, because of a buggy attempt to revert c/s
> ce3b7ce68426ea6249bb411f26b376d459c45450 (piix4acpi, xen: change in
> ACPI to match the change in the BIOS) "for debugging purposes" which
> has remained present in XenServer for several releases, an
> incompatibility in the Qemu save record went unnoticed until now
> when I tried to clean up the patch queue.
> 
> The result is that save-records for XenServer 6.0 to 6.2 advertise a
> piix4acpi record of version 2, but with the content of version 1
> record (also corrupting everything later in the stream, but as this
> is the last record and qemu doesn't care about junk in the end of
> the record, this went completely unnoticed).
> 
> While this can of-course be fixed by us locally, reserving version_id 3
> upstream is the only way to prevent further incompatibilities if/when the
> piix4acpi object gets further development/bugfixes which require a change to
> the save-record.

Just to be clear, what you are saying is this: there is no bug in
upstream.  However, some versions of XenServer have a bug which means
that they generate broken savefiles with declared version 2 which are
not compatible with upstream's.  You intend to fix this in XenServer
by allocating a new savefile version 3 for your users.

You would like Xen.org's qemu-xen-traditional to also bump the
savefile version to 3 because that would avoid your continuing
divergence on this point from Xen.org's qemu-xen-traditional.

This is in principle allowable because we guarantee forward but not
backward migration compatibility.  However, it does have a cost:
without this change, it is possible that in practice reverse migration
or save/restore from 4.4 to 4.3 would work.  I haven't thought through
whether this is in fact possible at the moment.

It seems to me that your proposal is only useful if as a result (at
least) XenServer's "version 3" savefiles are compatible with Xen.org's
"version 3" qemu-xen-traditional savefiles.  What steps have you taken
to verify that this is the case ?  What do you think the usage
scenario of this compatibility would be - some kind of migration to or
from XenServer ?

An aside: I haven't ever tried a migration (or save/restore) from
qemu-xen-traditional to qemu-xen-upstream but I can't see it working
because the set of devices will be different.  So I think
savefile compatibility between qemu-xen-traditional and
qemu-xen-traditional is not a consideration.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.