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

Re: [Xen-devel] vnc=1 / pvgrub / close fb: backend at /local/domain/0/backend/vfb/xx/0



On Wed, 2014-10-22 at 08:24 +1100, Steven Haigh wrote:
> As a side note to this - if I use pygrub as a bootloader vs using
> pvgrub, then VNC works perfectly.
> 
> So, what options exist to make pvgrub behave properly for booting with
> VNC enabled?

ISTR (vaguely) that way back when the backends needed to be modified to
cope with kexec (which is effectively what pvgrub does) by not exiting
when the frontend disconnects, instead sticking around waiting for a new
frontend, this relates somehow to the "online" key in xenstore.

Perhaps the pvfb backend never got that treatment, which would explain
#2? 

That was ages ago (like 2005/6?) so it seems a bit unlikely you'd be the
first to try this and notice.

I've no idea for #1 though.

Oh, is this with pvgrub 1 (the thing which ships with Xen) or pvgrub 2
(from the upstream grub project fairly recently)? Your logs hint towards
the former.

Ian.

> On 22/10/2014 2:17 AM, Steven Haigh wrote:
> > Hi all,
> > 
> > I'm toying around with having VNC accessable for some PV guests - but
> > having a bit of an issue.
> > 
> > 1) When vnc is enabled, the grub menu shown via pvgrub stays until a
> > selection is made on the vnc console. The timeout does not seem to ever
> > kick in and the DomU more or less sits there churning CPU waiting for a
> > selection. Once a selection is made, we move to problem #2.
> > 
> > 2) When the DomU boots, I see this as one of the last messages before
> > the DomU kernel takes over:
> > 
> > backend at /local/domain/0/backend/vfb/55/0
> > /local/domain/0/backend/vkbd/55/0 connected
> > ************************** KBDFRONT
> > Thread "kbdfront" exited.
> > /local/domain/0/backend/vfb/55/0 connected
> > ************************** FBFRONT
> > Thread "kbdfront close": pointer: 0x2200004550, stack: 0x3a30000
> > close fb: backend at /local/domain/0/backend/vfb/55/0
> > close kbd: backend at /local/domain/0/backend/vkbd/55/0
> >   Booting 'Scientific Linux (3.14.21-1.el6xen.x86_64)'
> > 
> > At this point, the VNC server dies and never returns. No VNC connections
> > are accepted at this point on - and the port (verified via netstat -lnp)
> > is not open.
> > 
> > I have tried this with both the following layouts of options:
> > vfb = [ 'type=vnc, vnclisten=192.168.1.1, vncpasswd=supasecret,
> > vncdisplay=10' ]
> > 
> > and;
> > vnc             = 1
> > vnclisten       = "192.168.1.1"
> > 
> > Has anyone had VNC working properly?
> > 
> > # xl info
> > host                   : xenhost.local
> > release                : 3.14.20-1.el6xen.x86_64
> > version                : #1 SMP Mon Oct 6 22:03:42 EST 2014
> > machine                : x86_64
> > nr_cpus                : 8
> > max_cpu_id             : 7
> > nr_nodes               : 1
> > cores_per_socket       : 4
> > threads_per_core       : 1
> > cpu_mhz                : 2327
> > hw_caps                :
> > bfebfbff:20000800:00000000:00000900:0004e3bd:00000000:00000001:00000000
> > virt_caps              : hvm
> > total_memory           : 20479
> > free_memory            : 2587
> > sharing_freed_memory   : 0
> > sharing_used_memory    : 0
> > outstanding_claims     : 0
> > free_cpus              : 0
> > xen_major              : 4
> > xen_minor              : 4
> > xen_extra              : .1
> > xen_version            : 4.4.1
> > xen_caps               : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32
> > hvm-3.0-x86_32p hvm-3.0-x86_64
> > xen_scheduler          : credit
> > xen_pagesize           : 4096
> > platform_params        : virt_start=0xffff800000000000
> > xen_changeset          :
> > xen_commandline        : dom0_mem=1G cpufreq=xen dom0_max_vcpus=1
> > dom0_vcpus_pin console=tty0 console=com1 com1=115200,8n1
> > cc_compiler            : gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4)
> > cc_compile_by          : mockbuild
> > cc_compile_domain      : crc.id.au
> > cc_compile_date        : Tue Oct  7 01:00:52 EST 2014
> > xend_config_format     : 4
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxx
> > http://lists.xen.org/xen-devel
> > 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

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