1:04 p.m.
Hi libvirt-users,
Hope this is the right place to ask, otherwise please point me in the
right direction.
I have a libvirt virtual machine running on the session bus that I would
like to access through SSH. I have previously done so using X11
forwarding and while it works, it is very sluggish with the connection I
have.
I recently learned that you can access the virtual machine with
virt-viewer through SSH which should perform much better. Unfortunately,
my virtual machine is currently running on the session bus and that
doesn't seem to be supported (please do correct if I'm wrong here).
It doesn't really matter to much if the VM is running on the system bus
or session bus, I just prefer running things as a non privileged user
for all the obvious reasons, so that's where I created the VM initially.
I tried to follow this guide to move my VM to the system bus.
Running `sudo virsh define vm.xml` fails with:
error: invalid argument: could not find capabilities for arch=x86_64
domaintype=kvm
Digging a bit further into it, I figured out that the cause of the error
message is, that I for some reason do not have KVM acceleration support
when running VMs on the system bus (as root) running my VM on the
session bus as a normal user (with the correct group membership) works fine.
Trying to launch virt-manager as root verifies that, as creating a new
VM warns me that I do not have KVM support.
I'm fairly lost as to what to do from here. I must admit I remember
struggling a bit to get the virtual machine to run with KVM support on
the session bus in the first place, but have completely forgotten what
the problem and resolution was.
I'm using Debian stable (Buster) with standard package versions:
QEMU 3.1.0
libvirt 5.0.0
Any kind of help or input would be greatly appreciated.
Thanks a lot and kind regards,
Kasper Laudrup
9:11 a.m.
On 1/25/20 8:04 PM, Kasper Laudrup wrote:
Hi libvirt-users,
Hope this is the right place to ask, otherwise please point me in the
right direction.
I have a libvirt virtual machine running on the session bus that I would
like to access through SSH. I have previously done so using X11
forwarding and while it works, it is very sluggish with the connection I
have.
I recently learned that you can access the virtual machine with
virt-viewer through SSH which should perform much better. Unfortunately,
my virtual machine is currently running on the session bus and that
doesn't seem to be supported (please do correct if I'm wrong here).
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.
It doesn't really matter to much if the VM is running on the system bus
or session bus, I just prefer running things as a non privileged user
for all the obvious reasons, so that's where I created the VM initially.
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.
I tried to follow this guide to move my VM to the system bus.
Running `sudo virsh define vm.xml` fails with:
error: invalid argument: could not find capabilities for arch=x86_64
domaintype=kvm
Digging a bit further into it, I figured out that the cause of the error
message is, that I for some reason do not have KVM acceleration support
when running VMs on the system bus (as root) running my VM on the
session bus as a normal user (with the correct group membership) works
fine.
Trying to launch virt-manager as root verifies that, as creating a new
VM warns me that I do not have KVM support.
I'm fairly lost as to what to do from here. I must admit I remember
struggling a bit to get the virtual machine to run with KVM support on
the session bus in the first place, but have completely forgotten what
the problem and resolution was.
I'm using Debian stable (Buster) with standard package versions:
QEMU 3.1.0
libvirt 5.0.0
Any kind of help or input would be greatly appreciated.
Thanks a lot and kind regards,
Kasper Laudrup
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.
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:
# getfacl /dev/kvm
getfacl: Removing leading '/' from absolute path names
# file: dev/kvm
# owner: root
# group: kvm
user::rw-
user:zippy:rw-
group::rw-
mask::rw-
other::---
After these steps, libvirt should detect KVM just fine.
Michal
5:41 p.m.
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
1792
days inactive
1794
days old
2 comments
2 participants
participants (2)
-
Kasper Laudrup -
Michal Prívozník