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 > _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users