Xen users - Jun 2008 - VNC console access in paravirtualized domUs

Hi all.  In my CentOS 5.1 domUs, I add the following to the config file:

vfb = [
''type=vnc,vnclisten=0.0.0.0,vncdisplay=1,vncpasswd=somepass'' ]

at which point console output will default to vnc (assuming I remove
the "console=xvc0" argument from the kernel line in grub).  To enable
interactive logon I''d just add another line into /etc/inittab for the
vnc console.  On Debian Etch (2.6.18-4-xen-686) I''m trying to
accomplish the same thing but without any success.  When I launch the
domU and hit the VNC server, it simply says "parallel0 console" but
does not output anything else.  I''ve tried poking around in /dev and
it does not appear that the vfb gets a separate device as it would
under CentOS.  Google is also not very helpful in this regard, the
only thing remotely relevant (which doesn''t solve my problem) is
http://lists.xensource.com/archives/html/xen-users/2008-04/msg00686.html.
 dom0 is Cent 5.1 with Xen 3.2.1 compiled from source.

Any idea what I should be doing to get debian to work?  And on a
related note, Ubuntu 7.10 appears to do what I want by default (I
haven''t tested it yet - I gather that from google), but is there
anything I should know about for Ubuntu 7.04?

-Ray

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

On Thursday June 05 2008 04:38:05 am Ray Barnes wrote:
> Hi all.  In my CentOS 5.1 domUs, I add the following to the config file:
>
> vfb = [
''type=vnc,vnclisten=0.0.0.0,vncdisplay=1,vncpasswd=somepass'' ]
>
> at which point console output will default to vnc (assuming I remove
> the "console=xvc0" argument from the kernel line in grub).  To
enable
> interactive logon I''d just add another line into /etc/inittab for
the
> vnc console.  On Debian Etch (2.6.18-4-xen-686) I''m trying to
> accomplish the same thing but without any success.  When I launch the
> domU and hit the VNC server, it simply says "parallel0 console"
but
> does not output anything else.  I''ve tried poking around in /dev
and
> it does not appear that the vfb gets a separate device as it would
> under CentOS.  Google is also not very helpful in this regard, the
> only thing remotely relevant (which doesn''t solve my problem) is
> http://lists.xensource.com/archives/html/xen-users/2008-04/msg00686.html.
>  dom0 is Cent 5.1 with Xen 3.2.1 compiled from source.
Did you read all of that thread?:
> Try type <ctrl>-<alt>-1. You accidentally have gotten into the
monitor mode
> of qemu-dm.


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

On Thu, Jun 5, 2008 at 5:26 AM, jim burns <jim_burn@bellsouth.net>
wrote:
> On Thursday June 05 2008 04:38:05 am Ray Barnes wrote:
>> Hi all.  In my CentOS 5.1 domUs, I add the following to the config
file:
>>
>> vfb = [
''type=vnc,vnclisten=0.0.0.0,vncdisplay=1,vncpasswd=somepass'' ]
>>
>> at which point console output will default to vnc (assuming I remove
>> the "console=xvc0" argument from the kernel line in grub). 
To enable
>> interactive logon I''d just add another line into /etc/inittab
for the
>> vnc console.  On Debian Etch (2.6.18-4-xen-686) I''m trying to
>> accomplish the same thing but without any success.  When I launch the
>> domU and hit the VNC server, it simply says "parallel0
console" but
>> does not output anything else.  I''ve tried poking around in
/dev and
>> it does not appear that the vfb gets a separate device as it would
>> under CentOS.  Google is also not very helpful in this regard, the
>> only thing remotely relevant (which doesn''t solve my problem)
is
>>
http://lists.xensource.com/archives/html/xen-users/2008-04/msg00686.html.
>>  dom0 is Cent 5.1 with Xen 3.2.1 compiled from source.
>
> Did you read all of that thread?:
Sure, did you read mine?  I believe I said something about "without
any success".
>
>> Try type <ctrl>-<alt>-1. You accidentally have gotten into
the monitor mode
>> of qemu-dm.
It didn''t do anything; console still says "parallel0
console".  It
doesn''t spawn a login prompt and it doesn''t echo anything I
type.

-Ray

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

On Thu, Jun 5, 2008 at 5:49 PM, jim burns <jim_burn@bellsouth.net>
wrote:
> Now I know how far you got. Maybe vnc doesn''t have anything to
say, because of
> a mis-configuration of the frame buffer. I''m not sure how you
created the
> domu, but on CentOS dom0 and with virt-manager, it should have set that up
> for you correctly. Since this is Debian w/xen 3.2.1, double check your
domu''s
> xorg.conf. (ssh into the domain, or shut it down and mount it.) Modern xens
> (since 3.1.2) use the video device ''fbdev''. Check your
/var/log/Xorg.0.log
> before and after any changes. Hope that was more helpful.
>
Thanks Jim.  I have no xorg.conf:

debian:/dev# find / -print|grep -i xorg
debian:/dev#

I''m also trying to figure out what bearing xorg has on this, being
paravirtualized.  Are you saying that xorg is mandatory in order to
receive the text output of the console via VNC?  For absolute clarity,
I have no interest in running X or VNC on the domU.  Although I did
install it via ''apt-get -y install xorg'' I could find no
reference to
fbdev in xorg.conf.  Are there alternatives, i.e. backported kernels
from Lenny/Sid?

-Ray

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

On Thursday June 05 2008 11:35:48 pm Ray Barnes wrote:
> Thanks Jim.  I have no xorg.conf:
>
> debian:/dev# find / -print|grep -i xorg
> debian:/dev#
Probably a ''chicken or the egg'' problem - you probably
don''t get
an /etc/X11/xorg.conf until you have a desktop you can run display device 
configuration from :-) This is usually handled by your domu installer.
> I''m also trying to figure out what bearing xorg has on this, being
> paravirtualized.  Are you saying that xorg is mandatory in order to
> receive the text output of the console via VNC?  For absolute clarity,
> I have no interest in running X or VNC on the domU.  Although I did
> install it via ''apt-get -y install xorg'' I could find no
reference to
> fbdev in xorg.conf.  Are there alternatives, i.e. backported kernels
> from Lenny/Sid?
Vnc itself requires some sort of frame buffer device, which is only supported 
in X. It''s not a pv or hvm thing - it''s a virtual device
thing.

Now if you only want text output, all you need is ''xm create -c
dom.cfg''. If
you want the boot message output, you probably want to put back 
the ''console=xvc0'' clause. Where you put this depends on your
cfg''s kernel=
parm. If you have ''kernel=''/usr/bin/pygrub'', you want
it in your
domu''s /boot/grub/grub.conf (or menu.lst for SuSE) at the end of the
''kernel''
line. If you have kernel=path-to-kernel-in-dom0, you want it in the extra= 
parm of your domu''s .cfg. (If you are trying to boot a 2.6.24 or higher
kernel, this becomes hvc0 instead of xvc0. My Fedora 9 pv is pretty good 
about knowing the default, tho''.)

Additionally, if you want to log in after the boot messages, you need a getty 
running on xvc0 (or hvc0). In the domu''s /etc/inittab, near the end in
the
getty section, I have co:2345:respawn:/sbin/agetty xvc0 9600 vt100-nav, and 
the xvc0 device has to be listed in /etc/securetty. Personally, tho'' I
just
use ssh to log in to the domu, since it adapts to my terminal size better.

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

On Fri, Jun 6, 2008 at 5:33 AM, jim burns <jim_burn@bellsouth.net> wrote:
> Probably a ''chicken or the egg'' problem - you probably
don''t get
> an /etc/X11/xorg.conf until you have a desktop you can run display device
> configuration from :-) This is usually handled by your domu installer.
I get one upon ''apt-get -y install xorg'' but no mention of
"fbdev" therein.
> Vnc itself requires some sort of frame buffer device, which is only
supported
> in X. It''s not a pv or hvm thing - it''s a virtual device
thing.
Got it.  How to go about that under Debian is another story.
>
> Now if you only want text output, all you need is ''xm create -c
dom.cfg''. If
> you want the boot message output, you probably want to put back
> the ''console=xvc0'' clause. Where you put this depends on
your cfg''s kernel> parm. If you have
''kernel=''/usr/bin/pygrub'', you want it in your
> domu''s /boot/grub/grub.conf (or menu.lst for SuSE) at the end of
the ''kernel''
> line. If you have kernel=path-to-kernel-in-dom0, you want it in the
extra> parm of your domu''s .cfg. (If you are trying to boot a 2.6.24
or higher
> kernel, this becomes hvc0 instead of xvc0. My Fedora 9 pv is pretty good
> about knowing the default, tho''.)
The tip about hvc0/xvc0 was helpful in getting Debian Lenny going; for
grins I decided to spin an image of Lenny to assist in
troubleshooting.  Regarding the framebuffer (using Lenny for
reference), I''ve got the xorg fbdev package installed.  I''ve
added a
section to xorg.conf like:

Section "Device"
         Identifier "vnctest"
         Driver "fbdev"
EndSection

But as far as I can tell, the issue is that the domU does not expose
the framebuffer to the dom0:

XENBUS: Device with no driver: device/vkbd/0
XENBUS: Device with no driver: device/vfb/0
XENBUS: Device with no driver: device/console/0

I believe that''s why I see "parallel0 console" in VNC.  There
is no
/dev/fb0 on the domU (docs make reference to this; I''ve got to believe
udev would throw it up if it were configured properly).  Any ideas
there?
>
> Additionally, if you want to log in after the boot messages, you need a
getty
> running on xvc0 (or hvc0). In the domu''s /etc/inittab, near the
end in the
> getty section, I have co:2345:respawn:/sbin/agetty xvc0 9600 vt100-nav, and
> the xvc0 device has to be listed in /etc/securetty. Personally,
tho'' I just
> use ssh to log in to the domu, since it adapts to my terminal size better.
Right; that''s exactly what I''ve done under CentOS.  Understand
that
this isn''t in vain; I''m trying to provide console access to
people who
senselessly lock themselves out of their domU, otherwise ssh would be
fine.

-Ray

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

On Friday June 06 2008 07:30:44 am you wrote:
> The tip about hvc0/xvc0 was helpful in getting Debian Lenny going; for
> grins I decided to spin an image of Lenny to assist in
> troubleshooting.  Regarding the framebuffer (using Lenny for
> reference), I''ve got the xorg fbdev package installed.
 I''ve added a
> section to xorg.conf like:
>
> Section "Device"
>          Identifier "vnctest"
>          Driver "fbdev"
> EndSection
Here''s my F9 pv xorg.conf:

# Xorg configuration created by system-config-display

Section "ServerLayout"
	Identifier     "single head configuration"
	Screen      0  "Screen0" 0 0
	InputDevice    "Keyboard0" "CoreKeyboard"
EndSection

Section "InputDevice"
	Identifier  "Keyboard0"
	Driver      "kbd"
	Option	    "XkbModel" "pc105"
	Option	    "XkbLayout" "us+inet"
EndSection

Section "Device"
	Identifier  "Videocard0"
	Driver      "fbdev"
EndSection

Section "Screen"
	Identifier "Screen0"
	Device     "Videocard0"
	DefaultDepth     24
	SubSection "Display"
		Viewport   0 0
		Depth     24
	EndSubSection
EndSection

In particular, note how the last two sections relate to each other - The 
identifier you associate with the fbdev driver has to be specified in the 
Screen section.
> But as far as I can tell, the issue is that the domU does not expose
> the framebuffer to the dom0:
>
> XENBUS: Device with no driver: device/vkbd/0
> XENBUS: Device with no driver: device/vfb/0
> XENBUS: Device with no driver: device/console/0
I''ve seen this many times on this list, and on my own pv domus, and I
think
they are just pre-initialization messages - an indication that xen is about 
to look for drivers. Anybody know any differently?
> I believe that''s why I see "parallel0 console" in VNC.
 There is no
> /dev/fb0 on the domU (docs make reference to this; I''ve got to
believe
> udev would throw it up if it were configured properly).  Any ideas
> there?
With no more than the above xorg.conf, the output of ''ls -alF
/dev/fb*'' for me
is:

lrwxrwxrwx 1 root root     3 2008-05-26 17:21 /dev/fb -> fb0
crw------- 1 jimb root 29, 0 2008-06-06 18:05 /dev/fb0

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

Thanks Jim.  I''m led to believe that xorg.conf doesn''t have
anything to do
with the ability of the console framebuffer to function:

[root@dbi1-2 ~]# uname -r
2.6.18-8.el5xen
[root@dbi1-2 ~]# find / -print|grep xorg.conf
[root@dbi1-2 ~]# rpm -q xorg-x11-drv-fbdev
package xorg-x11-drv-fbdev is not installed
[root@dbi1-2 ~]#

This comes from a CentOS 5 domU with a working VNC text console.  My
/dev/fb* looks exactly as yours does in FC9; this is being generated by udev
in the case of Cent 5 (and yes, my Debian domUs have udev).  What am I
missing here?  Anyone?

-Ray



On Fri, Jun 6, 2008 at 6:13 PM, jim burns <jim_burn@bellsouth.net> wrote:
> On Friday June 06 2008 07:30:44 am you wrote:
> > The tip about hvc0/xvc0 was helpful in getting Debian Lenny going; for
> > grins I decided to spin an image of Lenny to assist in
> > troubleshooting.  Regarding the framebuffer (using Lenny for
> > reference), I''ve got the xorg fbdev package installed. 
I''ve added a
> > section to xorg.conf like:
> >
> > Section "Device"
> >          Identifier "vnctest"
> >          Driver "fbdev"
> > EndSection
>
> Here''s my F9 pv xorg.conf:
>
> # Xorg configuration created by system-config-display
>
> Section "ServerLayout"
>        Identifier     "single head configuration"
>        Screen      0  "Screen0" 0 0
>        InputDevice    "Keyboard0" "CoreKeyboard"
> EndSection
>
> Section "InputDevice"
>        Identifier  "Keyboard0"
>        Driver      "kbd"
>        Option      "XkbModel" "pc105"
>        Option      "XkbLayout" "us+inet"
> EndSection
>
> Section "Device"
>        Identifier  "Videocard0"
>        Driver      "fbdev"
> EndSection
>
> Section "Screen"
>        Identifier "Screen0"
>        Device     "Videocard0"
>        DefaultDepth     24
>        SubSection "Display"
>                Viewport   0 0
>                Depth     24
>        EndSubSection
> EndSection
>
> In particular, note how the last two sections relate to each other - The
> identifier you associate with the fbdev driver has to be specified in the
> Screen section.
>
> > But as far as I can tell, the issue is that the domU does not expose
> > the framebuffer to the dom0:
> >
> > XENBUS: Device with no driver: device/vkbd/0
> > XENBUS: Device with no driver: device/vfb/0
> > XENBUS: Device with no driver: device/console/0
>
> I''ve seen this many times on this list, and on my own pv domus,
and I think
> they are just pre-initialization messages - an indication that xen is about
> to look for drivers. Anybody know any differently?
>
> > I believe that''s why I see "parallel0 console" in
VNC.  There is no
> > /dev/fb0 on the domU (docs make reference to this; I''ve got
to believe
> > udev would throw it up if it were configured properly).  Any ideas
> > there?
>
> With no more than the above xorg.conf, the output of ''ls -alF
/dev/fb*'' for
> me
> is:
>
> lrwxrwxrwx 1 root root     3 2008-05-26 17:21 /dev/fb -> fb0
> crw------- 1 jimb root 29, 0 2008-06-06 18:05 /dev/fb0
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
>

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

On Saturday June 07 2008 05:54:42 am you wrote:
> This comes from a CentOS 5 domU with a working VNC text console.  My
> /dev/fb* looks exactly as yours does in FC9; this is being generated by
> udev in the case of Cent 5 (and yes, my Debian domUs have udev).  What am I
> missing here?  Anyone?
I believe I mentioned that the fbdev frame buffer is what is used by xen 3.1.2 
and up. CentOS 5[.1] uses a xen 3.0.3 with 3.1 forward ports. I would doubt 
it changed over to fbdev, since that change was introduced in F8 after CentOS 
5.1 had been out for awhile.

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

On Sat, Jun 7, 2008 at 9:14 AM, jim burns <jim_burn@bellsouth.net>
wrote:
> I believe I mentioned that the fbdev frame buffer is what is used by xen
3.1.2
> and up. CentOS 5[.1] uses a xen 3.0.3 with 3.1 forward ports. I would doubt
> it changed over to fbdev, since that change was introduced in F8 after
CentOS
> 5.1 had been out for awhile.
Got it.  Please bear with me as I''m relatively noobish on this
subject.  First off, I did replace my xorg.conf with yours - no
change, but I''ve got a pretty good idea why it doesn''t work
(below).
At the risk of generating more (potentially useless) list traffic,
here''s what I''ve done as of late:

I found http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=398056 which
purports that the framebuffer simply doesn''t work under kernel
versions prior to 2.6.25-1 under Debian (granted the platform is k7
not 686, but I assumed that to be true on 686 for the moment since I
have no desire to weed through endless changelogs).  So I upgraded
Lenny to Sid which has 2.6.25-2, figuring it wouldn''t hurt (hopefully)
to have the newer kernel.  What I found is there''s still no generation
of /dev/fb0.  If I ''insmod vfb.ko'' (not sure if
that''s appropriate or
not), I get "-1 No such device or address" returned.  All of
vfb.ko''s
module dependencies are loading fine.  I can also ''insmod
vga16fb.ko''
which works and outputs:

vga16fb: mapped to 0xc00a0000
Console: switching to colour frame buffer device 80x30
fb0: VGA16 VGA frame buffer device

as seen by dmesg.  So now I have a /dev/fb0 which goes nowhere as Xen
won''t attach it.  I tried sticking the vga16fb module in the initrd;
it loads right after I get the "XENBUS: Device with no driver:
device/vfb/0" message on the console.  It never connects up
subsequently either, as I see "xenbus_dev_shutdown: device/vfb/0:
Initialising != Connected, skipping" - not sure if xen would make any
attempt to connect up if the driver were subsequently exposed, so
forgive me if that sounds dumb.  I''ve also read about a new driver
called "pvfb" which was introduced into the kernel earlier this year -
not sure what bearing that has on things, or if it makes fbdev
obsolete in some way.

-Ray

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

On Saturday June 07 2008 02:35:42 pm Ray Barnes wrote:
> I found http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=398056 which
> purports that the framebuffer simply doesn''t work under kernel
> versions prior to 2.6.25-1 under Debian (granted the platform is k7
Can''t speak to Debian, so I may be at the limit to what I can recommend
based
on what Fedora does. Sorry my xorg.conf didn''t help.
> not 686, but I assumed that to be true on 686 for the moment since I
> have no desire to weed through endless changelogs).  So I upgraded
> Lenny to Sid which has 2.6.25-2, figuring it wouldn''t hurt
(hopefully)
> to have the newer kernel.  What I found is there''s still no
generation
> of /dev/fb0.  If I ''insmod vfb.ko'' (not sure if
that''s appropriate or
> not), I get "-1 No such device or address" returned.  All of
vfb.ko''s
> module dependencies are loading fine.  I can also ''insmod
vga16fb.ko''
> which works and outputs:
Understand, fbdev is an Xorg module, not a kernel module. The output 
of ''lsmod | grep fb'' on both my F8 dom0 and my F9 domu is
(null) - ie: no
modules loaded with ''fb'' in them. Also, F8''s dom0 is
based on 2.6.21, further
underscoring the kernel version has nothing to do with this. It might very 
well be a newer Xorg is required. My F9 domu fbdev comes from 
xorg-x11-drv-fbdev-0.3.1-7.fc9.i386.rpm. Back when this domu was F8, it was 
xorg-x11-drv-fbdev-0.3.1-4.fc8. This is generally Xorg 7.2/7.3 with 
xorg-x11-server-Xorg 1.3 (F8) or 1.4 (F9). I believe I remember you saying 
your domu was CentOS, which probably means an older Xorg. I''ve never 
installed a CentOS domu.

Sorry, but I''m probably not going to be much help now :-(

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

Ray Barnes wrote:
> Hi all.  In my CentOS 5.1 domUs, I add the following to the config file:
>
> vfb = [
''type=vnc,vnclisten=0.0.0.0,vncdisplay=1,vncpasswd=somepass'' ]
>
> at which point console output will default to vnc (assuming I remove
> the "console=xvc0" argument from the kernel line in grub).  To
enable
> interactive logon I''d just add another line into /etc/inittab for
the
> vnc console.  On Debian Etch (2.6.18-4-xen-686) I''m trying to
> accomplish the same thing but without any success.  When I launch the
> domU and hit the VNC server, it simply says "parallel0 console"
but
> does not output anything else.  I''ve tried poking around in /dev
and
> it does not appear that the vfb gets a separate device as it would
> under CentOS.  Google is also not very helpful in this regard, the
> only thing remotely relevant (which doesn''t solve my problem) is
> http://lists.xensource.com/archives/html/xen-users/2008-04/msg00686.html.
>  dom0 is Cent 5.1 with Xen 3.2.1 compiled from source.
>
> Any idea what I should be doing to get debian to work?  And on a
> related note, Ubuntu 7.10 appears to do what I want by default (I
> haven''t tested it yet - I gather that from google), but is there
> anything I should know about for Ubuntu 7.04?
>
> -Ray
>   
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@lists.xensource.com
http://lists.xensource.com/xen-users

On Wed, Jun 18, 2008 at 10:15 AM, Mike Lovell <mike@dev-zero.net> 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
>
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


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

-----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@gmx.net
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@dev-zero.net>
>> 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@lists.xensource.com
> 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@lists.xensource.com
http://lists.xensource.com/xen-users

On Thursday June 19 2008 10:03:27 am Paul Schulze wrote:
> 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).
This would be true for, say, 2.6.21. For a pvops kernel such as 2.6.25, the 
config setting is XEN_FBDEV_FRONTEND (for the domu), which typically is 
builtin, not a module (as is also XEN_FRAMEBUFFER). Also note that in Xorg 
7.3, with xorg-x11-drv-fbdev installed, and ''fbdev'' as your
video device in
your xorg.conf, it is actually /usr/bin/Xorg that opens the /dev/fb0 device, 
which can be confirmed with ''lsof|grep /dev/fb''.
> 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.
At one point, Ray did an ''apt-get -y install xorg'', but that
may have just
been experimentation.

I''m glad that you and Ray are putting your heads together on this. I
was very
impressed how you researched that Xorg bug in your thread ''PV DomU VNC
screen
black and Xorg error''.

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

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

Hi Jim,

For a 2.6.25 kernel that is be true, but he said he is using Hardy  
and I think he is using the same kernel for his Hardy DomU as me.  
That being said, the standard Hardy Dom0/U kernel is version 2.6.24  
with the Xen components ported from RedHat/Fedora kernel 2.6.22 or 23  
(as far as I remember), so it is still the old XEN_FRAMEBUFFER=y he  
has to look out for. It would be interesting to see what happens with  
a 2.6.25+ kernel though, but at the moment I have more pressing  
issues to deal with, so I can''t do any testing.

However, I can say this much, as long as Xorg is not running, it  
won''t have any effect on the framebuffer. The problem here is simply  
to tell the kernel to use XenFB for its output, though there is the  
possibility that the same problem occurs with the kernel output  
module as does with Xorg and therefor the kernel refuses to use the  
framebuffer. In that case, the sollution is not that simple, it would  
need some kernel debugging since there doesn''t seem to be a patch  
yet. And thats rather complicated (not sure if I could do it, maybe  
Ray can, depending on his level of experience). "/var/log/syslog" or  
"/var/log/kern.log" might have some information on this.

Even though I think VNC for console output isn''t all that useful, I  
will do some testing on it once I finish up my current Xen project,  
but don''t expect too much.

Cheers,


Paul.


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

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


Am 20.06.2008 um 01:25 schrieb jim burns:
> On Thursday June 19 2008 10:03:27 am Paul Schulze wrote:
>> 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).
>
> This would be true for, say, 2.6.21. For a pvops kernel such as  
> 2.6.25, the
> config setting is XEN_FBDEV_FRONTEND (for the domu), which  
> typically is
> builtin, not a module (as is also XEN_FRAMEBUFFER). Also note that  
> in Xorg
> 7.3, with xorg-x11-drv-fbdev installed, and ''fbdev'' as
your video
> device in
> your xorg.conf, it is actually /usr/bin/Xorg that opens the /dev/ 
> fb0 device,
> which can be confirmed with ''lsof|grep /dev/fb''.
>
>> 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.
>
> At one point, Ray did an ''apt-get -y install xorg'', but
that may
> have just
> been experimentation.
>
> I''m glad that you and Ray are putting your heads together on this.
> I was very
> impressed how you researched that Xorg bug in your thread ''PV DomU
> VNC screen
> black and Xorg error''.
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@lists.xensource.com
> http://lists.xensource.com/xen-users
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFIW4/bYDWOGtiChoARAkj7AJwPKApzxDioe2rqQeFSQPJbgKq7PQCff8f2
u3ysKGSB0i0Z1uzDnP+4xvU=o7bm
-----END PGP SIGNATURE-----

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

On Friday June 20 2008 07:09:14 am Paul Schulze wrote:
> For a 2.6.25 kernel that is be true, but he said he is using Hardy
> and I think he is using the same kernel for his Hardy DomU as me.
> That being said, the standard Hardy Dom0/U kernel is version 2.6.24
> with the Xen components ported from RedHat/Fedora kernel 2.6.22 or 23
> (as far as I remember), so it is still the old XEN_FRAMEBUFFER=y he
> has to look out for.
Heh - I always wondered whether Hardy built on top of the 2.6.24 pvops work, 
or they forward ported Xen/Redhat code. That clears that up :-) Still, that 
just means that Hardy is closer in function to the F8 2.6.21 kernel-xen, 
instead of the F9 2.6.25. Either way, Xorg 7.3 acts the same way on both 
systems. On my former F8 domu (& now F9), I had/have a desktop in vnc, but I
could always Ctrl-Alt-1 to a console, if I so desired. (Actually, virt-viewer 
makes that real easy, altho'' it''s possible with Fedora vnc.)
In fact, setting
initdefault to 3 in /etc/inittab does away with the desktop altogether. (I 
tend to do init 3/init 5 in my F9 domu to test xorg.conf changes, since it is 
easier than trying to get Tightvnc to send Ctrl-Alt-Backspace ;-), and vnc 
never quits.)
> However, I can say this much, as long as Xorg is not running, it
> won''t have any effect on the framebuffer. The problem here is
simply
> to tell the kernel to use XenFB for its output, 
(Aside - does Hardy use xen-vncfb (typical for xen 3.1.0 or lower) 
or ''qemu-dm -M xenpv ...'' (typical for xen 3.1.2 or higher) as
the dom0 vnc
server?)
> though there is the 
> possibility that the same problem occurs with the kernel output
> module as does with Xorg and therefor the kernel refuses to use the
> framebuffer. In that case, the sollution is not that simple, it would
> need some kernel debugging since there doesn''t seem to be a patch
> yet.
I hope not! It seems strange that I''ve only seen a handful of
complainers
about Hardy vnc support this year. Do Hardy-ers not use vnc, or does it work 
for most of them?

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

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

Am 21.06.2008 um 01:19 schrieb jim burns
> On Friday June 20 2008 07:09:14 am Paul Schulze wrote:
>> For a 2.6.25 kernel that is be true, but he said he is using Hardy
>> and I think he is using the same kernel for his Hardy DomU as me.
>> That being said, the standard Hardy Dom0/U kernel is version 2.6.24
>> with the Xen components ported from RedHat/Fedora kernel 2.6.22 or 23
>> (as far as I remember), so it is still the old XEN_FRAMEBUFFER=y he
>> has to look out for.
>
> Heh - I always wondered whether Hardy built on top of the 2.6.24  
> pvops work,
> or they forward ported Xen/Redhat code. That clears that up :-)  
> Still, that
> just means that Hardy is closer in function to the F8 2.6.21 kernel- 
> xen,
> instead of the F9 2.6.25. Either way, Xorg 7.3 acts the same way on  
> both
> systems. On my former F8 domu (& now F9), I had/have a desktop in  
> vnc, but I
> could always Ctrl-Alt-1 to a console, if I so desired. (Actually,  
> virt-viewer
> makes that real easy, altho'' it''s possible with Fedora
vnc.) In
> fact, setting
> initdefault to 3 in /etc/inittab does away with the desktop  
> altogether. (I
> tend to do init 3/init 5 in my F9 domu to test xorg.conf changes,  
> since it is
> easier than trying to get Tightvnc to send Ctrl-Alt-Backspace ;-),  
> and vnc
> never quits.)
Well, I can''t tell you how Xen VNC ought to work, because I''ve
never
seen it work correctly, except for when I''m running my Xorg session.  
However, I wouldn''t use init to restart X for testing. Assuming you  
are using a graphical login manager (xdm/gdm/kdm), you''re probably  
better off just restarting that (like /etc/init.d/gdm restart or  
something, no clue if this works the same way on Fedora systems as it  
does on Debian based ones).
>> However, I can say this much, as long as Xorg is not running, it
>> won''t have any effect on the framebuffer. The problem here is
simply
>> to tell the kernel to use XenFB for its output,
>
> (Aside - does Hardy use xen-vncfb (typical for xen 3.1.0 or lower)
> or ''qemu-dm -M xenpv ...'' (typical for xen 3.1.2 or
higher) as the
> dom0 vnc
> server?)
I would say that depends. In Hardy you actually have two choices for  
the Xen installation, 3.1(.0) or 3.2(.0). I am using 3.2 and it uses  
qemu-dm for VNC, though I imagine 3.1 is still using xen-vncfb. So  
there is also the possibility of Xorg working correctly with Xen 3.1,  
since xen-vncfb might not suffer from the same problem with the  
pixclock, which, as I recall, has something to do with the monitor  
connection/detection. Setting it to 0 like qemu-dm or xenfb (no clue  
which one is responsible) seems to be a bad choice even if it is the  
logical one in this case). Lets hope this will be taken into  
consideration in the future development of applications, relying on  
framebuffer, or the responsible component.
>> though there is the
>> possibility that the same problem occurs with the kernel output
>> module as does with Xorg and therefor the kernel refuses to use the
>> framebuffer. In that case, the solution is not that simple, it would
>> need some kernel debugging since there doesn''t seem to be a
patch
>> yet.
>
> I hope not! It seems strange that I''ve only seen a handful of  
> complainers
> about Hardy vnc support this year. Do Hardy-ers not use vnc, or  
> does it work
> for most of them?
That''s actually not strange at all, if you consider some things:  
Virtualization of Linux is mainly used for servers, which in general  
don''t need VNC access and in my opinion are better off with just SSH  
access anyways. There are some exceptions to this, like a single VM  
out of the 6, I am currently running, that actually has some use for  
graphical output. I use this VM to run an IRC client, kind of like a  
message box and some custom X-Chat scripts for a channel. But that''s  
a pretty unusual thing to do, so not many people will resort to it.  
Secondly, if you run a HVM, VNC should work just fine (and no, I  
haven''t tried, because currently, I just don''t need HVM  
virtualization for anything). And thirdly, Ubuntu is not all that  
popular for server application. Add all that up and you get like a  
hand full of people that this problem really concerns. I really doubt  
it works out of the box for other Hardy users, with the Xorg package  
in its current state and all (though I am not quiet sure about it).  
But I don''t think you should be worried too much, seeing as you use  
Fedora anyways. To me, it sounds like those problems were fixed or  
never occurred in in their packages anyways.


Paul.

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

"Making mistakes is human,
but to really fuck things up you need Computers"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFIXSCPYDWOGtiChoARAn31AKCDT8weHevSVRZ9pM177LdMIoDpJQCfQEe8
T0lB0dc3YdFtisKCjvWMUJ8=RvFg
-----END PGP SIGNATURE-----

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

On Saturday June 21 2008 11:38:54 am Paul Schulze wrote:
> Well, I can''t tell you how Xen VNC ought to work, because
I''ve never
> seen it work correctly, except for when I''m running my Xorg
session.
> However, I wouldn''t use init to restart X for testing. Assuming
you
> are using a graphical login manager (xdm/gdm/kdm), you''re probably
> better off just restarting that (like /etc/init.d/gdm restart or
> something, no clue if this works the same way on Fedora systems as it
> does on Debian based ones).
Unfortunately, not on Fedora. On SuSE, it''s /etc/init.d/xdm, where the
actual
window manager used is set in /etc/sysconfig/displaymanager. Near as I can 
tell in Fedora, it''s setup by /etc/rc.d/rc, not a service, hence the
need for
init.
> I would say that depends. In Hardy you actually have two choices for
> the Xen installation, 3.1(.0) or 3.2(.0). I am using 3.2 and it uses
> qemu-dm for VNC, though I imagine 3.1 is still using xen-vncfb. So
> there is also the possibility of Xorg working correctly with Xen 3.1,
Something I hadn''t considered, or even known about. Thanx.
> since xen-vncfb might not suffer from the same problem with the
> pixclock, which, as I recall, has something to do with the monitor
> connection/detection. Setting it to 0 like qemu-dm or xenfb (no clue
> which one is responsible) seems to be a bad choice even if it is the
> logical one in this case). Lets hope this will be taken into
> consideration in the future development of applications, relying on
> framebuffer, or the responsible component.
Yeah, well what''s expedient to fix a bug is not what always is
rigorously
correct. :-)
> > I hope not! It seems strange that I''ve only seen a handful of
> > complainers
> > about Hardy vnc support this year. Do Hardy-ers not use vnc, or
> > does it work
> > for most of them?
>
> That''s actually not strange at all, if you consider some things:
> Virtualization of Linux is mainly used for servers, which in general
> don''t need VNC access and in my opinion are better off with just
SSH
> access anyways.
Ok.

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