[libvirt] RFC: Admin interface for connection monitoring
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
On Mon, Feb 04, 2013 at 11:52:41AM +0100, Martin Kletzander wrote:
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.
Completely agreed - the administrative inteface must always be usable, regardless of anything a regular client might have done.
My idea is following:
- new 'admin_protocol.x' with specification of new program,
Agreed, we want this completely independant of existing RPC programs.
- 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,
Agreed, making this kind of thing remote accessible is just asking for trouble.
- configurable number of admin workers, but with 1 as a default,
Yep, makes sense.
- splitting usable parts of virsh and reusing them to create virsh-admin binary.
Or to following our more usual naming convention virt-admin
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)
Yes, we want this library to be completely separate because we don't want to make guarantees about long term ABI/API stability for this. We should still use a URI format to connect, but this should be a completely separate URI from the "normal" URIs, not least because a admin connection is completely independant of any hypervisor. Indeed this library should not even need to link to libvirt.so - it can be completely standalone, because (unlike libvirt-qemu.so) these APIs are completely separate from all existing APIs.
- 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),
I don't think there's any compelling reason to disable this separately from disabling of libvirtd itself. ie if you have libvirtd built, then you should always have the admin service and shell built too.
- 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),
Yep, a new socket is inherantly required since we need separate auth requirements
- 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;
Ok.
- 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'm not sure what you're refering to here, but opening admin connections should be completely separate from existing connection opening APIs.
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.
You have to create the admin_protocol-structs file yourself - that is the master ABI definition. The makefile creates a admin_protocol-struct (notice lack of a trailing 's'), and compares it to the file you wrote Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
participants (2)
-
Daniel P. Berrange -
Martin Kletzander