From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41674) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZqyN0-00077X-Jz for qemu-devel@nongnu.org; Tue, 27 Oct 2015 03:08:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZqyMx-0005HO-BX for qemu-devel@nongnu.org; Tue, 27 Oct 2015 03:08:34 -0400 Received: from mailout3.w1.samsung.com ([210.118.77.13]:23515) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZqyMx-0005H8-5U for qemu-devel@nongnu.org; Tue, 27 Oct 2015 03:08:31 -0400 Received: from eucpsbgm2.samsung.com (unknown [203.254.199.245]) by mailout3.w1.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTP id <0NWV00A8QAI3EH40@mailout3.w1.samsung.com> for qemu-devel@nongnu.org; Tue, 27 Oct 2015 07:08:27 +0000 (GMT) From: Pavel Fedin References: <014501d10fec$8b2548b0$a16fda10$@samsung.com> <562E5D60.7060501@redhat.com> In-reply-to: <562E5D60.7060501@redhat.com> Date: Tue, 27 Oct 2015 10:08:26 +0300 Message-id: <00b801d11086$47049600$d50dc200$@samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: quoted-printable Content-language: ru Subject: Re: [Qemu-devel] [PATCH] migration: Introduce MIGRATION_STATUS_FINISHING List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: 'Eric Blake' , qemu-devel@nongnu.org Cc: 'Amit Shah' , 'Juan Quintela' , 'Luiz Capitulino' Hello! > adding new user-visible states > has a tendency to break existing clients that aren't prepared for > unexpected states (although technically such bugs are in the client - = in > the past, libvirt used to be one such client, although we've tried to > fix it to gracefully ignore unknown states). Yes, i know this, my host uses libvirt v1.2.9.3 (i backport necessary = patches to it) and it barfed. I didn't check master though... > Are we sure no other > existing state works for this? I'm not opposed to the addition, just > wanting to make sure we have good reason for it. You know, actually, this is a thing only for qemu's internal use, we = don't need a new state at all. Instead, we could introduce a 'bool = cpus_stopped' to MigrationState structure and test for it in = migration_in_finishing(), like: --- cut --- bool migration_in_finishing(MigrationState *s) { return s->cpus_stopped; } --- cut --- What do you think about this solution? It is much less complicated = than... > One design idea for adding new states is making sure the new state = will > not be exposed unless the client specifies some new option to enable = the > state, so that old clients will never see the state and new clients = have > expressed their interest in the state With this kind of approach we would not be able to migrate ITS without = this option. Because it's not external clients being interested in this = state at the moment, but qemu itself. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia