Commit Graph

9 Commits

Author SHA1 Message Date
Eric Blake
a4ef805758 build: fix 32-bit build of admin
We can't guarantee which 64-bit type will be used in an RPC struct;
while %lu worked on 64-bit Linux, that won't always be the type
used on all 64-bit platforms; and certainly is not right for 32-bit:

admin.c: In function 'adminDispatchClientGetInfo':
admin.c:265:25: error: format '%lu' expects argument of type 'long unsigned int', but argument 7 has type 'uint64_t {aka long long unsigned int}' [-Werror=format=]

Signed-off-by: Eric Blake <eblake@redhat.com>
2016-05-04 13:20:23 -06:00
Erik Skultety
4a0e910825 admin: Introduce virAdmClientGetInfo API
Expose a public API to retrieve some identity and connection information about
a client connected to the specified server on daemon. The identity info
retrieved is mostly connection transport dependent, i.e. there won't be any
socket address returned for a local (UNIX socket) connection, while on the
other hand, when connected through TLS or unencrypted TCP, obviously no UNIX
process identification will be present in the returned data. All supported
values that can be returned in typed params are exposed and documented in
include/libvirt/libvirt-admin.h

Signed-off-by: Erik Skultety <eskultet@redhat.com>
2016-05-03 15:52:50 +02:00
Erik Skultety
ed978fa2bc admin: Introduce listing clients
Finally add public method to retrieve the list of currently connected clients
to a given server.

Signed-off-by: Erik Skultety <eskultet@redhat.com>
2016-05-03 10:04:54 +02:00
Erik Skultety
93ab4da5f4 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-04-18 17:07:46 +02:00
Erik Skultety
caa16d3168 admin: Introduce virAdmServerGethreadPoolParameters
New API to retrieve current server workerpool specs. Since it uses typed
parameters, more specs to retrieve can be further included in the pool of
supported ones.

Signed-off-by: Erik Skultety <eskultet@redhat.com>
2016-04-18 17:07:36 +02:00
Martin Kletzander
d949280c72 admin: Generate ConnectListServers dispatch helpers
Since we have the opportunity now, let's save some precious code lines.

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2016-03-11 12:58:41 +01:00
Martin Kletzander
a0dbed6160 admin: Do not work with virAdm on the server side
virAdm is prefix only used on the client side.  Or at least for now.  On
server, though, this corresponds to virNet structures (virAdmConnect is
virNetDaemon, virAdmServer should be virNetServer, in the future
virAdmClient will be resolved to virNetServerClient, and so on).

This will also make future work clearer and easier.

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2016-03-11 12:58:41 +01:00
Erik Skultety
1a07c2efb3 admin: Introduce adminDaemonConnectListServers API
This API is merely a convenience API, i.e. when managing clients connected to
daemon's servers, we should know (convenience) which server the specific client
is connected to. This implies a client-side representation of a server along
with a basic API to let the administrating client know what servers are actually
available on the daemon.

Signed-off-by: Erik Skultety <eskultet@redhat.com>
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2016-02-17 12:46:34 +01:00
Erik Skultety
159a37f659 admin: Move admin_server.{h,c} to admin.{h,c}
This change is merely because admin_server would contain all the code
from dispatchers and helpers to the actual APIs. Admin should have
similar structure to the daemon-side remote driver - dispatchers and
helpers in a separate module, APIs in a separate module.

Best viewed with -M.

Signed-off-by: Erik Skultety <eskultet@redhat.com>
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2016-02-17 12:46:34 +01:00