If you want to create a 3D-accelerated on Fedora25, you still have to follow a few special steps today. It is possible that many of these steps will no longer be necessary in Fedora 26, so this post may have a short useful lifetime. In the meantime…
System or User session?
When you create a guest under KVM/QEMU, you can use either a system session or a user session. They show up in different sections in
virt-manager. On the command line, they are identified with
For 3D-accelerated guests, this choice is important, because there is a small trade-off. User session guests are slightly easier to setup, but they lack one feature that I personally need for my guests: easily setup bridged networking, i.e. the ability to easily access the guest over the network from outside your host. In theory, it should be possible, but quite frankly, I’ve not been successful so far. So if you need to access your guest from outside, you probably want to create a guest with
The downside, however, is that setting up 3D acceleration for the guest is slightly more complicated if you use
qemu:///system. Unlike bridged networking for user-session guests, I managed to get that working, so this is what I’m sharing here.
Creating the guest
You can create the Fedora 25 guest in a number of ways, either using
virsh define. I used
virt-manager with default settings. Then I ran the installer and completed it before I enabled 3D acceleration. There is more than one way to do it.
Enabling 3D acceleration
By default, 3D acceleration is not enabled in the guest. To enable it, you must edit the configuration file (for example using
virsh edit) and perform two small changes:
- You need to add a
virtiovideo device to your virtual machine instead of QXL.
<video> <model type='virtio' heads='1'> <acceleration accel3d='yes'/> </model> </video>
- Then you need to enable OpenGL on your SPICE graphics node:
<graphics type='spice' autoport='no'> <gl enable='yes'/> </graphics>
You don’t need any port/address as they won’t be usable with GL for the moment. If you define one, KVM/QEMU issues an error message at boot. You have to make sure that the section does no longer
to non-local address, and to change
These changes are all that is required for a
qemu://session guest to get 3D acceleration.
qemu:///system device, the changes in the previous section are not sufficient. You also have to make sure that user
qemu can access your
/dev/dri rendering interface. That’s because system VMs run under this
qemu user. The
/dev/dri interface is owned by
root:video, so adding user
qemu to the
video group gives the correct access to
usermod -a -G video qemu
But that’s still not sufficient. After this change, I still have an issue opening the EGL render.
Error starting domain: internal error: process exited while connecting to monitor: 2017-04-06T09:19:07.265013Z qemu-system-x86_64: egl: no drm render node available 2017-04-06T09:19:07.265115Z qemu-system-x86_64: Failed to initialize EGL render node for SPICE GL
Updating qemu configuration
The solution to this second issue is suggested in this comment.
You need to edit /etc/libvirt/qemu.conf to add access to /dev/dri/renderD128:
cgroup_device_acl = [ "/dev/null", "/dev/full", "/dev/zero", "/dev/random", "/dev/urandom", "/dev/ptmx", "/dev/kvm", "/dev/kqemu", "/dev/rtc","/dev/hpet", "/dev/vfio/vfio", "/dev/dri/renderD128" ]
Now guest is booting and sees the accelerated 3D interface:
[ddd@f25-shuttle ~]$ dmesg | grep drm [ 22.531176] [drm] Initialized [ 22.938684] [drm] pci: virtio-vga detected at 0000:00:02.0 [ 22.939198] [drm] virgl 3d acceleration enabled [ 22.939972] [drm] virtio vbuffers: 288 bufs, 192B each, 54kB total. [ 22.940246] [drm] number of scanouts: 1 [ 22.940255] [drm] number of cap sets: 1 [ 22.947790] [drm] cap set 0: id 1, max-version 1, max-size 308 [ 22.969754] virtio_gpu virtio0: fb0: virtiodrmfb frame buffer device [ 22.975394] [drm] Initialized virtio_gpu 0.0.1 0 on minor 0
Still experimental – YMMV
While the setup described here lets you boot 3D-accelerated guests, whether the guests actually run and run well still depends a lot on the graphic card and driver involved. For example, with this setup, I was able to run a 3D accelerated guest on recent NVIDIA cards, but other configurations did not work.
Older NVIDIA cards: video bugs
For example, an older GTX-580 shows a number of video artefacts:
Interestingly, the problems are only visible through
virt-viewer. If you enable screen sharing in the guest and connect remotely to it with VNC, then the picture looks OK.
I need to check with various drivers to see if this makes a difference, but that specific machine corrupted its filesystem, so this is on hold.
AMD FireGL V7900: No go
On an AMD graphic card, things are even worse:
In that setup, I also see a number of errors reported by
[ +0.000004] radeon 0000:01:00.0: evergreen_cs_track_validate_texture:831 texture invalid 0x1dfc3bc1 0x40000437 0x060a0000 0x00000000 0x80000000 0x800304da [ +0.000033] [drm:radeon_cs_ioctl [radeon]] *ERROR* Invalid command stream !
It is possible to get 3D accelerated system guests working in Fedora 25. This still requires a little bit of ad-hockery (permissions and QEMU configuration file), and a little bit of luck (having a graphic card that supports it).