From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [Qemu-devel] live migration between qemu-kvm 1.0 and 0.15 Date: Thu, 29 Mar 2012 13:56:48 +0200 Message-ID: <4F744E00.9020901@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> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Avi Kivity , Vasilis Liaskovitis , "qemu-devel@nongnu.org" , "kvm@vger.kernel.org" , Juan Quintela To: Anthony Liguori Return-path: Received: from thoth.sbs.de ([192.35.17.2]:21131 "EHLO thoth.sbs.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759083Ab2C2L5A (ORCPT ); Thu, 29 Mar 2012 07:57:00 -0400 In-Reply-To: <4F71ED3F.4030809@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: 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? Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux