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: Wen Congyang
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:54:00 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0

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.

> 
> 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?

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
> .
> 




reply via email to

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