quickemu
quickemu copied to clipboard
Issues with qemu 7.0 (archlinux)
Expected behaviour
Start the VM without any issue
Actual behaviour
It won't start
Steps to reproduce the behaviour
Start a VM with the defaults
Quickemu output
Quickemu 3.15 using /usr/bin/qemu-system-x86_64 v7.0.0
- Host: "EndeavourOS Linux" running Linux 5.17 (eosbox)
- CPU: Intel(R) Core(TM) i7-4500U CPU @ 1.80GHz
- CPU VM: 1 Socket(s), 1 Core(s), 2 Thread(s), 4G RAM
- BOOT: EFI (Linux), OVMF (/usr/share/OVMF/x64/OVMF_CODE.fd), SecureBoot (off).
- Disk: manjaro-gnome/disk.qcow2 (16G)
- Display: SDL, virtio-vga, GL (on), VirGL (on)
- ssh: On host: ssh user@localhost -p 22220
- SPICE: On host: spicy --title "manjaro-gnome" --port 5930 --spice-shared-dir /home/lorenzo/Pubblici
- WebDAV: On guest: dav://localhost:9843/
- 9P: On guest: sudo mount -t 9p -o trans=virtio,version=9p2000.L,msize=104857600 Public-lorenzo ~/Pubblici qemu-system-x86_64: Display spice is incompatible with the GL context cat: manjaro-gnome/manjaro-gnome.pid: No such file or directory
Linux Distribution & Kernel
LSB Version: n/a
Distributor ID: EndeavourOS
Description: EndeavourOS Linux
Release: rolling
Codename: rolling
Linux eosbox 5.17.5-arch1-1 #1 SMP PREEMPT Wed, 27 Apr 2022 20:56:11 +0000 x86_64 GNU/Linux
Hello there 👋 Thanks for submitting your first issue to the Quickemu project 🐛 We'll try and take a look at your issue soon ⏲
In the meantime you might want to join the Wimpys World Discord 🗣 where we have a large community of Linux 🐧 enthusiasts and passionate open source developers 🧑💻
You might also be interested in following Wimpys World Twitch 📡 channel where Wimpy streams let's code video, including this project, several times a week. A back catalog of past live stream and other Linux related content is available on Wimpys World YouTube 📺 channel.
Having the same issue. It seems perhaps the new version of qemu requires different arguments? I've tried with a bunch of my VMs that were all previously working, now none are working.
EDIT: Temporary workaround: edit the vmname.sh file in the vmname/ directory. Remove -device virtio-vga-gl,xres=1664,yres=936
and also remove ,gl=on
from the statement immediately afterward. The vm will launch, though it will not have GL acceleration.
EDIT: Temporary workaround: edit the vmname.sh file in the vmname/ directory. Remove
-device virtio-vga-gl,xres=1664,yres=936
and also remove,gl=on
from the statement immediately afterward. The vm will launch, though it will not have GL acceleration.
Thanks but I prefer to wait for a real fix. OpenGL acceleration with virgl (dev build) is pretty good on my system and I'm not in a hurry tbh
This issue made all my virtual machines totally unusable :/
The temporary workaround proposed by @MrAureliusR works for me but sadly the resolution and low speed makes de virtual machine difficult to use.
Anybody else knows a workaround?
Anybody else knows a workaround?
Using the spice-app
viewer is working on my PC.
In the script vmname.sh
replace:
-spice disable-ticketing=on,port=5930
-display sdl,gl=on
with:
-spice disable-ticketing=on,port=0
-display spice-app,gl=on
VM should start in virt-viewer
, the same viewer that virt-manager
uses.
BONUS:
if we add max_outputs=2
to virtio gpu like this:
-device virtio-vga-gl,xres=1152,yres=648,max_outputs=2
virt-viewer,
starts with two windows.
From my limited testing spice-app is the only viewer that works OK with multiple screens.
@MatejSpindler thanks it works :) sadly the gl acceleration seems not working :/ but it works a bit better than the other option above. Regarding the multiple screens, I've never experienced any issue running it in i3wm / swaywm. It might be that they handle the windows a bit different.
Anybody else knows a workaround?
Using the
spice-app
viewer is working on my PC.In the script
vmname.sh
replace:-spice disable-ticketing=on,port=5930 -display sdl,gl=on
with:
-spice disable-ticketing=on,port=0 -display spice-app,gl=on
VM should start in
virt-viewer
, the same viewer thatvirt-manager
uses.
Thanks but even after I edited the .sh script I will alway get the same error (do I have to pass a different option to the command line of quickemu?)
Thanks but even after I edited the .sh script I will alway get the same error (do I have to pass a different option to the command line of quickemu?)
After you edit the .sh script you have to run the edited script (don't forget to set executable bit for the file). Running quickemu after editing the file will overwrite the script with the default version.
I'm having this issue too. Also on EndeavourOS but on 5.17.9-arch1-1 kernel (although probably not relevant here :smile: )
From @MatejSpindler post above, changing -display sdl,gl=on
to -display spice-app,gl=on
, is it correct to assume that SDL2 is part of the problem here?
I tried downgrading SDL2 trying all versions as far back as 2.0.18-1 but to no avail. Pretty sure I have used quickemu later that that also so maybe it was a long shot. I'm poking around in the dark here, I might add. There's probably a lot lacking in my understanding of the problem :smile:
I ran into this yesterday. EndeavourOS with whatever the latest versions of qemu, quickemu etc. are. All my VMs, both existing and new, fail with the "qemu-system-x86_64: Display spice is incompatible with the GL context" message when I run them with the simple "quickemu --vm VMNAME.conf" command. The workaround posted above by @MatejSpindler works, but without GL acceleration, as reported by others.
Interestingly, if I launch quickemu with "quickemu --vm VMNAME.conf --display spice" (or --display spice-app), it DOES work. The VM launches normally in the specified spice client, and GL acceleration seems to be working. I haven't compared the resulting launch scripts because doing a diff of the massive oneliners is useless, and I didn't have time to reformat them to do a proper side-by-side comparison.
In summary, perhaps another workaround is to explicitly pass in the display type when launching.
quickemu already supports specifying a display backend. So you don't need to edit the shell scripts
--display : Select display backend. 'sdl' (default), 'gtk', 'none', 'spice' or 'spice-app'
Still having this issue, even with quickemu 4.0, though I'm now also getting an error about the .pid file not existing (am I supposed to manually create it? I kind of doubt it...) First run after freshly installing version 4.0 and using quickget to get openSUSE Tumbleweed:
$ quickemu --vm opensuse-tumbleweed.conf
Quickemu 4.0 using /usr/bin/qemu-system-x86_64 v7.0.0
- Host: "Arch Linux" running Linux 5.19 (archnitro)
- CPU: Intel(R) Core(TM) i5-9300H CPU @ 2.40GHz
- CPU VM: 1 Socket(s), 2 Core(s), 2 Thread(s), 8G RAM
- BOOT: EFI (Linux), OVMF (/usr/share/OVMF/x64/OVMF_CODE.fd), SecureBoot (off).
- Disk: opensuse-tumbleweed/disk.qcow2 (16G)
Looks unused, booting from opensuse-tumbleweed/openSUSE-Tumbleweed-DVD-x86_64-Current.iso
- Boot ISO: opensuse-tumbleweed/openSUSE-Tumbleweed-DVD-x86_64-Current.iso
- Display: SDL, virtio-vga, GL (on), VirGL (on)
- ssh: On host: ssh user@localhost -p 22220
- SPICE: On host: spicy --title "opensuse-tumbleweed" --port 5930 --spice-shared-dir /home/amr/Public
- WebDAV: On guest: dav://localhost:9843/
- 9P: On guest: sudo mount -t 9p -o trans=virtio,version=9p2000.L,msize=104857600 Public-amr ~/Public
- smbd: On guest: smb://10.0.2.4/qemu
- Monitor: On host: nc -U "opensuse-tumbleweed/opensuse-tumbleweed-monitor.socket"
or : socat -,echo=0,icanon=0 unix-connect:opensuse-tumbleweed/opensuse-tumbleweed-monitor.socket
- Serial: On host: nc -U "opensuse-tumbleweed/opensuse-tumbleweed-serial.socket"
or : socat -,echo=0,icanon=0 unix-connect:opensuse-tumbleweed/opensuse-tumbleweed-serial.socket
qemu-system-x86_64: Display spice is incompatible with the GL context
cat: opensuse-tumbleweed/opensuse-tumbleweed.pid: No such file or directory
- Process: Starting opensuse-tumbleweed.conf as opensuse-tumbleweed ()
---
Kind of sad this still isn't working. I have just gone back to manually starting qemu as I did before, but using quickemu was so nice as it just had sane defaults. But it seems like it just won't work with archlinux and/or qemu 7.0?
Can those of you with system running Qemu 7.0 confirm if either of the following work for you:
quickemu --vm myvm.conf --display spice
quickemu --vm myvm.conf --display spice-app
Can those of you with system running Qemu 7.0 confirm if either of the following work for you:
quickemu --vm myvm.conf --display spice
quickemu --vm myvm.conf --display spice-app
quickemu --vm myvm.conf --display spice
Is working
quickemu --vm myvm.conf --display spice
Is not working
For me,
quickemu --vm myvm.conf --display spice
works,
quickemu --vm myvm.conf --display spice-app
errors out with ERROR! Requested output 'spice-app' is not recognised.
Can those of you with system running Qemu 7.0 confirm if either of the following work for you:
quickemu --vm myvm.conf --display spice
quickemu --vm myvm.conf --display spice-app
Both work here on arch, qemu 7.0 and quickemu 4.0
When testing can we also post the quickemu version:
quickemu --version
4.0
Excellent. Then we have workarounds depending on if you have spicy
(--display spice
) or virt-viewer
(--display spice-app
)installed.
Out of interest does this work:
quickemu --vm myvm.conf --display gtk
Out of interest does this work:
quickemu --vm myvm.conf --display gtk
Yes it does, also running quickemu v4.0
Do you have the qemu-ui-sdl package installed?
yes
And usr/lib/qemu/ui-sdl.so
is present on the filesystem?
Yes
And using --display sdl
does not work?
Yes using --display sdl
does not work.
Please can you try adding each of these options to your VM config file:
-
gl=core
-
gl=es
-
gl=off
-
gl=on
...and let me know which of the above work with --display=sdl
.
Only gl=off
works
Thanks to all of you for helping debugging this issue :+1:
I think we have demonstrated this is a bug in qemu
in Arch Linux.
- You have the appropriate backend (
qemu-ui-sdl
) installed. - We've checked the shared object (
/usr/lib/qemu/ui-sdl.so
) is in the right place on the file system. - We've proven the other backends (gtk, spice, spice-app) are all working correctly.
- We've discovered the SDL backend only works when GL is disabled.
Sorry, but I am going to close this issue as I do not believe this is a bug in Quickemu. I suggest you raise a bug against qemu-ui-sdl in Arch Linux stating the GL acceleration does not work.
Until the SDL render in Arch Linux is fixed I suggest Arch Linux users use one of the alternate display renders when using Quickemu:
-
--display gtk
(requiresqemu-ui-gtk
to be installed) -
--display spice
(requiresqemu-ui-spice-core
andspice-gtk
to be installed) -
--display spice-app
(requiresqemu-ui-spice-app
andvirt-viewer
to be installed)
I experienced the problem in gentoo. 7.0 qemu.
On Thu, Aug 18, 2022, 2:00 PM Martin Wimpress @.***> wrote:
Thanks to all of you for helping debugging this issue 👍
I think we have demonstrated this is a bug in qemu in Arch Linux.
- You have the appropriate backend (qemu-ui-sdl) installed.
- We've checked the shared object (/usr/lib/qemu/ui-sdl.so) is in the right place on the file system.
- We've proven the other backends (gtk, spice, spice-app) are all working correctly.
- We've discovered the SDL backend only works when GL is disabled.
Sorry, but I am going to close this issue as I do not believe this is a bug in Quickemu. I suggest you raise a bug against qemu-ui-sdl in Arch Linux stating the GL acceleration does not work.
- https://bugs.archlinux.org/?project=1&string=qemu-ui-sdl
Until the SDL render in Arch Linux is fixed I suggest Arch Linux users use one of the alternate display renders when using Quickemu:
- --display gtk (requires qemu-ui-gtk to be installed)
- --display spice (requires qemu-ui-spice-core and spice-gtk to be installed)
- --display spice-app (requires qemu-ui-spice-app and virt-viewer to be installed)
— Reply to this email directly, view it on GitHub https://github.com/quickemu-project/quickemu/issues/466#issuecomment-1219778127, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCQZ55S766J4QGY2CT55F3VZZ22JANCNFSM5VODQMSQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>
--display spice-app
(requiresqemu-ui-spice-app
andvirt-viewer
to be installed)
--display spice-app
does not work.
Only --display spice
and --display gtk
work
Reopening to continue the discussion.
- @bigdiff There are reports that
spice-app
works with Qemu 7.0 on Arch Linux - @PloniAlmoni As you are seeing this on Gentoo, maybe more research is required. Perhaps to determine if this is a bug/regression in Qemu itself?
It is possible I could change the default renderer in Quickemu to --display gtk
, but that needs testing because I found the GTK render to have some other issues which prevented it from working reliably for everyone.
When I create a local repo in Gentoo with the old now-removed QEMU 6.20 I think, everything works fine, when I use the 7.0 version now in Portage, I have issues. To my knowledge all other libraries are similar in each case.
This is with an old quickemu, the one in Guru.
I think I have found a solution. Please try adding the following options to Quickemu when launching the VM.
--extra_args "-vga none" --display sdl
You should see this is the Quickemu status messages:
- Display: SDL, virtio-vga, GL (on), VirGL (on)
Adding -vga none
prevents having two scanouts, one for VGA and another for virtio-vga-gl. Even if this doesn't work for SDL, it does look like a solution for the GTK display when using VirGL; something I have not got working previously due to a GTK assertion failure in gtk_widget_get_realized()
.
I tried this command
quickemu --extra_args "-vga none" --display sdl --vm ubuntu-22.04.conf
and as you said the status message looks like this.
- Display: SDL, virtio-vga, GL (on), VirGL (on)
But the VM does not start.
I've built QEMU 7.0 for Ubuntu 22.04 and am now unable to use SDL or GTK displays. This looks like a bug in QEMU:
- https://gitlab.com/qemu-project/qemu/-/issues/1036
I may have found a workaround.
With QEMU 7.0 you can not enable GL acceleration with GTK/SDL and enable SPICE simultaneously.
Some initial testing suggests that when GTK or SDL are used, preventing SPICE from being brought up solves the problem. More testing required....