If you execute cat /dev/urandom at the xm console of a guest domain, it will spew garbage forever. Attempts to run xm destroy on it simply hang. _______________________________________________ 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:> 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