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: NErik Skultety <eskultet@redhat.com>

Since we have the opportunity now, let's save some precious code lines.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

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: NMartin Kletzander <mkletzan@redhat.com>

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: NErik Skultety <eskultet@redhat.com>
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

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: NErik Skultety <eskultet@redhat.com>
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

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.

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: NMartin Kletzander <mkletzan@redhat.com>

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.

This reverts commit 5792fabb.

I mistakenly pushed it along with the Admin API series.

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: NMartin Kletzander <mkletzan@redhat.com>

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: NMartin Kletzander <mkletzan@redhat.com>