On 08/02/2011 06:25 PM, Juan Quintela wrote:
Anthony Liguori<aligu...@us.ibm.com> wrote:
As Paolo points out, the migration protocol is ambiguous when using subsections
today. That means that even if we preserve subsections and change the protocol
accordingly, the old protocol w/subsections is still ambiguous.
Remove subsection usage and bump any device using subsections. This effectively
eliminates the amiguouity and allows for a clean transition to a new protocol
with unambiguous subsections.
If you are doing that, you can just remove the old protocol altogether.
The fundamental problem is that newer QEMUs generate migration state
that is ambiguous to older QEMUs.
No matter what, we have to change the migration protocol in some way as
to make it impossible to migrate from newer QEMUs to older QEMUs.
Even with subsections in the older protocol, newer QEMUs (provided we
don't add more subsections), can still read the old protocol.
Paolo's proposed changes make newer QEMUs use a new protocol. It's
still possible to read the older protocol. This means that you can't
migrate new to old, but can migrate old to new.
I've poured over these patches in great detail and the changes are just
too much right now. Just the ram_addr_t change which now conflicts has
a non-trivial resolution due to a related Xen change.
So my thinking is to be a bit more conservative. If we bump the version
number for 0.15.0, we make sure that we don't allow new -> old
migration. We will break old -> new migration, but we can fix that
(including in the stable series) by adding special handling of the
previous version.
Fixing new->old is the critical bit here. We can resolve old->new as a
stable update.
You are missing also ide on your patch.
Thanks for catching that.
Only platform that
ever cares about forward compatiblity is pc's. And pc's always use
floppies on qemu.
I still think that improving the "subsection" match is the way to go for 0.15.
This series was just too late for 0.15. I can close to suggesting that
we delay 0.15 in order to give this time to be tested thoroughly but I
think my proposal is a reasonable compromise.
Regards,
Anthony Liguori
Later, Juan.
