From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: live migration between qemu-kvm 1.0 and 0.15 Date: Thu, 29 Mar 2012 17:53:50 +0200 Message-ID: <4F74858E.9070806@siemens.com> References: <20120327085521.GA4567@dhcp-192-168-178-175.profitbricks.localdomain> <4F718E8B.5090601@siemens.com> <4F71E3CC.9070103@redhat.com> <4F71E95C.3070100@siemens.com> <4F71ED3F.4030809@codemonkey.ws> <4F71EEEC.5000903@redhat.com> <4F71EFAB.4070304@codemonkey.ws> <4F71FBE9.3040906@siemens.com> <4F747E78.3070501@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Vasilis Liaskovitis , "qemu-devel@nongnu.org" , Avi Kivity , "kvm@vger.kernel.org" , Juan Quintela To: Anthony Liguori Return-path: In-Reply-To: <4F747E78.3070501@codemonkey.ws> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org On 2012-03-29 17:23, Anthony Liguori wrote: > On 03/27/2012 12:42 PM, Jan Kiszka wrote: >> On 2012-03-27 18:49, Anthony Liguori wrote: >>> On 03/27/2012 11:46 AM, Avi Kivity wrote: >>>> On 03/27/2012 06:39 PM, Anthony Liguori wrote: >>>>> >>>>> So, since we're approaching 1.1, we should really discuss release >>>>> criteria for 1.1 with respect to live migration. I'd prefer to avoid >>>>> surprises in this release. >>>> >>>> Agree strongly. >>>> >>>>> >>>>> My expectation is that migration works from: >>>>> >>>>> qemu-1.0 -M 1.0 => qemu-1.1 -M 1.1 >>>> >>>> Why do you expect that? Maybe you meant -M 1.0 at the end? >>> >>> Sorry, I did mean -M 1.0. >>> >>>> >>>>> qemu-1.1 -M 1.0<= qemu-1.1 -M 1.0 >>>>> >>>>> I would expect that migration works from: >>>>> >>>>> qemu-0.15 -M 0.15 => qemu-1.1 -M 0.15 >>>>> >>>> >>>> Ack. >>>> >>>>> I'm okay if this fails gracefully: >>>>> >>>>> qemu-1.1 -M 0.15<= qemu-0.15 -M 0.15 >>>> >>>> RHEL has more stringent requirements (going back to its heavily patched >>>> 0.12). I think we should have the infrastructure that allow one to add >>>> the hacks to make this work, even if we don't actually do the compat >>>> work for the release (I think it's fine for qemu to support just one >>>> version going back; and unreasonable to require it to go as far back as >>>> RHEL). >>> >>> This is reasonable to me. >> >> Here is a draft to get things written in the old format. Totally >> untested and likely borken (written in a hurry). I'll split up if it >> works fine. > > I don't really like this as a matter of principle. > > Knowingly migrating when the result may be a broken guest is a bug, it's not a > feature. > > It's one thing if we're changing formats for other reasons, but if we're > changing the format to send what's effectively broken migration state, then > that's an evil thing to do. > > Subsections are the compromise. We send a subsection when we think migration > can work and fail gracefully when it can't. Presumably there's a reason we're > not using subsections here. In this case (instance ID), it's actually not about a bug fix but a consolidation of the vmstate format. So I think it's an exception, though I don't like the code changes it requires as well. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux