On Tue, Mar 10, 2009 at 11:36:01AM -0400, Laine Stump wrote:
> To help with lutter's network configuration project, I'm looking at
> adding API functions to libvirt which are essentially pass-throughs to
> netcf library APIs called by libvirtd. Can someone point me to good
> examples of APIs that are not hypervisor driver-dependent (and possibly
> not host OS-dependent either - I believe the final intent is for netcf
> to handle all host OS dependencies itself) to use as a basis for writing
> these new APIs?
>
> At a more detailed level, a quick trace through the code of some other
> APIs got me as far as the call to the "call" function, with an RPC code,
> but I didn't find where that call was caught (and the RPC code
> interpreted, eg REMOTE_PROC_NETWORK_CREATE_XML - cscope couldn't find
> any other reference to this value) on the libvirtd side. I'm about run
> virsh and libvirtd under gdb to learn this by experimentation, but if
> someone wants to take the fun out of it for me, hints would be gladly
> accepted! ;-)
- Application connects to libvirt (virConnectOpen()
- in src/libvirt.c we activate a hypervisor driver based on the
URI given. If successful, we then try to activate a number of
secondary drivers (eg virtual network, storage, node device)
- in src/libvirt.c, virConenctPtr is populted with callbacks for
each of the activated drivers
Now....
- Application calls virNetworkCreateXML()
- in src/libvirt.c, this runs virNetworkCreateXML code
- this uses the networkDriver callback sets, invoking
the networkCreateXML() callback, eg
conn->networkDriver->networkCreateXML()
For something like the network driver, in the application process
the driver that's activated will be the generic remote driver.
- So, networkCreateXML() is pointing to remoteNetworkCreateXML()
in src/remote_driver.c
- remoteNetworkCreateXML() now serializes the parameters into
XDR format, and makes an RPC call REMOTE_PROC_NETWORK_CREATE_XML
The RPC calls are handling by the libvirtd daemon.
- libvirtd gets REMOTE_PROC_NETWORK_CREATE_XML and dispatches
it to remoteDispatchNetworkCreateXML() in qemud/remote.c
- libvirtd itself uses libvirt.so, so it once against calls
into the public API virNetworkCreateXML() as the application
did much earlier.
- in src/libvirt.c, this runs virNetworkCreateXML code
- this uses the networkDriver callback sets, invoking
the networkCreateXML() callback, eg
conn->networkDriver->networkCreateXML()
When run inside libvirtd though, libvirt.so does not activate
the 'remote' driver. Instead it activates the real driver,
in this case provided by src/network_driver.c
- So, networkCreateXML() is pointing to networkCreate()
in src/network_driver.c
- networkCreate() finally does whatever interesting stuff
needs to be done to complete the operation.
Summarizing
app -> libvirt.so -> remote driver -> XDR ->...
... TCP socket ...
... XDR -> libvirtd -> libvirt.so -> network driver
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list