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>
Function virAdmConnectListServers() forgot to check for flags at all,
virAdmConnectOpen() on the other hand checked them but did no dispatch
the error. virCheckFlags() should be used only when there should be no
other thing done after erroring out and since they are used on different
places then just public API, they cannot dispatch errors. So let's use
virCheckFlagsGoto instead.
Signed-off-by: Martin 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: Erik Skultety <eskultet@redhat.com>
Signed-off-by: Martin 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: Martin 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.
As we need a client disconnect handler, we also need a mechanism to register
such handlers for a client. This patch introduced both the close callbacks and
also the client vshAdmCatchDisconnect handler to be registered with it. By
registering the handler we still need to make sure the client can react to
daemon's events like disconnect or keepalive, so asynchronous I/O event polling
is necessary to be enabled too.
Now that we introduced URI support in libvirt-admin, we should also support URI
aliases during connection establishment phase. After applying this patch,
virAdmConnectOpen will also support VIR_CONNECT_NO_ALIASES flag.
By moving the remote version into a separate module, we gain a slightly
better maintainability in the long run than just by leaving it in one
place with the existing libvirt-admin library which can start getting
pretty messy later on.
Since most of our APIs rely on an acive functional connection to a daemon and
we have such a mechanism in libvirt already, there's need to have such a way in
libvirt-admin as well. By introducing a new public API, this patch provides
support to check for an active connection.
Unfortunately, client side version retrieval API virGetVersion uses
one-time initialization (due to the fact we might not have initialized the
library by calling connect prior to this) which is not completely compatible
with admin initialization. This API is rather simplistic and reimplementing
it for admin might be the preferred method of reusing it. Note that even though
the method will be reimplemented, the version number is still the same for both
the libvirt and libvirt-admin library.
Running valgrind on a very simplistic program consisting only of
opening and closing admin connection (virAdmConnect{Open,Close}) shows a
leak in remoteAdminPrivNew, because the last reference to privateData is
not decremented, thus the object won't be disposed. This patch unrefs
the privateData object once we closed the active connection to daemon,
making further use of this connection useless.
==24577== at 0x4A089C7: calloc (in /usr/lib64/valgrind/vgpreload_***linux.so)
==24577== by 0x4E8835F: virAllocVar (viralloc.c:560)
==24577== by 0x4EDFA5C: virObjectNew (virobject.c:193)
==24577== by 0x4EDFBD4: virObjectLockableNew (virobject.c:219)
==24577== by 0x4C14DAF: remoteAdminPrivNew (libvirt-admin.c:152)
==24577== by 0x4C1537E: virAdmConnectOpen (libvirt-admin.c:308)
==24577== by 0x400BAD: main (listservers.c:39)
==24577== LEAK SUMMARY:
==24577== definitely lost: 80 bytes in 1 blocks
==24577== indirectly lost: 840 bytes in 6 blocks
==24577== possibly lost: 0 bytes in 0 blocks
==24577== still reachable: 12,179 bytes in 199 blocks
==24577== suppressed: 0 bytes in 0 blocks
By trying to lead the way of clean includes, I sorted the lines
alphabetically and that is a problem for mingw builds with gnulib.
As 'configmake.h' defines DATADIR and 'datatypes.h' transitively
includes 'winsock.h' that uses 'DATADIR' as a name for a struct,
it's enough to reorder those.
Even though this might be worked around in gnulib later on, this
fixes the build for now.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
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>
Initial scratch of the admin library. It has its own virAdmConnectPtr
that inherits from virAbstractConnectPtr and thus trivially supports
error reporting.
There's pkg-config file added and spec-file adjusted as well.
Since the library should be "minimalistic" and not depend on any other
library, the list of files is especially crafted for it. Most of them
could've been put to it's own sub-libraries that would be LIBADD'd to
libvirt_util, libvirt_net_rpc and libvirt_setuid_rpc_client to minimize
the number of object files being built, but that's a refactoring that
isn't the orginal aim of this commit.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
