[libvirt] questions about libvirtd and virsh
hello, everyone I am now reading the souce code of libvirtd and virsh, and got some questions: 1. Is libvirtd necessary when I use some tools(based on libvirt) to control domains? 2. It seems that virsh use remote driver to comunicate to libvirtd (the hypervisor is qemu), why doesn't it call libvirt directly? 3. In the souce code, there is "server" and "client" functions, so what is a "client", and what is a "server"? 4. libvirtd has 7 threads, what are these threads doing? thanks fengzihuachuan 2011-02-25 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
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.
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. Sincerely Philipp -- Philipp Hahn Open Source Software Engineer hahn@univention.de Univention GmbH Linux for Your Business fon: +49 421 22 232- 0 Mary-Somerville-Str.1 28359 Bremen fax: +49 421 22 232-99 http://www.univention.de/ ** Besuchen Sie uns auf der CeBIT in Hannover ** ** Auf dem Univention Stand D36 in Halle 2 ** ** Vom 01. bis 05. März 2011 **
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 :|
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@redhat.com>:
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@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
participants (4)
-
Daniel P. Berrange -
Desmond He -
fengzi.gg
-
Philipp Hahn