[libvirt] [PATCH] sanlock: Retry after EINPROGRESS

Eric Blake eblake at redhat.com
Mon Nov 12 22:39:12 UTC 2012


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 at redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 617 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20121112/d61a5ab3/attachment-0001.sig>


More information about the libvir-list mailing list