I noticed a strange behavior on one machine using Debian that I can't reproduce on another machine running Ubuntu. When listing virsh networks as an ordinary user, it shows an empty list:

~$ virsh net-list --all
 Name                 State      Autostart     Persistent

When running the same command with sudo, it shows the default connection:

~$ sudo virsh net-list --all
 Name                 State      Autostart     Persistent
 default              active     no            yes

The permissions on the files themselves seem to be set correctly:

~$ ls -l /etc/libvirt/qemu/networks
total 8
drwxr-xr-x 2 root root 4096 Jul  1 18:19 autostart
-rw-r--r-- 1 root root  228 Jul  1 18:19 default.xml

The user belongs to kvm and libvirtd groups.

What is happening? Why can't I list the networks as an ordinary user?

4 Answers 4


It appears that:

If not explicitly stated, the virsh binary uses the 'qemu:///session' URI (at least under debian).

Therefore, not only virsh net-list, but practically any command, including virsh list, behaved differently when running with sudo. In other words, virsh net-list was using user's scope instead of global ones.

This makes sense; trying to create the default connection and then starting it led to “Network is already in use by interface virbr0” error—without knowing it, I was starting a second connection named “default”, while one was already running.

The solution is straightforward:

virsh --connect qemu:///system net-list

does what I was expecting it to do, while:

virsh net-list


Why is Ubuntu machine not having the issue?

According to the documentation:

If virsh finds the environment variable VIRSH_DEFAULT_CONNECT_URI set, it will try this URI by default. Use of this environment variable is, however, deprecated now that libvirt supports LIBVIRT_DEFAULT_URI itself.

It appears, indeed, that on Ubuntu machine, the second variable was defined:


ubuntu:~$ echo $LIBVIRT_DEFAULT_URI

On Debian machine, on the other hand, none of those variables are set:


debian:~$ echo $LIBVIRT_DEFAULT_URI

Setting one of those variables to qemu:///system would probably work, but, well, it's easier to specify the connection string directly in virsh command (at least when writing a script).

  • If you are using ssh it's a very good idea to use "--connect qemu:///system". May 4, 2020 at 11:58
  • I had the same problem on Rocky Linux 8.5. export LIBVIRT_DEFAULT_URI=qemu:///system made virsh list --all do the right thing without sudo for a user in the libvirt group.
    – kbro
    May 6, 2022 at 10:19

uncomment this line in file /etc/libvirt/libvirt.conf

uri_default = "qemu:///system"

was enough for me in fedora 29 .

Edit: as it says here https://libvirt.org/uri.html for non root users that file also needs to be in $XDG_CONFIG_HOME/libvirt/libvirt.conf

which in my case is:


so i copy the file there (on my fresh install) and now virsh net-list works as a non-root user and no need to espicify --connect

  • 1
    "also needs" looks as if I need to edit both files. I only created ~/.config/libvirt/libvirt.conf and did not edit /etc/libvirt/libvirt.conf, and it worked. May 24, 2022 at 7:32

it is possible to setup virsh to work with local user. More information is here:


basically you need to setup polkit rule and connect to libvirtd daemon


From the docs, root is (mostly) required, and virsh is chatting up a daemon (and not poking around manually at files in the /etc/libvirt directory, which a strace or sysdig will confirm):

   Most virsh operations rely upon the libvirt library being able to
   connect to an already running libvirtd service.  This can usually be
   done using the command service libvirtd start.

   Most virsh commands require root privileges to run due to the
   communications channels used to talk to the hypervisor.  Running as non
   root will return an error.

So why virsh list does not return an error might either be a bug or in need of clarification in the virsh(1) man page...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.