On 29/09/16 16:25, mordenkainen wrote: That depends on what you're trying to achieve if you describe your intended use case thoroughly we might be able to give you a better answer. The configuration file does contain plenty of commentaries on what purpose does each parameter serve, although I can understand your concern and definitely can imagine having some extensive documentation for the config with some examples as well as some tutorials for users starting with libvirt (I have it on my TODO list, though not with the highest priority). To answer your question in subject (unix_sock_admin_perms purpose), by changing the permissions on the admin socket you allow users with enough privileges to connect to the admin socket and configure the daemon during runtime. First, dropping the admin socket privileges (root only by default) is not recommended unless you really know what you're doing and fully understand all possible outcomes and that is because you're able to tweak the maximum number of allowed clients connected to the daemon, force close existing connections, manipulating the amount of worker threads in the threadpool, etc. In wrong hands, the APIs designated to accomplish the operations mentioned above can be used to perform DOS attack on the daemon. Secondly, the libvirtd.conf file can only be edited by root by default, so it was only natural that the default choice on the admin unix socket permissions would be root-only. Before the administration interface was introduced in libvirt, the only way how to configure libvirtd daemon was via libvirtd.conf, which you've already come across. Editing the configuration via this file however only provides users with persistent configuration, therefore we came up with the administration interface, to be able to alter the runtime configuration of the daemon (but not all configuration parameters that can be found in the config file can be modified during runtime at the moment). Regards, Erik