Commit Graph

24 Commits

Author SHA1 Message Date
Erik Skultety
8b1f04693d admin: Introduce virAdmServerSetClientLimits
Opposite operation to virAdmServerGetClientLimits. Understandably though,
setting values for current number of clients connected or still waiting
for authentication does not make sense, since changes to these values are event
dependent, i.e. a client connects - counter is increased. Thus only the limits
to maximum clients connected and waiting for authentication can be set. Should
a request for other controls to be set arrive (provided such a setting will
be first introduced to the config), the set of configuration controls can be
later expanded (thanks to typed params). This patch also introduces a
constraint that the maximum number of clients waiting for authentication has to
be less than the overall maximum number of clients connected and any attempt to
violate this constraint will be denied.

Signed-off-by: Erik Skultety <eskultet@redhat.com>
2016-05-19 12:31:53 +02:00
Erik Skultety
509bd5d8b3 admin: Introduce virAdmServerGetClientLimits
Enable retrieval of the number of maximum clients connected to all sockets
combined, as well as the number of maximum clients waiting for authentication,
in order to be successfully connected. These are the attributes configurable
through libvirtd.conf, however, it could be handy to not only know values for
these limits, but also the values for the current number of clients
connected and number of clients currently waiting for authentication which are
changing dynamically. This API does both, retrieves the limits as well as the
current dynamic values.

Signed-off-by: Erik Skultety <eskultet@redhat.com>
2016-05-19 12:31:53 +02:00
Erik Skultety
c22ac618b5 admin: Introduce virAdmClientClose API
Once we're able to list and identify all clients connected to a specific
server, we can then support force-closing a connection. This patch introduces
a simple API calling virNetServerClientClose on a specific client, which
can be later extended easily, e.g. by sending an event once the client is
disconnected successfully.

Signed-off-by: Erik Skultety <eskultet@redhat.com>
2016-05-10 16:05:17 +02:00
John Ferlan
70e9114e7c admin: Clean up error path in adminServerListClients
Coverity noted that in adminServerListClients if virNetServerGetClients
returns a -1 into ret, then the call virObjectListFreeCount in cleanup
will not be very happy.

Adjust the code to skip the cleanup label and just return -1 if
virNetServerGetClients fails.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2016-05-09 19:33:56 -04: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
52a2eef948 admin: Introduce virAdmServerLookupClient
Just like with server-related APIs, before any of client-based APIs can be
called, a reference to a client-side client object needs to be obtained. For
this purpose, a lookup method should exist. Apart from the client retrieval
logic, a new error code for non-existent client had to be added as well.

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
Michal Privoznik
d715bfac08 admin_server: Avoid accessing unallocated memory
In 68b726b93c we tried to fix a mem leak. However, it
wasn't done quite well. Problem is, virNetDaemonGetServers() may
fail in which case virObjectListFreeCount() would be called with
-1 objects to free. But the number of elements is taken in
unsigned rather than signed integer.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2016-03-25 10:18:00 +01:00
Pavel Hrdina
68b726b93c admin_server: fix memory leak
If caller of adminConnectListServers() pass NULL instead of servers we
need to free the list we've received from virNetDaemonGetServers().

Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2016-03-24 14:03:18 +01:00
Martin Kletzander
b9a3ce95ce admin: Add virAdmConnectLookupServer
It does not have a suffix ByName because there are no other means of
looking up the server and since the name is known, this should be the
preferred one.

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2016-03-17 17:06:22 +01: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
d4218ca64f Change virNetDaemonGetServerNames to virNetDaemonGetServers
For now it does not matter which ones we return as the code is similarly
complex, however it will fit in with other constructs in the future,
mainly when we will be able to generate dispatch helpers.

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
Michal Privoznik
702713af5a adminDaemonListServers: Don't leak @srv_names array
When getting a list of servers registered for a daemon, it's
returned as a dynamically allocated array filled in with pointers
to constant strings. Because the array is dynamic, it should be
freed when no longer needed (but not the strings!). Even the
function that creates the array suggests that.

==19446== 48 bytes in 3 blocks are definitely lost in loss record 821 of 1,034
==19446==    at 0x4C2C28E: realloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==19446==    by 0x54BAFC8: virReallocN (viralloc.c:245)
==19446==    by 0x54BB0BE: virExpandN (viralloc.c:294)
==19446==    by 0x54BB391: virInsertElementsN (viralloc.c:436)
==19446==    by 0x164E3D: virNetDaemonGetServerNames (virnetdaemon.c:217)
==19446==    by 0x15616F: adminDaemonListServers (admin_server.c:52)
==19446==    by 0x155B8C: adminDispatchConnectListServers (admin.c:151)
==19446==    by 0x155FD8: adminDispatchConnectListServersHelper (admin_dispatch.h:101)
==19446==    by 0x568E862: virNetServerProgramDispatchCall (virnetserverprogram.c:437)
==19446==    by 0x568E3C3: virNetServerProgramDispatch (virnetserverprogram.c:307)
==19446==    by 0x5687B5B: virNetServerProcessMsg (virnetserver.c:135)
==19446==    by 0x5687C1B: virNetServerHandleJob (virnetserver.c:156)

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2016-02-22 07:25:18 +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
Erik Skultety
3245e1783c Revert "admin: Rename virAdmConnect to virAdmDaemon"
Commmit df8192aa introduced admin related rename and some minor
(caused by automated approach, aka sed) and some more severe isues along with
it. First reason to revert is the inconsistency with libvirt library.
Although we deal with the daemon directly rather than with a specific
hypervisor, we still do have a connection. That being said, contributors might
get under the impression that AdmDaemonNew would spawn/start a new daemon
(since it's admin API, why not...), or AdmDaemonClose would do the exact
opposite or they might expect DaemonIsAlive report overall status of the daemon
which definitely isn't the case.
The second reason to revert this patch is renaming virt-admin client. The
client tool does not necessarily have to reflect the names of the API's it's
using in his internals. An example would be 's/vshAdmConnect/vshAdmDaemon'
where noone can be certain of what the latter function really does. The former
is quite expressive about some connection magic it performs, but the latter does
not say anything, especially when vshAdmReconnect and vshAdmDisconnect were
left untouched.
2015-12-21 10:07:59 +01:00
Martin Kletzander
df8192aaf4 admin: Rename virAdmConnect to virAdmDaemon
virAdmConnect was named after virConnect, but after some discussions,
most of the APIs called will be working with remote daemon and starting
them virAdmDaemon will make more sense.  Only possibly controversal name
is CloseCallback (de)registration, and connecting to the daemon (which
will still be Open/Close), but even this makes sense if one thinks about
the daemon being opened and closed, e.g. as file, etc.

This way all the APIs working with the daemon will start with
virAdmDaemon prefix, they will accept virAdmDaemonPtr as first parameter
and that will better suit with other namings as well (virDomain*,
virAdmServer*, etc.).

Because in virt-admin, the connection name does not refer to a struct
that would have a connect in its name, also adjust 'connname' in
clients.  And because it is not used anywhere in the vsh code, move it
from there into each client.

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2015-12-01 11:44:48 +01:00
Erik Skultety
a474371fc6 admin: Introduce virAdmConnectGetLibVersion
Introduce a new API to get libvirt version. It is worth noting, that
libvirt-admin and libvirt share the same version number. Unfortunately,
our existing API isn't generic enough to be used with virAdmConnectPtr
as well. Also this patch wires up this API to the virt-admin client
as a generic cmdVersion command.
2015-11-30 09:44:28 +01:00
Martin Kletzander
2cc6c652cf Revert "admin: Add virAdmHello function"
This reverts commit 5792fabb7b.

I mistakenly pushed it along with the Admin API series.
2015-06-16 14:08:59 +02:00
Martin Kletzander
5792fabb7b admin: Add virAdmHello function
Just one of the simplest functions that returns string "Clients: X"
where X is the number of connected clients to daemon's first
subserver (the original one), so it can be tested using virsh, ipython,
etc.

The subserver is gathered by incrementing its reference
counter (similarly to getting qemu capabilities), so there is no
deadlock with admin subserver in this API.

Here you can see how functions should be named in the client (virAdm*)
and server (adm*).

There is also a parameter @flags that must be 0, which helps testing
proper error propagation into the client.

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2015-06-16 13:46:21 +02:00
Martin Kletzander
d5f4241bbc Add support for admin API in libvirt daemon
For this to pe properly separated from other protocols used by the
server, there is second server added which allows access to the whole
virNetDaemon to its clients.

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2015-06-16 13:46:21 +02:00