Re: [Xen-users] VNC console access in paravirtualized domUs

[Paul Schulze <avlex@xxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 19.06.2008 um 09:54 schrieb Ray Barnes:

> Per my last post in this thread, I came to the same conclusion you  
> did (that Etch wouldn't have the framebuffer stuff in the kernel)  
> so I subsequently tried Lenny and Sid.  I found that the modules  
> for something called "vfb" in Sid, but they won't load.  Adding  
> "video=xenfb" to the kernel parameters is of none effect either; I  
> still get "XENBUS: Device with no driver: device/vfb/0" in the  
> kernel messages (and no /dev/fb0 either).  Ubuntu Hardy is a little  
> different story.  It generates the /dev/fb0 and seems to act right,  
> it just won't send anything to VNC.  Even with "console=xvc  
> console=tty" in the kernel args, I get a black VNC screen that's  
> sized appropriately, but no text.  Still trying to ascertain what,  
> if anything, this has to do with Xorg.
> I'm hoping someone will fix this; it sure would be nice to have.
>
> -Ray
The vfb.ko module has nothing to do with Xen as far as I know. That  
is only a dummy module, used for development and testing. What you  
need is the Xen framebuffer, you can check which Xen components are  
in your DomU's kernel by simply using: "grep 'XEN' /boot/config-$ 
(uname -r)". You'll want to look for XEN_FRAMEBUFFER in this  
particular case (I think that was it).
For your Hardy DomU, the only thing I can tell you is that this has  
nothing to do with Xorg, since it isn't even installed. It is simply  
a matter of the kernel not sending the console data to the  
appropriate device, though I can't tell you why or how to make it  
work. The best thing would probably be to compare the boot cycle  
(kernel, patches, kernel options, modules, /etc/modu*, etc.) to a  
system where it works. You could also try to play with the vga  
command line option (if it's supported by the kernel), because I  
think the default Hardy Server kernel doesn't use the framebuffer at  
all. Thats just a hunch though, no clue if I'm right there, since I'm  
pretty new to Xen myself.

Paul.

- --
Paul Schulze
avlex@xxxxxxx
Public Key: http://solaris-net.dyndns.org/keys/key_avlex.asc

"Making mistakes is human,
but to really fuck things up you need Computers"


> > On Wed, Jun 18, 2008 at 10:15 AM, Mike Lovell <mike@xxxxxxxxxxxx>  
> > wrote:
> > I have seen this problem on a setup that I did with debian etch.  
> > Unfortunately, I didn't spend enough time with it to see if this  
> > is a solution since I didn't need a graphical console anyways.
> > Are you using the xen kernel that is available in the debian etch  
> > repositories? If so, that might be your problem. The kernel there  
> > (2.6.18-4-xen-686) is one that was build with xen 3.0.3 which did  
> > not have the vfb capabilities. The 3.0.4 release did. So the  
> > kernel doesn't have a way to do a graphical console. I would try  
> > building the linux kernel with the 3.2.0 patch set and using that  
> > for the domu. (http://bits.xensource.com/oss-xen/release/3.2.0/ 
> > linux-2.6.18-xen-3.2.0.tar.gz). I started to try that on my set up  
> > but didn't have enough time to fully explore the possibility.
> > I might be completely off on this since I am definitely not a xen  
> > expert but it seems like a logical explanation.
> > Mike
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-users
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFIWmcvYDWOGtiChoARAhiaAJ4qcytGd6jDNWyHoDNCDWhnU/iPuQCeKMQp
cY8lV+8sGiuFZELvEwpPdYw=
=4aBQ
-----END PGP SIGNATURE-----

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