Re: [Xen-users] how to start X in the guest domain

[Matthew Haas <haas@xxxxxxxxxxxxxx>]

Good day,

 I had stumbled upon the post regarding the Xen 3.0.4 framebuffer 
support in domU, and have been trying to set it up to try some things out.
 I am interested in setting up a situation where X is running on the 
domU (a paravirtualized Linux guest), in a way where a user can sit down 
in front of the machine running the domU and use the monitor, keyboard, 
and mouse that is directly attached to the machine.
 Can I assume this sort of functionality is possible with the 3.0.4 
framebuffer support? Or am I more interested in playing around with the 
pciback.hide functionality (which I have also experimented with)?
 So far, according to the informal HOWTO as laid out by Mark Williamson 
on January 4th, 2007, as seen here:
http://lists.xensource.com/archives/html/xen-users/2007-01/msg00106.html

 I have done the following:

 - recompiled my kernel to include the various Xen & framebuffer bits
   that were specified in follow-up messages in that thread (I've
   attached a gzip'ed copy of my kernel config to this message).

   Additionally, I should note I am attempting this with a combined
   kernel (ie 1 kernel for dom0/domU, instead of separate kernels for
   dom0 and domU... if this is problematic, let me know and I can
   revert).

 - I have made the following change to xen-3.0.4_1-src/Config.mk:

        XENFB_TOOLS ?= y     (from its default of "n")

   And have done:

        make tools
        make install-tools

 - On the dom0, I have made the following changes to the domU config:

        extra = 'xencons=ttyS0 console=ttyS0 video=xenfb'
        vfb = ['type=sdl']

   Again, I am using the same kernel as I am on the dom0, because I have
   compiled in support for both dom0 and domU things (frontend/backend,
   etc.).

   I will say that the presence of the vfb line currently seems
   counter-intuitive to what I am trying to accomplish, as I would like
   the domU to take over the real console of the system (in place of the
   dom0 console -- in the long run I am just going to be ssh'ing in to
   the dom0).

   Yet, I have also tried replacing the vfb line with:

        vfb = ['type=xenfb']

   And this is not a recognized type.

   Am I misinterpreting the functionality of this line?

   I would think it is saying where to send the output of the virtual
   frame buffer, which ends up being to the real frame buffer but
   assigned to the domU.

 - I have removed all pciback.hide parameters from the dom0 kernel
   arguments in grub. I was successful in earlier attempts (before I
   learned how of 3.0.4's paravirt framebuffer support) to get the dom0
   to hide the framebuffer from it, and when I fired up the domU it the
   main display would come back to life (although, it would then only
   display the console of the dom0, curiously enough, which obviously
   isn't what I'm after). It also seems 3.0.4 doesn't support the
   pciback.permissive argument to the kernel as some of the xen-unstable
   trees do. But this is more of an aside.

   Just clarifying that I am not currently hiding any devices from the
   dom0. If I need to, let me know and I'll restore the argument.

 And, after doing all this, I can get the domU to start up, but see 
nothing that indicates it is even trying to gain control of the local 
display (it does look like the frame buffer functionality is alive and 
well, as I see it kick over during the kernel boot process of the dom0). 
Any ideas of what I could do to achieve my desired functionality 
(assuming what I'm after is even possible)?
 My goal is for the dom0 to be more of a management interface to the 
machine, inaccessible to the regular users (I plan on running the 
above-mentioned domU so users can perform some graphics work (and is 
remotely accessible via ssh)), but also have an additional domU for 
purely remote computational work.
 The environment is a cluster, so ultimately I am looking to implement 
this across 16 machines which will be running MPI jobs as well as the 
desired graphic work (I will admit I am ultimately interested in getting 
direct rendering support up and running to access the hardware 
accelerated features for OpenGL work, but I'm hoping first for simple X 
display on the domU on the local monitor). I am currently testing on a 
machine with an ATI Rage 128 card, but the machines in question have ATI 
Radeon 9550 cards.
 And suggestions, pointers, advice would be greatly appreciated. Until 
then, I will continue to scour google and the mailing list archives for 
any additional hints.
 Thanks for your time.

-Matthew
--
 Matthew Haas
 Visiting Instructor
 Corning Community College
 Computer & Information Science
 http://lab46.corning-cc.edu/haas/home/

  "Writing should be like breathing;
   It is one of those important things we do." -- me

Attachment: config-2.6.16.33-xen-mth-20070221.gz
Description: GNU Zip compressed data

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users