qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] Migration compatibility for serial


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCH] Migration compatibility for serial
Date: Wed, 17 Jun 2015 16:44:28 +0200

On Wed, Jun 17, 2015 at 02:20:42PM +0200, Paolo Bonzini wrote:
> 
> 
> On 17/06/2015 14:07, Dr. David Alan Gilbert wrote:
> > Of course for us on RHEL our minor releases don't correspond to
> > QEMU minor releases, so we already support migrating from our
> > downstream 7.1 (QEMU 2.1) derivative to our 7.0 (1.5.3) version.  
> > And the reason for this patch series is to support something >2.2
> > migrating back to that 2.1 (or maybe even to that 1.5.3).
> > 
> > I don't believe we're alone in wanting to be able to do that type
> > of thing;
> 
> Others may prefer to have migration only work when it is absolutely sure
> that it works.  It is much easier to add hacks on top of what upstream
> QEMU does (e.g. using the static checker), than to remove the hacks.
> 
> If we really didn't care about others' support for bidirectional
> migration, we would have kept the static checker internal to Red Hat.
> Or we wouldn't have bothered to refine the .needed functions, and so on.
> 
> Paolo

What we need to decide is how major is the breakage.
If it's minor - like some lost characters - then it's not
worth breaking migration for most users.
And I think this should be a property so people can
force strict mode if they really want to.

If it's a major breakage, it's harder to decide:
some people might be able to retry migration later.
Maybe a flag to enable this mode would make sense?
Also, maybe it would be better to fail migration on source
rather than send something destination can't handle?

But let's see what the symptoms are before we argue
about this option.

> > so you can either worry about not burdening upstream
> > with compatibility patches like this, or think it's not fair
> > to leave them out if others upstream might want them.  How many
> > others? Well I'd say it's got to be more than some of the other
> > obscure features in QEMU!



reply via email to

[Prev in Thread] Current Thread [Next in Thread]