<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 11 Apr 2014, at 22:37, Lars Ellenberg <<a href="mailto:lars.ellenberg@linbit.com">lars.ellenberg@linbit.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><br>please start new threads not as reply to unrelated threads.<br>(thread hijacking... goole it ...)<br><br>On Fri, Apr 11, 2014 at 10:14:50PM +0200, Bart Coninckx wrote:<br><blockquote type="cite"><span class="Apple-tab-span" style="white-space:pre"> </span>Hi all,<br><br>when enabling automated LVM snapshots, do they interfere (or vice<br>versa) with the LVM configurations of a nested LVM setup?<br></blockquote><br>I think you need to elaborate a bit more...<br><br>What would your "nested LVM setup" look like,<br>and where/how would you do the "automated" snapshots?<br><br><br>I've seen problems with LVM,<br>if you snapshot the LV below DRBD<br>(which temporarily has to suspend that LV)<br>while having the DRBD "visible" to the LVM tools<br>(not filtered out in the device filter of lvm.conf)...<br><br>The tools could end up scanning the DRBD for LVM meta data,<br>while having the lower LV suspended, which will obviously cause those<br>tools to deadlock (and DRBD to remain "hung" or blocked as well).<br><br>If you really need a nested LVM setup<br>where both "layers" are visible to the host<br>(not in the sense of LV -> DRBD -> virtual machine image,<br> and then LVM inside that VM)<br><br>I'd recommend to utilize the "LVM_SYSTEM_DIR" environment variable,<br>and have two (or more) separate lvm.conf with suitable filter settings,<br>with the "outer" one being the default (and filter out all DRBD),<br>and any "inner" one(s) only being used explicitly by setting the<br>respective LVM_SYSTEM_DIR (and filter out everything BUT the<br>corresponding DRBD).<br><br>hth,<br><span class="Apple-tab-span" style="white-space:pre"> </span>Lars<br><br><br>-- <br>: Lars Ellenberg<br>: LINBIT | Your Way to High Availability<br>: DRBD/HA support and consulting <a href="http://www.linbit.com">http://www.linbit.com</a><br><br>DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.<br>__<br>please don't Cc me, but send to list -- I'm subscribed<br>_______________________________________________<br>drbd-user mailing list<br><a href="mailto:drbd-user@lists.linbit.com">drbd-user@lists.linbit.com</a><br>http://lists.linbit.com/mailman/listinfo/drbd-user<br></blockquote></div><br><div><br></div><div>Hi Lars,</div><div><br></div><div>thanks for your answer and time. </div><div>The kind of LVM setup I'm referring to is that one on <a href="http://www.drbd.org/users-guide/s-nested-lvm.html">http://www.drbd.org/users-guide/s-nested-lvm.html</a> . The reason for this would be to have maximum flexibility in (re)sizing DRBD resources, but maybe that overcomplicates things and I would better stick to LVM on the backing device. Would that interfere with the automated LVM snapshots feature described in <a href="http://www.drbd.org/users-guide/s-lvm-snapshots.html">http://www.drbd.org/users-guide/s-lvm-snapshots.html</a> ?</div><div><br></div><div>Thx again,</div><div><br></div><div>BC</div><div><br></div><div><br></div><div><br></div><div><br></div></body></html>