[libvirt] Looking for good example API function(s)
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! ;-)
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?
Well you can start to look at existng network interfaces like virNetworkCreateXML you can find the signatures in include/libvirt/libvirt.h[.in] and the real API entry point in src/libvirt.c Then everything is dispatched to some kind of drivers associated to the connection (depending how it was established).
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! ;-)
Well depending on how the client library is being used to connect to the host there is multiple variation but the implermentation will go though a driver, with either a local execution or a remote one, where the execution will be called from the daemon (in qemud). The fact that you ended up in a remote execution is probably normal if you were not root on the target box, and in many case still everything is centralized in the daemon. For the remote stubs they are of course generated which may explain why your index didn't include said funtions. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/
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 :|
On 03/11/2009 09:55 AM, Daniel P. Berrange wrote:
- 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
I had figured out everything up to here with no problems...
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
This is where I got stuck. As DV says, the dispatch table is generated, and doesn't reference the enum value directly (it's just implied via the index into the table). Also, the name of the remoteDispatchxxx function is generated, and the way that it's generated causes "XML" to be "Xml". Anyway, thanks to both of you for filling in the missing links. I think I understand how it works now!
- 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
participants (4)
-
Daniel P. Berrange -
Daniel Veillard -
Laine Stump -
Laine Stump