[libvirt] RFC [3/3]: Lock manager usage scenarios

[David Teigland]

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