Re: [Qemu-devel] [RFC PATCH v2 00/23] COarse-grain LOck-stepping(COLO) Virtual Machines for Non-stop Service

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

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