On Mon, Sep 13, 2010 at 03:20:13PM +0200, Saggi Mizrahi wrote:
On Mon, 2010-09-13 at 13:35 +0100, Daniel P. Berrange wrote:
> >
> > Overall, this looks workable to me. As proposed, this assumes a 1:1
> > relation between LockManager process and managed VMs. But I guess you
> > can still have a central manager process that manages all the VMs, by
> > having the lock manager plugin spawn a simple shim process that does all
> > the communication with the central lock manager.
>
> I could have decided it such that it didn't assume presence of a angel
> process around each VM, but I think it is easier to be able to presume
> that there is one. It can be an incredibly thin stub if desired, so I
> don't think it'll be too onerous on implementations
> We are looking into the possibility of not having a process manage a
VM but rather having the sync_manager process register with a central
daemon and exec into qemu (or anything else) so assuming there is a
process per VM is essentially false. But the verb could be used for
"unregistering" the current instance with the main manager so the verb
does have it use.
Further more, even if we decide to leave the current 'sync_manager
process per child process' system as is for now. The general direction
is a central deamon per host for managing all the leases and guarding
all processes. So be sure to keep that in mind while assembling the API.
Having a single daemon per host that exec's the VMs is explicitly *not*
something we intend to support because the QEMU process needs to inherit
its process execution state from libvirtd. It is fundamental to the
security architecture that processes are completely isolated the moment
that libvirtd has spawned them. We don't want to offload all the security
driver setup into a central lock manager daemon. Aside from this we also
pass open file descriptors down from libvirtd to the QEMU daemon.
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 :|