Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
So, always the same problem without understanding why it works when all iSCSI clients are connected to the same DRBD, and no way to synchronize lvcreate/lvremove between clients on different DRBD hosts, despite they are primary/primary.. I search a solution to the LVM side, but answers were "check your DRBD replication link". :( Olivier XO Project http://xen-orchestra.com On Tue, Mar 9, 2010 at 3:46 PM, Olivier LAMBERT <lambert.olivier at gmail.com> wrote: >> It just replicates whatever you write to it, no more, no less. > > That's why I don't understand why it works fine when LVM clients are > connected on the same DRBD server, and it doesn't work when each > client is on separate DRBD server (despite replication is working). > Can you explain this behaviour ? > > Furthermore, I do some tests with cLVM. My cluster is working, I can > create pv and vg on one node, but the other can't see it. Then, when I > try to create a LV, cLVM says : > lvcreate -L82M -n testvol vg_xen > Rounding up size to full physical extent 84,00 MB > Error locking on node ad37864: Volume group for uuid not found: > 1xgSmqky8beMkIQSGqYQ0fSC6IdOBOJEg46qEeWY9eV9njYJ2B9zxJwyXIaSHs3h > Aborting. Failed to activate new LV to wipe the start of it. > > > Sorry if I miss someting... > > > Olivier > XO Project > http://xen-orchestra.com > > > On Tue, Mar 9, 2010 at 3:09 PM, Lars Ellenberg > <lars.ellenberg at linbit.com> wrote: >> On Tue, Mar 09, 2010 at 11:39:34AM +0100, Olivier LAMBERT wrote: >>> Hmmm. I like riddles, so I'm going to google this. Is there any simple >>> solutions, in example force drbd to deal with that ? >> >> You need to "force" your application stuff (and, yes, in this context >> lvm is an application) do deal with that, and cLVM would be the means >> to do that, i.e. coordinate. Possibly you even need to start earlier, >> and fix your iSCSI target configuration. >> >> There is nothing to force DRBD to do in this context. >> It just replicates whatever you write to it, no more, no less. >> >> If you have caches on "the way" to "the other client" >> that happen to happily cache stale content (are "incoherent"), >> there is nothing DRBD can do about it. >> >> -- >> : Lars Ellenberg >> : LINBIT | Your Way to High Availability >> : DRBD/HA support and consulting http://www.linbit.com >> >> DRBD® and LINBIT® are registered trademarks of LINBIT, Austria. >> __ >> please don't Cc me, but send to list -- I'm subscribed >> _______________________________________________ >> drbd-user mailing list >> drbd-user at lists.linbit.com >> http://lists.linbit.com/mailman/listinfo/drbd-user >> >