Home / server / Questions / 803283
Accepted
Arseni Mourzenko
Asked: 2016-09-16 05:35:08 +0800 CST

How do I list virsh networks without sudo?

  • 772

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?

permissions sudo virsh

4 Answers

  1. Best Answer

    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

    doesn't.

    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 $VIRSH_DEFAULT_CONNECT_URI

ubuntu:~$ echo $LIBVIRT_DEFAULT_URI
qemu:///system

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

    debian:~$ echo $VIRSH_DEFAULT_CONNECT_URI

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).

    • 23

  2. 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: 

     ~/.config/libvirt/libvirt.conf

    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

    • 15

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

    https://major.io/2015/04/11/run-virsh-and-access-libvirt-as-a-regular-user/

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

    • 1

  4. 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...

    • 0