From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:41916) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SDH9y-0005PC-Nz for qemu-devel@nongnu.org; Thu, 29 Mar 2012 11:21:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SDH9w-0004qV-KP for qemu-devel@nongnu.org; Thu, 29 Mar 2012 11:21:10 -0400 Received: from mail-yw0-f45.google.com ([209.85.213.45]:43308) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SDH9w-0004qK-F9 for qemu-devel@nongnu.org; Thu, 29 Mar 2012 11:21:08 -0400 Received: by yhoo21 with SMTP id o21so1927444yho.4 for ; Thu, 29 Mar 2012 08:21:07 -0700 (PDT) Message-ID: <4F747DDF.5020105@codemonkey.ws> Date: Thu, 29 Mar 2012 10:21:03 -0500 From: Anthony Liguori MIME-Version: 1.0 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> <4F744E00.9020901@siemens.com> <4F747CF4.3040503@redhat.com> In-Reply-To: <4F747CF4.3040503@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] live migration between qemu-kvm 1.0 and 0.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Vasilis Liaskovitis , Jan Kiszka , "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" , Juan Quintela On 03/29/2012 10:17 AM, Avi Kivity wrote: > On 03/29/2012 01:56 PM, Jan Kiszka wrote: >> On 2012-03-27 18:39, Anthony Liguori wrote: >>> On 03/27/2012 11:22 AM, Jan Kiszka wrote: >>>> On 2012-03-27 17:59, Avi Kivity wrote: >>>>> On 03/27/2012 11:55 AM, Jan Kiszka wrote: >>>>>> On 2012-03-27 10:55, Vasilis Liaskovitis wrote: >>>>>>> Hi, >>>>>>> >>>>>>> is live migration between qemu-kvm stable-0.15 and stable-1.0 trees possible? >>>>>>> When I live migrate a VM from 1.0 to 0.15, the destination side 0.15 qemu-kvm >>>>>>> exits with: >>>>>>> (qemu) Unknown savevm section or instance 'i8259' 0 >>>>>>> >>>>>>> That's expected, since commit "i8259:convert to qdev" 747c70af78f7088f182c87e683bdf847beead1e4 >>>>>>> introduces the i8259 device in the qdev tree. >>>>>>> >>>>>>> The other direction (live migrate from 0.15.1 to 1.0.0) seems to work fine. >>>>>>> Are any other issues expected in this direction? >>>>>>> >>>>>>> The vmstate for i8259 has not changed between these trees afaict. If the >>>>>>> qdev-ified i8259 is reverted from stable-1.0 tree (to restore live-migration >>>>>>> compatibility between the versions), would you expect problems? >>>>>> >>>>>> The legacy instance IDs used in old versions are not written out by >>>>>> newer ones. They are just accepted on reading to allow moving forward. >>>>>> There are more devices in the tree that used those instance IDs, not >>>>>> only the i8259. Reverting the qdev conversion may reactivate backward >>>>>> migratability for 1.0->0.15 (unless there are others as well). But that >>>>>> will definitely be over after 1.1 as inrevertible code depends on the >>>>>> qdev conversion. >>>>> >>>>> Is this true even for -M pc-0.15? >>>> >>>> Yes. Alias IDs enable modeling according to qdev (back then) for devices >>>> that wrote oddly numbered states in the past and porting them over to >>>> the new format. Adding some compat write-out mode would probably be >>>> feasible but would also require some thoughts and quite a bit work to >>>> integrate this cleanly in vmstate. >>>> >>>> I guess this just remained unnoticed because the introduction of the >>>> alias ID concept and first conversions happened at a time when lots of >>>> devices increased their vmstate version anyway. >>> >>> 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. >>> >>> My expectation is that migration works from: >>> >>> qemu-1.0 -M 1.0 => qemu-1.1 -M 1.1 >>> qemu-1.1 -M 1.0<= qemu-1.1 -M 1.0 >> >> Besides the instance ID thing, I found two further blockers: >> >> - kvm-tpr-op (kvmvapic), easy to disable in non-1.1 machines >> >> - vmstate fix for i8254 which involved a version bump from 2 to 3. >> That is actually now compatible with qemu-kvm and should not cause >> troubles there. But it breaks the backward-migration scenario for >> QEMU. I have no good idea how to resolve this while pleasing all >> consumers we care about. Any suggestions? > > Option 1: make -M old force an old vmstate to be written out. Sounds > like a generally useful thing. > Option 2: ask those consumers to issue updates that bring their code up > to version 3. Require fully updated qemus on both sides. Easy to > achieve, result is less flexible but reasonable IMO (especially with a > long lead time, which we have). I prefer Option 2 presuming the bug is a legitimate bug fix. If it couldn't be done as a subsection, then there's really no choice IMHO. Regards, Anthony Liguori >