Daniel P. Berrange wrote:
On Tue, Jan 16, 2007 at 07:09:30PM +0000, Daniel P. Berrange wrote:
On Tue, Jan 16, 2007 at 05:21:15PM +0000, Mark McLoughlin wrote:
- Or perhaps, libvirt would *always* talk to a daemon ... whether
local or remote. That way you don't have the race condition where
multiple apps can create a guest of the same name or uuid at once.
Possibly :-) I think I'll draw another diagram...
One way is to move the entire driver model out of libvirt and into a daemon,
so that libvirt itself is just a very thin layer which marshalls APIs calls
onto the wire. So whether local or remote the diagram looks the same:
http://people.redhat.com/berrange/libvirt/libvirt-arch-local-1.png
http://people.redhat.com/berrange/libvirt/libvirt-arch-remote-3.png
This adds an extra daemon in the simplest case (everything running on
one machine), so it makes that case harder to manage than it needs to be.
The extra daemon might be required to manage all VM instances or perhaps
ensure serialisation of requests when there are multiple libvirts, but
is that really a requirement? With upstream patches it should be
possible for an independent libvirt to enumerate both Xen & QEMU instances.
Rich.
--
Red Hat UK Ltd.
64 Baker Street, London, W1U 7DF
Mobile: +44 7866 314 421 (will change soon)
