Currently, I'm trying to setup a HA evaluation platform based on Remus using Debian 6.0.6 amd64 as a base. However, following the instructions and suggestion found mainly in this and the xen.org wikis gave me a lot of grieves. F.e., using exactly the Xen 4.1.2, Linux 2.6.32.40 for Dom0 and protocol D enabled DRBD 8.3.9 mentioned there, I ended up with a setup which constantly complained that the DRBD backing devices would freeze, not even allowing to install DomU, let alone firing it up.
I then decided to apart from DRBD go with the packages shipping with Debian experimental, given it has Xen 4.2.0 (which according to the release notes has Remus compression included) and Linux 3.7 (which includes sch_plug) for both Dom0 and DomU. With that combination, regular DomU worked but migrating TCP connections via Remus didn't work even once.
Finally, I achieved a working Remus setup using Xen 4.2.0 from Debian experimental (plus the persistent bitmaps patch), stock Linux 3.2.32 from Debian testing, sch_plug from pasik.reaktio.net plus the fix from forum post #1409955 and the Remus version of DRBD 8.9.11.
My next problem then was that using xenstore signalling was too slow for my application (btw., is there any particular reason the suspend event channel isn't in upstream pv_ops Linux? It seems trivial to implement.). Thus, I switched to linux-2.6.18-xen (1214:c340a22a3a63) for the DomU. However, this kernel turned out to suffer from network starvation already under light load, pretty soon after boot and without Remus in the loop. The packets seen via tcpdump in the DomU then just no longer arriving on the Dom0 side when sniffing on the bridge there.
Therefore, I switched to a Debian stable Linux 2.6.32 kernel built with the Novell SLES11 SP1 XenLinux forward-ported patches provided by the Gentoo folks applied. This finally gave me a working Remus setup - somewhat.
Anyway, thus far in case someone wants to build a working Remus setup (it's great that I'm not allowed to post links here …). The "official" instructions seem to be in dare need of an update though.
My real question is though why Remus failover doesn't work properly more than once. My understanding is that due to missing resynchronization, this just isn't possible with blktap2 but should work without problems with DRBD (but actually doesn't). The strange thing is, that after the first failover, additional ones actually work (also without any issues on the block device side) but the migration of TCP connections doesn't work (traffic just stops without any indication of a reason in the logs) any longer. However, even after the Nth (for N > 1) failover, I still can create new TCP connections, which work until the next failover. Is this a bug or a limitation in Remus?