WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] "right" way to gather domU stats in xen 3 & 4?
From: Florian Heigl <florian.heigl@xxxxxxxxx>
Date: Tue, 1 Mar 2011 00:16:22 +0100
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 28 Feb 2011 15:17:30 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jutitKJ21E2fFY8GAcGOqnyQ+ewoVyBbOCVeHORfsTg=; b=JNgR1F+PjnMZmanmar21tYhwfdRYRhh+PB/oL8sI0Az0CXLZDAJ79upHmUstKgx/ri iH5Lhe5rccodCvrA68FyMzoqkPhpjGcWBuPNYoEd6ysdfEl/DU994g8HJUBjRaxDkTKE apXwCsjZmobjgpNIuShn+NClIIO1yw6nST71A=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=iSg7GqokEZZwx0Hxksqfrxze87Vm5Ll9ndfMtQPjgJf2mS2X0Mgz8jz22XtZD+o3ZC +bNOyeho4QPUgDwzzt9tpp/nrhm0Rx78ldpTfYhd+F5QiO+ILA6M5TzcYbMnaIFtfNBA uGSY8/aXZBESrnrt5WYy4JMC9wmpAf0J6ZNFY=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <alpine.DEB.2.00.1102281127510.19277@kaball-desktop>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <AANLkTi=cK7b_FbTMXyQp3E=iTHw9R3L4yiNQBqq8Zrhw@xxxxxxxxxxxxxx> <alpine.DEB.2.00.1102281127510.19277@kaball-desktop>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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

<Prev in Thread] Current Thread [Next in Thread>