From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36142) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTZnK-0005IA-RI for qemu-devel@nongnu.org; Tue, 08 Oct 2013 12:06:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VTZnE-00064F-S7 for qemu-devel@nongnu.org; Tue, 08 Oct 2013 12:05:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:61589) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTZnE-000640-JZ for qemu-devel@nongnu.org; Tue, 08 Oct 2013 12:05:52 -0400 Message-ID: <52542D57.30401@redhat.com> Date: Tue, 08 Oct 2013 18:05:43 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1374501718-2581-1-git-send-email-mrhines@linux.vnet.ibm.com> <1374501718-2581-8-git-send-email-mrhines@linux.vnet.ibm.com> <52541B75.7010704@redhat.com> In-Reply-To: <52541B75.7010704@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v3 resend 7/8] rdma: introduce MIG_STATE_NONE and change MIG_STATE_SETUP state transition List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: aliguori@us.ibm.com, quintela@redhat.com, knoel@redhat.com, mrhines@linux.vnet.ibm.com, qemu-devel@nongnu.org, owasserm@redhat.com, abali@us.ibm.com, mrhines@us.ibm.com, gokul@us.ibm.com, chegu_vinod@hp.com 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? >