<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Oct 24, 2017 at 10:35 AM, Gianluca Cecchi <span dir="ltr"><<a href="mailto:gianluca.cecchi@gmail.com" target="_blank">gianluca.cecchi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-">On Tue, Oct 24, 2017 at 7:29 AM, Idan Shaby <span dir="ltr"><<a href="mailto:ishaby@redhat.com" target="_blank">ishaby@redhat.com</a>></span> wrote:<br></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><div><div>Hi Gianluca,<br><br></div><span class="gmail-">Can you try to reproduce it with FC? Maybe it's somehow related to that.<br></span></div><span class="gmail-">Did you try to lvremove the old lv's, or are they still in use?<br></span></div></div></div></blockquote><div><br></div><div>Do you mean directly from OS using lvremove command? </div></div></div></div></blockquote><div>Yes <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div></div>Trying to do this from the SPM should be ok. </div></div></blockquote><div><br></div></span><div>OK. I can try it on SPM node if you confirm </div></div></div></div></blockquote><div>Sure, go ahead. <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>What do you mean synchronize the information at the other node side?<br></div></div></blockquote><div><br></div></span><div>I mean that in the past I worked with RHCS clusters, in both kinds of LVM configurations: 1) CLVMD and 2) HA-LVM</div><div>In 1) I have the LVM layer that is cluster aware so if I run commands that modify metadata information for LVM (such as adding, removing, extending LV) I'm confident.</div><div>In 2), as LVM itself is not cluster aware, it is dangerous to do LVM metadata operations with both nodes accessing the shared volumes.</div><div>So in this case I typically executed these steps:</div><div>- relocate the services so that they are all on one node </div><div>- power down the other one</div><div>- execute the required LVM changes </div><div>- power on the second node to have it join the cluster again</div><div>- eventually relocate back part of the cluster services to the second node</div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>If I run "lvs" command on both oVirt nodes, they now both show the information regarding the not-removed LV.</div><div>How does oVirt manage synchronization and coherence of LVM metadata between nodes?</div></div></div></div></blockquote><div>oVirt (vdsm, to be precise) uses SANLock [1] to achieve that goal. <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>This is what I meant with my question...</div></div></div></div></blockquote><div>Thanks for the explanation!</div><div>Generally you're right. We do have to make sure that metadata operations on a logical volume are done by only one host, because we're indeed not using clvm.</div><div>However, here we're talking about a stale lv that no one should access anymore, and that we don't have interest in anymore.</div><div>In that case, we can just go and lvremove it.</div><div>Regarding the bug itself, if you are able to reproduce it in any way, please send the full logs so we can understand its cause.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div>In any case, this is a disk that you don't need anymore, isn't it? You said that the copy part of the move operation went well.<br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail-m_-7346633918361847056gmail-m_8286679596754900879gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br>Regards,<br></div>Idan<br></div></div></div></div></div></div></div><div><div class="gmail-m_-7346633918361847056gmail-h5"><br></div></div></div></blockquote><div><br></div></span><div>Yes. the move operation succeeded and I'm usingthe target LV, that indeed is marked with "open" (o) while the source not (-)</div><span class="gmail-HOEnZb"><font color="#888888"><div><br></div><div>Gianluca</div><div><br></div><div><br></div><div> </div></font></span></div></div></div>
</blockquote></div> [1] <a href="https://www.ovirt.org/develop/developer-guide/vdsm/sanlock/">https://www.ovirt.org/develop/developer-guide/vdsm/sanlock/</a><br></div></div>