Fedora25 3D-accelerated guest

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 qemu:///system and qemu:///session respectively.

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 qemu:///system.

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 virt-manager or 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 virtio video 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 autoport='yes'to autoport='no'.

These changes are all that is required for a qemu://session guest to get 3D acceleration.

Fixing permissions

For a 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 qemu:

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

The original problem is described in Red Hat Bugzilla 1337290. Reading information from Red Hat Bugzilla 1337333, which I reached from Red Hat Bugzilla 1364075, referred in Red Hat Bugzilla 1337290.

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-manager or 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 dmesg.

[ +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 !

Conclusion

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