Eduardo Habkost wrote:
Excerpts from Anthony Liguori's message of Mon Nov 23 12:49:23 -0200 2009:
Juan Quintela wrote:
But if you know substitute qemu-0.11 and qemu-0.12 for RHEL5.4 and
RHEL5.4.1, you will see that the code bases are going to be really,
really similar. And if any savevm format is changed, it is because
there are no other solution.
In our own stable branch, we do not introduce any savevm changes. I
would recommend the same policy for RHEL :-)
But what if you need to add a savevm change to make migration work
properly on the stable branch?
Define "properly".
If we have to introduce a new version in VMstate, there are two
possibilities. The first is that we have to backlist the old version
because it was fundamentally broken. This is rare but it happens. In
this case, we would not be able to support migrating from that stable
release to any other stable release. Really unfortunate for users but
we would have no other choice.
The second is that we introduce a new version but don't blacklist the
old. This means the old version wasn't fundamentally broken. It also
means that the "fix" is a feature. It makes things better but isn't
strictly required. That gets deferred to the next release.
You can't just tell users "migration is
known to be broken on the stable branch, please don't run migrations
when using the stable branch". That's the case for the pvclock MSR
migration fix.
You're assuming that backporting the pvclock change is a bug fix. It's
a new feature as far as I'm concerned and doesn't belong in stable.
In a perfect world, the set of state data that is migrated by the
current implementation would always match exactly the expected behavior
of the virtual machine. Unfortunately sometimes the implementation
doesn't follow the "contract" (be it some written specification,
documentation, or just user expectations). When that happens, it is a
bug on qemu and it needs to be fixed on the stable branch.
Note that (right now) I am not arguing for backward migration, but just
arguing that we can't have a strict "no savevm changes" policy on the
stable branch.
That's exactly what I'm advocating: a strict savevm policy for stable
branch. It's something I've always enforced in the past. It's
necessary to preserve the integrity of live migration.
Regards,
Anthony Liguori
