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

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



On 4/10/06 18:19, "Daniel P. Berrange" <berrange@xxxxxxxxxx> 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.

There's also the issue of backward compatibility with guests with a small
inter-domain ring. And this doesn't solve the fundamental problem of dom0
getting slammed with lots of event-channel notification. We need rate
limiting anyhow, on all our inter-domain comms channels.

 -- Keir



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


 


Rackspace

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