Re: [Qemu-devel] Microcheckpointing: Memory-VCPU / Disk State consistency

["Michael R. Hines" <mrhines@linux.vnet.ibm.com>]

On 08/14/2014 06:58 PM, Dr. David Alan Gilbert wrote:
> cc'ing in a couple of the COLOers.
Thanks, David. Glad to see their patches in last month - I need to take 
a look at them.

> The 2013 paper says: 'COLO modifies the guest OS’s TCP/IP stack in 
> order to make the behavior more deterministic. ' but does say that an 
> alternative might be to have a ' comparison function that operates 
> transparently over re-assembled TCP streams' 

Ouch - I didn't realize that.

It may or may not be a problem - but if it gets us further towards 
fault-tolerance, I'm open-minded. =)

The Xen paper did the same thing for databases - they also modified the 
guest TCP stack.

>> My hope in the future was that the two approaches could be used in a
>> "Hybrid" manner - actually MC has much more of a performance hit for I/O
>> than COLO does because of its buffering requirements.
>>
>> On the other hand, MC would perform better in a memory-intensive or
>> CPU-intensive situation - so maybe QEMU could "switch" between the two
>> mechanisms at different points in time when the resource bottleneck changes.
> If the primary were to rate-limit the number of resynchronisations
> (and send the secondary a message as soon as it knew a resync was needed) that
> would get some of the way, but then the only difference from microcheckpointing
> at that point is the secondary doing a wasteful copy and sending the packets across;
> it seems it should be easy to disable those if it knew that a resync was going to
> happen.
>
> Dave