[libvirt] RFC [0/3]: A proposal for lock manager plugins

[Saggi Mizrahi]

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