Re: [libvirt] RFC [0/3]: A proposal for lock manager plugins
Sorry for commenting so late but it was Rosh Hashana over here.
Just to give you some pointers, sync_manager should also be zero config.
host id, timeouts etc are not in a config.
Host Id is decided when sync_manager starts, and timeouts are decided
upon lease creation so that all the sync_managers in the cluster are
synchronized.
Also when thinking about migration we have to think about the situation
where the source host in the migration can't see the storage thus can't
update the lease.
The solution we currently have in mind is using the leader version to
make sure no one took the lease while the handover was happening.
This will mean giving sync_manager an optional parameter (forceLVer?).
This will all be managed by vdsm\rhev-m. You just have to think that
there might be something other then leases location. Maybe just add a
generic addArg param. Or if you think all locking mechanisms should have
this feature, make it a part of the API.
On Fri, 2010-09-10 at 16:49 +0100, Daniel P. Berrange wrote:
A few weeks back David introduce sync-manager as a means for
protecting
against the same VM being started on multiple hosts:
https://www.redhat.com/archives/libvir-list/2010-August/msg00179.html
This is obviously a desirable feature for libvirt, but we don't want to
have a hardcoded dependancy on a particular implementation. We can
achieve isolation between libvirt & sync-manager, allowing for alternative
implementations by specifying a formal plugin for supervisor processes.
What follows is my mockup of what a plugin API would look like, its
internal libvirt API and an outline of the usage scenarios in psuedo
code.
At the minimum level of compliance, the plugin implementation provides
for per-VM level exclusion. Optionally a plugin can declare that it
- supports locks against individual resources (disks)
- supports hotplug of individual resources
- supports migration of the supervised process even
Migration/hotplug will be forbid if those capabilities aren't declared
by the plugin.
In parallel with David's work on sync-manager, I intend to write a simple
plugin implementation based solely on fcntl() locking. It is important
that we have 2 independant implementations to prove the validity of the
plugin API. The fcntl() impl should provide a zero-config impl we can
deploy out of the box that will provide protection against 2 vms using
the same disk image on a host, and limited protection in multi-host
scenarios with shared filesystems (no protection for shared block devs).
Perhaps we should have a 3rd impl based on libdlm too, for Red Hat
ClusterSuite scenarios, though sync-manager may well be general &
simple enough to easily cope with this already.
Daniel