Check out the "Disk I/O Reads and Writes" section in the "Waste, Stress, and Capacity Report" on VM entity level. Or check the "Resources" section in the "Virtual Machine Capacity Overview Report". From there you can see a line called "Host Disk I/O Reads per Second" and "Host Disk I/O Writes per Second".
Hi,
I need to get IOPS report for VMs too.
I have custom dashboard which shows top VMs by IOPS, but because those VMs are from VCD, I don't know in which vApp are they so i want to export CSV and get the other data by PowerCLI.
Anybody else?
If you need just the report and not only from vCOPS you can download I/O Analyzer from VMware labs and try it.
Ah – good idea. Thank you!! ☺ tom
You are welcome 🙂
Please consider closing the thread by choosing a correct/helpful answer.
If you're running vCD, you'll want to add/config the vCD adapter. By doing that you'll import the organizational constructs such as vOrg, vApp, etc in to vCOps. Once you have it imported, you can dashboard your heart out with those new containers and relationships. If you have a custom dashboard already, that tells me you've got sufficient licensing to add in the vCD adapter.
I looked at the I/O numbers in the Capacity Overview Report, found disk usage in Mbps and I/O Read/Write in Tps.
What is Tps?? How do I relate the numbers I found in Mbps and Tps to IOPS used??
Or must I find and use something else to understand how much our disks are being used??
The current SAN is all 15k SAS disks so I know it is presently adequate.
Thank you, Tom
Are you running 5.7.1?
TPS = Transfers Per Second, which = IOPS
I never would have known that about Tps. Thank you.
In 1.2.2 Resources at the cluster lever I have:
Host Disk I/O
Reads per
Second
> 1 year 576 Tps / total IOPS for all the hosts??
Host Disk I/O
Writes per
Second
> 1 year 137 Tps / total IOPS for all the hosts??
This means all the hosts are using 576 IOPS read and 137 IOPS write?? Or is this a per-host number??
Am I interpreting/understanding the report correctly??
I have this at the cluster lever -- means all hosts in cluster have done this much IOPS???
and then I have this set of averages per VM??? in 1.3.1 Average VM Profile:
VM Disk I/O Reads per Second 15 Tps x 30 powered on VM = 450 total
VM Disk I/O Writes per Second 3.6 Tps x 30 powered on VM = 108 total
I had way different numbers than this with a Dell Dpack that I did last year, I'm going to redo it next week...
The current disks are 15k disks but they are not large disks...
Thank you, Tom
mark.j wrote:
Are you running 5.7.1?
yes, it's an evaluation version -- thank you, tom
ALSO -- one has no idea how/where vCOPs *gets* these Tps/IOPS numbers, how they are calculated etc., so one has not really a good idea of the measurements. for example, I do not know if NFS storage is included or not...
The capacity planning #s are derived from mainly the storage metrics. The storage metrics are derived from the metrics that are applicable to that particular type of storage based on programmatic selection. NFS storage is included in the capacity planning #s, but since it's not a disk don't expect to see that workload in the "device" or "disk" attribute metrics.
We say IOPs, but it's actually Commands Per Second. Commands Per Second is usually best calculated at the Virtual Disk attribute level, then aggregated as a total for a VM. The Virtual Disks in the environment are also aggregated as a total for Datastores as appropriate.
The reporting/capacity Storage I/O #s run true in vCOps. The Disk Space #s are only skewed by RDMs.
I've done enough looking at vCOPS to realize it thinks datastore usage is way low compared to capacity but vCOPS does not tell anything about how this capacity is even calclated, a number like 8713 Tps is mostly meaningless when you do not know how it's calculated etc.
vCOPS also thinks I have plenty storage and does not appear to allow for or know anything about over-provisioned (thin provisioned) storage versus actually used storage...
Thank you, Tom
Trans per second on the report is Commands Per Second. That is collected from the Virtual Disks. That # is very accurate from a VM-perspective and I observe that repeatedly in many different environments from 6 VMs to 6000 VMs. If you're getting inaccurate readings for a datastore, I:
1. recommend ensuring you're actually collect proper #s from your environment - this includes hosts, VMs, and datastores. Check that you've got Read+StorageView:Views+Global:Health on everything, propagating from the root of vCenter.
2. If you think you're missing metrics, I can tell you point blank to check every single Host System in vCenter to ensure you're actually collecting performance metrics. 25-50% of the environments I see running 5.x Hosts have connection problems with at least 'some' of their hosts that are preventing metric collection - the Hosts connect and function, but if you try checking any performance stats you'll get 0-utilization or No-Data. If vCenter doesn't get the data, vCOps won't. People don't realize this until they start watching with vCOps and wonder why the data looks incomplete.
Let's step back from the Tps for a moment if we're talking about capacity.
The reason why you're saying that vCOps thinks one way or another is due to the way it has been configured. The vCOps capacity planning out of the box will always need adjusting for the environment in which it is running. This includes selecting a capacity planning model (demand/alloca), setting buffers and overcommit for cpu/mem/disk... all of section 3 in the config policy. vCOps CAN take in to account thin-prov disks and show accurate #s however you need to configure it properly.
Some "good things to know" in this post -- excellent.
A couple questions are spurred, though:
1)If hosts sometimes do not connect sufficiently to allow metrics collection - is this a known issue, and is there a way to fix it? Maint mode, reboot, or ... something easier?
2) how to "vCOps CAN take in to account thin-prov disks and show accurate #s however you need to configure it properly" do this? Is it documented anywhere?
On the problem, rebooting the host or restart mgmt agents is ONLY a temp fix that lasts a couple weeks - it will happen again 75%+ of the time. I've seen it perm-fixed usually by disconnect/reconnecting a host, however there have also been instances were there was vcdb corruption and we had to get on the phone with GSS and clean up the DB. Just depends on your environment and situation, really. I always suggest disconnect/reconnect of the host first, see how that works, then if the problem persist give GSS a call.
The cap plan settings are documented pretty well in the manual, but the examples are a bit lacking. If you're running thin prov disks, you'll want to use the demand model on the disk space. Also, you'll want to ensure you've got overalloc levels set in 3c.
So let's say you've got a 100GB datastore. 3a is set to use usable capacity.. using disk space demand model (not alloc)... 3b is set to have a 10% buffer on disk space.. and 3c is set to 50% overallocation. Of this 100GB, you can only use 90GB (due to the 10% usable buffer). Of that 90GB, you can overallocate 50%, so capacity planning with indicate you "can" PROVISION 135GB to that datastore and will indicate to that effect in planning views/reports.
what is "3a, 3c" etc?
Thank you…the only user is the admin user which I assume has full rights as suggested.
I cloned default policy and made a new policy but it’s not obvious anywhere how to make the new policy become the effective policy, I’ll keep looking.
Thank you, Tom