From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33770) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YlT78-0004fW-Q3 for qemu-devel@nongnu.org; Thu, 23 Apr 2015 22:13:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YlT74-0000cu-KG for qemu-devel@nongnu.org; Thu, 23 Apr 2015 22:13:10 -0400 Message-ID: <5539A78D.1020206@cn.fujitsu.com> Date: Fri, 24 Apr 2015 10:16:45 +0800 From: Wen Congyang MIME-Version: 1.0 References: <20150423101716.GF5289@noname.redhat.com> <5538CA77.4030708@redhat.com> <20150423104045.GG5289@noname.redhat.com> <5538CD0F.1060100@redhat.com> <20150423113631.GH5289@noname.redhat.com> <5538DD52.3020101@redhat.com> <20150423120533.GF2177@work-vm> <5538E174.9020201@redhat.com> <20150423121953.GG2177@work-vm> <5538E459.5030801@redhat.com> <20150424020149.GL2723@ad.nay.redhat.com> In-Reply-To: <20150424020149.GL2723@ad.nay.redhat.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH COLO v3 01/14] docs: block replication's description List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fam Zheng , Paolo Bonzini Cc: Kevin Wolf , Yang Hongyang , Lai Jiangshan , qemu block , armbru@redhat.com, jcody@redhat.com, Jiang Yunhong , Dong Eddie , "Dr. David Alan Gilbert" , qemu devel , Gonglei , Stefan Hajnoczi , Max Reitz , zhanghailiang On 04/24/2015 10:01 AM, Fam Zheng wrote: > On Thu, 04/23 14:23, Paolo Bonzini wrote: >> >> >> On 23/04/2015 14:19, Dr. David Alan Gilbert wrote: >>>>> So that means the bdrv_start_replication and bdrv_stop_replication >>>>> callbacks are more or less redundant, at least on the primary? >>>>> >>>>> In fact, who calls them? Certainly nothing in this patch set... >>>>> :) >>> In the main colo set (I'm looking at the February version) there >>> are calls to them, the 'stop_replication' is called at failover time. >>> >>> Here is I think the later version: >>> http://lists.nongnu.org/archive/html/qemu-devel/2015-03/msg05391.html >> >> I think the primary shouldn't do any I/O after failover (and the >> secondary should close the NBD server) so it is probably okay to ignore >> the removal for now. Inserting the filter dynamically is probably >> needed though. > > Or maybe just enabling/disabling? Hmm, after failover, the secondary qemu should become primary qemu, but we don't know the nbd server's IP/port when we execute the secondary qemu. So we need to inserting nbd client dynamically after failover. Thanks Wen Congyang > > Fam > . >