Re: [PATCH RFC] remus: implement remus replicated checkpointing disk

[Lai Jiangshan <laijs@cn.fujitsu.com>]

On 03/12/2014 06:07 PM, Ian Campbell wrote:
> On Wed, 2014-03-12 at 10:35 +0800, Lai Jiangshan wrote:
>>> 2. The tapdisk based replication unfortunately is outdated. Please correct me if I have got this wrong.
>>> Haven't we decided to get rid of blktap2 and go with the qemu disk models? In which case, the tapdisk
>>> remus code has to be ported into some qemu disk variant.
>>
>> We are implementing *qemu* replicated checkpointing disk, but we can't make it public even we have done,
>> we need to delay the publication due to we are paid to implement it by a paid customer.
> 
> Are you saying you are never going to be able to make this code public?
> Or just that it will be delayed by some months?

It will be just delayed, but it will be public finally.

This private code is just under implementing, it is far from mature.
I hope the community also makes efforts to it.

see also to: http://wiki.qemu.org/Features/MicroCheckpointing


> 
>>
>>>
>>> Without getting a resolution to the above two, my stance is that we shouldn't pollute xl with functionality
>>> that requires out-of-band modules that may prove pretty painful to install for the majority of folks out there.
>>
>> I'm also concern with out-of-band modules, since remus-drbd can't be merged upstream,
>> It will be valueless to apply remus-drbd replicated checkpointing disk to xl.
>>
>> What's the status of blktap3 now? (I am asking to xen community)
> 
> AFAIK the XenServer are not continuing down the blktap3 path and are
> instead planning to switch to qemu qdisk as a backend.
> 
> 
>