White Papers

VMware vSphere settings
19 Dell EMC PowerVault ME4 Series and VMware vSphere | 3922-BP-VM
6.3 ESXi iSCSI setting: delayed ACK
Delayed ACK is a TCP/IP method of allowing segment acknowledgments to transport upon each other or on
other data that is passed over a connection with the goal of reducing I/O overhead. One side effect of delayed
ACK is that if the pipeline is not filled, acknowledgment of the data is delayed. This can be seen as higher
latency during lower I/O periods. Latency is measured from the time data is sent to when the acknowledgment
is received. With disk I/O, any increase in latency can result in decreased performance. If higher latency
during lower I/O periods is observed in the environment, disabling delayed ACK may resolve the issue.
Otherwise, consult Dell Support.
VMware KB article 1002598 provides additional information, including instructions for disabling delayed ACK
on ESXi.
6.4 Virtual SCSI controllers
When adding additional virtual hard drives (VMDKs) to a virtual machine, there are two virtual SCSI controller
changes that should be considered.
Virtual machines can be configured with additional SCSI controllers. Each SCSI controller not only enables a
greater number of VMDKs to be added to the virtual machine, they also add a separate disk queue. These
separate disk queues can prevent contention for I/O between VMDKs. Adding virtual SCSI controllers
involves the same process as adding any virtual hardware to a virtual machine, through the Edit settings
menu.
There are several virtual SCSI controllers. By default, any additional virtual SCSI controllers will be of the
default type for that guest operating system. For example, the default virtual SCSI controller with Windows
Server 2012 is LSI Logic SAS. However, the VMware Paravirtual (PVSCSI) virtual SCSI controller has a lower
host CPU cost per I/O, freeing up those CPU cycles for more valuable uses. VMware has a detailed white
paper that takes a close look at the IOPS, latency, and cost of the PVSCSI and LSI Logic SAS controllers.
Check the VMware Guest OS Compatibility Guide to ensure that the Paravirtual controller is compatible with
the virtual machine’s operating system.
6.5 Datastore size and virtual machines per datastore
While administrators continually try to maintain optimized data layout and performance, the size of the
datastore becomes a question. Because every environment is different, there is no single answer to the size
and number of LUNs. However, the typical recommendation is 10 to 30 VMs per datastore. Several factors in
this decision include the speed of the disks, RAID type, and workload intensity of the virtual machines.
VMware currently supports a maximum datastore size of 64 TB. However, in most circumstances, a much
smaller, more manageable size would be recommended to accommodate a reasonable number of virtual
machines per datastore. Having one virtual machine per datastore would pose an abundance of
administrative overhead, and putting all virtual machines on a single datastore would likely cause a
performance bottleneck. VMware currently supports a maximum of 2,048 powered-on virtual machines per
VMFS datastore. However, in most circumstances and environments, a target of 15 to 25 virtual machines per
datastore is the conservative recommendation. By maintaining a smaller number of virtual machines per
datastore, potential for I/O contention is greatly reduced, resulting in more consistent performance across the
environment.
Determine the most beneficial compromise by monitoring the performance environment to find volumes that
may be underperforming. In addition, monitor the queue depth with esxtop to see if there are outstanding I/Os