Module libvirt-host from libvirt

The operating system group name as VIR_TYPED_PARAM_STRING.

The operating system process ID as VIR_TYPED_PARAM_LLONG.

The operating system process start time as VIR_TYPED_PARAM_ULLONG. The units the time is measured in vary according to the host operating system. On Linux this is usually clock ticks (as reported in /proc/$PID/stat field 22).

The SASL authenticated username as VIR_TYPED_PARAM_STRING

The application's SELinux context as VIR_TYPED_PARAM_STRING.

The UNIX group ID as VIR_TYPED_PARAM_ULLONG.

The UNIX user ID as VIR_TYPED_PARAM_ULLONG.

The operating system user name as VIR_TYPED_PARAM_STRING.

The TLS x509 certificate distinguished named as VIR_TYPED_PARAM_STRING

This macro is to calculate the total number of CPUs supported but not necessary active in the host.

Macro providing the field length of virNodeCPUStats

The cumulative idle CPU time, since the node booting up (in nanoseconds).

The cumulative interrupt CPU time, since the node booting up (in nanoseconds).

The cumulative I/O wait CPU time, since the node booting up (in nanoseconds).

Macro for the cumulative CPU time which was spent by the kernel, since the node booting up (in nanoseconds).

The cumulative CPU time which was spent by user processes, since the node booting up (in nanoseconds).

The CPU utilization of a node. The usage value is in percent and 100% represents all CPUs of the node.

Macro for typed parameter that represents how many times all mergeable areas have been scanned.

Macro for typed parameter that represents whether pages from different NUMA nodes can be merged. The parameter has type int, when its value is 0, only pages which physically reside in the memory area of same NUMA node are merged; When its value is 1, pages from all nodes can be merged. Other values are reserved for future use.

Macro for typed parameter that represents how many the shared memory pages are being used.

Macro for typed parameter that represents how many sites are sharing the pages i.e. how much saved.

Macro for typed parameter that represents how many present pages to scan before the shared memory service goes to sleep.

Macro for typed parameter that represents how many pages unique but repeatedly checked for merging.

Macro for typed parameter that represents how many pages changing too fast to be placed in a tree.

Macro for typed parameter that represents how many milliseconds the shared memory service should sleep before next scan.

Macro for the buffer memory: On Linux, it is only returned in case of VIR_NODE_MEMORY_STATS_ALL_CELLS.

Macro for the cached memory: On Linux, it is only returned in case of VIR_NODE_MEMORY_STATS_ALL_CELLS.

Macro providing the field length of virNodeMemoryStats

Macro for the free memory of specified cell: On Linux, it includes buffer and cached memory, in case of VIR_NODE_MEMORY_STATS_ALL_CELLS.

Macro for the total memory of specified cell: it represents the maximum memory.

Macro represents the CBit Position used by hypervisor when SEV is enabled.

Macro represents the platform certificate chain that includes the platform endorsement key (PEK), owner certificate authority (OCD) and chip endorsement key (CEK), as VIR_TYPED_PARAMS_STRING.

Macro represents the unique ID of CPU0 (socket 0) needed to retrieve the signed CEK of the CPU from AMD's Key Distribution Service (KDS), as VIR_TYPED_PARAMS_STRING.

Macro represents the number of SEV-ES guests that can be run on the host, as a VIR_TYPED_PARAM_UINT.

Macro represents the number of SEV guests that can be run on the host, as a VIR_TYPED_PARAM_UINT.

Macro represents the Platform Diffie-Hellman key, as VIR_TYPED_PARAMS_STRING.

Macro represents the number of bits we lose in physical address space when SEV is enabled in the guest.

Macro providing the maximum length of the virSecurityModel doi string.

Macro providing the maximum length of the virSecurityLabel label string. Note that this value is based on that used by Labeled NFS.

Macro providing the maximum length of the virSecurityModel model string.

This macro provides the length of the buffer required for virDomainGetUUID()

This macro provides the length of the buffer required for virDomainGetUUIDString()

Flags when getting XML description of a computed CPU

Flags when opening a connection to a hypervisor

a virConnectPtr is pointer to a virConnect private structure, this is the type used to reference a connection to the Hypervisor in the API.

a virNodeCPUStatsPtr is a pointer to a virNodeCPUStats structure.

Value for specifying request for the total CPU time/utilization

Value for specifying request for the total memory of all cells.

a virNodeInfoPtr is a pointer to a virNodeInfo structure.

a virNodeMemoryStatsPtr is a pointer to a virNodeMemoryStats structure.

Flags to indicate which system-wide sleep state the host must be transitioned to.

a virSecurityLabelPtr is a pointer to a virSecurityLabel.

a virSecurityModelPtr is a pointer to a virSecurityModel.

a virStreamPtr is pointer to a virStream private structure, this is the type used to reference a data stream in the API.

When authentication requires one or more interactions, this callback is invoked. For each interaction supplied, data must be gathered from the user and filled in to the 'result' and 'resultlen' fields. If an interaction cannot be filled, fill in NULL and 0.

Computes the most feature-rich CPU which is compatible with all given host CPUs.

See virConnectBaselineHypervisorCPU() to get a CPU which can be provided by the hypervisor.

If flags includes VIR_CONNECT_BASELINE_CPU_EXPAND_FEATURES then libvirt will explicitly list all CPU features that are part of the host CPU, without this flag features that are part of the CPU model will not be listed.

If flags includes VIR_CONNECT_BASELINE_CPU_MIGRATABLE, the resulting CPU will not include features that block migration.

Computes the most feature-rich CPU which is compatible with all given CPUs and can be provided by the specified hypervisor. For best results the host-model CPUs as advertised by virConnectGetDomainCapabilities() should be passed in xmlCPUs. Any of emulator, arch, machine, and virttype parameters may be NULL; libvirt will choose sensible defaults tailored to the host and its current configuration.

This is different from virConnectBaselineCPU() which doesn't consider any hypervisor abilities when computing the best CPU.

If ncpus == 1, the result will be the first (and only) CPU in xmlCPUs tailored to what the hypervisor can support on the current host. Specifically if this single CPU definition contains no feature elements and a CPU model listed as usable='no' in domain capabilities XML, the result will contain a list usability blockers, i.e., a list of features that would need to be disabled to for the model to be usable on this host. This list may contain more features than what the hypervisor reports as blockers in case the CPU model definition in libvirt differs from QEMU definition.

If flags includes VIR_CONNECT_BASELINE_CPU_EXPAND_FEATURES then libvirt will explicitly list all CPU features that are part of the computed CPU, without this flag features that are part of the CPU model will not be listed.

If flags includes VIR_CONNECT_BASELINE_CPU_MIGRATABLE, the resulting CPU will not include features that block migration.

This function closes the connection to the Hypervisor. This should not be called if further interaction with the Hypervisor are needed especially if there is running domain which need further monitoring by the application.

Connections are reference counted; the count is explicitly increased by the initial open (virConnectOpen, virConnectOpenAuth, and the like) as well as virConnectRef; it is also temporarily increased by other API that depend on the connection remaining alive. The open and every virConnectRef call should have a matching virConnectClose, and all other references will be released after the corresponding operation completes.

A callback function to be registered, and called when the connection is closed.

Compares the given CPU description with the host CPU.

See virConnectCompareHypervisorCPU() if you want to consider hypervisor abilities and compare the CPU to the CPU which a hypervisor is able to provide on the host.

Compares the given CPU description with the CPU the specified hypervisor is able to provide on the host. Any of emulator, arch, machine, and virttype parameters may be NULL; libvirt will choose sensible defaults tailored to the host and its current configuration.

This is different from virConnectCompareCPU() which compares the CPU definition with the host CPU without considering any specific hypervisor and its abilities.

Get the list of CPU models supported by libvirt for a specific architecture.

The returned list limits CPU models usable with libvirt (empty list means there's no limit imposed by libvirt) and it does not reflect capabilities of any particular hypervisor. See the XML returned by virConnectGetDomainCapabilities() for a list of CPU models supported by libvirt for domains created on a specific hypervisor.

Provides capabilities of the hypervisor / driver.

This returns a system hostname on which the hypervisor is running (based on the result of the gethostname system call, but possibly expanded to a fully-qualified domain name via getaddrinfo). If we are connected to a remote system, then this returns the hostname of the remote system.

Provides libVer, which is the version of libvirt used by the daemon running on the conn host

Provides the maximum number of virtual CPUs supported for a guest VM of a specific type. The 'type' parameter here corresponds to the 'type' attribute in the <domain> element of the XML. This API doesn't take emulator limits into consideration, hence the returned value is not guaranteed to be usable. It is recommended to use virConnectGetDomainCapabilities() and look for "<vcpu max='...'>" in its output instead.

This returns the XML description of the sysinfo details for the host on which the hypervisor is running, in the same format as the <sysinfo> element of a domain XML. This information is generally available only for hypervisors running with root privileges.

Get the name of the Hypervisor driver used. This is merely the driver name; for example, both KVM and QEMU guests are serviced by the driver for the qemu:// URI, so a return of "QEMU" does not indicate whether KVM acceleration is present. For more details about the hypervisor, use virConnectGetCapabilities().

This returns the URI (name) of the hypervisor connection. Normally this is the same as or similar to the string passed to the virConnectOpen/virConnectOpenReadOnly call, but the driver may make the URI canonical. If name == NULL was passed to virConnectOpen, then the driver will return a non-NULL URI which can be used to connect to the same hypervisor later.

Get the version level of the Hypervisor running.

Determine if the connection to the hypervisor is still alive

A connection will be classed as alive if it is either local, or running over a channel (TCP or UNIX socket) which is not closed.

Determine if the connection to the hypervisor is encrypted

Determine if the connection to the hypervisor is secure

A connection will be classed as secure if it is either encrypted, or running over a channel which is not exposed to eavesdropping (eg a UNIX domain socket, or pipe)

This function should be called first to get a connection to the Hypervisor and xen store

If name is NULL, if the LIBVIRT_DEFAULT_URI environment variable is set, then it will be used. Otherwise if the client configuration file has the "uri_default" parameter set, then it will be used. Finally probing will be done to determine a suitable default driver to activate. This involves trying each hypervisor in turn until one successfully opens.

If connecting to an unprivileged hypervisor driver which requires the libvirtd daemon to be active, it will automatically be launched if not already running. This can be prevented by setting the environment variable LIBVIRT_AUTOSTART=0

URIs are documented at https://libvirt.org/uri.html

virConnectClose should be used to release the resources after the connection is no longer needed.

This function should be called first to get a connection to the Hypervisor. If necessary, authentication will be performed fetching credentials via the callback

See virConnectOpen for notes about environment variables which can have an effect on opening drivers and freeing the connection resources

URIs are documented at https://libvirt.org/uri.html

This function should be called first to get a restricted connection to the library functionalities. The set of APIs usable are then restricted on the available methods to control the domains.

See virConnectOpen for notes about environment variables which can have an effect on opening drivers and freeing the connection resources

URIs are documented at https://libvirt.org/uri.html

Increment the reference count on the connection. For each additional call to this method, there shall be a corresponding call to virConnectClose to release the reference count, once the caller no longer needs the reference to this object.

This method is typically useful for applications where multiple threads are using a connection, and it is required that the connection remain open until all threads have finished using it. ie, each new thread using a connection would increment the reference count.

Registers a callback to be invoked when the connection is closed. This callback is invoked when there is any condition that causes the socket connection to the hypervisor to be closed.

This function is only applicable to hypervisor drivers which maintain a persistent open connection. Drivers which open a new connection for every operation will not invoke this.

The freecb must not invoke any other libvirt public APIs, since it is not called from a re-entrant safe context.

Override the default identity information associated with the connection. When connecting to a stateful driver over a UNIX socket, the daemon will interrogate the remote end of the UNIX socket to acquire the application's identity. This identity is used for the fine grained access control checks on API calls.

There may be times when application is operating on behalf of a variety of users, and thus the identity that the application runs as is not appropriate for access control checks. In this case, if the application is considered trustworthy, it can supply alternative identity information.

The driver may reject the request to change the identity on a connection if the application is not trustworthy.

Start sending keepalive messages after interval seconds of inactivity and consider the connection to be broken when no response is received after count keepalive messages sent in a row. In other words, sending count + 1 keepalive message results in closing the connection. When interval is <= 0, no keepalive messages will be sent. When count is 0, the connection will be automatically closed after interval seconds of inactivity without sending any keepalive messages.

Note: The client has to implement and run an event loop with virEventRegisterImpl() or virEventRegisterDefaultImpl() to be able to use keepalive messages. Failure to do so may result in connections being closed unexpectedly.

Note: This API function controls only keepalive messages sent by the client. If the server is configured to use keepalive you still need to run the event loop to respond to them, even if you disable keepalives by this function.

Unregisters the callback previously set with the virConnectRegisterCloseCallback method. The callback will no longer receive notifications when the connection closes. If a virFreeCallback was provided at time of registration, it will be invoked

Provides version information. libVer is the version of the library and will always be set unless an error occurs, in which case an error code will be returned. typeVer exists for historical compatibility; if it is not NULL it will duplicate libVer (it was originally intended to return hypervisor information based on type, but due to the design of remote clients this is not reliable). To get the version of the running hypervisor use the virConnectGetVersion() function instead. To get the libvirt library version used by a connection use the virConnectGetLibVersion() instead.

This function includes a call to virInitialize() when necessary.

Initialize the library.

This method is invoked automatically by any of the virConnectOpen() API calls, and by virGetVersion(). Since release 1.0.0, there is no need to call this method even in a multithreaded application, since initialization is performed in a thread safe manner; but applications using an older version of the library should manually call this before setting up competing threads that attempt virConnectOpen in parallel.

The only other time it would be necessary to call virInitialize is if the application did not invoke virConnectOpen as its first API call, such as when calling virEventRegisterImpl() before setting up connections, or when using virSetErrorFunc() to alter error reporting of the first connection attempt.

Sometimes, when trying to start a new domain, it may be necessary to reserve some huge pages in the system pool which can be then allocated by the domain. This API serves that purpose. On its input, pageSizes and pageCounts are arrays of the same cardinality of npages. The pageSizes contains page sizes which are to be allocated in the system (the size unit is kibibytes), and pageCounts then contains the number of pages to reserve. If flags is 0 (VIR_NODE_ALLOC_PAGES_ADD), each pool corresponding to pageSizes grows by the number of pages specified in the corresponding pageCounts. If flags contains VIR_NODE_ALLOC_PAGES_SET, each pool mentioned is resized to the given number of pages. The pages pool can be allocated over several NUMA nodes at once, just point at startCell and tell how many subsequent NUMA nodes should be taken in. As a special case, if startCell is equal to negative one, then kernel is instructed to allocate the pages over all NUMA nodes proportionally.

Get CPU map of host node CPUs.

This function provides individual cpu statistics of the node. If you want to get total cpu statistics of the node, you must specify VIR_NODE_CPU_STATS_ALL_CPUS to cpuNum. The params array will be filled with the values equal to the number of parameters suggested by nparams

As the value of nparams is dynamic, call the API setting nparams to 0 and params as NULL, the API returns the number of parameters supported by the HV by updating nparams on SUCCESS. The caller should then allocate params array, i.e. (sizeof(sizeofvirNodeCPUStats * nparams) bytes and call the API again.

Here is a sample code snippet:

if (virNodeGetCPUStats(conn, cpuNum, NULL, &nparams, 0) == 0 &&
    nparams != 0) {
    if ((params = malloc(sizeof(virNodeCPUStats) * nparams)) == NULL)
        goto error;
    memset(params, 0, sizeof(virNodeCPUStats) * nparams);
    if (virNodeGetCPUStats(conn, cpuNum, params, &nparams, 0))
        goto error;
}

This function doesn't require privileged access to the hypervisor. This function expects the caller to allocate the params.

CPU time Statistics:

VIR_NODE_CPU_STATS_KERNEL: The cumulative CPU time which spends by kernel, when the node booting up.(nanoseconds) VIR_NODE_CPU_STATS_USER: The cumulative CPU time which spends by user processes, when the node booting up.(nanoseconds) VIR_NODE_CPU_STATS_IDLE: The cumulative idle CPU time, when the node booting up.(nanoseconds) VIR_NODE_CPU_STATS_IOWAIT: The cumulative I/O wait CPU time, when the node booting up.(nanoseconds) VIR_NODE_CPU_STATS_UTILIZATION: The CPU utilization. The usage value is in percent and 100% represents all CPUs on the server.

This call returns the amount of free memory in one or more NUMA cells. The freeMems array must be allocated by the caller and will be filled with the amount of free memory in bytes for each cell requested, starting with startCell (in freeMems[0]), up to either (startCell + maxCells), or the number of additional cells in the node, whichever is smaller.

provides the free memory available on the Node Note: most libvirt APIs provide memory sizes in kibibytes, but in this function the returned value is in bytes. Divide by 1024 as necessary.

This calls queries the host system on free pages of specified size. For the input, pages is expected to be filled with pages that caller is interested in (the size unit is kibibytes, so e.g. pass 2048 for 2MB), then startcell refers to the first NUMA node that info should be collected from, and cellcount tells how many consecutive nodes should be queried. On the function output, counts is filled with desired information, where items are grouped by NUMA node. So from counts[0] till counts[npagess - 1] you'll find count for the first node (startcell), then from counts[npages]] till count[2 * npages - 1] you'll find info for the (startcell + 1) node, and so on. It's callers responsibility to allocate the counts array.

Example how to use this API:

unsigned int pages[] = { 4, 2048, 1048576}
unsigned int npages = G_N_ELEMENTS(pages);
int startcell = 0;
unsigned int cellcount = 2;

unsigned long long counts = malloc(sizeof(long long) * npages * cellcount);

virNodeGetFreePages(conn, pages, npages,
                    startcell, cellcount, counts, 0);

for (i = 0 ; i < cellcount ; i++) {
    fprintf(stdout, "Cell %d\n", startcell + i);
    for (j = 0 ; j < npages ; j++) {
       fprintf(stdout, "  Page size=%d count=%d bytes=%llu\n",
               pages[j], counts[(i * npages) +  j],
               pages[j] * counts[(i * npages) +  j]);
    }
}

This little code snippet will produce something like this:
Cell 0
 Page size=4096 count=300 bytes=1228800
 Page size=2097152 count=0 bytes=0
 Page size=1073741824 count=1 bytes=1073741824
Cell 1
 Page size=4096 count=0 bytes=0
 Page size=2097152 count=20 bytes=41943040
 Page size=1073741824 count=0 bytes=0

Extract hardware information about the node.

Use of this API is strongly discouraged as the information provided is not guaranteed to be accurate on all hardware platforms.

The mHZ value merely reflects the speed that the first CPU in the machine is currently running at. This speed may vary across CPUs and changes continually as the host OS throttles.

The nodes/sockets/cores/threads data is potentially inaccurate as it assumes a symmetric installation. If one NUMA node has more sockets populated that another NUMA node this information will be wrong. It is also not able to report about CPU dies.

Applications are recommended to use the virConnectGetCapabilities() call instead, which provides all the information except CPU mHZ, in a more accurate representation.

Get all node memory parameters (parameters unsupported by OS will be omitted). On input, nparams gives the size of the params array; on output, nparams gives how many slots were filled with parameter information, which might be less but will not exceed the input value.

As a special case, calling with params as NULL and nparams as 0 on input will cause nparams on output to contain the number of parameters supported by the hypervisor. The caller should then allocate params array, i.e. (sizeof(sizeofvirTypedParameter * nparams) bytes and call the API again. See virDomainGetMemoryParameters() for an equivalent usage example.

This function provides memory stats of the node. If you want to get total memory statistics of the node, you must specify VIR_NODE_MEMORY_STATS_ALL_CELLS to cellNum. The params array will be filled with the values equal to the number of stats suggested by nparams

As the value of nparams is dynamic, call the API setting nparams to 0 and params as NULL, the API returns the number of parameters supported by the HV by updating nparams on SUCCESS. The caller should then allocate params array, i.e. (sizeof(sizeofvirNodeMemoryStats * nparams) bytes and call the API again.

Here is the sample code snippet:

if (virNodeGetMemoryStats(conn, cellNum, NULL, &nparams, 0) == 0 &&
    nparams != 0) {
    if ((params = malloc(sizeof(virNodeMemoryStats) * nparams)) == NULL)
        goto error;
    memset(params, cellNum, 0, sizeof(virNodeMemoryStats) * nparams);
    if (virNodeGetMemoryStats(conn, params, &nparams, 0))
        goto error;
}

This function doesn't require privileged access to the hypervisor. This function expects the caller to allocate the params.

Memory Stats:

VIR_NODE_MEMORY_STATS_TOTAL: The total memory usage.(KB) VIR_NODE_MEMORY_STATS_FREE: The free memory usage.(KB) On linux, this usage includes buffers and cached. VIR_NODE_MEMORY_STATS_BUFFERS: The buffers memory usage.(KB) VIR_NODE_MEMORY_STATS_CACHED: The cached memory usage.(KB)

If hypervisor supports AMD's SEV feature, then params will contain various platform specific information like PDH and certificate chain. Caller is responsible for freeing params.

Extract the security model of a hypervisor. The 'model' field in the secmodel argument may be initialized to the empty string if the driver has not activated a security model.

Change all or a subset of the node memory tunables. The function fails if not all of the tunables are supported.

Note that it's not recommended to use this function while the outside tuning program is running (such as ksmtuned under Linux), as they could change the tunables in parallel, which could cause conflicts.

This function may require privileged access to the hypervisor.

Attempt to suspend the node (host machine) for the given duration of time in the specified state (Suspend-to-RAM, Suspend-to-Disk or Hybrid-Suspend). Schedule the node's Real-Time-Clock interrupt to resume the node after the duration is complete.