Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials

VM Guest Reports with NPM

In trying to write some reports to get VMGuest statistics out of NPM I have run into a few problems and I am wondering if anyone else has had success in getting VMGuest stats.

What I am trying to do is get the following information for the past month.

VMGuest Name
OS
Allocated Memory
AVG CPU Load / Memory Usage / Network Tx and Rx
Max CPU Load / Memory Usage / Network Tx and Rx

There appears to be data in the Database however some of the data doesn't seem to be kept historically. I am also questioning the accuracy of the roll up data

VIM_VirtualMachineNodes has a lot of good data. The columns I am interested in are:

CpuLoad
MemoryConfigured
MemoryShares
MemUsage
MemUsageMB
NetworkTransmitRate
NetworkReceiveRate

In looking in the other views it seems like VIM_VMStatistics keeps the historical data. However the MinCPULoad, MaxCPULoad and AvgCPULoad columns are no where close to the data seen in VIM_VirtualMachineNodes. It looks like these numbers are the VMGuest machines Load % of the actual Host and not the allocated CPU to the Guest OS (VIM_VirtualMachineNodes CpuLoad matches that of the Guest OS).

Still looking at VIM_VMStatistics the Memory is definitely just the % of the Host ESX server however this number means nothing if the VM moves from a Server with say 96GB of RAM to one that has 256GB for example.

Next regarding VIM_VMStatistics is the Min / Max / Avg Network Transmit/Receive Rate columns. These seem to be way off compared to VIM_VirtualMachineNodes. The NetworkTransmitRate and NetworkReceiveRate columns in VIM_VirtualMachineNodes seems to match the actual Network Tx/Rx (in MBps and not Mbps but that I can deal with ... )

Now in the VIM_VMStatisticsByDays view, this looks to be a role up of VIM_VMStatistics however when this happens the Max numbers for CPULoad, Network etc seem to be much higher than the details in VIM_VMStatistics.

I have looked at the VIM_VMStatistic, VIM_VMStatisticsByDays Views the VMStatistic, VMStatisticsByDays Views and the actual VIM_VMStatistics_Daily/Detail/Hourly tables.

I am not a database guy so I could be all turned around on this. Any help would be greatly appreciated.

Find more posts tagged with

Accepted answers

All comments

jason.brown

I have opened up a support case on this and the response is basically this:

"This is by design. To monitor the CPU Load and Memory of the actual Virtual Machine, you will need to enable SNMP on the Virtual Machine and monitor the device in Orion. If you select the Node it should ask if you would like to monitor the Virtual Machine, then you can enter in the SNMP information and add the device."

Can a PM or DEV from Solarwinds comment on this?

The data is in Virtual Center, and you are polling the data via the API already and just not storing it historically. Adding every host to the system via SNMP just isn't feasible when you have multiple customers / business units that manage the actual OS.

byrona

While I don't work at SolarWinds, I do have a lot of experience using Orion to monitor nodes in a VMWare environment.

The information you have been provided is correct, monitoring each individual node is the best practice and best way to get what you are looking for. The information that is polled via the API is stored historically; it's just not likely in stored in such a way to give you what you are looking for.

In VMWare if you are using DRS, which you likely are, the VM's will dynamically move between hosts and in Orion I believe this information is stored as associated with the hosts which as noted, it always changing.

If you monitor the nodes themselves directly you can consistently get resource usage associated with that node as well as allocated resources in VMWare.

Hope this helps!

jason.brown

Thanks for the reply. The data that I could use is not stored historically (Details found in VIM_VirtualMachineNodes). The DRS issue shouldn't be a problem as we are polling everything via Virtual Center.

The problem is that in larger environments where you are doing IaaS you don't always have the option to manage all of the VM's as I mentioned. In small environments where IT has full control of everything that is doable.

With "Virtualization Manager" you can probably get this information however building a monitoring solution with different point products isn't fun (ask all of the HP ITSM users)

byrona

The data that I could use is not stored historically (Details found in VIM_VirtualMachineNodes). The DRS issue shouldn't be a problem as we are polling everything via Virtual Center.

The CPU and Memory details that are stored at a host level per VM are stored historically somewhere in the DB because you can look at them historically in Orion though I couldn't tell you where because I haven't bothered to try and find it. When DRS moves nodes around I would guess that it moves where it's stored because those graphs appear to be associated with the host systems though I don't know this for sure.

The problem is that in larger environments where you are doing IaaS you don't always have the option to manage all of the VM's as I mentioned. In small environments where IT has full control of everything that is doable.

This has been a bit of an issue for us as well as we are also an IaaS provider as well. You can still get memory shares which is important for how VMWare licenses work.

With "Virtualization Manager" you can probably get this information however building a monitoring solution with different point products isn't fun (ask all of the HP ITSM users)

I also totally agree with you here, we try and do everything from Orion as our "single pane of glass". Having to implement a half dozen point solutions is a total pain in the rear.