What if we move all vm off the lun which causes this error, drop the lun and recreated it. Will we "migrate" the error with the VM to a different lun or could this be a fix? Am 6/3/2016 um 10:08 AM schrieb InterNetX - Juergen Gotteswinter:
Hello David,
thanks for your explanation of those messages, is there any possibility to get rid of this? i already figured out that it might be an corruption of the ids file, but i didnt find anything about re-creating or other solutions to fix this.
Imho this occoured after an outage where several hosts, and the iscsi SAN has been fenced and/or rebooted.
Thanks,
Juergen
Am 6/2/2016 um 6:03 PM schrieb David Teigland:
On Thu, Jun 02, 2016 at 06:47:37PM +0300, Nir Soffer wrote:
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?
I can think of nothing more to learn from sanlock. I'd suggest tighter, higher level checking or control of storage. Low level sanity checks detecting lease corruption are not a convenient place to work from.
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users