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