From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58779) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WkvG4-00020p-3Z for qemu-devel@nongnu.org; Thu, 15 May 2014 08:59:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WkvFw-0006lM-Rn for qemu-devel@nongnu.org; Thu, 15 May 2014 08:59:36 -0400 Received: from mx1.redhat.com ([209.132.183.28]:26599) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WkvFw-0006l8-Jr for qemu-devel@nongnu.org; Thu, 15 May 2014 08:59:28 -0400 Date: Thu, 15 May 2014 15:58:16 +0300 From: "Michael S. Tsirkin" Message-ID: <20140515125816.GA23167@redhat.com> References: <20140514154130.10746.1412.stgit@bahia.local> <20140514154137.10746.94708.stgit@bahia.local> <20140515060425.GA31192@grmbl.mre> <20140515062351.GB14456@redhat.com> <20140515064635.GB31192@grmbl.mre> <20140515090449.2db0cbe0@bahia.local> <537486D2.1060609@suse.de> <20140515095208.GB16405@redhat.com> <878uq3b4r8.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <878uq3b4r8.fsf@blackfin.pond.sub.org> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH RFC 1/8] virtio: add subsections to the migration stream List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Kevin Wolf , Fam Zheng , Anthony Liguori , Juan Quintela , Alexander Graf , qemu-devel@nongnu.org, Stefan Hajnoczi , Amit Shah , Paolo Bonzini , Andreas =?iso-8859-1?Q?F=E4rber?= , Greg Kurz On Thu, May 15, 2014 at 02:33:47PM +0200, Markus Armbruster wrote: > "Michael S. Tsirkin" writes: >=20 > > On Thu, May 15, 2014 at 11:20:18AM +0200, Andreas F=E4rber wrote: > >> Am 15.05.2014 09:04, schrieb Greg Kurz: > >> > On Thu, 15 May 2014 12:16:35 +0530 > >> > Amit Shah wrote: > >> >> On (Thu) 15 May 2014 [09:23:51], Michael S. Tsirkin wrote: > >> >>> On Thu, May 15, 2014 at 11:34:25AM +0530, Amit Shah wrote: > >> >>>> On (Wed) 14 May 2014 [17:41:38], Greg Kurz wrote: > >> >>>>> Since each virtio device is streamed in its own section, the i= dea is to > >> >>>>> stream subsections between the end of the device section and t= he start > >> >>>>> of the next sections. This allows an older QEMU to complain an= d exit > >> >>>>> when fed with subsections: > >> >>>>> > >> >>>>> Unknown savevm section type 5 > >> >>>>> Error -22 while loading VM state > >> >>>> > >> >>>> Please make this configurable -- either via configure or device > >> >>>> properties. That avoids having to break existing configuration= s that > >> >>>> work without this patch. > >>=20 > >> Since backwards migration is not supported upstream, wouldn't it be > >> easiest to just add support for the subsection marker and skipping t= o > >> the end of section in that downstream? > > > > Backwards and forwards migration need to be supported, > > customers told us repeatedly. >=20 > Can I have world peace and a pony with that? >=20 > Given the current state of things, attempting to support backward > migration is trying to run before you can walk. We need to put > migration on a more solid footing first. >=20 > The migration format is crap, and needs to be replaced. >=20 > Reasoning on migration compatibility is entirely manual. >=20 > Systematic testing of migration compatibility is done downstream. >=20 > Fortunately, there's progress being made on all of the above. Let's no= t > sabotage it by biting off yet another mouthful. >=20 > > So some downstreams support this > > and not supporting it upstream just means downstreams need > > to do their own thing. > > > > As importantly, ping-pong migration is the only > > reliable way to stress migration. > > > > So if we want to test cross-version we need it to work > > both way. >=20 > Non sequitur. >=20 > > Finally, the real issue and difficulty with cross-version migration i= s > > making VM behave in a backwards compatible way. Serializing in a > > compatible way is a trivial problem, or would be if the code wasn't a > > mess :) >=20 > However, it is. >=20 > > Once you do the hard part, breaking migration because of the > > trivial serialization issue is just silly. And special-casing forwar= d > > migration does not make code simpler, it really only leads to > > proliferation of hacks and lack of symmetry. >=20 > Bold claim; citation needed. You are asking for examples of ugly assymetry? It's easy: grep for .load_state_old. You have here a bunch of functions loading format that qemu can no longer produce, with any set of flags. The only way to make them run is to install two qemu versions side by sid= e, save from old one and load in the new one. What, would you guess, is the chance that they actually work? I'm going to send a patch removing all this stuff, it's effectively dead code, but this is just one, biggest example. > > So yes it's a useful feature, and no not supporting it does > > not help anyway. >=20 > Nobody denies reliable backward migration would be useful. However, > attempting to do every useful feature at once just because they're all > useful is foolish. >=20 > Treating backward migration as strictly secondary concern while we're u= p > to the ass in other alligators *can* help, by letting us focus on the > said other alligators. >=20 > I'm not opposed to coding things in ways that help backward migration. > Speaking of "support", however, is clearly premature and misleading. I agree it's a secondary concern upstream and your comments really apply to migration generally. We can't claim that it's properly supported by the upstream QEMU. I am merely asking that we don't break cross-version migration intentionally. I and others also try fix it when we notice it's broken. In particular I'm not asking that submitters test it. --=20 MST