[libvirt] how libvirt communicate with qemu?

[Eric Blake]

On 10/21/2012 03:42 AM, yue wrote:
> i am reading source code, begin with tracing simple command line ,like virsh list and forth.
> please look at my qurestions
> 1.how libvirt communicate with qemu?
> call qemu'lib or open special device/socket?
>  

Socket.  Basically, libvirt pre-creates a Unix socket and hooks that up
to the qemu -monitor command line argument, and then sends monitor
commands over this socket when libvirt needs to tell qemu to do anything.

> 2. i do not find the implement of function qemuAgentOpen---->qemuAgentInitialize().

src/qemu/qemu_agent.[ch]

> i also search qemu-kvm source

qemu is not a library - searching qemu-kvm source won't find you any of
the functions used in libvirt.  Rather, all libvirt<->qemu communication
is done over sockets.

>  
> 3. qemuListAllDomains  is the function which corespond to virsh-list.   please explain this function .
>  virDomainList(conn, driver->domains.objs, domains, flags);
>  i) it seems driver->domains.objs  have gotten all dmains.   so when and where   driver->domains.objs   is  assigned.
> ii)and what is conn,and its definition?

src/libvirt.c has a list of all public libvirt API.  src/driver.h has a
callback structure for all driver implementations.
src/qemu/qemu_driver.c installs qemuListAllDomains as the callback for
the public function virConnectListAllDomains.  conn is therefore the
virConnectPtr you get when you open a connection to your specified URI
(such as qemu:///system), and that conn pointer has enough information
to point to the callback, so that virConnectListAllDomains then forwards
into the qemuListAllDomains() function.

You also need to understand the architecture of remote calls - remember,
when virsh (or any other client) connects to qemu:///system, the local
instance of virConnectListAllDomains() happens to call into the RPC
driver rather than the qemu driver; that is, the local call is handled
by src/remote/remote_driver.c which bundles the API call into an RPC
packet.  Then, in the libvirtd process, daemon/remote.c unbundles the
RPC packet, and turns it back into an API call, but this time with the
qemu driver instead of the RPC driver.  So understanding the full path
of a message requires debugging multiple processes.

-- 
Eric Blake   eblake at redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 617 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20121022/cf02fc9b/attachment-0001.sig>