libvirt/docs/kbase/internals/overview.rst

libvirt API call overview

The following diagram depicts code flow from a client application, in this case the libvirt provided virsh command through the various layers to elicit a response from some chosen hypervisor.

Note: Some aspects of this document may be outdated.

• virsh -c qemu:///system list --all

  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).

• virConnectOpenAuth()

  Each of the virConnectOpen APIs will first call virInitialize() and then revector through the local "do_open()" call.

  • virInitialize()

    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.

  • Loop through virDriverTab[] entries trying to call their respective "open" entry point (in our case remoteOpen())

  • After successful return from the virDriverTab[] open() API, attempt to find and open other drivers (network, interface, storage, etc.)

• remoteOpen()

  After a couple of URI checks, a call to doRemoteOpen() is made

  • Determine network transport and host/port to use from URI

    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.

  • virNetClientRegisterAsyncIO()

    Register an I/O callback mechanism to get returned data via virNetClientIncomingEvent()

  • call(...REMOTE_PROC_OPEN...)

    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()

  • virNetClientIncomingEvent()

    Receives the returned packet and processes through virNetClientIOUpdateCallback()

• libvirtd Daemon

  • Daemon Startup

    The daemon initialization processing will declare itself as a daemon via a virNetDaemonNew() call, then creates new server using virNetServerNew() and adds that server to the main daemon struct with virNetDaemonAddServer() call. It will then use virDriverLoadModule() to find/load all known drivers, set up an RPC server program using the remoteProcs[] table via a virNetServerProgramNew() call. The table is the corollary to the remote_procedure 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 virStateDriverTab[], the network links are enabled, and the daemon waits for work.

  • RPC

    When a message is received, the remoteProcs[] table is referenced for the REMOTE_PROC_OPEN call entry. This results in remoteDispatchOpen() being called via the virNetServerProgramDispatchCall().

  • remoteDispatchOpen()

    The API will read the argument passed picking out the name of the driver to be opened. The code will then call virConnectOpen() or virConnectOpenReadOnly() depending on the argument flags.

  • virConnectOpen() or virConnectOpenReadOnly()

    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.

    The returned structure data is returned via the virNetServer interfaces to the remote driver which then returns it to the client application.