From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NCbaq-0003zw-6u for qemu-devel@nongnu.org; Mon, 23 Nov 2009 11:16:48 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NCbal-0003z0-Hl for qemu-devel@nongnu.org; Mon, 23 Nov 2009 11:16:47 -0500 Received: from [199.232.76.173] (port=55591 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NCbal-0003yx-B2 for qemu-devel@nongnu.org; Mon, 23 Nov 2009 11:16:43 -0500 Received: from mail-qy0-f194.google.com ([209.85.221.194]:36099) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NCbak-0004IS-Jh for qemu-devel@nongnu.org; Mon, 23 Nov 2009 11:16:42 -0500 Received: by qyk32 with SMTP id 32so2601392qyk.4 for ; Mon, 23 Nov 2009 08:16:41 -0800 (PST) Message-ID: <4B0AB567.8030400@codemonkey.ws> Date: Mon, 23 Nov 2009 10:16:39 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: Live migration protocol, device features, ABIs and other beasts References: <4B0952C9.9010803@redhat.com> <4B095D86.700@codemonkey.ws> <4B09F0CA.3060705@codemonkey.ws> <20091123082659.GC2999@redhat.com> <4B0A87B2.1030507@codemonkey.ws> <4B0AA0F3.6070205@codemonkey.ws> <1258988836-sup-800@blackpad.lan.raisama.net> In-Reply-To: <1258988836-sup-800@blackpad.lan.raisama.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Habkost Cc: Paolo Bonzini , Juan Quintela , Gleb Natapov , qemu-devel 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