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
