| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[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?
Regards,
Anthony Liguori
Dan.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home