2009-06-09 11:42:41 +00:00
|
|
|
<html>
|
|
|
|
|
<body>
|
|
|
|
|
<h1>libvirt internals</h1>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
This section provides documents useful to those working on the libvirt
|
|
|
|
|
internals, adding new public APIs, new hypervisor drivers or extending
|
|
|
|
|
the libvirtd daemon code.
|
|
|
|
|
</p>
|
2010-05-25 13:14:46 +00:00
|
|
|
|
|
|
|
|
<ul>
|
2013-02-16 12:43:31 +00:00
|
|
|
<li>Introduction to basic rules and guidelines for
|
|
|
|
|
<a href="hacking.html">hacking</a> on libvirt code</li>
|
2011-04-01 22:02:10 +00:00
|
|
|
<li>Guide to adding <a href="api_extension.html">public APIs</a></li>
|
2013-02-16 12:43:31 +00:00
|
|
|
<li>Approach for <a href="internals/command.html">spawning commands</a>
|
|
|
|
|
from libvirt driver code</li>
|
|
|
|
|
<li>The libvirt <a href="internals/rpc.html">RPC infrastructure</a></li>
|
|
|
|
|
<li>The <a href="internals/locking.html">Resource Lock Manager</a></li>
|
2010-05-25 13:14:46 +00:00
|
|
|
</ul>
|
|
|
|
|
|
2013-02-16 12:43:31 +00:00
|
|
|
<p>Before adding new code it will be important to get a basic understanding
|
|
|
|
|
of the many elements involved with making any call or change to the libvirt
|
|
|
|
|
code. The architecture <a href="goals.html">goals</a> must be adhered to
|
|
|
|
|
when submitting new code. Understanding the many places that need to be
|
|
|
|
|
touched and the interactions between various subsystems within libvirt
|
|
|
|
|
will directly correlate to the ability to be successful in getting new
|
|
|
|
|
code accepted.</p>
|
|
|
|
|
<p>The following diagram depicts code flow from a client application, in
|
|
|
|
|
this case the libvirt provided <code>virsh</code> command through the
|
|
|
|
|
various layers to elicit a response from some chosen hypervisor.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<p class="image">
|
|
|
|
|
<img alt="virConnectOpen calling sequence"
|
|
|
|
|
src="libvirt-virConnect-example.png"/>
|
|
|
|
|
</p>
|
|
|
|
|
<ul>
|
|
|
|
|
<li>"virsh -c qemu:///system list --all"
|
|
|
|
|
<p>After the virsh code processes the input arguments, it eventually
|
|
|
|
|
will make a call to open the connection using a default set of
|
|
|
|
|
authentication credentials (virConnectAuthDefault). </p></li>
|
|
|
|
|
<li>virConnectOpenAuth()
|
|
|
|
|
<p>Each of the virConnectOpen APIs will first call virInitialize() and
|
|
|
|
|
then revector through the local "do_open():" call.</p>
|
|
|
|
|
<ul>
|
|
|
|
|
<li>virInitialize()
|
|
|
|
|
<p>Calls the registration API for each of the drivers with
|
|
|
|
|
client-side only capabilities and then call the remoteRegister()
|
|
|
|
|
API last. This ensures the virDriverTab[] tries local drivers
|
|
|
|
|
first before using the remote driver.</p></li>
|
|
|
|
|
<li>Loop through virDriverTab[] entries trying to call their
|
|
|
|
|
respective "open" entry point (in our case remoteOpen())</li>
|
|
|
|
|
<li>After successful return from the virDriverTab[] open()
|
|
|
|
|
API, attempt to find and open other drivers (network, interface,
|
|
|
|
|
storage, etc.)</li>
|
|
|
|
|
</ul>
|
|
|
|
|
</li>
|
|
|
|
|
<li>remoteOpen()
|
|
|
|
|
<p>After a couple of URI checks, a call to doRemoteOpen() is made</p>
|
|
|
|
|
<ul>
|
|
|
|
|
<li>Determine network transport and host/port to use from URI
|
|
|
|
|
<p>The transport will be either tls, unix, ssh, libssh2, ext,
|
|
|
|
|
or tcp with the default of tls. Decode the host/port if provided
|
|
|
|
|
or default to "localhost".</p></li>
|
|
|
|
|
<li>virNetClientRegisterAsyncIO()
|
|
|
|
|
<p>Register an I/O callback mechanism to get returned data via
|
|
|
|
|
virNetClientIncomingEvent()</p></li>
|
|
|
|
|
<li>"call(...REMOTE_PROC_OPEN...)"
|
|
|
|
|
<p>Eventually routes into virNetClientProgramCall() which will
|
|
|
|
|
call virNetClientSendWithReply() and eventually uses
|
|
|
|
|
virNetClientIO()to send the message to libvirtd and
|
|
|
|
|
then waits for a response using virNetClientIOEventLoop()</p></li>
|
|
|
|
|
<li>virNetClientIncomingEvent()
|
|
|
|
|
<p>Receives the returned packet and processes through
|
|
|
|
|
virNetClientIOUpdateCallback()</p></li>
|
|
|
|
|
</ul>
|
|
|
|
|
</li>
|
|
|
|
|
<li>libvirtd Daemon
|
|
|
|
|
<p></p>
|
|
|
|
|
<ul>
|
|
|
|
|
<li>Daemon Startup
|
|
|
|
|
<p>The daemon initialization processing will declare itself
|
|
|
|
|
as a server via a virNetServerNew() call, then use
|
|
|
|
|
virDriverLoadModule() to find/load all known drivers,
|
|
|
|
|
set up an RPC server program using the <code>remoteProcs[]</code>
|
|
|
|
|
table via a virNetServerProgramNew() call. The table is the
|
|
|
|
|
corollary to the <code>remote_procedure</code> enum list in
|
|
|
|
|
the client. It lists all the functions to be called in
|
|
|
|
|
the same order. Once RPC is set up, networking server sockets
|
|
|
|
|
are opened, the various driver state initialization routines
|
|
|
|
|
are run from the <code>virStateDriverTab[]</code>, the network
|
|
|
|
|
links are enabled, and the daemon waits for work.</p></li>
|
|
|
|
|
<li>RPC
|
|
|
|
|
<p>When a message is received, the <code>remoteProcs[]</code>
|
|
|
|
|
table is referenced for the 'REMOTE_PROC_OPEN' call entry.
|
|
|
|
|
This results in remoteDispatchOpen() being called via the
|
|
|
|
|
virNetServerProgramDispatchCall().</p></li>
|
|
|
|
|
<li>remoteDispatchOpen()
|
|
|
|
|
<p>The API will read the argument passed picking out the
|
|
|
|
|
<code>name</code> of the driver to be opened. The code
|
|
|
|
|
will then call virConnectOpen() or virConnectOpenReadOnly()
|
|
|
|
|
depending on the argument <code>flags</code>.</p></li>
|
|
|
|
|
<li>virConnectOpen() or virConnectOpenReadOnly()
|
|
|
|
|
<p>Just like the client except that upon entry the URI
|
|
|
|
|
is what was passed from the client and will be found
|
|
|
|
|
and opened to process the data.</p>
|
|
|
|
|
<p>The returned structure data is returned via the
|
|
|
|
|
virNetServer interfaces to the remote driver which then
|
|
|
|
|
returns it to the client application.</p></li>
|
|
|
|
|
</ul>
|
|
|
|
|
</li>
|
|
|
|
|
</ul>
|
2009-06-09 11:42:41 +00:00
|
|
|
</body>
|
|
|
|
|
</html>
|
