# How to use virt-manager as a non-root user?

Same question was asked here which was answered by a 4 years old blog post. Four years are a long time and while searching one of the prevalent way of solving this problem is by adding $USER to group kvm and libvert. I was wondering which is the better and official way to solve this problem? edit retag close merge delete ## Comments What, exactly, do you want the non-root user to be able to do? There are a variety of options available for configuring non-root users to perform monitoring and some management tasks. ( 2014-04-24 14:44:02 -0500 )edit I would not like to enter root password to start and use virt-manager. I would like to create virtual images in my home folder instead of root drive. I would not like to use root password unless I am changing the behavior of currently running OS on my system. I just want it to work like the way VirtualBox works. Easily create and delete virtual machines. ( 2014-04-24 20:17:54 -0500 )edit ## 3 Answers Sort by » oldest newest most voted virt-manager defaults to using the libvirt URI qemu:///system, which connects to the system libvirtd instance, which runs as root. What you're requesting is basically the qemu:///session URI, which auto-launches a libvirtd instance running as your regular user, runs VMs as your user, and defaults to storing images in $HOME/VirtualMachines.

virt-manager --connect qemu:///session


Or

Virt-Manager->File->Add Connection->QEMU/KVM user session


Source

What is the difference between qemu:///system and qemu:///session? Which one should I use?

All 'system' URIs (be it qemu, lxc, uml, ...) connect to the libvirtd daemon running as root which is launched at system startup. Virtual machines created and run using 'system' are usually launched as root, unless configured otherwise (for example in /etc/libvirt/qemu.conf).

All 'session' URIs launch a libvirtd instance as your local user, and all VMs are run with local user permissions.

You will definitely want to use qemu:///system if your VMs are acting as servers. VM autostart on host boot only works for 'system', and the root libvirtd instance has necessary permissions to use proper networkings via bridges or virtual networks. qemu:///system is generally what tools like virt-manager default to.

qemu:///session has a serious drawback: since the libvirtd instance does not have sufficient privileges, the only out of the box network option is qemu's usermode networking, which has nonobvious limitations, so its usage is discouraged. More info on qemu networking options: http://people.gnome.org/~markmc/qemu-networking.html

The benefit of qemu:///session is that permission issues vanish: disk images can easily be stored in $HOME, serial PTYs are owned by the user, etc. Libvirt FAQ more With Fedora 20, virt-manager implements PolicyKit (I recommend reading the man page). If you want to allow a certain group of users access to virt-manager without providing root credentials, you can create a new rules file in /etc/polkit-1/rules.d and add a rule to permit users who are local, logged in, and in the group you specify (wheel in the example below) access to the virt-manager software. sudo vim /etc/polkit-1/rules.d/80-libvirt.rules  And then write: polkit.addRule(function(action, subject) { if (action.id == "org.libvirt.unix.manage" && subject.local && subject.active && subject.isInGroup("wheel")) { return polkit.Result.YES; } });  (That particular example syntax was taken from this fine site) Save and close the file. The polkitd daemon monitors the rules.d directory for changed content and automatically reloads the rules if changes are detected, so you don't need to reload the process with systemctl. If you've done it right, you should see that you can now launch virt-manager as the user(s) in the group you specified. more ## Comments (There's a typo in the last paragraph, it's polkitd that monitors changes to polkit rules). I don't know what is officially recommended with regards to this virt-manager issue, but for what it's worth I've been using a similar polkit rule for some time now. ( 2014-04-27 00:23:15 -0500 )edit @bitwiseoperator Thanks for that. That solves the virt-manager asking root password problem. virt-manager still creates storage as root user. I would like to create them as a normal user. Current storage is /var/lib/libvirt/images and I changed that to '$HOME/Documents/virt-images' in Edit > Connection Details > Storage. I had the virt-images folder created as a normal user. As soon as I chose that folder as storage folder it changed the user to root:root. Is there a way to change that and make images as a normal user?

( 2014-04-27 09:14:48 -0500 )edit

@Ahmad Thanks for the error correction. I've fixed the post accordingly.

@donniezazen I'll get back to you ASAP

( 2014-04-27 15:25:34 -0500 )edit

bitwiseoperator Any luck so far with not changing directory and file ownership bit?

( 2014-05-14 12:24:41 -0500 )edit

Hey man, sorry for the delay - life's gotten a little hectic. Do you mind if I ask why you want to modify the permissions on the images location? They're being set as root because libvirtd runs in a root context. Because of this, however, so long as your non-root user successfully authenticates and can make use of the libvirtd functionality, you can still manipulate those images without issue, right?

( 2014-05-20 15:27:53 -0500 )edit

Hello, I am using virt-manager as non-root, and without having kvm or libvirt group (F20). I just can't remember if the first time I used it I had to answer with root password and if it is stored somewhere. I also use virsh, virt-viewer as non-root, the only thing is I need to explicitely give the connection, for example: virsh -c qemu:///system shutdown winxp (see https://bugzilla.redhat.com/show_bug.cgi?id=564507 )

more

Indeed (thanks to bitwiseoperator) I can use virt-manager and other libvirt stuff as non-root: because my user is member of wheel group (I sometimes use su - as convenience), and I have set this file /etc/polkit-1/rules.d/80-libvirt-manage.rules to allow "org.libvirt.unix.manage" actions to "wheel" members. I did this a few month ago and had forgotten...

( 2014-04-27 07:50:44 -0500 )edit