Bug 1656895

Summary: Libvirt fails to start a VM using SPICE graphics with OpenGL turned off with error "No DRM render nodes available"
Product: Red Hat Enterprise Linux 7 Reporter: Erik Skultety <eskultet>
Component: libvirtAssignee: Erik Skultety <eskultet>
Status: CLOSED NOTABUG QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.7CC: yafu
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-12-07 09:13:44 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Erik Skultety 2018-12-06 15:49:00 UTC
Description of problem:
Libvirt is trying to pick a default DRI renderer for SPICE even if the XML doesn't have OpenGL turned on using <gl enable='yes'/>. This is a problem on a headless server without DRI because it fails to start a domain which previously started just fine.

Version-Release number of selected component (if applicable):
libvirt-5.0.0

How reproducible:
100% if the host doesn't have DRI

Steps to Reproduce:
1. prepare a VM with the following in the XML:
  <graphics type='spice'>
    <listen type='none'/>
  </graphics>
2. rename all /dev/dri/renderDX devices (skip if your host doesn't have DRI)
3. start the VM using virsh

Actual results:
error: Failed to start domain f-live
error: internal error: No DRM render nodes available

Expected results:
The domain starts just fine.

Additional info:

Comment 1 Erik Skultety 2018-12-06 16:13:55 UTC
Patch proposed upstream:
https://www.redhat.com/archives/libvir-list/2018-December/msg00176.html

Comment 2 Erik Skultety 2018-12-07 09:13:44 UTC
I'm closing this as NOTABUG since the intended future version of libvirt (5.0.0) will have this fixed, so technically there wouldn't be an issue to reproduce. However, I'm moving the reproducer for test verification purposes to the BZ linked below.