From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wen Congyang Subject: Re: [RFC Patch 00/25] COarse-grain LOck-stepping Virtual Machines for Non-stop Service Date: Fri, 18 Jul 2014 22:30:16 +0800 Message-ID: <53C92F78.202@gmail.com> References: <1405683551-12579-1-git-send-email-wency@cn.fujitsu.com> <53C92CCD.1000908@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <53C92CCD.1000908@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andrew Cooper , Wen Congyang , xen devel Cc: Ian Campbell , Ian Jackson , Jiang Yunhong , Dong Eddie , Yang Hongyang , Lai Jiangshan List-Id: xen-devel@lists.xenproject.org At 2014/7/18 22:18, Andrew Cooper Wrote: > On 18/07/14 12:38, Wen Congyang wrote: >> Virtual machine (VM) replication is a well known technique for providing >> application-agnostic software-implemented hardware fault tolerance - >> "non-stop service". Currently, remus provides this function, but it buffers >> all output packets, and the latency is unacceptable. >> >> In xen summit 2012, We introduce a new VM replication solution: colo >> (COarse-grain LOck-stepping virtual machine). The presentation is in >> the following URL: >> http://www.slideshare.net/xen_com_mgr/colo-coarsegrain-lockstepping-virtual-machines-for-nonstop-service >> >> Here is the summary of the solution: >> >From the client's point of view, as long as the client observes identical >> responses from the primary and secondary VMs, according to the service >> semantics, then the secondary vm is a valid replica of the primary >> vm, and can successfully take over when a hardware failure of the >> primary vm is detected. >> >> This patchset is RFC, and implements the frame of colo: >> 1. Both primary vm and secondary vm are running >> 2. do checkoint >> >> This patchset is based on remus-v15, and use migration v1. Only supports hvm >> guest now. >> >> TODO list: >> 1. rebase to remus-v17 or newer >> 2. support migration v2 >> 3. nic/disk replication >> 4. support pvm > > This is an interesting set of patches. One query I have is what you > mean by "support migration v2". > > While I am developing migration v2, the old legacy code is left in place > for easier testing and development purposes, but when the migration v2 > code does finally get committed, the legacy migration code will be > deleted. > > The legacy code is unfit for purpose and entirely replaced by v2, in a > backwards-compatible manor given the included conversion script (not > that that matters for Remus/colo). We use migration to implement remus/colo. If migration v2 is merged into upstream xen, I think I need to add codes to migration v2, and make colo can work with migration v2. Thanks Wen Congyang > > ~Andrew > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel >