Re: xenconsoled CPU denial of service problem

[Anthony Liguori <aliguori@us.ibm.com>]

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.
>