IOPS per vm

I am confused with IOPS in the storage world. Someone will explains.
My understanding is that if you have more spindles and faster disk then your storage will have higher IOPS, hence this will give better performance etc.
I called the storage vendor and he asked me what is IOPS you want, That question stumped me!!
 How do we calculate iops per vm?
My understanding is that more spindles and faster disk will have better IOPS and buy that storage.
Who is Participating?
Carlos IjalbaConnect With a Mentor Senior SysadminCommented:
If someone needs a good and quick IOPS & RAID penalty calculator, use this one:

Sara, today all storage vendors asks how many IOPS you need, since by using a mixture of disk spindles and SSD disks (with ridiculously high IOPS rates) they can offer you a tailored system.

More IOPS are better, as the price also sky-rockets, that's why you need to find out what IOPS you need for your VM's, but this is usually only needed if you are designing a VDI solution, or implementing a IOP hog on a VM (like, for example a DB like -MS SQL Server-, or MS Dynamics).

Otherwise you find out IOPS needed per LUN or Storage Groups.
Andrew Hancock (VMware vExpert / EE MVE^2)VMware and Virtualization ConsultantCommented:
More Disks = More Spindles = More Peformance = More IOPS

But also RAID type can affect performance as well!

CPU will also be increasing, because of lack of IOPS.

just as an example of 5,400 rpm SATA disks, not on a particular fast system

two disks - 84.5 MB/s Write,  150 MB/s Read
four disks - 196 MB/s Write, 276 MB/s Read
eight disks - 212 MB/s Write,  287 MB/s Read

Some very rough quick calculations

Total IOPS = (DriveIOPS * #Drives) / (ReadRatio + (RAIDWritePenalty * WriteRatio))

RAID 10 6 x 7,200 RPM SATA drive - Approx 50 IOPS each disk. assuming 33% Writes

Total IOPS = (50 IOPS x 6 disks)/(.67 + 2*.33))
           = 225 IOPS

RAID 5 6 x 600 SAS 15k Drives - Approx 200 IOPS each disk. assuming 33% writes

Total IOPS = (200 IOPS x 6 disks)/(0.67+4*.33))
           = 603 IOPS

Difference = 378 IOPS

Your DB Administrator or Vendors will have an idea of how many IOPS are required.

What you require is the fatest performing datastore you can afford, do not get too confused with how many IOPS you need per VM, very few know, when asked that question!
7200rev/min / 60 sec/min = 120 rev/sec = 120 IOPS.
Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

Handy HolderSaggar maker's bottom knockerCommented:
You've missed out seek time gheist...

7200rev/min / 60 sec/min = 120 rev/sec = 8.3ms per revolution
Average seek 8.5 ms (from here)
rotational latency + average seek 16.8ms . 1/16.8ms =60 IOPS.

As to the question of what is needed though if the current physical servers are performing OK you can use perfmon or similar tools to get the current IOPS requirements.
Not really.... Seek hapens while disk spins...
Handy HolderSaggar maker's bottom knockerCommented:
The seek has to be completed before the drive starts to read the track and on average one half revolution is needed after the seek/settle time for the head to reach the data.

There is an error in my calculation though, a half revolution is 4.15ms, nevertheless the seek/settle and rotational latency have to be added together. Using 4.15ms for half rotation gives 12.65 ms for an IO, so 79 raw IOPS for a 7.2K disk. There is a fairly accurate list at
vmware writes data in 16MB chunks, so it is mostly sequential access where IOPS matter.
Handy HolderSaggar maker's bottom knockerCommented:
No it doesn't, VMware may use what they call a 16MB block size for VMFS but that's just for disk formatting, it reads and writes using whatever size the virtual machine decides to. If it was to only write in 16MB chunks and the guest was a database that wrote in 4K blocks then the DB would stop dead waiting for VMware to confirm the data was written to the platter while VMware refused to commit the data since there wasn't 16MB queued by then.

You can also tell that from various IOmeter results that use varying "block sizes*", if VMware didn't write the size the guest required then the graphs would look identical for different read/write sizes.

*They should have called the VMFS block size something else to avoid this confusion.
There is command queue on disk. Which in turn means that full seek is done once per queue (like 255 requests)
Handy HolderSaggar maker's bottom knockerCommented:
Indeed, there's also cache on the controller that can improve raw IOPS, nevertheless raw IOPS (implies a queue depth of 1) is the most important starting point. You can ignore seek time if you want but nobody else ignores it.
All Courses

From novice to tech pro — start learning today.