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