Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Dear Dmitry, Am Freitag, 4. Mai 2007 16:34:50 schrieb Dmitry S. Makovey: > 1. your setup seems "strange" in a way that it seems you're doing > > > /dev/mdX --> LVM2 volumes --> drbd volume for each LV --> XEN domU > > and what I'd do would be /dev/mdX -> drbd -> Xen domU + LVM2 this way you > end up with only several drbdX (or maybe just one). I also considered this option, but for the reason why I chose drbd on top of LVM2, see below. > 2. you're assuming that Xen migration is going to work with DRBD but from > my understanding Xen needs both systems to have their storage to be > attached at the same time for some period of time (time of migration). With > DRBD one system should stay offline, unless you're ready to run out of sync > between two systems. Exactly. To enable XEN live migration, both nodes need to be primary - with one drbd8 volume for each domU, I can modify the migration scripts to go primary on both for the period of the migration and secondary on the "old" node after migration has finished. This has, IMHO, two advantages: - live migration should work - in normal operation, only one node is primary, and thus the chances of going split-brain should be _very_ slim (the network would need to fail exactly during migration, which seems unlikely) Therefore, and after reading of different setup-variants, I decided to go for this one. It seemed the most flexible of the "safe" setups (since e.g. ocfs2 over drbd8 does not yet seem to be mature enough for production systems(. With LVM on top of drbd8, both would need to be primary for the whole drbd volume, although they would only ever write in different logical volumes, i.e. different parts of the drbd8 volume. Without stonith hardware, this somehow seems like a recipe for split-brain to me (without having tried in practice). Does anybody on this list use LVM2 on top of drbd8? Have you ever encountered split-brain? > Those were probably not the root cause of your trouble but simplifying > setup could help to get around the problem ;) I completely agree, and am open for any suggestions that would have the above benefits ;) with best regards, Rene -- ------------------------------------------------- Gibraltar firewall http://www.gibraltar.at/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20070504/d6b64b02/attachment.pgp>