Mailing List Archive

On 6/14/05, William Schaller <wschalle@gmail.com> wrote:
> If you execute cat /dev/urandom at the xm console of a guest domain,
> it will spew garbage forever.

one question: what do you expect to get from /dev/urandom?

regards,
aq

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

Since Xend handles console output, splurging huge amounts of text to the
console is probably breaking it. (which is still a known issue, AFAIK)

Does the domain actually keep outputting to the console? Can you disconnect
and reconnect to the console? What happens then?

Cheers,
Mark

On Tuesday 14 June 2005 10:45, aq wrote:
> On 6/14/05, William Schaller <wschalle@gmail.com> wrote:
> > If you execute cat /dev/urandom at the xm console of a guest domain,
> > it will spew garbage forever.
>
> one question: what do you expect to get from /dev/urandom?
>
> regards,
> aq
>
> _______________________________________________
> 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

Here's the scenario: I'm using two ssh windows to control the box.
With one, I start xend, create the domain. With the other, I use xm
console to log into the domain. Logged into the domain, I exec cat
/dev/urandom. Predictably, the screen starts to fill with junk. At
this point, ctrl-c, nor any other method of escaping either cat or
this console will work. Attempting any command using xm or xend in the
other window simply hangs until I ctrl-c. Stopping and restarting xend
has no effect. I can kill the bash process the other window is
running, but if I reconnect to the console, I get the same garbage
dumping endlessly.

I discovered this while testing out the balloon driver. I was going to
cat /dev/urandom > file for a while until I had about 60 GB, then gzip
the file to see if I would get a OOM. But I left off the > file and
ended up with the above conundrum.

-Bill

On 6/14/05, Mark Williamson <mark.williamson@cl.cam.ac.uk> wrote:
> Since Xend handles console output, splurging huge amounts of text to the
> console is probably breaking it. (which is still a known issue, AFAIK)
>
> Does the domain actually keep outputting to the console? Can you disconnect
> and reconnect to the console? What happens then?
>
> Cheers,
> Mark
>
> On Tuesday 14 June 2005 10:45, aq wrote:
> > On 6/14/05, William Schaller <wschalle@gmail.com> wrote:
> > > If you execute cat /dev/urandom at the xm console of a guest domain,
> > > it will spew garbage forever.
> >
> > one question: what do you expect to get from /dev/urandom?
> >
> > regards,
> > aq
> >
> > _______________________________________________
> > 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 6/14/05, William Schaller <wschalle@gmail.com> wrote:
> Here's the scenario: I'm using two ssh windows to control the box.
> With one, I start xend, create the domain. With the other, I use xm
> console to log into the domain. Logged into the domain, I exec cat
> /dev/urandom. Predictably, the screen starts to fill with junk. At
> this point, ctrl-c, nor any other method of escaping either cat or
> this console will work. Attempting any command using xm or xend in the
> other window simply hangs until I ctrl-c. Stopping and restarting xend
> has no effect. I can kill the bash process the other window is
> running, but if I reconnect to the console, I get the same garbage
> dumping endlessly.

yes, it is very annoying not be able to even destroy the domain in
this case. i wonder what makes xend so unresponsive, and how to fix
it.

i think ideally, xend should always be able to handle the requests
(from xm), no matter what is happening.

regards,
aq

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

> > has no effect. I can kill the bash process the other window is
> > running, but if I reconnect to the console, I get the same garbage
> > dumping endlessly.
>
> yes, it is very annoying not be able to even destroy the
> domain in this case. i wonder what makes xend so
> unresponsive, and how to fix it.
>
> i think ideally, xend should always be able to handle the
> requests (from xm), no matter what is happening.

We need to move the console handling out of xend and into a separate
daemon, making them available as pty's (with controllable user/group
settings). We can then just use ssh wrappers to enable consoles to be
accessed over the network, potentially with an interposed screend. Not
sure how best to handle the pty naming, but this is a problem with the
current tcp port based scheme anyhow.

As soon as the xenbus patch goes in this will be the highest priority
xend work item.

Ian

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

What about creating a virtual serial terminal?

On 6/14/05, Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk> wrote:
> > > has no effect. I can kill the bash process the other window is
> > > running, but if I reconnect to the console, I get the same garbage
> > > dumping endlessly.
> >
> > yes, it is very annoying not be able to even destroy the
> > domain in this case. i wonder what makes xend so
> > unresponsive, and how to fix it.
> >
> > i think ideally, xend should always be able to handle the
> > requests (from xm), no matter what is happening.
>
> We need to move the console handling out of xend and into a separate
> daemon, making them available as pty's (with controllable user/group
> settings). We can then just use ssh wrappers to enable consoles to be
> accessed over the network, potentially with an interposed screend. Not
> sure how best to handle the pty naming, but this is a problem with the
> current tcp port based scheme anyhow.
>
> As soon as the xenbus patch goes in this will be the highest priority
> xend work item.
>
> Ian
>

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