Describe the issue
After updating UTM to 5.0.4 Beta, all Linux virtual machines configured with virtio-ramfb-gl display a completely white screen on an M2 Mac mini.
The virtual machines appear to start normally. The debug log shows that QEMU starts successfully, the SPICE display channel connects, a monitor is detected, and the GL scanout is received:
display-2:0: channel up, state 3
display-2:0: gl scanout fd: 40
[CocoaSpice] cs_gl_scanout: got scanout
received new monitors config from guest: n: 1/1
monitor id: 0, surface id: 0, +0+0-640x480
However, the VM window remains completely white.
Changing the display device from:
to:
immediately restores normal display output.
The generated QEMU command line for the affected configuration includes:
-device virtio-ramfb-gl,hostmem=8G,blob=true,venus=true,neptune=true
The environment also includes:
ANGLE_DEFAULT_PLATFORM=metal
NPT_BACKEND=dxmt
VK_DRIVER_FILES=/Applications/UTM.app/Contents/Resources/vulkan/icd.d/MoltenVK_icd.json
This may be related to the known limitation described in UTM 5.0.4 Beta:
Linux desktop rendering in Vulkan does not work due to lack of support for indirect draws for geometry shaders. Please configure your guest to use the older VirGL Gallium driver.
However, the VM shows a white screen from startup, and the current UTM interface does not appear to provide an obvious way to retain virtio-ramfb-gl while disabling Venus/Vulkan and using only the older VirGL Gallium path.
The issue affects multiple VMs after upgrading to UTM 5.0.4 Beta. The same VMs worked before the update.
Steps to reproduce
- Run UTM 5.0.4 Beta on an M2 Mac mini.
- Configure a Linux VM to use
virtio-ramfb-gl.
- Start the VM.
- Observe that the display window is completely white.
- Stop the VM and change the display device to
virtio-ramfb.
- Start the VM again.
- Observe that the display works normally.
Expected behavior
The Linux guest display should render normally when using virtio-ramfb-gl, or UTM should provide an option to use the older VirGL Gallium driver without enabling the currently unsupported Venus/Vulkan Linux desktop rendering path.
Actual behavior
The VM starts and the SPICE display channel receives a GL scanout, but the UTM display window remains completely white.
Workaround
Changing the display device to virtio-ramfb restores the display, but disables accelerated graphics.
Configuration
- UTM Version: 5.0.4 Beta
- macOS Version: [insert macOS version]
- Mac Chip: Apple M2, Mac mini
- Guest OS: UnionTech OS / UOS Linux
- Architecture: ARM64
- Virtualization backend: Apple Hypervisor Framework (
hvf)
- Display device:
virtio-ramfb-gl
- Working display device:
virtio-ramfb
Crash log
The application did not crash. QEMU remained running until the VM was manually stopped.
The debug log shows a normal host-requested shutdown:
Therefore, no crash report was generated.
Debug log
The full exported UTM debug log is attached as:
Relevant excerpts include:
-device virtio-ramfb-gl,hostmem=8G,blob=true,venus=true,neptune=true
display-2:0: channel up, state 3
display-2:0: gl scanout fd: 40
[CocoaSpice] cs_gl_scanout: got scanout
received new monitors config from guest: n: 1/1
monitor id: 0, surface id: 0, +0+0-640x480
There are no obvious QEMU crashes, Metal validation errors, or SPICE display connection failures after initialization.
Upload VM
no
Describe the issue
After updating UTM to 5.0.4 Beta, all Linux virtual machines configured with
virtio-ramfb-gldisplay a completely white screen on an M2 Mac mini.The virtual machines appear to start normally. The debug log shows that QEMU starts successfully, the SPICE display channel connects, a monitor is detected, and the GL scanout is received:
However, the VM window remains completely white.
Changing the display device from:
to:
immediately restores normal display output.
The generated QEMU command line for the affected configuration includes:
The environment also includes:
This may be related to the known limitation described in UTM 5.0.4 Beta:
However, the VM shows a white screen from startup, and the current UTM interface does not appear to provide an obvious way to retain
virtio-ramfb-glwhile disabling Venus/Vulkan and using only the older VirGL Gallium path.The issue affects multiple VMs after upgrading to UTM 5.0.4 Beta. The same VMs worked before the update.
Steps to reproduce
virtio-ramfb-gl.virtio-ramfb.Expected behavior
The Linux guest display should render normally when using
virtio-ramfb-gl, or UTM should provide an option to use the older VirGL Gallium driver without enabling the currently unsupported Venus/Vulkan Linux desktop rendering path.Actual behavior
The VM starts and the SPICE display channel receives a GL scanout, but the UTM display window remains completely white.
Workaround
Changing the display device to
virtio-ramfbrestores the display, but disables accelerated graphics.Configuration
hvf)virtio-ramfb-glvirtio-ramfbCrash log
The application did not crash. QEMU remained running until the VM was manually stopped.
The debug log shows a normal host-requested shutdown:
Therefore, no crash report was generated.
Debug log
The full exported UTM debug log is attached as:
Relevant excerpts include:
There are no obvious QEMU crashes, Metal validation errors, or SPICE display connection failures after initialization.
Upload VM
no