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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]