Arch Linux

Boring_nick

Member

Registered: 2017-05-06

Posts: 20

Virtio-gpu cache permission issues in libvirt, works in plain qemu

Trying to launch a virtual machine in libvirt with virtio-gpu and spice gl monitor gives me an error:

Error starting domain: internal error: process exited while connecting to monitor: 2019-01-19 11:22:11.486+0000: Domain id=4 is tainted: host-cpu
Failed to create //.cache for shader cache (Permission denied)---disabling.

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 75, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 111, in tmpcb
    callback(*args, **kwargs)
  File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 66, in newfn
    ret = fn(self, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/domain.py", line 1400, in startup
    self._backend.create()
  File "/usr/lib/python3.7/site-packages/libvirt.py", line 1080, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirt.libvirtError: internal error: process exited while connecting to monitor: 2019-01-19 11:22:11.486+0000: Domain id=4 is tainted: host-cpu
Failed to create //.cache for shader cache (Permission denied)---disabling.

Using plain qemu with options " -vga virtio -display gtk,gl=on" works with no issues. libvirt, qemu and virglrenderer are latest versions from repos. I couldn't find a .cache folder in /var/lib/libvirt or /var/cache/libvirt, and a quick search didn't give me any results.

dmartins

Member

Registered: 2006-09-23

Posts: 360

Re: Virtio-gpu cache permission issues in libvirt, works in plain qemu

Hey, we may need some more information!

What client are you using for libvirt?
Are you using libvirt as a system daemon or from your user session?
What qemu command line is libvirt running? (output from ps -ef | grep qemu)
Please check and provide logs.

If running as a system daemon, make sure virtlogd.service is also started. Logs should go to /var/log/libvirt/qemu/
If running from your user session, logs should go to ~/.cache/libvirt/qemu/log

Thanks

Boring_nick

Member

Registered: 2017-05-06

Posts: 20

Re: Virtio-gpu cache permission issues in libvirt, works in plain qemu

I am using virt-manager.
libvirt is running a system daemon.
"ps  -ef | grep qemu" doesn't show the qemu, as the vm doesn't start, however there was a full command line in /var/log/libvirt/qemu:

2019-01-20 06:50:37.675+0000: starting up libvirt version: 4.9.0, qemu version: 3.1.0, kernel: 4.20.3-arch1-1-ARCH, hostname: ILYA-ARCH
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin QEMU_AUDIO_DRV=spice /usr/bin/qemu-system-x86_64 -name guest=fedora29,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-2-fedora29/master-key.aes -machine pc-q35-3.1,accel=kvm,usb=off,vmport=off,dump-guest-core=off -cpu host -drive file=/usr/share/ovmf/x64/OVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on -drive file=/var/lib/libvirt/qemu/nvram/fedora29_VARS.fd,if=pflash,format=raw,unit=1 -m 2048 -realtime mlock=off -smp 4,sockets=4,cores=1,threads=1 -uuid c74bbb1c-fdd6-4ac3-bf20-e6716155f67c -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=27,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -global ICH9-LPC.disable_s3=1 -global ICH9-LPC.disable_s4=1 -boot strict=on -device pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2 -device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 -device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 -device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 -device pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x4 -device pcie-root-port,port=0x15,chassis=6,id=pci.6,bus=pcie.0,addr=0x2.0x5 -device pcie-root-port,port=0x16,chassis=7,id=pci.7,bus=pcie.0,addr=0x2.0x6 -device qemu-xhci,p2=15,p3=15,id=usb,bus=pci.2,addr=0x0 -device virtio-serial-pci,id=virtio-serial0,bus=pci.3,addr=0x0 -drive file=/files/VM/fedora.qcow2,format=qcow2,if=none,id=drive-virtio-disk0 -device virtio-blk-pci,scsi=off,bus=pci.4,addr=0x0,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=2 -drive if=none,id=drive-sata0-0-0,media=cdrom,readonly=on -device ide-cd,bus=ide.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 -netdev tap,fd=29,id=hostnet0,vhost=on,vhostfd=30 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:8a:44:d2,bus=pci.1,addr=0x0 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,fd=31,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -chardev spicevmc,id=charchannel1,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=com.redhat.spice.0 -device usb-tablet,id=input0,bus=usb.0,port=1 -spice port=0,disable-ticketing,image-compression=off,gl=on,rendernode=/dev/dri/by-path/pci-0000:00:01.0-render,seamless-migration=on -device virtio-vga,id=video0,virgl=on,max_outputs=1,bus=pcie.0,addr=0x1 -device ich9-intel-hda,id=sound0,bus=pcie.0,addr=0x1b -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev spicevmc,id=charredir0,name=usbredir -device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=2 -chardev spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 -device virtio-balloon-pci,id=balloon0,bus=pci.5,addr=0x0 -object rng-random,id=objrng0,filename=/dev/urandom -device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.6,addr=0x0 -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on
2019-01-20 06:50:37.675+0000: Domain id=2 is tainted: host-cpu
char device redirected to /dev/pts/2 (label charserial0)
Failed to create //.cache for shader cache (Permission denied)---disabling.
2019-01-20 06:50:38.244+0000: shutting down, reason=failed

If any other logs are needed, I will provide them. This has happened only on this arch installation, the previous installation on the same machine had virtio-gpu working through the same setup.

Last edited by Boring_nick (2019-01-20 06:57:56)

bugsmanagement

Member

Registered: 2017-04-21

Posts: 201

Re: Virtio-gpu cache permission issues in libvirt, works in plain qemu

Hello,

Failed to create //.cache for shader cache

Out of curiosity, isn't this possibly the problem here?

Only information I could find online is this here and here.

I haven't tested 'virtio-gpu' myself and I'm not sure where the 'cache' is suppose to be created, does creating '/.cache' as the 'qemu' user; I suspect the 'user' would be your 'user' get you going?

Regards

P.S.

//

Looks suspicious to me. It seems like something suppose to in between //. There are no pointers here https://wiki.archlinux.org/index.php/QEMU#virtio.

dmartins

Member

Registered: 2006-09-23

Posts: 360

Re: Virtio-gpu cache permission issues in libvirt, works in plain qemu

The bit about the cache might just be a symptom of the problem. libvirt runs qemu as user 'nobody' by default. This user has / as their home directory, and no group memberships that would grant them extra access.

See if this makes any difference:
https://wiki.archlinux.org/index.php/PC … ion_issues

Boring_nick

Member

Registered: 2017-05-06

Posts: 20

Re: Virtio-gpu cache permission issues in libvirt, works in plain qemu

The bit about the cache might just be a symptom of the problem. libvirt runs qemu as user 'nobody' by default. This user has / as their home directory, and no group memberships that would grant them extra access.

See if this makes any difference:
https://wiki.archlinux.org/index.php/PC … ion_issues

Setting "Group" to "kvm" and "User" to my user in /etc/libvirt/qemu.conf gives me another error:

Error starting domain: internal error: qemu unexpectedly closed the monitor: spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 -device virtio-balloon-pci,id=balloon0,bus=pci.5,addr=0x0 -object rng-random,id=objrng0,filename=/dev/urandom -device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.6,addr=0x0 -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 75, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 111, in tmpcb
    callback(*args, **kwargs)
  File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 66, in newfn
    ret = fn(self, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/domain.py", line 1400, in startup
    self._backend.create()
  File "/usr/lib/python3.7/site-packages/libvirt.py", line 1080, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirt.libvirtError: internal error: qemu unexpectedly closed the monitor: spicevmc,id=charredir1,name=usbredir -device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 -device virtio-balloon-pci,id=balloon0,bus=pci.5,addr=0x0 -object rng-random,id=objrng0,filename=/dev/urandom -device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.6,addr=0x0 -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on

From what it seems, the spice monitor crashes, however I don't see any audible errors. My user is in groups kvm and libvirt. The vm doesn't have any special devices that aren't usable by non-root users.

Other manipulations with permissions and running libvirt as other users end up with similar results.

TheDarkCorner

Member

Registered: 2019-02-17

Posts: 1

Re: Virtio-gpu cache permission issues in libvirt, works in plain qemu

Hi!
I do have the very same problem, and it seems we are not alone.
As @bugsmanagement has pointed out before me, there is already a bug reported on the relevant Red Hat Bugzilla.
I did add my infos there too, and maybe you others could join me.

I am trying my best as a still very noobish Linux user (with only some months of intensive experience) to help pin down this issue, but in the (likely) case i missed something, reports from other affected Arch users would of course be very beneficial.

As far as i can tell (and as @Boring_nick can confirm too) this seems not to be a permissions issue.
The proposed fix by @dmartins does not work; it seems the underlying bug for this fix has already been patched some time ago.
The cause for this new issue seems to be unrelated.

So right now there seems to be no clear indication what exactly is the problem.

You can find the bug report here: https://bugzilla.redhat.com/show_bug.cgi?id=1659484

If someone wants to check my report and all relevant details: They can be found on the Bugzilla. If requested, i can post them here too, as well as further information.

Kind regards & happy hunting!

A still more happy than frustrated new Linux and Arch user