Right Sizing Report - How much historical data req?

[steveburkett]

Have managed to get an evaluation install of v5.7 installed no problems and it's happily collecting data and throwing some interesting alerts up.

Just starting to look at the Right Sizing report, it's showing I've got 107 VM's, but none can be analyzed. Just wondering if there's a minumum number of days worth of historical data required before it'll start showing results?

[steveburkett]

Have been working on this a bit with Veeam Support but not getting very far, so I'll post my findings in the hope others might know more.

It looks like any VM's with an Ops Manager agent installed don't show any results in reports for vCPU and vRAM, including both the performance and right-sizing reports. Any VM without an Ops Manager agent shows full results for all reports.

Looking at the performance views in the nWorks VMware MP view in SCOM does show pretty graphs for the Ops Manager agented VM's though, so SCOM is able to get the data it needs, it's either not getting the data in to the Datawarehouse or the reports are trying to pull the wrong information from the Datawarehouse for these VMs.

One curious thing I noticed in the monitoring performance graphs was a slight change in rule for those Ops Manager agent enabled VMs compared to non-Ops Manager Agent enabled machines. Ops Manager agent enabled VMs use a rule 'VMGuest.memory.collect.memoryactive' while non-Ops Manager agent enabled VM's use 'VMGuest.collect.memoryactive'. One rule targets vRAM (doesn't work) while the other targets VMGuest Virtual Machine (does work).

One factor might be that I've enabled the VMGuest contains OpsMgr Agent discovery rule as per the nWorks 5.7 Operations Guide.

Am I seeing a bug here? Do the reports not take in to account this slight change in behaviour for OpsMgr Agent enabled VM's?

[Alec King]

Hi Steve,

The two different memory collection rules should be (automatically) used depending on whether 'VM Child Objects' is enabled - this is our topology option, of having a simpler more scalable topology with less objects, or the full set of child objects including a specific vRAM object for memory counters, vCPU object for CPU counters etc.
These rules should not change depending on whether there is an Ops Mgr agent installed....However, the rules change depending on group membership of VMs, the group is controlled by the VM property 'Child Objects Enabled'. So perhaps there is some problem with the group membership. Maybe the 'VMGuest Contains Ops Mgr Agent' discovery is a factor, because it does update some properties of the associated VMGUEST object....

We will investigate here in R&D and update you ASAP. Thanks!
Alec

[Alec King]

Steve, one thing to confirm first please - are these VMs actually monitored through nworks Enterprise Manager? That is, do these problem VMs exist in a vCenter which nworks is connected to via nworks Enterprise Manager UI?

That's just a sanity check - because we do not collect VM performance data via Ops Mgr agent in the VM. We use that agent only for some specific tasks (such as discovering relationship between Ops Mgr agent and VM). Generally all of our performance data is collected agentlessly, via remote vCenter SDK/API connection. In order to get performance data on the VM, it must be in a vCenter which is connected to nworks UI. Just pushing an Ops Mgr agent inside a VMware VM will not monitor it.

Thanks,
Alec

[steveburkett]

We've actually got a mix, one vSphere 4.1 vCenter with three vSphere Esxi 4.1 hosts under it, and also three ESXi 4.1 standalone hosts. Some of the VMs that were returning vCPU results existed on the vCenter ESXi hosts, and some were on the ESXi standalone hosts. We've got the vCenter and the three standalone ESXi hosts listed under the Default Monitoring group on the Enterprise Manager so believe she's monitoring them all ok. And as I mentioned before, we get the performance data in the nWorks MP view showing up for all our VM's, even if they're on the standalone ESXi hosts, which is cool, it's just the reports that don't seem to be showing data for vCPU and vRAM on some systems.

[Alec King]

OK, thanks Steve! We'll dive in to your logs and do some analysis. Update you ASAP!

[steveburkett]

Just a quick update to this, Veeam Support are still working on this problem and have requested a few SQL query results from our Data Warehouse DB etc. Seems like it's not just me affected by it.

[marinus1985]

I also have a problem with this new report, posted here: http://forums.veeam.com/viewtopic.php?f=1&t=10762
My idea is that it's related to the SQL version your running for your SCOM DB's.
I have it working in SQL 2008 R2 and a non-working with SQL 2008.

[steveburkett]

Interesting observation! We're on SQL 2008 (non-R2).

But saying that, the guys at Veeam Tech Support fired me over a hotfixed version of the MP yesterday and it's fixed the issues, I'm getting good results for the right-sizing report now! So would expect an updated MP to be released shortly once they've verified it's all ok.

[Alec King]

Thanks for the update Steve! Glad you are up and running
Hope you're enjoying the new Reporting in 5.7 - any feedback please let me know!

Cheers
Alec

[marinus1985]

Alec,

Can you send me the updated version of the MP or can I download it?

[vBPav]

Marinus,

Open up a case with support via the cp.veeam.com support portal. They should be able to assist.

Thanks!