[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
Re: [Qemu-devel] [PATCH v3 resend 7/8] rdma: introduce MIG_STATE_NONE and change MIG_STATE_SETUP state transition
Tue, 08 Oct 2013 18:05:43 +0200
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?