10:36 a.m.
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! ;-)
8:35 a.m.
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(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
8:55 a.m.
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 :|
11:43 a.m.
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
5736
days inactive
5737
days old
3 comments
4 participants
participants (4)
-
Daniel P. Berrange -
Daniel Veillard -
Laine Stump -
Laine Stump