From: Ian Campbell <Ian.Campbell@citrix.com>
To: Steven Haigh <netwiz@crc.id.au>
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>, xen-devel@lists.xen.org
Subject: Re: vnc=1 / pvgrub / close fb: backend at /local/domain/0/backend/vfb/xx/0
Date: Wed, 22 Oct 2014 10:00:36 +0100 [thread overview]
Message-ID: <1413968436.20604.53.camel@citrix.com> (raw)
In-Reply-To: <5446CF1D.6030307@crc.id.au>
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@lists.xen.org
> > http://lists.xen.org/xen-devel
> >
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2014-10-22 9:00 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-21 15:17 vnc=1 / pvgrub / close fb: backend at /local/domain/0/backend/vfb/xx/0 Steven Haigh
2014-10-21 21:24 ` Steven Haigh
2014-10-22 9:00 ` Ian Campbell [this message]
2014-10-22 9:59 ` Samuel Thibault
2014-10-22 10:10 ` Steven Haigh
2014-10-22 10:19 ` Samuel Thibault
2014-10-22 10:31 ` Ian Campbell
2014-10-22 10:45 ` Steven Haigh
2014-10-22 10:40 ` Ian Campbell
2014-10-22 11:57 ` Stefano Stabellini
2014-10-22 12:05 ` Ian Campbell
2014-10-22 12:13 ` Stefano Stabellini
2014-10-22 15:23 ` Steven Haigh
2014-10-22 15:40 ` Ian Campbell
2014-10-22 15:53 ` Steven Haigh
2014-10-23 8:21 ` Ian Campbell
2014-11-05 17:49 ` Stefano Stabellini
2014-11-06 9:49 ` Steven Haigh
2014-11-06 10:34 ` Stefano Stabellini
2014-11-06 11:05 ` Steven Haigh
2014-11-06 10:41 ` [PATCH] pvgrub: ignore NUL Stefano Stabellini
2014-11-06 11:39 ` Samuel Thibault
2014-11-06 15:43 ` Stefano Stabellini
2014-11-06 19:36 ` Konrad Rzeszutek Wilk
2014-11-06 23:13 ` Samuel Thibault
2014-11-10 12:20 ` Ian Campbell
2014-11-10 12:21 ` Ian Campbell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1413968436.20604.53.camel@citrix.com \
--to=ian.campbell@citrix.com \
--cc=netwiz@crc.id.au \
--cc=samuel.thibault@ens-lyon.org \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.