On Fri, Jun 29, 2012 at 03:07:54PM +0800, Dennis Chen wrote:
On 06/29/2012 02:49 PM, Daniel Veillard wrote:
[...]
> virsh talks to the libvirtd daemon, the libvirtd daemon run
those
>calls from the qemu driver. The documentation is relatively sparse,
>but reading what is available will help:
>
>
http://libvirt.org/api.html
>
http://libvirt.org/internals.html
>
>so if you want to step though that function you must gdb the libvirt
>daemon, not the client application.
>
>Daniel
en, this Daniel is not that Daniel: ) I remember that I joined the
presentation about
libvirt delivered by you in Nanjing University last year.
ah yes, there is Dan and Daniel that can be a bit confusing :-)
Yes, the document about libvirt is sparse, so I am often confused
when I try to
understand the internals of the relationship between QEMU, KVM and
libvirt...
ah, yes the overall stack is a bit complex.
Let me go through the link you mentioned to see if I can understand
libvirtd comes from
and the relationship with libvirt...
Basically for some driver the application talk to the libvirt daemon
to implement all the entry points of a driver (qemu/lxc for example),
it uses the remote driver to connect to the daemon, and the daemon calls
the real driver. Sometimes, the driver in the applcation does the work
by talking directly to the hypervisor (ESX/Hyper-V).
So if you want to debug/gdb the qemu code you must attach to libvirtd
daemon not to the application.
See slide 5 of the CLK slides ;-)
http://veillard.com/Talks/CLKLinux2011.pdf
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit
http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine
http://rpmfind.net/
http://veillard.com/ | virtualization library
http://libvirt.org/