On Fri, 2007-03-02 at 22:12 -0800, Tom Mornini wrote:
> You don't believe that *testing* is a good thing?
>
> I'm pretty sure the Xen documentation points out that Dom0 is not
> particularly special, except that it is privileged to manipulate DomUs.
>
> I'd love to hear other's opinions on this topic. Should Dom0 be
> entirely free of disk I/O?
That's impossible.
> Now, I should make it clear, I'm a big supporter of Dom0 doing
> essentially nothing. Yet, I'm also a supporter of not having
> difficulty sleeping at night, afraid that Dom0 might write a block or
> two to its own disks...
That is a very silly extreme. When tweaking any system practical Linux
experience comes into play. This starts from selecting the right file
systems for the job at hand setup on networks that work well.
I've seen people using calls like :
cat /var/myfile | tr ':' '#' | sed -e 's/group:/q-group/d' | grep
"#hello" | awk '{ print $2,$3 }' | tr '#' ':' (silly extreme)
That run within loops of scripts and fork a thousand times. Then they
wonder why loads shoot so high when the scripts run and scan syslog.
A big part of what Xen is bringing back to Linux is forcing integrators
and Administrators to once again be more conscious and aware of how
their operating systems and computers actually work.
> I have a job that runs every five minutes to grab CPU utilization,
> and writes that to disk.
> That job doesn't cause destabilization.
No. Its important to write scripts a little differently on dom-0 to be
sure you fork the least amount possible and you don't get carried away
with over malloc()'ing utilities like sed awk and grep.
Keep perl and PHP down to a minimum and if you use PHP in your shell
scripts, make sure you built a small copy of PHP just for doing that.
Be sensible but don't make a new phobia out of it.
There are *lots* of things that really should go on dom-0 just because
its the easiest place to put them. Bandwidth loggers, snort, traffic
shaping scripts, stuff scanning syslog every few minutes to see what Xen
has been up to, watching for brute force attacks on the public ports,
pinging iscsi or AoE targets and exports, etc. Its also a handy place to
stick rrdtool/mrtg style tools, or even centralize snmp data for all the
guests. Lots of good sane strategic uses for dom-0, its not nearly the
'black hole' people make it to be.
There should also be room for some application that handles repetitive
tasks for you, such as setting up and managing the guests.
We made 'grawk' to help do some of the scraping and sawing more
efficiently : http://dev1.netkinetics.net/grawk/grawk.c on dom-0.
> My
> problem seems to be related to kernel SLAB corruption, which is why I
> mentioned this as something to test, and made it clear that in my
> case, it made the machine unstable.
Time for a memtest and to make sure no dust bunnies have made their home
on your DDR depending on what exactly was in slabs. But sheesh, don't
let a project list or some wiki make you afraid to touch your
computer :)
Best,
--Tim
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home