On Thu, Dec 06, 2012 at 11:19:34PM +0800, Shu Ming wrote:
> 于 2012-12-6 4:51, Itamar Heim 写道:
> >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?
> >
> I am thinking to have the collectd as a stand alone service to
> collect the statics from both ovirt-guest and qemu-ga.  Then
> collected can export the information to host proc file system in
> layered architecture.  Then mom or other vdsm service can get the
> information from the proc file system like other OS statics exported
> in the host.

You wouldn't use the host /proc filesystem for this purpose.  /proc is an
interface between userspace and the kernel.  It is not for direct application

The problem I see with hooking collectd up to ovirt-ga is that vdsm still needs
a connection to ovirt-ga for things like shutdown and desktopLogin.  Today vdsm,
owns the connection to the guest agent and there is not a nice way to multiplex
that connection for use by multiple clients simultaneously.

Adam Litke <a...@us.ibm.com>
IBM Linux Technology Center

vdsm-devel mailing list

Reply via email to