On 14.12.2012 13:42, Jiri Denemark wrote: > 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 > Thanks, pushed. Michal -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list