[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.