[Libvir] PATCH 0/3: Refactor QEMU daemon

[Daniel P. Berrange]

On Mon, Jun 18, 2007 at 02:25:36PM +0100, Richard W.M. Jones wrote:
> Daniel P. Berrange wrote:
> >On Mon, Jun 18, 2007 at 05:32:45AM -0400, Daniel Veillard wrote:
> >>On Sun, Jun 17, 2007 at 10:48:17PM +0100, Daniel P. Berrange wrote:
> >>>The 3 patches which follow are work-in-progress to re-factor the QEMU
> >>>daemon / driver to eventually adhere to the main libvirt internal driver
> >>>API. Once this work is complete, there will only need to be a single
> >>>daemon running which can provide both remote & QEMU capabilities at once
> >>>with no QEMU specific code in it.
> >> Just to clarify, we will still need one process to be forked per QEmu
> >>instance which is under control, right ?
> >
> >
> >Yes to be clear. This is changing from a model where we have processes:
> >
> >   libvirtd
> >   libvirt_qemud
> >      |
> >      +- qemu
> >      +- qemu
> >      +- dnsmasq
> >
> >To merge the two daemons so we have
> >
> >   libvirtd
> >      |
> >      +- qemu
> >      +- qemu
> >      +- dnsmasq
> >
> >The single daemon serves as both the remote daemon & QEMU daemon all in
> >one, with no need for QEMU specific code.
> 
> I'm still looking at your first (and most complicated patch), so the 
> answer may well be in there, but just to check anyway: does this solve 
> the deadlock where we try to do qemu-over-remote?

Not yet, because at this point we've still got two daemons. Once the patch
set is complete, moving the QEMU stuff into libvirt.so with the real driver
API, then there will only be one daemon & thus we should not have any
deadlock issue.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|