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: Juan Quintela
Subject: Re: [Qemu-devel] [PATCH] Migration compatibility for serial
Date: Wed, 17 Jun 2015 18:34:55 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

"Michael S. Tsirkin" <address@hidden> wrote:
> 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?

Source don't know if destination understand it or not.  That is the
whole point of being optional.  Source sends it if it is needed.
Destination can handle it (or not).

there are (at least) two qemu pc-2.2:
qemu-2.2 -M pc-2.2
qemu-2.3 -M pc-2.2

Same machine type.  Second is able to receive it.  First one is not.
Source don't know what is on the other side.  If user is going to put a:

--dont_send_serial_because_I_don't_care

Then it can as well just disable the serial device and live with it.

Later, Juan.


>
> 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]