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 :|