qemu-devel
[Top][All Lists]
Advanced

[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: Chris Wulff
Subject: Re: [Qemu-devel] [PATCH v3 resend 7/8] rdma: introduce MIG_STATE_NONE and change MIG_STATE_SETUP state transition
Date: Tue, 22 Oct 2013 19:39:19 -0400




On Oct 8, 2013, at 12:05 PM, Paolo Bonzini <address@hidden> wrote:

> 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".
> 
> Paolo
> 
>> 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]