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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list