thanks a lot for your reply, Philipp and Daniel I think I almost figure it out. When libvirtd get control message(is it should called "a event"?) in event loop thread from virsh(for example), in the event loop thread it push the message to a message queue, then let worker threads to do the real thing, is this right? Event can be a remote message(just like a control message from virsh) or a local message from hypervisor or from node OS(domain0), is this right? Regards, fengzihuachuan 2011/2/25 Daniel P. Berrange <berrange@xxxxxxxxxx>: > On Fri, Feb 25, 2011 at 03:24:06PM +0100, Philipp Hahn wrote: >> Hello, >> >> Am Freitag 25 Februar 2011 14:33:31 schrieb fengzi.gg: >> > 1. Is libvirtd necessary when I use some tools(based on libvirt) >> > to control domains? >> >> Yes, libvirt ist designed to (almost) always require a running libvirtd. Even >> when using session Qemu domains, one daemon gets forked for the running user. > > The QEMU, UML, LXC, Xen drivers (and the storage, network, nwfilter > sub-drivers) all run within the context of libvirtd. > > The VirtualBox, ESX, Phyp, VMware, Test and XenAPI drivers don't > require libvirtd, though it is technically possible to access them > via libvirtd. > >> > 2. It seems that virsh use remote driver to comunicate to libvirtd (the >> > hypervisor is qemu), why doesn't it call libvirt directly? >> >> libvirtd often runs as root to keep the required privileges to configure the >> network, start domains, mount storage pools, etc. >> >> > 4. libvirtd has 7 threads, what are these threads doing? >> >> I thinks they wait for work to arrive: 1 is accepting new connections, 1 runs >> the event loop and 5 (configurable) wait for work to be pushed to the >> internal work queue. > > Yes, that is nearly correct. The initial process thread doesn't actually > do anything currently. Connections are accepted in the event loop thread. > In a future patch I'm working on, the initial process thread will become > the event loop thread once again. The QEMU driver may also sometimes > create threads, for handling core dumps from crashed guests. > > Regards, > Daniel > -- > |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| > |: http://libvirt.org -o- http://virt-manager.org :| > |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| > |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| > > -- > libvir-list mailing list > libvir-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/libvir-list > -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list