On 08/14/2012 01:18 AM, He Xin wrote: src/libvirt.c contains the public API. This API then calls a callback from src/driver.h according to the URI. If you connected to test:///default, those callbacks live in src/test/test_driver.c. If you connected to qemu:///system or qemu:///session, then the first round of those callbacks live in src/remote/remote_driver.c (to package the request into an RPC call), which is then received by daemon/remote.c (which unbundles the RPC call back into a public call to libvirt.c), and then from the libvirtd process calls into src/qemu/qemu_driver.c. Once you are in src/qemu/qemu_driver.c, most actions are either persistent (altering state in the domain definition structure, using functions from src/conf/domain_conf.c) or active (making monitor calls over a UNIX socket to the running qemu process). If you are asking how monitor calls are made, then look into src/qemu/qemu_monitor.c which then forwards to a text monitor (HMP - human monitor protocol, in qemu <= 0.14, qemu_monitor_text.c) or the JSON monitor (QMP - qemu monitor protocol using structured JSON queries, in qemu >= 0.15, qemu_monitor_json.c). There's also the task of initially starting up the qemu process to have an attached monitor, see qemu_capabilities.c to see how libvirt learns what qemu supports, and qemu_command.c to see how libvirt constructs the command line arguments for starting qemu. You seem to be asking a lot of questions, but not actually using gdb to step through the whole process. Try it - it's rather enlightening to actually trace a call through the stack yourself, instead of asking someone else to explain it all. Note that you have to debug the libvirtd process, rather than your application linked to libvirt.so, thanks to the RPC boundary where your API calls are translated to an RPC message to be passed between processes to reach libvirtd. -- Eric Blake eblake(a)redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org