On 11/12/2012 09:01 AM, Michal Privoznik wrote:
It may take some time for sanlock to add a lockspace. And if user
restart libvirtd service meanwhile, the fresh daemon can fail adding the
same lockspace with EINPROGRESS. Hence, we should retry a few times
before claiming an error. This issue can be easily reproduced:
for i in {1..1000} ; do echo $i; service libvirtd restart; sleep 2; done
20
Stopping libvirtd daemon: [FAILED]
Starting libvirtd daemon: [ OK ]
21
Stopping libvirtd daemon: [ OK ]
Starting libvirtd daemon: [ OK ]
22
Stopping libvirtd daemon: [ OK ]
Starting libvirtd daemon: [ OK ]
error : virLockManagerSanlockSetupLockspace:334 : Unable to add
lockspace /var/lib/libvirt/sanlock/__LIBVIRT__DISKS__: Operation now in
progress
---
src/locking/lock_driver_sanlock.c | 16 +++++++++++++++-
1 files changed, 15 insertions(+), 1 deletions(-)
@@ -320,9 +326,17 @@ static int
virLockManagerSanlockSetupLockspace(void)
ls.host_id = driver->hostID;
/* Stage 2: Try to register the lockspace with the daemon.
* If the lockspace is already registered, we should get EEXIST back
- * in which case we can just carry on with life
+ * in which case we can just carry on with life, or EINPROGRESS if
+ * previous libvirtd instance started the work but didn't finish.
+ * Unfortunately, sanlock lacks an API to determine state of lockspace,
+ * so we have to do this blindly.
Have we reported this deficiency to the sanlock folks?
At any rate, your retry loop looks sane; it can probably still timeout
under heavy load, but at least it won't be as common. You may want to
wait for danpb or DV to chime in, but you have my ACK.
--
Eric Blake eblake(a)redhat.com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org