|
|
|
|
|
|
|
|
|
|
xen-devel
[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
|
|
|
|
|