[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH v2 00/23] COarse-grain LOck-stepping(COLO) V
From: |
Dr. David Alan Gilbert |
Subject: |
Re: [Qemu-devel] [RFC PATCH v2 00/23] COarse-grain LOck-stepping(COLO) Virtual Machines for Non-stop Service |
Date: |
Wed, 29 Oct 2014 11:05:59 +0000 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
* Wen Congyang (address@hidden) wrote:
> On 10/29/2014 05:34 PM, Dr. David Alan Gilbert wrote:
> > * Wen Congyang (address@hidden) 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 / address@hidden / Manchester, UK
> > .
> >
>
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK