New thought on VMWare ESX stuff
Moderators: Developers, Moderators
-
- Posts: 26
- Joined: Wed Sep 24, 2008 5:37 pm
New thought on VMWare ESX stuff
So, I have been sitting here trying to think of a way to get information from the VM guests and hosts with ESX 3.5. Turns out I think most of the information we would like to get is in Virtualcenter.
So I am snmpwalking it now and I am going to try and figure some stuff out. If anyone has any idea to make it easier let me know.
So I am snmpwalking it now and I am going to try and figure some stuff out. If anyone has any idea to make it easier let me know.
I had a similar thought, but it involved using the VI Perl toolkit to query the performance counters from Virtual Center. In fact, they can provide you with a boat load more information than the SNMP interface can. It can even tell you the configuration of any given VM, what your hosts are capable of and show you what's going on with your DataStores...
Unnoc (http://unnoc.org/) has a few handy looking Perl scripts that seem to query Virtual Center and return performance counters using the MOB interface provided with VC.
I'm not totally sure how it works, nor do I REALLY feel like figuring it out, but if you go to https://VIRTUALCENTERSERVER/mob, you'll be given access to a whole whack of information. Unnoc queries this via a Perl module which VMware gives out for free (or so I remember seeing).
All that said, I've found that querying the guests running in VMware is just as effective, if not a little more cumbersome.
Unnoc (http://unnoc.org/) has a few handy looking Perl scripts that seem to query Virtual Center and return performance counters using the MOB interface provided with VC.
I'm not totally sure how it works, nor do I REALLY feel like figuring it out, but if you go to https://VIRTUALCENTERSERVER/mob, you'll be given access to a whole whack of information. Unnoc queries this via a Perl module which VMware gives out for free (or so I remember seeing).
All that said, I've found that querying the guests running in VMware is just as effective, if not a little more cumbersome.
-
- Posts: 26
- Joined: Wed Sep 24, 2008 5:37 pm
Yeah, that's exactly what I was thinking of doing. I am looking over the unnoc scripts now to see if I can glean any onformation from it.
I would do the VM's but I have a #$*@ load of them and would rather do host-level graphing with the option of drilling down.
We have a guy here who knows perl *real* well, I think I am gonna con him into writing it for me once I figure it all out.
I would do the VM's but I have a #$*@ load of them and would rather do host-level graphing with the option of drilling down.
We have a guy here who knows perl *real* well, I think I am gonna con him into writing it for me once I figure it all out.
Yeah, I really didn't want to get that deep into it. Cacti is only something of a hobby at work, so I can't really dedicate that much time to it. Besides, I can't figure out Perl to save my life :).
My main concern is that I think it's going to be slow. If you have a LOT of VM's, it might drive the poller time through the roof. I had thought about running a cronjob every minute to pull the data out of VC and put it somewhere (flat file, xml, database) that Cacti could then fetch whenever it needed. I'm basing the speed of the few cli tests I did with the Perl Toolkit, so the APIs they provide via the Perl module might be WAY faster.
I hope you have some luck with this, because I'd really like to to see this working as well.
My main concern is that I think it's going to be slow. If you have a LOT of VM's, it might drive the poller time through the roof. I had thought about running a cronjob every minute to pull the data out of VC and put it somewhere (flat file, xml, database) that Cacti could then fetch whenever it needed. I'm basing the speed of the few cli tests I did with the Perl Toolkit, so the APIs they provide via the Perl module might be WAY faster.
I hope you have some luck with this, because I'd really like to to see this working as well.
-
- Posts: 26
- Joined: Wed Sep 24, 2008 5:37 pm
cacti does not work with esx 3.5
For those like me that are researching billing options for ESX 3.5 guests, is it accurate to say that Cacti and the Cacti ISP billing module are *not* compatible with ESX 3.5?
I've been looking for months for a way to calculate bandwidth charges for ESX guests and it seemed that Cacti would work, but that was before ESX 3.5 was released.
--Gil
I've been looking for months for a way to calculate bandwidth charges for ESX guests and it seemed that Cacti would work, but that was before ESX 3.5 was released.
--Gil
I think it would depend on how you were looking to bill the clients.
If you're looking for a 95th percentile (or something of the sort) rating of their usage (memory, disk, CPU, network), then cacti could probably do it if the templates existed. This would require some work, which fsckedagain is working on (I think). it's simply a matter of getting the data out of Virtual Center and into Cacti.
If you're looking for a 95th percentile (or something of the sort) rating of their usage (memory, disk, CPU, network), then cacti could probably do it if the templates existed. This would require some work, which fsckedagain is working on (I think). it's simply a matter of getting the data out of Virtual Center and into Cacti.
Who is online
Users browsing this forum: No registered users and 1 guest