[ovirt-users] move disk and lv not removed

[Idan Shaby]

On Tue, Oct 24, 2017 at 10:35 AM, Gianluca Cecchi <gianluca.cecchi at gmail.com
> wrote:

> On Tue, Oct 24, 2017 at 7:29 AM, Idan Shaby <ishaby at redhat.com> wrote:
>
>> Hi Gianluca,
>>
>> Can you try to reproduce it with FC? Maybe it's somehow related to that.
>> Did you try to lvremove the old lv's, or are they still in use?
>>
>
> Do you mean directly from OS using lvremove command?
>
Yes

>
>
>> Trying to do this from the SPM should be ok.
>>
>
> OK. I can try it on SPM node if you confirm
>
Sure, go ahead.

>
>
>> What do you mean synchronize the information at the other node side?
>>
>
> I mean that in the past I worked with RHCS clusters, in both kinds of LVM
> configurations: 1) CLVMD and 2) HA-LVM
> 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.
> In 2), as LVM itself is not cluster aware, it is dangerous to do LVM
> metadata operations with both nodes accessing the shared volumes.
> So in this case I typically executed these steps:
> - relocate the services so that they are all on one node
> - power down the other one
> - execute the required LVM changes
> - power on the second node to have it join the cluster again
> - eventually relocate back part of the cluster services to the second node
>

> If I run "lvs" command on both oVirt nodes, they now both show the
> information regarding the not-removed LV.
> How does oVirt manage synchronization and coherence of LVM metadata
> between nodes?
>
oVirt (vdsm, to be precise) uses SANLock [1] to achieve that goal.

> This is what I meant with my question...
>
Thanks for the explanation!
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.
However, here we're talking about a stale lv that no one should access
anymore, and that we don't have interest in anymore.
In that case, we can just go and lvremove it.
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.


>
>> 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.
>>
>>
>> Regards,
>> Idan
>>
>>
> Yes. the move operation succeeded and I'm usingthe target LV, that indeed
> is marked with "open" (o) while the source not (-)
>
> Gianluca
>
>
>
>
 [1] https://www.ovirt.org/develop/developer-guide/vdsm/sanlock/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20171025/fba2ed98/attachment.html>