RFC: Admin interface for connection monitoring

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello everyone.

Trying to create new interface for the libvirt daemon, mainly for
connection monitoring, I came across few things I'd like to
propose/discuss.  This interface will be used to manage active
connections of the daemon (list/kill) and other until-now impossible
things (e.g. changing logging filters on-the-fly).


Connection to this interface will be:

 - available even when no normal/priority workers are available,

 - distinguished (or completely separated) from other daemon
   connections,

 - (should be) more restricted than other connections.

Having the connection available with all the worker threads being
blocked/deadlocked creates the possibility of for example listing the
connections even when all APIs block.  Such manipulations mustn't be
possible over the standard connections and that's why the connections
should be distinguished.  The connection restriction is hard to check,
but the permissions for the socket should be less or equal to the rw
socket with having no authentication only when rw socket has no
authentication.


My idea is following:

 - new 'admin_protocol.x' with specification of new program,

 - default connection limitation to this interface to only root-owned
   socket with 700 (authentication optional, see above), so only root on
   the host can utilize it,

 - configurable number of admin workers, but with 1 as a default,

 - splitting usable parts of virsh and reusing them to create
   virsh-admin binary.


More controversial ideas I'd like to hear somebody else's opinion (even
more than for the other things):

 - create a new separate library (libvirt-admin.so) to be used in the
   client, this library will have it's own virAdminConnect{,Auth}Open(),
   probably without an URI parameter (or with, but disabled for now, in
   case we want to enable remote connections later)

 - it is IMHO pointless to add a driver type for this, but it should
   definitely be configurable at compile time as well as in config
   (admin_workers = 0, maybe),

 - keep the connection handling on the current code and instead of
   duplicating much of it (so there will be a new service, much like the
   read-only socket, but for admin API only),

 - create a new pool of workers just for admin connections (similarly to
   the priority workers pool), with the dispatching being recognized by
   the protocol it is created in (remote, qemu, lxc protocols will go to
   normal/priority workers, whether admin protocol will be dispatched to
   the admin workers) and of course impossible from other connections
   than the admin one, which leads me to the next point;

 - we can either add next flag for admin connection (similarly to the
   readonly one) or make it future-friendly and change the readonly bool
   into a virConnectionType enum (for example).


I must admit, I'm probably doing something wrong or we have old
documentation.  Commands like 'make -C src rpcgen' don't work and I
don't understand why admin_protocol-structs isn't automatically
generated, but I've made it work for now.


Have a nice day,
Martin

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]