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:
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.
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
>>> 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