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
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users