From mboxrd@z Thu Jan 1 00:00:00 1970 From: Brendan Cully Subject: [PATCH 0 of 9] Xen support for Remus Date: Wed, 13 May 2009 17:19:28 -0700 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com Cc: andy@cs.ubc.ca List-Id: xen-devel@lists.xenproject.org Hi all, This set of patches adds Remus support to Xen. Remus extends the Xen live migration machinery in order to provide transparent, comprehensive high availability for ordinary virtual machines. More information can be found at . This patch set is against the current tip of xen-unstable (changeset 2522cc95efd2). It provides support for PV guests in 32-on-32 and 64-on-64 configurations -- 32-on-64 and HVM are still in progress. These patches modify Xen to support Remus -- to actually use it, you'll also need the control tools and instructions available here: http://dsg.cs.ubc.ca/remus/hg/tools/ I'll investigate integrating the tool stack into the Xen repository's 'tools' directory soon. I've tested these changes for backward compatibility with unpatched Xen. Specifically, I've tested live migration in both directions (from plain Xen to Remusified Xen and vice versa) for PV and HVM guests, each in 32-on-32, 32-on-64, and 64-on-64 configurations. I'm maintaining these patches in an hg queue repository here: http://dsg.cs.ubc.ca/remus/hg/xen-3.4-testing.hg/patches/ Details of the patch series: The first two patches provide core support for incremental checkpointing: continuous-checkpoint continuous-restore The next 3 provide a new tapdisk module ('remus') which acts as a proxy for any other tapdisk module, replicating writes to the backup node: tapdisk-more-fds tapdisk-image-check tapdisk-remus All following patches are performance related. These patches are a request for comment, and as such are optimized to be easy to rebase rather than beautiful, but I'm happy to discuss how they could be polished. With that in mind, I hope that you'll try them out if you're interested in high availability or fast, incremental checkpointing in general. I look forward to your feedback! Brendan