2015-04-15 14:16:24 +00:00
|
|
|
#
|
|
|
|
|
# Officially exported symbols, for which header
|
|
|
|
|
# file definitions are installed in /usr/include/libvirt
|
|
|
|
|
# from libvirt-admin.h
|
|
|
|
|
#
|
|
|
|
|
# Versions here are *fixed* to match the libvirt version
|
|
|
|
|
# at which the symbol was introduced. This ensures that
|
|
|
|
|
# a new client app requiring symbol foo() can't accidentally
|
|
|
|
|
# run with old libvirt-admin.so not providing foo() - the global
|
|
|
|
|
# soname version info can't enforce this since we never
|
|
|
|
|
# change the soname
|
|
|
|
|
#
|
2016-06-24 17:27:09 +00:00
|
|
|
LIBVIRT_ADMIN_2.0.0 {
|
2015-04-15 14:16:24 +00:00
|
|
|
global:
|
2016-06-29 14:12:58 +00:00
|
|
|
virAdmInitialize;
|
2016-04-13 08:35:26 +00:00
|
|
|
virAdmClientFree;
|
|
|
|
|
virAdmClientGetID;
|
|
|
|
|
virAdmClientGetTimestamp;
|
|
|
|
|
virAdmClientGetTransport;
|
2015-12-10 12:46:45 +00:00
|
|
|
virAdmConnectOpen;
|
|
|
|
|
virAdmConnectClose;
|
|
|
|
|
virAdmConnectRef;
|
2015-11-26 14:08:36 +00:00
|
|
|
virAdmGetVersion;
|
2015-12-10 12:46:45 +00:00
|
|
|
virAdmConnectIsAlive;
|
|
|
|
|
virAdmConnectGetURI;
|
|
|
|
|
virAdmConnectGetLibVersion;
|
|
|
|
|
virAdmConnectRegisterCloseCallback;
|
|
|
|
|
virAdmConnectUnregisterCloseCallback;
|
2015-08-14 07:17:01 +00:00
|
|
|
virAdmConnectListServers;
|
|
|
|
|
virAdmServerGetName;
|
2015-11-23 11:41:32 +00:00
|
|
|
virAdmServerGetThreadPoolParameters;
|
2015-08-14 07:17:01 +00:00
|
|
|
virAdmServerFree;
|
2016-04-22 07:47:09 +00:00
|
|
|
virAdmServerLookupClient;
|
2016-03-01 16:33:37 +00:00
|
|
|
virAdmConnectLookupServer;
|
admin: Introduce virAdmServerSetThreadPoolParameters
Since threadpool increments the current number of threads according to current
load, i.e. how many jobs are waiting in the queue. The count however, is
constrained by max and min limits of workers. The logic of this new API works
like this:
1) setting the minimum
a) When the limit is increased, depending on the current number of
threads, new threads are possibly spawned if the current number of
threads is less than the new minimum limit
b) Decreasing the minimum limit has no possible effect on the current
number of threads
2) setting the maximum
a) Icreasing the maximum limit has no immediate effect on the current
number of threads, it only allows the threadpool to spawn more
threads when new jobs, that would otherwise end up queued, arrive.
b) Decreasing the maximum limit may affect the current number of
threads, if the current number of threads is less than the new
maximum limit. Since there may be some ongoing time-consuming jobs
that would effectively block this API from killing any threads.
Therefore, this API is asynchronous with best-effort execution,
i.e. the necessary number of workers will be terminated once they
finish their previous job, unless other workers had already
terminated, decreasing the limit to the requested value.
3) setting priority workers
- both increase and decrease in count of these workers have an
immediate impact on the current number of workers, new ones will be
spawned or some of them get terminated respectively.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
2016-02-22 13:24:04 +00:00
|
|
|
virAdmServerSetThreadPoolParameters;
|
2016-04-14 22:20:11 +00:00
|
|
|
virAdmServerListClients;
|
2016-04-22 11:05:42 +00:00
|
|
|
virAdmClientGetInfo;
|
2016-04-28 08:26:25 +00:00
|
|
|
virAdmClientClose;
|
2016-04-04 08:28:22 +00:00
|
|
|
virAdmServerGetClientLimits;
|
2016-04-04 12:24:52 +00:00
|
|
|
virAdmServerSetClientLimits;
|
2015-04-15 14:16:24 +00:00
|
|
|
};
|
2016-03-04 22:00:40 +00:00
|
|
|
|
|
|
|
|
LIBVIRT_ADMIN_3.0.0 {
|
|
|
|
|
global:
|
|
|
|
|
virAdmConnectGetLoggingOutputs;
|
2016-03-04 21:58:55 +00:00
|
|
|
virAdmConnectGetLoggingFilters;
|
2016-03-08 12:37:56 +00:00
|
|
|
virAdmConnectSetLoggingOutputs;
|
2016-03-30 13:14:54 +00:00
|
|
|
virAdmConnectSetLoggingFilters;
|
2016-03-04 22:00:40 +00:00
|
|
|
} LIBVIRT_ADMIN_2.0.0;
|
