[libvirt] RFC: Introduce a dlm-corosync for Lock manager plugin
Daniel P. Berrange
berrange at redhat.com
Fri Dec 22 08:57:10 UTC 2017
On Fri, Dec 22, 2017 at 12:59:24AM -0700, Lin Fu wrote:
> > How are locks acquired by libdlm scoped ? The reason we have virtlockd is
> > that the fcntl() locks need to be held by a running process, and we wanted
> > them to persist across libvirtd restarts. This required holding them in a
> > separate process.
> Locks are managed by 'dlm_controld' daemon. There is a flag marked as
> `LKF_PERSISTENT` could archive the purpose that locks still exist after
> restarting libvirtd. And within my current cognition, lock would only
> disappear after rebooting OS, (not release the locks manually); at the
> same time, other nodes in clusters could recovery the lock context.
> > Are libdlm locks automatically released when the process that acquired
> > them dies, or is a manual release action required ? If they always require
> > a manual release, then there would be no need to use virtlockd - the plugin
> > can just take care of acquire & release, and still cope with lbivirtd
> > restarts.
> So why do I talk about virtlockd? It about the lockid. And what is lockid?
> In dlm, there are concepts about 'lockspace', 'resource' and 'lockid'. The
> relationship: multiple locks could be associated with the same resource,
> one lockspace could be added in multiple resource. When acquire a lock for
> the resource, lockid is returned by acquiring API call.
> Question: How could I know that which lockid is associated with the clear
> resource? After all, all lockid information will be lost after rebooting
> libvirtd in generally.
It is valid for the lock manager plugin to create its own state files on
disk to record this information across restarts if desired. No need to pass
the info to virtlockd in this case.
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
More information about the libvir-list