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

[Xen-devel] Re: xenconsoled CPU denial of service problem

Daniel P. Berrange wrote:
On Wed, Oct 04, 2006 at 11:49:56AM -0500, Anthony Liguori wrote:
Considering that today in Xen we have a default buffer size, it seems considerably easier to me to just get rid of xenconsoled completely and expand the domU-kernel ring queue to be the actual size of what we're buffering today.

This eliminates all of these problems and gets rid of a dom0 daemon. Plus, the domU gets taxed for the buffer memory instead of dom0.

We would then change xenconsole to read the buffer directly.

Its very useful to be able to expose the data as a Psuedo-TTY, as
it lets people use standard toolset for dealing the DomU log data.
eg virt-manager can just connect up a VTE terminal widget straight
to the TTY for a terminal UI. Or tools like ttywatch can log the
data to file, or network, etc. Or minicom for a standard text based
interactive client, etc Forcing everything to use the custom
xenconsole client program would be a step backward.

Xenconsole could still spit out on a PTY. You don't necessarily need a daemon though (you could launch a xenconsole for each domain that was started).

That also gives you a bit more choice in how you expose the console (you could have a xenconsole that spit out via TCP).

Furthermore, we don't have to break guest compatibility. Older guests just have a very small buffer.

It doesn't solve the event channel storming.. Maybe that's something to do in the hypervisor?


Anthony Liguori


Xen-devel mailing list



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