Bug 536693

Summary: SDL does not work out of the box: Could not initialize SDL - exiting
Product: [Fedora] Fedora Reporter: Andrew McNabb <amcnabb>
Component: libvirtAssignee: Libvirt Maintainers <libvirt-maint>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 14CC: berrange, bfay, bos, clalance, crobinso, itamar, jforbes, maurizio.antillon, mbooth, pedemonte, soren, veillard, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-01-24 21:54:44 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
xml config file for the virtual machine
none
log file from /var/log/libvirt/qemu none

Description Andrew McNabb 2009-11-10 23:47:10 UTC
I started a virtual machine and got the following error:

"""
Error starting domain: internal error unable to start guest: char device redirected to /dev/pts/10
No protocol specified
No protocol specified
Could not initialize SDL - exiting

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/engine.py", line 571, in run_domain
    vm.startup()
  File "/usr/share/virt-manager/virtManager/domain.py", line 664, in startup
    self.vm.create()
  File "/usr/lib64/python2.6/site-packages/libvirt.py", line 293, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: internal error unable to start guest: char device redirected to /dev/pts/10
No protocol specified
No protocol specified
Could not initialize SDL - exiting
"""

Setting user="root" and group="root" in qemu.conf seems to work around the problem.  Please let me know if there is any other information I can provide.  Thanks.

Comment 1 Andrew McNabb 2009-11-10 23:47:36 UTC
By the way, this is with libvirt-0.7.1-15.fc12.x86_6.

Comment 2 Mark McLoughlin 2009-11-19 12:34:06 UTC
Thanks for the report

Could you include the guest XML for the guest and the log file from /var/log/libvirt/qemu ?

It sounds fairly similar to bug #528757

Comment 3 Andrew McNabb 2009-11-19 18:41:36 UTC
SELinux is disabled on this system, so it can't be the same problem.  I will attach the guest XML and the log file momentarily.

Comment 4 Andrew McNabb 2009-11-19 18:47:07 UTC
Created attachment 372313 [details]
xml config file for the virtual machine

Comment 5 Andrew McNabb 2009-11-19 18:49:25 UTC
Created attachment 372314 [details]
log file from /var/log/libvirt/qemu

Comment 6 Mark McLoughlin 2009-11-20 17:37:00 UTC
Ah, okay - you do actually have SDL configured:

  <graphics type='sdl' display=':0.0' xauth='/aml/home/amcnabb/.Xauthority'/>

(Incidentally, why? SDL is known to be buggy. We recommend people use VNC)

It sounds like you just need to make sure the qemu user can read the .Xauthority file ?

Could you change the permissions or use 'setfacl -m u:qemu:x' and confirm?

If that's the case, then it's expected really - getting the permssions right will be a required step for setting up SDL.

Comment 7 Andrew McNabb 2009-11-20 20:46:22 UTC
(In reply to comment #6)
> 
> (Incidentally, why? SDL is known to be buggy. We recommend people use VNC)

Why would you do that?  :)

Sound doesn't work with VNC, and SDL is faster (and in my experience less buggy).  But anyway, as long as sound doesn't work, VNC isn't even an option.


> It sounds like you just need to make sure the qemu user can read the
> .Xauthority file ?

Hmm.  I hadn't thought of that.  Since we can't make the qemu user read the .Xauthority without opening up all kinds of permissions problems, I guess the only option is to run libvirtd as root.


> Could you change the permissions or use 'setfacl -m u:qemu:x' and confirm?

I'm not experienced with setfacl, so I might be doing this wrong:

amcnabb@prodigy:~% setfacl -m u:qemu:x .Xauthority
setfacl: .Xauthority: Operation not supported


> If that's the case, then it's expected really - getting the permssions right
> will be a required step for setting up SDL.  

It would at least be nice if the error was "User qemu could not open .Xauthority: permission denied" or something like that.  Thanks.

Comment 8 Matthew Booth 2009-12-03 16:50:02 UTC
I can't make this work either. Domain contains:

    <graphics type='sdl' display=':0.0' xauth='/var/run/gdm/auth-for-mbooth-ZCKyMu/database'/>

If that xauth looks weird, looks like it's normal for F12:
[mbooth@t500 ~]$ echo $XAUTHORITY 
/var/run/gdm/auth-for-mbooth-ZCKyMu/database
[mbooth@t500 ~]$ echo $DISPLAY
:0.0

Error message at startup is:
[root@t500 ~]# virsh start rawhide
error: Failed to start domain rawhide
error: internal error unable to start guest: char device redirected to /dev/pts/1
No protocol specified
No protocol specified
Could not initialize SDL - exiting

SELinux is in permissive mode. setfacl run on xauth file as above.

Comment 9 Cole Robinson 2010-07-12 17:06:18 UTC
Using setfacl actually does help solve this issue, but we need to run

setfacl -m u:qemu:r .Xauthority

NOT -m u:qemu:x   . Execute permission doesn't matter here. I put some docs up on the fedora wiki about making SDL work:

https://fedoraproject.org/wiki/How_to_debug_Virtualization_problems#SDL_Graphics

There are two issues preventing this from 'Just Work'ing:

- Selinux preventing emulator from accessing .Xauthority: https://bugzilla.redhat.com/show_bug.cgi?id=609279

We probably can't svirt relabel this file, so maybe something like Dan's suggestion in that bug: iff the guest needs SDL, we label it with svirt_with_xserver_t or similar.

- qemu emulator user needs read access to .Xauthority file

This doesn't really fit the current libvirt permissioning model, which only changes file ownership. Not really sure what to do here.

Comment 10 Daniel Berrangé 2010-07-12 17:30:46 UTC
I have dodgy code to switch to using ACLs instead of ownership for the QEMU security driver. That could easily cope with Xauth too

Comment 11 Soren Hansen 2010-09-20 10:18:19 UTC
The guest doesn't really need access to the user's XAuthority, afaics. It just needs a cookie for the current $DISPLAY. What if we added a generic method to pass credentials to a guest and let it accept X cookies? virt-manager and virt-viewer could be taught to pass a cookie to the guest before spawning it.

Comment 12 Bug Zapper 2010-11-04 06:34:48 UTC
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 13 Andrew McNabb 2010-11-04 20:22:35 UTC
In Fedora 14, I still can't get libvirtd to work with SDL, and now setting user="root" in qemu.conf no longer helps.  The backtrace I'm getting is in bug #635328.

Comment 14 Fedora Admin XMLRPC Client 2011-09-22 17:56:35 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 15 Fedora Admin XMLRPC Client 2011-09-22 17:59:51 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 16 Fedora Admin XMLRPC Client 2011-11-30 19:56:05 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 17 Fedora Admin XMLRPC Client 2011-11-30 19:59:20 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 18 Fedora Admin XMLRPC Client 2011-11-30 20:02:20 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 19 Fedora Admin XMLRPC Client 2011-11-30 20:03:24 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 20 Cole Robinson 2012-01-24 21:54:44 UTC
F14 is EOL, please reopen if this is still relevant in a more recent fedora.