On 12/07/2012 12:39 PM, Mark Wu wrote:
On 12/06/2012 11:29 PM, Adam Litke wrote:
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
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
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
the guest agents and probably does not want to multiplex those
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
The problem I see with hooking collectd up to ovirt-ga is that vdsm
a connection to ovirt-ga for things like shutdown and desktopLogin.
owns the connection to the guest agent and there is not a nice way to
that connection for use by multiple clients simultaneously.
Actually, I don't like to collect from statistics from guest agent. Now
libvirt can provide the statistics of vcpu, block and network
interface. So I think we should reconsider enabling guest memory report
in virtio balloon driver. I am not sure if async event is
supported in qmp now. How do you think of it?
In vdsm and mom, we don't just simply collect statistics, but also need
perform appropriate action on it. So probably we still need a output
for collectd to to make the data is available to vdsm and mom, and
generate an event to vdsm or mom when the data reaches a given threshold.
Just an idea. I am not sure how easy to implement it.
should be easy for such stats, question is what other items are reported
by the current guest agent (say, list of installed applications).
vdsm-devel mailing list