On Tuesday 8 May 2012 at 18:56, Frido Roose wrote:
Hello,
I wonder what the "open error -1" / "release open_disk error" messages in sanlock.log actually mean.
I saw these messages in the log on a KVM host that rebooted, and after running "/usr/sbin/virt-sanlock-cleanup" on that host. The resources where disks from 2 guests running on another KVM host.
So in fact the disks are still in use, bot got cleaned up by the other KVM host because it thought they were not longer in use...
Several questions: 1. Could this indicate a problem with the lease of these resources on the server that host these guests?
Let's try to answer myself from what I've learned so far... Doing a "sanlock client status" revealed that in fact virt-sanlock-cleanup had removed the resource, so I suspect the device were no longer 'locked' at that point. The reason for this is still unclear to me, but I think I found a way to re-register the resources.
2. Is there a way to reregister these resources, because they are still in use (but not for sanlock it seems)?
I made a script to reregister the resources by looking up the devices that were assigned to the VM and by running some sanlock commands. The crucial part in this is: dd if=/dev/zero of=/var/lib/libvirt/sanlock/$MD5 bs=1M count=1 chmod 600 /var/lib/libvirt/sanlock/$MD5 sanlock direct init -r __LIBVIRT__DISKS__:$MD5:/var/lib/libvirt/sanlock/$MD5:0 sanlock client acquire -r __LIBVIRT__DISKS__:$MD5:/var/lib/libvirt/sanlock/$MD5:0 -p $pid The $pid of the VM was still registered with the sanlock daemon, so running these commands was sufficient.
3. Overall, is it a bad idea to run virt-sanlock-cleanup?
Running virt-sanlock-cleanup now leaves the resources assigned, so I don't know why the were cleaned up. Perhaps sanlock was not completely ready with initialization after the reboot… I'm not sure. I guess time will figure out. Best regards, Frido