[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: port-xen/40675: Xen 3.3: guest serial console not functional
The following reply was made to PR port-xen/40675; it has been noted by GNATS.
From: "Christoph Egger" <Christoph_Egger%gmx.de@localhost>
Subject: Re: port-xen/40675: Xen 3.3: guest serial console not functional
Date: Thu, 19 Feb 2009 11:22:00 +0100
Below the referenced e-mail.
On Sunday 17 August 2008 14:01:09 Christoph Egger wrote:
> Something strange is going on with the xenconsole:
> There is no console output if domain id is "1".
> This impacts both PV and HVM guests (latter one only
> if serial console is configured).
> Console output is there if domain id is anything else
> than "1".
> Console input is working so you can work blindly on it
> (or connect via ssh :)
> How to reproduce:
> Boot your Xen machine, make sure xend and xenbackendd
> are running.
> Launch your first guest and connect to the console with:
> xm create -c <guest-config>
> xm create <guest-config>
> xm console 1
> How xenconsole is supposed to work:
> Interaction between Dom0 and the DomU happens through
> a console ring-buffer, each entry can hold max. 512 chars.
> The ring-buffer frontend is in the DomU, the ring-buffer
> backend in the Dom0.
> xenstored runs in the Dom0 and holds the information how to
> access the ring-buffer.
> xenconsoled opens one tty for each launched domU via openpty().
> xenconsoled tells xenstored which pty (e.g. /dev/pts/3) is
> used for that domU.
> The masterfd will be used for console input/output.
> It writes anything read from the ring-buffer into
> the pty (= console output) and writes anything read from the pty
> into the ring-buffer (= console input).
> xenconsoled multiplexes the ring-buffer content to the different
> domUs ptys.
> When the user connects to the console, the xenconsole client
> runs. It queries xenstored which pty to use that domU.
> It uses select() to wait for any input from stdin or any output
> from the pty becoming available.
> When the user types something on the keyboard, xenconsole reads
> this from stdin and writes this into the pty and returns
> back to select().
> When output fromt the pty is available, xenconsole reads it
> from the pty and writes this to stdout.
> What I figured out or what is going wrong:
> I ktraced xenconsoled, launched the first guest (= domain id 1)
> and connected to its console.
> In the ktrace I saw, xenconsoled (= daemon)
> actually receives the console output
> and writes into the pty.
> I also ktraced xenconsole and I also put some debug fprintf(stderr, ...)
> into xenconsole to noticed, select() reacts as expected on
> console input.
> But: If domain id is "1", select() does not notice when an output is
> available. That is why no console output is there and why you can work
> blindly on the guest.
> If domain id is != "1", select() actually does notice when an output
> is available and xenconsole writes this to stdout.
> Open questions:
> Why does select() not notice when the domU pty change? And why
> only on domain id "1" ?
> Is there a (hidden) relation between select() and Xen-kernel code ?
> select(), openpty() and ptyfs are supposed to work ?
I figured out, this issue is not bound to domain id "1".
If you start some HVM guests which don't have a serial console
first and then a guest with a serial console, then you
the first guest with a serial console is impacted by this issue.
I suspect the bug in xenconsoled (daemon) since it does
the terminal settings. I think something is missing in
terminal initializing. But I'm stuck there.
Main Index |
Thread Index |