From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55739) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XjR50-0004fp-Qb for qemu-devel@nongnu.org; Wed, 29 Oct 2014 07:06:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XjR4w-0007q2-6j for qemu-devel@nongnu.org; Wed, 29 Oct 2014 07:06:18 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49075) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XjR4v-0007py-VT for qemu-devel@nongnu.org; Wed, 29 Oct 2014 07:06:14 -0400 Date: Wed, 29 Oct 2014 11:05:59 +0000 From: "Dr. David Alan Gilbert" Message-ID: <20141029110558.GF2310@work-vm> References: <1411464235-5653-1-git-send-email-yanghy@cn.fujitsu.com> <54508EF5.8000908@cn.fujitsu.com> <20141029093457.GB2310@work-vm> <5450B938.503@cn.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5450B938.503@cn.fujitsu.com> Subject: Re: [Qemu-devel] [RFC PATCH v2 00/23] COarse-grain LOck-stepping(COLO) Virtual Machines for Non-stop Service List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Wen Congyang Cc: Gui Jianfeng , Jiang Yunhong , Dong Eddie , qemu-devel@nongnu.org, "Michael R. Hines" , Paolo Bonzini , Walid Nouri , Yang Hongyang * Wen Congyang (wency@cn.fujitsu.com) wrote: > On 10/29/2014 05:34 PM, Dr. David Alan Gilbert wrote: > > * Wen Congyang (wency@cn.fujitsu.com) wrote: > > > > > > > >> Hi all: > >> > >> I will start to implement disk replication. Before doing this, I think we should decide > >> how to implement it. > >> > >> I have two ideas about it: > >> 1. implement it in qemu > >> Advantage: very easy, and don't take too much time > >> Disadvantage: the virtio disk with vhost is not supported, because the disk I/O > >> operations are not handled in qemu. > >> > >> 2. update drbd and make it support colo > >> Advantage: we can use it for both KVM and XEN. > >> Disadvantage: The implementation may be complex, and need too much time to > >> implement it.(I don't read the drbd's codes, and can't estimate the cost) > >> > >> I think we can use 1 to implement it first. > >> If you have some other idea, please let me know. > > > > For the COLO disk replication; are you talking here about 'local storage' > > and treating it as 'internal state' or 'external state' (as described in the > > first half of 4.4 in the original COLO paper)? > > I don't know what is 'internal state' or 'external state'. It's OK, Yang clarified that; it's 'local storage/internal state'. > What I want to implement is: > 1. forward primary vm's write operation(start sector, size, content) to secondary vm > 2. Cache the primary vm's write operation in secondary vm's qemu > 3. cache the secondary vm's write operation in secondary vm's qemu > 4. flush primary vm's write operation, and drop secondary vm's write operation after a > checkpoint > 5. drop primary vm's write operation and flush secondary vm's write operation when doing > failover. OK; and each QEMU has it's own disk image file that needs to be copied at the start? > > I know some groups would like to take advantage of facilities in the storage > > layer to help; e.g. take snapshots/rollback etc - so I think it's best > > I don't use snapshots recently years. Is it still too slow? How much time to > take snapshot/rollback? I don't know; I'd hope it could be fast if it's a COW underneath. Dave > Thanks > Wen Congyang > > > to do (1) but make the interface clean so that other mechanisms could be added. > > Similarly I guess things like scsi-xcopy might help for some people - I'm > > not saying implement these, just if possible make an interface where it could > > fit later. > > > > It's probably best to check with the QEMU storage guys that you can reuse > > anything they have; there was a discussion a few weeks back where I cc'd > > Fam, Stefan and Kevin in). > > > > Dave > > > > -- > > Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK > > . > > > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK