[ovirt-users] Sanlock add Lockspace Errors

[Nir Soffer]

On Thu, Jun 2, 2016 at 6:35 PM, David Teigland <teigland at redhat.com> wrote:
>> verify_leader 2 wrong space name
>> 4643f652-8014-4951-8a1a-02af41e67d08
>> f757b127-a951-4fa9-bf90-81180c0702e6
>> /dev/f757b127-a951-4fa9-bf90-81180c0702e6/ids
>
>> leader1 delta_acquire_begin error -226 lockspace
>> f757b127-a951-4fa9-bf90-81180c0702e6 host_id 2
>
> VDSM has tried to join VG/lockspace/storage-domain "f757b127" on LV
> /dev/f757b127-a951-4fa9-bf90-81180c0702e6/ids.  But sanlock finds that
> lockspace "4643f652" is initialized on that storage, i.e. inconsistency
> between the leases formatted on disk and what the leases are being used
> for.  That should never happen unless sanlock and/or storage are
> used/moved/copied wrongly.  The error is a sanlock sanity check to catch
> misuse.
>
>
>> s1527 check_other_lease invalid for host 0 0 ts 7566376 name  in
>> 4643f652-8014-4951-8a1a-02af41e67d08
>
>> s1527 check_other_lease leader 12212010 owner 1 11 ts 7566376
>> sn f757b127-a951-4fa9-bf90-81180c0702e6 rn f888524b-27aa-4724-8bae-051f9e950a21.vm1.intern
>
> Apparently sanlock is already managing a lockspace called "4643f652" when
> it finds another lease in that lockspace has the inconsistent/corrupt name
> "f757b127".  I can't say what steps might have been done to lead to this.
>
> This is a mess that's been caused by improper use of storage, and various
> sanity checks in sanlock have all reported errors for "impossible"
> conditions indicating that something catastrophic has been done to the
> storage it's using.  Some fundamental rules are not being followed.

Thanks David.

Do you need more output from sanlock to understand this issue?

Juergen, can you open ovirt bug, and include sanlock and vdsm logs from the time
this error started?

Thanks,
Nir