On Oct 8, 2013, at 12:05 PM, Paolo Bonzini <pbonz...@redhat.com> 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?
>
>
