|
From: | Michael R. Hines |
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 13:32:06 -0400 |
User-agent: | Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 |
On 10/08/2013 12:05 PM, Paolo Bonzini 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
That makes sense to me too - the setup state is "effectively" the same as active and can be safely treated as such. There's a similar issue MigrationInfo statistics - what's the backwards/forwards-compatible procedure for not breaking libvirt when new statics appear? - such as "setup-time", which timestamps the new state that was introduced? - Michael for adding new statistics - Michael
[Prev in Thread] | Current Thread | [Next in Thread] |