How to install Virt-Manager needs fixing

Forum & Website Wiki entry
1

https://discovery.endeavouros.com/applications/how-to-install-virt-manager-complete-edition/2021/09/

This part isn’t explained and it doesn’t work. I couldn’t start libvirtd with it, I have removed it from the config and the daemon works now.

4. Add these two lines at the end of /etc/libvirt/qemu.conf
swtpm_user = "swtpm"
swtpm_group = "swtpm"
user = "yourusername"
group = "yourusername"
1 Like
2

i will check just happens i am into the wiki to fix some stuff so i will do it just… now…
Thanks for the heads up!

3 
3. Add these two lines at the end of /etc/libvirt/libvirtd.conf
unix_sock_group = "libvirt"
unix_sock_ro_perms = "0777"
unix_sock_rw_perms = "0770"

This part needs some explanation too, I’m not sure it’s really needed or what it does. I’m to tired to check. Also I’m not sure if you need to add the user to the kvm group, the arch wiki only says the libvirt group. Also, the groups were already there in my system.

1 Like
4

Out of curiosity: shouldn’t

extra/swtpm 0.8.1-1
    Libtpms-based TPM emulator with socket, character device, and Linux CUSE interface

be installed for it to work? That is of course if one needs that functionality.

https://man.archlinux.org/man/swtpm.8.en

1 Like
5

I have managed to install almalinux without it. Maybe it’s needed for a windows guest. I installed windows 11 in the user session almost two years ago, don’t remember what I did for TPM, but not this. I checked swtpm was installed already, but libvirtd didn’t start with this config.

1 Like
6 
# User for the swtpm TPM Emulator
#
# Default is 'tss'; this is the same user that tcsd (TrouSerS) installs
# and uses; alternative is 'root'
#
#swtpm_user = "tss"
#swtpm_group = "tss"

# The user for QEMU processes run by the system instance. It can be
# specified as a user name or as a user id. The qemu driver will try to
# parse this value first as a name and then, if the name doesn't exist,
# as a user id.
#
# Since a sequence of digits is a valid user name, a leading plus sign
# can be used to ensure that a user id will not be interpreted as a user
# name.
#
# Some examples of valid values are:
#
#       user = "qemu"   # A user named "qemu"
#       user = "+0"     # Super user (uid=0)
#       user = "100"    # A user named "100" or a user with uid=100
#
#user = "libvirt-qemu"

# The group for QEMU processes run by the system instance. It can be
# specified in a similar way to user.
#group = "libvirt-qemu"

from the

/etc/libvirt/qemu.conf
7

i bet not to run virtmanager as normal user…

1 Like
8

What do you mean? What’s wrong with using libvirtd as a normal user? I couldn’t use the default network without it in the user session.

9 
# UNIX socket access controls
#

# Set the UNIX domain socket group ownership. This can be used to
# allow a 'trusted' set of users access to management capabilities
# without becoming root.
#
# This setting is not required or honoured if using systemd socket
# activation.
#
# This is restricted to 'root' by default.
#unix_sock_group = "libvirt"

# Set the UNIX socket permissions for the R/O socket. This is used
# for monitoring VM status only
#
# This setting is not required or honoured if using systemd socket
# activation.
#
# Default allows any user. If setting group ownership, you may want to
# restrict this too.
#unix_sock_ro_perms = "0777"

# Set the UNIX socket permissions for the R/W socket. This is used
# for full management of VMs
#
# This setting is not required or honoured if using systemd socket
# activation.
#
# Default allows only root. If PolicyKit is enabled on the socket,
# the default will change to allow everyone (eg, 0777)
#
# If not using PolicyKit and setting group ownership for access
# control, then you may want to relax this too.
#unix_sock_rw_perms = "0770"
10

From what i see the wiki entry should get reviewed depper… the options are mainly not added they are in the configs already needing to get uncommeted with this you would also see the comments on the options… or as @mihalycsaba mentioned wiki would need to get the comments added to understand what they are for…

11

I’m tired, but I tried it out, I have managed to change the guest’s configurations without the configs above after a restart.

So I’m not sure what they do, I thought, from what you copied, I wouldn’t be able to modify the guest’s configs. But there’s not much about these in the arch wiki. The only thing you probably need is to be in the libvirt group, unless you use polkit or whatnot. But I think on a regular desktop setup, you just need to add yourself to the group. From the wiki:

Set up authentication

From libvirt: Connection authentication:

The libvirt daemon allows the administrator to choose the authentication mechanisms used for client connections on each network socket independently. This is primarily controlled via the libvirt daemon master config file in /etc/libvirt/libvirtd.conf. Each of the libvirt sockets can have its authentication mechanism configured independently. There is currently a choice of none, polkit and sasl.

Using libvirt group

The easiest way to ensure your user has access to libvirt daemon is to add member to libvirt user group.

Members of the libvirt group have passwordless access to the RW daemon socket by default.

Using polkit

Because libvirt pulls polkit as a dependency during installation, polkit is used as the default value for the unix_sock_auth parameter (source). File-based permissions remain nevertheless available.

Note: A system reboot may be required before authenticating with polkit works correctly.

The libvirt daemon provides two polkit actions in /usr/share/polkit-1/actions/org.libvirt.unix.policy:

  • org.libvirt.unix.manage for full management access (RW daemon socket), and
  • org.libvirt.unix.monitor for monitoring only access (read-only socket).

The default policy for the RW daemon socket will require to authenticate as an admin. This is akin to sudo auth, but does not require that the client application ultimately run as root. Default policy will still allow any application to connect to the RO socket.

Arch defaults to consider anybody in the wheel group as an administrator: this is defined in /usr/share/polkit-1/rules.d/50-default.rules (see Polkit#Administrator identities). Therefore there is no need to create a new group and rule file if your user is a member of the wheel group: upon connection to the RW socket (e.g. via virt-manager) you will be prompted for your user’s password.

1 Like
12

I think we need to keep eOS wiki as simple as possible, only include stuff that is needed for a regular desktop user. For everything else, there’s arch wiki. Someone already got tripped up needlessly by it. Unable to use "Bridge device" on Virt-Manager - #16 by mihalycsaba

1 Like
13

yes i will go to remove that part all together.
It is not needed to run virtmanager and is confusing …