[Top][All Lists]

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

Re: [Qemu-devel] Re: Live migration protocol, device features, ABIs and

From: Anthony Liguori
Subject: Re: [Qemu-devel] Re: Live migration protocol, device features, ABIs and other beasts
Date: Mon, 23 Nov 2009 10:16:39 -0600
User-agent: Thunderbird (X11/20090825)

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.


Anthony Liguori

reply via email to

[Prev in Thread] Current Thread [Next in Thread]