Re: [libvirt] RFC [3/3]: Lock manager usage scenarios
On Mon, Sep 13, 2010 at 02:29:49PM +0100, Daniel P. Berrange wrote:
> > 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.
I think there are two valid approaches people may want to take, both of
which seem compatible with the requirements you describe.
First, per the RFC (and current sync_manager design):
Method 1: libvirt forks a supervisor process which:
1. acquires lock
2. forks qemu
3. waits for qemu exit
4. releases lock
Method 2: without a supervisor process, libvirt:
1. calls plugin acquire_lock()
2. forks qemu
3. waits for qemu exit
4. calls plugin release_lock()
(I should add 2.b. calls plugin set_pid() to tell lock manager the qemu pid.)
In method 2, I expect the plugin functions would generally send ipc to a
local lock manager daemon that holds and manages locks. (And may also
wish to monitor the qemu pid itself.)
Dave