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
