|
From: | Michael R. Hines |
Subject: | Re: [Qemu-devel] Microcheckpointing: Memory-VCPU / Disk State consistency |
Date: | Fri, 15 Aug 2014 01:23:14 +0800 |
User-agent: | Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 |
On 08/14/2014 06:58 PM, Dr. David Alan Gilbert wrote:
Thanks, David. Glad to see their patches in last month - I need to take a look at them.cc'ing in a couple of the COLOers.
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
[Prev in Thread] | Current Thread | [Next in Thread] |