Re: [libvirt] Looking for good example API function(s)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]