Sergey Nivens - Fotolia
Virt-manager is the primary tool that is used for managing KVM virtual environments. In order to run it with default settings, you need to run it as root user. That's not always convenient, however, as you might want to host virtual machines on your KVM hypervisor server that are accessed by end users instead of root users.
In some situations, it's easy to avoid running into that issue. If the end user needs remote access to just the virtual machine (VM), you might need to give him just Secure Shell access to the VM. This option isn't complicated, as no additional permissions need to be granted on the host machine and the user will need only root access to the VM itself. However, if your user needs full control of the VM, including its hardware settings as displayed from virt-manager, the situation isn't as easy.
If you try to launch virt-manager as a non-root user, you'll end with an error message indicating that libvirtd could not be contacted because of Policy Kit rules that don't exist. To enable end users to access VMs through libvirtd, you will first need to provide end-user access to libvirtd. To do this, it's sufficient to add a few lines to the libvirtd configuration file /etc/libvirt/libvirtd.conf. Make sure this file includes the following lines:
unix_sock_group = "libvirt"
unix_sock_rw_perms = "0770"
auth_unix_rw = "none"
When virt-manager accesses libvirtd, it uses a Unix socket to do so. By default, root permissions are required to access the socket. The first line that you'll add to libvirtd.conf changes that behavior and tells libvirtd to use the libvirt group instead. Next, you'll add the line unix_sock_rw_perms to make sure that users, as well as groups, have written permissions to the socket. The third line is added to specify that no further authentication is required.
Now that you have configured the libvirt group to access the socket on which libvirtd is listening, you'll need to configure group access as well, which is a simple operation.
First, type "groupadd libvirt" followed by "usermod -aG libvirt user1 user2". This will add user1 and user2 to the libvirt group. After doing so, you can now run virt-manager as user1 or user2.
The last part to consider for such a configuration is the accessibility of disk image files. By default, these are stored in the /var/lib directory. You'll have to change that and tell the users to store VM image files in their home directory because users normally don't have write permissions.
If you don't want to tell your users that they need to change the directory to their home directory, you might consider adding file system access control lists (ACLs) to the /var/lib/libvirt/images directory.
To add an ACL to the directory, you'll first need to check and see whether it is supported on the file system mount. If it is, you can use these two commands to allow write access to /var/lib/libvirtd/images:
setfacl -R -m g:libvirt:rw /usr/lib/libvirt/qemu
setfacl -R -m d:g:libvirt:rw /usr/lib/libvirt/qemu
At this point you're all set, and end users will be able to manage VMs from virt-manager. Using this method doesn't make your KVM environment a private cloud, however. Through virt-manager, the user will see not only their own VM, but all other VMs as well. And because libvirtd accesses the VM image files with root permission, there's not much you can do about this. But at least you have created a configuration where users don't need root access to work with VMs.