On 12/05/2012 11:11 PM, Adam Litke wrote:
On Wed, Dec 05, 2012 at 10:51:23PM +0200, Itamar Heim wrote:
On 12/05/2012 10:33 PM, Adam Litke wrote:
On Wed, Dec 05, 2012 at 10:21:39PM +0200, Itamar Heim wrote:
On 12/05/2012 10:16 PM, Adam Litke wrote:
On Wed, Dec 05, 2012 at 09:01:24PM +0200, Itamar Heim wrote:
On 12/05/2012 08:57 PM, Adam Litke wrote: > On Wed, Dec 05, 2012 at 08:30:10PM +0200, Itamar Heim wrote: >> On 12/05/2012 04:42 PM, Adam Litke wrote: >>>> I wanted to know what do you think about it and if you have better >>>>> solution to avoid initiate so many threads? And if splitting vdsm is >>>>> a good idea here? >>>>> In first look, my opinion is that it can help and would be nice to >>>>> have vmStatisticService that runs and writes to separate log the vms >>>>> status. >>> Vdsm recently started requiring the MOM package. MOM also performs some host >>> and guest statistics collection as part of the policy framework. I think it >>> would be a really good idea to consolidate all stats collection into MOM. Then, >>> all stats become usable within the policy and by vdsm for its own internal >>> purposes. Today, MOM has one stats collection thread per VM and one thread for >>> the host stats. It has an API for gathering the most recently collected stats >>> which vdsm can use. >>> >> >> isn't this what collectd (and its libvirt plugin) or pcp are already doing? > > Lot's of things collect statistics, but as of right now, we're using MOM and > we're not yet using collectd on the host, right? >
I think we should have a single stats collection service and clients for it. I think mom and vdsm should get their stats from that service, rather than have either beholden to any new stats something needs to collect.
How would this work for collecting guest statistics? Would we require collectd to be installed in all guests running under oVirt?
my understanding is collectd is installed on the host, and uses collects libvirt plugin to collect guests statistics?
Yes, but some statistics can only be collected by making a call to the oVirt guest agent (eg. guest memory statistics). The logical next step would be to write a collectd plugin for ovirt-guest-agent, but vdsm owns the connections to the guest agents and probably does not want to multiplex those connections for many reasons (security being the main one).
and some will come from qemu-ga which libvirt will support? maybe a collectd vdsm plugin for the guest agent stats?
Then you still have vdsm plus one other entitity in the business of stats collection. I don't see how that's any better than what we have today.
either more stats are moved to qemu-ga and libvirt gets them, or we decide long term we need them from ovirt-ga, and we split the channel so colelctd can get them directly. the benefit of using something like collectd is all the stats vdsm/mom don't care about