qemu-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]