[Top][All Lists]

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

Re: [Qemu-devel] [PATCH v3 resend 7/8] rdma: introduce MIG_STATE_NONE an

From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH v3 resend 7/8] rdma: introduce MIG_STATE_NONE and change MIG_STATE_SETUP state transition
Date: Tue, 08 Oct 2013 18:05:43 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130923 Thunderbird/17.0.9

Il 08/10/2013 16:49, Eric Blake ha scritto:
> You are now returning a state that older libvirt versions are not
> expecting.  Obviously, we can patch newer libvirt to make migration work
> again, but should we be thinking about damage control by stating that an
> older management app should still be able to drive migration on a new
> qemu?  Or is it acceptable to state that newer qemu requires newer
> management tools?

We strive for that, but sometimes we break because we do not really know
what management expects from QEMU.

In this case, in particular, I think a capability is a bit overkill.
Libvirt needs to be somewhat liberal in what it accepts; in this case it
can treat any unknown state as "active".


> If we try to support this working under older management tools, maybe
> the approach is that we have to add some new migration capability; newer
> management tools set the capability to true and are therefore allowed to
> see the new state name; older management tools do not set the capability
> and when that is the case we guarantee that we do not return a state
> string that the older tool is not expecting.  Thoughts on whether we
> should pursue this?

reply via email to

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