Re: [Qemu-devel] [PATCH RFC 1/8] virtio: add subsections to the migration stream

[Greg Kurz <gkurz@linux.vnet.ibm.com>]

On Thu, 15 May 2014 15:58:16 +0300
"Michael S. Tsirkin" <mst@redhat.com> wrote:

> On Thu, May 15, 2014 at 02:33:47PM +0200, Markus Armbruster wrote:
> > "Michael S. Tsirkin" <mst@redhat.com> writes:
> > 
> > > On Thu, May 15, 2014 at 11:20:18AM +0200, Andreas Färber wrote:
> > >> Am 15.05.2014 09:04, schrieb Greg Kurz:
> > >> > On Thu, 15 May 2014 12:16:35 +0530
> > >> > Amit Shah <amit.shah@redhat.com> 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 idea is to
> > >> >>>>> stream subsections between the end of the device section and the start
> > >> >>>>> of the next sections. This allows an older QEMU to complain and 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 configurations that
> > >> >>>> work without this patch.
> > >> 
> > >> Since backwards migration is not supported upstream, wouldn't it be
> > >> easiest to just add support for the subsection marker and skipping to
> > >> the end of section in that downstream?
> > >
> > > Backwards and forwards migration need to be supported,
> > > customers told us repeatedly.
> > 
> > Can I have world peace and a pony with that?
> > 
> > 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.
> > 
> > The migration format is crap, and needs to be replaced.
> > 
> > Reasoning on migration compatibility is entirely manual.
> > 
> > Systematic testing of migration compatibility is done downstream.
> > 
> > Fortunately, there's progress being made on all of the above.  Let's not
> > sabotage it by biting off yet another mouthful.
> > 
> > >                               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.
> > 
> > Non sequitur.
> > 
> > > Finally, the real issue and difficulty with cross-version migration is
> > > 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 :)
> > 
> > However, it is.
> > 
> > >         Once you do the hard part, breaking migration because of the
> > > trivial serialization issue is just silly.  And special-casing forward
> > > migration does not make code simpler, it really only leads to
> > > proliferation of hacks and lack of symmetry.
> > 
> > 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 side,
> 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.
> > 
> > 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.
> > 
> > Treating backward migration as strictly secondary concern while we're up
> > to the ass in other alligators *can* help, by letting us focus on the
> > said other alligators.
> > 
> > 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.
> 

Michael,

I fully understand your concern and I will take some time to study backward
migration. This being said, the task is not that simple and I will need
several rounds to have the job done...

Cheers.

-- 
Gregory Kurz                                     kurzgreg@fr.ibm.com
                                                 gkurz@linux.vnet.ibm.com
Software Engineer @ IBM/Meiosys                  http://www.ibm.com
Tel +33 (0)562 165 496

"Anarchy is about taking complete responsibility for yourself."
        Alan Moore.