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: Stefan Hajnoczi
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 17:19:43 +0000
User-agent: Mutt/1.5.23 (2014-03-12)

On Wed, Oct 29, 2014 at 05:54:00PM +0800, Wen Congyang 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'.
> 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.

This is more complicated than it sounds.

I suggest writing a prototype in QEMU and sending RFC patches to the
mailing list.

After the error scenarios and problems have been fully thought through,
then it will be clearer whether to implement it in QEMU or the kernel.

Stefan

Attachment: pgpBoCcBUiDl1.pgp
Description: PGP signature


reply via email to

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