Bug 504637 - Fails to start when using SDL display
Fails to start when using SDL display
Product: Virtualization Tools
Classification: Community
Component: libvirt (Show other bugs)
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Daniel Veillard
Depends On:
  Show dependency treegraph
Reported: 2009-06-08 11:47 EDT by michael.leies
Modified: 2010-03-16 13:20 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-07-30 07:43:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
windows.xml - config for my guest (1.18 KB, text/plain)
2009-06-08 14:55 EDT, michael.leies
no flags Details
virt-manager shows SDL is configured (48.52 KB, image/png)
2009-06-08 15:18 EDT, michael.leies
no flags Details

  None (edit)
Description michael.leies 2009-06-08 11:47:54 EDT
Description of problem:

I've installed KVM and libvirt from debian packages, release Lenny, AMD_64

After installation all worked fine.   I switched my guest (Vista) to display in a SDL windows, and again all worked fine.   

Some days later I tried to run my guest again and I got the following error:

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/engine.py", line 531, in run_domain
  File "/usr/share/virt-manager/virtManager/domain.py", line 380, in startup
  File "/usr/lib/python2.5/site-packages/libvirt.py", line 262, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: internal error QEMU quit during console startup
No protocol specified
No protocol specified

     =======================|  DirectFB 1.0.1  |=======================
          (c) 2001-2007  The DirectFB Organization (directfb.org)
          (c) 2000-2004  Convergence (integrated media) GmbH

(*) DirectFB/Core: Single Application Core. (2008-08-17 14:50) 
(*) Direct/Memcpy: Using libc memcpy()
(!) Direct/Util: opening '/dev/fb0' and '/dev/fb/0' failed
    --> No such file or directory
(!) DirectFB/FBDev: Error opening framebuffer device!
(!) DirectFB/FBDev: Use 'fbdev' option or set FRAMEBUFFER environment variable.
(!) DirectFB/Core: Could not initialize 'system' core!
    --> Initialization error!
Could not initialize SDL - exiting

If I reinstall the libvirt packages, it will work again, but only for a short time.

I believe the problem has to do with the environment passed to Qemu.  If I run Qemu via the KVM command it will start up the SDL window, although I'm not doing something right when doing this as Vista doesn't boot properly and blue screens.  

I read that if SDL can find the DISPLAY variable then it trys the frame buffer.

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

Version identified in the Debian package 4.6-10

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:
Comment 1 Daniel Berrange 2009-06-08 11:51:35 EDT
Please provide the XML config you are using for your guest with SDL graphics
Comment 2 michael.leies 2009-06-08 14:55:55 EDT
Created attachment 346905 [details]
windows.xml - config for my guest
Comment 3 Daniel Berrange 2009-06-08 15:04:54 EDT
Ok, there is no display specified for the graphics tag here:

    <graphics type='sdl'/>

so SDL ends up falling back to trying the framebuffer.

You can explicitly set a display using display=XXX attribute, eg

   <graphics type='sdl' display=':0.0'/>

You may also need to add  xauth='/path/to/.Xauthority'  file to get permission to conenct
Comment 4 michael.leies 2009-06-08 15:18:37 EDT
Created attachment 346908 [details]
virt-manager shows SDL is configured
Comment 5 michael.leies 2009-06-08 15:21:14 EDT
Thanks.  After I inserted the graphics tag it works.   

Of note, virt-manager showed that the display was configured for SDL, see attached screen shot.  The screen shot was taken before I added the the graphics tag to the xml file.
Comment 6 Daniel Berrange 2009-07-30 07:43:45 EDT
Closed since this was just a mis-configuration not a libvirt bug

Note You need to log in before you can comment on or make changes to this bug.