On 2015/7/30 12:23, Jason Wang wrote: > > > On 07/20/2015 02:42 PM, Li Zhijian wrote: >> Hi, all >> >> We are planning to implement colo-proxy in qemu to cache and compare >> packets. >> This module is one of the important component of COLO project and now >> it is >> still in early stage, so any comments and feedback are warmly welcomed, >> thanks in advance. >> >> ## Background >> COLO FT/HA (COarse-grain LOck-stepping Virtual Machines for Non-stop >> Service) >> project is a high availability solution. Both Primary VM (PVM) and >> Secondary VM >> (SVM) run in parallel. They receive the same request from client, and >> generate >> responses in parallel too. If the response packets from PVM and SVM are >> identical, they are released immediately. Otherwise, a VM checkpoint >> (on demand) >> is conducted. >> Paper: >> http://www.socc2013.org/home/program/a3-dong.pdf?attredirects=0 >> COLO on Xen: >> http://wiki.xen.org/wiki/COLO_-_Coarse_Grain_Lock_Stepping >> COLO on Qemu/KVM: >> http://wiki.qemu.org/Features/COLO >> >> By the needs of capturing response packets from PVM and SVM and >> finding out >> whether they are identical, we introduce a new module to qemu >> networking called >> colo-proxy. > > A question here, the packet comparing may be very tricky. For example, > some protocol use random data to generate unpredictable id or something > else. One example is ipv6_select_ident() in Linux. So COLO needs a > mechanism to make sure PVM and SVM can generate same random data? > Good question, the random data connection is a big problem for COLO. At present, it will trigger checkpoint processing because of the different random data. I don't think any mechanisms can assure two different machines generate the same random data. If you have any ideas, pls tell us :)
Frequent checkpoint can handle this scenario, but maybe will cause the performance poor. :( Regards, -Gonglei
