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
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
--
|: Red Hat, Engineering, London -o-
http://people.redhat.com/berrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org -o-
http://deltacloud.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|