On Fri, Dec 14, 2012 at 12:41:07 +0100, Michal Privoznik wrote: > Currently, if sanlock is already registering a lockspace other > libvirtd instances (from other hosts) obtain -EINPROGRESS. On > sufficiently new sanlock, sanlock_inq_lockspace() is called, > which suspend execution until lockspace state is changed. With > current libvirt implementation, we fail to retry adding the > lockspace again but continue in error path. Therefore we produce > meaningless error message: > > virLockManagerSanlockSetupLockspace:363 : Unable to add lockspace > /var/lib/libvirt/sanlock/__LIBVIRT__DISKS__: Success > qemudLoadDriverConfig:558 : Failed to load lock manager sanlock > > We should try to re-add the lockspace after its state change to > be sure it was added successfully. In fact, with sufficiently new > sanlock we can just avoid dummy usleep() which is used if there's > no inquire API. > --- > src/locking/lock_driver_sanlock.c | 20 ++++++++------------ > 1 files changed, 8 insertions(+), 12 deletions(-) ACK Jirka -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list