On Thu, Oct 16, 2008 at 10:02:10AM +0200, Guido G?nther wrote:
On Wed, Oct 15, 2008 at 09:59:12PM +0100, Daniel P. Berrange wrote:
> When you get to that level of cleverness, it seems to me that it is verging
> on a complete re-implementation of DLM (distributed lock manager), which
> really, AFAIK, needs a proper cluster setup so it can safely fence
> mis-behaving nodes, and avoid quorum/split-brain problems.
I've been toying with the idea of using DLM for libvirt earlier this
year [1](but infered from other postings on the list that this would be out
of scope for libvirt - probably should have asked). I looked at vm based
locks then but having storage based locks is even better.
Currently you have to make sure "manually" that people using i.e.
virt-manager[2] don't accidentally fire up VMs managed via e.g.
rgmanager.
Having cluster wide storage based locks would be an awesome solution.
If libvirt is deployed in an environment where DLM is present & configured
I've no objection to libvirt making use of it. It should just be a soft
dependancy, where we also need to make a best effort for cases where DLM
isn't around, even if that only works on a single host, or with a subset
of storage backends. Give users the flexibility in terms of how they
deploy & integrate libvirt, without imposing too many constraints.
Daniel
--
|: Red Hat, Engineering, London -o-
http://people.redhat.com/berrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org -o-
http://ovirt.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|