Re: [Xen-devel] "right" way to gather domU stats in xen 3 & 4?

[Florian Heigl <florian.heigl@xxxxxxxxx>]

Hi Stefano,

firstofall thanks for your reply!

2011/2/28 Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>:
> On Sat, 26 Feb 2011, Florian Heigl wrote:
>> Hi all,
>>
>> I'm building a xen agent for nagios / check_mk.
>> Automatic inventory of VMs and the basic up / down reporting are
>> reliable now, and I'm looking at the next items on my list.
>
> it looks like a interesting and useful project

I hope it'll be helpful, definitely works good for me. Things are a
lot easier if you can just say "scan for any VMs on that host" and
then they're monitored / assign them to clusters. ( you can read here
if you wanna: 
http://deranfangvomende.wordpress.com/2011/02/09/check_mk-xen-plugin-online/
).

I'm a *very* great fan of libxenlight. Many years ago there was
"libxen" which wasn't brought over to Xen3 and it was really time
there's a new fast tool "to rule them all". (i just had to).
The host-side agent is very small and thus i'll be just in /bin/sh and
use xm/xl as available. I could use python, too, but if libxenlight is
around the corner i don't wanna re-introduce a python dependency :)
I'm gonna trash the local agent code a few more times since it's
neither elegant nor fast yet. Both shell and python should work on
Linux/NetBSD/Solaris. On the other hand the python bindings as shown
at http://wiki.xensource.com/xenwiki/XenApi are probably completely
outdated, and libxenlight is only available on Xen4.1 which severly
limits it's usability right now.
Not sure how to go about this, but I think it will pay out to start
simple with "xm", not thinking about performance impact and then
rewrite the host agent later on to mostly use xl via i.e. python.

I understand I gave too much thought about free memory and how much of
is used by dom0/hypervisor/free. Besides the free memory nobody ever
cares, me included. On most of my hosts I couldn't say how much
"total_mb" they display, because I just look at the "free_mb". So that
point is sorted.

I will try digging into xentop over the next days, as I the main
magick of breaking down stats per domU is still open.
I hope I will find other data than cpu seconds used, because that
would mean UGLY calculations
(in theory: multiply uptime by number of cores, and divide that by the
seconds used by the domain?)

Any comment about tmem / baloon would still be great... why doesn't
anyone jump when our coolest features are mentioned? :)
I think it's important to make them visible to the general users...

>> That's just a 1.5GHz VIA box, but I'll have to see how long it takes
>> for 100 VMs or more.
>
> Xenstore can become very busy on systems with many VMs running.

So, any advice? Obviously, limiting my queries is the main trick, but
seems the tools do a lot of calls internally.

I wonder if that post about xenstore IO performance
http://xen.1045712.n5.nabble.com/Revisiting-XenD-XenStored-performance-scalability-issues-td2504870.html
still applies. I'll try the ramdisk hack he described out of
curiosity.

Florian


-- 
the purpose of libvirt is to provide an abstraction layer hiding all
xen features added since 2006 until they were finally understood and
copied by the kvm devs.

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