provides a link to a Java program to allow network and disk red/write stats (as opposed to aggregate read+write stats - I think). However, not many details are presented therein, and I am curious if anyone has tried this "fix".
1. What are the database space implications (CBM database - stats are dup'd) of running this fix? Does it balloon the space requirements for the CBM database? Or is the growth moderate/negligible? (From the text of the KB article, it seems like only separate read/write stats are added and not the rest of L3 stats...but I am not sure how much L3 normally adds, and how much(little) this fix adds in comparison).
2. "Reverting" this fix -why might we want to do this (eliminate DB growth?), and what happens to the CBM reports thereafter (I assume we lose the individual read/write stats after that and have only the aggregate? Other?)
3. I assume that we need to run this on each vCenter server? Or does running it on a single vC suffice (vCs are linked, if this makes any difference)?
Thanks in advance.
Please find the answer to question posted above in the same order.
Answer to Q1
When the tool is run, we will start getting the split stats of network (transmitted + received) and datastore (read + write). Definitely we will be storing more stats and this will have space implications. However, the amount of extra space that will be needed depends on the no. of devices per VM i.e. the no. of VNICs for network and datastores associated with a VM. This is because the split stats are available per VM, per device.
Chargeback publishes a 'Database Sizing Tool (in the form of an Excel sheet)' to estimate the DB size based on the count of VMs, duration, enabled counters. Please refer to the documentation about this guide to estimate the DB size increase.
Answer to Q2
This will also increase/affect db sizing of vCenter as well. So, you need to plan for that as well. Usually, you should not face any problem in CBM/vCenter because of this. In case, if you face any problem, you can revert. Already ran reports in CBM are not affected, but further reports which generates usage/cost for these split counters, will not give any data.
If the setting is reverted the cost /usage report will have only the aggregate stats and not the split stats. There will be *NO* side effects.
Answer to Q3
Yes, The tool needs to be run on each vCenter Server. Even in case of a linked VC configuration every VC maintains its own configurations.
Thank you for the response - however,
The fix states "... the statistics collection level in vCenter Server must be set to 3 or above. However, this is not recommended in a production environment. Therefore, to obtain split the disk and network utilization data, you must run the Update Performance Counter utility one time on the vCenter Server machine...".
As stats L3 is not recommended for production (as stated in the "fix"), and as we should - instead of setting stats to L3 - run this "fix", I assume (perhaps incorrectly??) that this fix does not implement a "full on" L3 stats environment, but some lesser collection environment that captures (perhaps only)
separate reads and writes in addition to/instead of the aggregates.
Also, it is not clear if this fix collects (whatever extra stats it collects) for only the 5 min interval, trusting the stats replication to capture them before they evaporate in VC, or if these stats will then be propagated to all retention periods (1 hour, day, etc.).
Also, IFF this is not a "full on" L3, it is still difficult to determine what effects this will have on the VC database, as the "tool" is not (that I can find) set up to calculate "partial" L3 stats collection for some unknown retentions.
The so called "fix" elaborated in the KB is NOT a fix, but a simple tool that will promote some (that are absolutely required) of the counters from L3 to L1. By this way, VC will start treating those counters, "like other" L1 counters and collect stats (5mins, 30mins etc) for it. On the DB growth side, please threat it as any other L1 counter.
Hope I clarified all your questions.
Thank you - that answers those questions - just one more thing:
Java is not installed on our VC server machine - and 1.6 is no longer recommended AND does not appear on the oracle download page. Will Java 7 work? If not, will there be a Java 7 "re-work" of this utility in the near future?