All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 0 of 9] Xen support for Remus
@ 2009-05-14  0:19 Brendan Cully
  2009-05-14  0:19 ` [PATCH 1 of 9] Add callbacks for suspend, postcopy and preresume in xc_domain_save Brendan Cully
                   ` (8 more replies)
  0 siblings, 9 replies; 10+ messages in thread
From: Brendan Cully @ 2009-05-14  0:19 UTC (permalink / raw)
  To: xen-devel; +Cc: andy

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
<http://dsg.cs.ubc.ca/remus/>.

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2009-05-14  0:19 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-05-14  0:19 [PATCH 0 of 9] Xen support for Remus Brendan Cully
2009-05-14  0:19 ` [PATCH 1 of 9] Add callbacks for suspend, postcopy and preresume in xc_domain_save Brendan Cully
2009-05-14  0:19 ` [PATCH 2 of 9] Make xc_domain_restore loop until the fd is closed Brendan Cully
2009-05-14  0:19 ` [PATCH 3 of 9] Initiate failover if a packet is not received every 500ms Brendan Cully
2009-05-14  0:19 ` [PATCH 4 of 9] Support more than 2 FDs per tapdisk Brendan Cully
2009-05-14  0:19 ` [PATCH 5 of 9] Check tapdisk paths from the last colon instead of the first Brendan Cully
2009-05-14  0:19 ` [PATCH 6 of 9] Remus tapdisk proxy Brendan Cully
2009-05-14  0:19 ` [PATCH 7 of 9] Buffer checkpoint data locally until domain has resumed execution Brendan Cully
2009-05-14  0:19 ` [PATCH 8 of 9] Do not bother with to_skip/to_fix bitmaps after the first final round Brendan Cully
2009-05-14  0:19 ` [PATCH 9 of 9] Do bitmap scan word-by-word before bit-by-bit Brendan Cully

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.