Hi Michal, Thanks a lot for your long and detailed response! On 26/01/2020 16.11, Michal Prívozník wrote:
Virt-viewer accepts -c URI argument. In your case you can do:
virt-viewer -c qemu:///session $domain
and it will show the domain's GUI. >
I've tried doing exactly that, but it fails when using SSH as the transport with: "Connecting to session instance without socket path is not supported by the ssh transport" According to this reply from this very mailing list, this means using SSH with the session bus is not supported: https://www.redhat.com/archives/libvirt-users/2014-June/msg00089.html The error message is not exactly clear, but looking at the source (remote/remote_driver.c), it seems to mean that only unix sockets are supported as transport when using the session bus. I could be wrong of course.
Domains running under the system connection doesn't necessarily run as root:root. You can configure the UID:GID pair in /etc/libvirt/qemu.conf (search user/group). Alternatively, each domain can be fine tuned to run under different user. See https://libvirt.org/formatdomain.html#seclabel for more info.
Thanks a lot. That's very useful to know.
First of all, you need to verify that the host is KVM capable. Try running "virt-host-validate qemu" under root. It should do some basic diagnostic and suggest resolution to possible errors.
Well, that's what really puzzles me since I can run the VM perfectly fine on the session bus and running the validation command gives me the exact same output both as a normal user and as root: QEMU: Checking for hardware virtualization : PASS QEMU: Checking if device /dev/kvm exists : PASS QEMU: Checking if device /dev/kvm is accessible : PASS QEMU: Checking if device /dev/vhost-net exists : PASS QEMU: Checking if device /dev/net/tun exists : PASS QEMU: Checking for cgroup 'cpu' controller support : PASS QEMU: Checking for cgroup 'cpuacct' controller support : PASS QEMU: Checking for cgroup 'cpuset' controller support : PASS QEMU: Checking for cgroup 'memory' controller support : PASS QEMU: Checking for cgroup 'devices' controller support : PASS QEMU: Checking for cgroup 'blkio' controller support : PASS QEMU: Checking for device assignment IOMMU support : PASS QEMU: Checking if IOMMU is enabled by kernel : PASS Doesn't look like there's a problem with hardware support or the kernel driver and again, it works just fine as a normal user.
Secondly, you want to make sure that /dev/kvm is accessible to the user that you want to start your domain under. I'm using consolekit on my desktop so whenever I log in it appends an ACL entry to the file so that my user can run domains:
Now we're getting to something very interesting, since my knowledge of ACLs on Linux and consolekit is extremely limited, so that could very well explain it. I'm not sure if that could limit the root user from accessing something root would normally have access to? Anyway, the output from getacl on my system as my normal user (klau) that can run the VM with KVM acceleration: # file: dev/kvm # owner: root # group: plugdev user::rw- user:klau:rw- group::rw- mask::rw- other::--- The same command run as root: # file: dev/kvm # owner: root # group: plugdev user::rw- user:klau:rw- group::rw- mask::rw- other::--- So it does indeed seem like my normal user has some ACLs associated that the root user doesn't. That's something I can look into, but any further input from you would be much appreciated as well. Thanks a lot once again. Kind regards, Kasper Laudrup