Home > Storage > Unity XT > Virtualization, Cloud & Applications > Dell EMC Unity: VMware vSphere Best Practices > iSCSI LUNs
Dell Technologies Unity LUNs presented to vSphere hosts through iSCSI should utilize the following best practices.
On the Dell Technologies Unity array (in Unisphere click Settings > Access > Ethernet), as well as on all vSphere hosts accessing its iSCSI storage, the MTU size should be set to 9000 to enable the transmission of large blocks of data, which is more efficient than the default MTU size with block-based storage. Additionally, all Ethernet switches in the iSCSI data path must support jumbo frames. Refer to the specific switch configuration guide for instructions on enabling jumbo frames.
In some environments, periods of high network congestion can cause iSCSI transfer latency to exceed acceptable levels. To avoid this, VMware recommends disabling delayed ACK following the steps provided in the VMware Knowledge Base article ESX/ESXi hosts might experience read or write performance issues with certain storage arrays
Determining the size and number of LUNs to create and present to your vSphere environment is a complex task. This section does not provide specific recommendations for the size and number of LUNs because every environment is different, but it provides guidance for identifying the most effective configuration for your environment.
VMware currently supports a maximum datastore size of 64 TB. However, in most circumstances, a much smaller, more manageable size is recommended to accommodate a reasonable number of virtual machines (VMs) per datastore (learn more in section 3.5.2). Since LUNs and vSphere datastores can be expanded to address future growth, the recommendation is to create LUNs and datastores with sizes in the range of 500–750 GB for most environments. This size of datastore accommodates 10–15 virtual machines with a 40 GB virtual disk and provides the additional capacity required for the various overhead files for each virtual.
Note: This sizing recommendation supports limitations on the number of virtual machines on each datastore to keep performance optimal. This recommendation does not take into consideration high-capacity virtual machines. Virtual machines requiring a large virtual disk would require a larger LUN/datastore size and would not be exempt from these best practices.
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–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. For this reason, the recommended LUN/datastore size is 1–3 TB.
Note: The virtual-machines-per-datastore recommendation should be adjusted to support your environment. The appropriate number should be based on the I/O and capacity requirements for your specific environment.
Dell Technologies Unity block LUNs where VMFS datastores are created do not require alignment because VMFS automatically aligns the partition at creation time.
When creating a new virtual machine, vSphere automatically selects the recommended virtual SCSI controller based on the operating system being installed to the VM. The best practice is to maintain the automatically selected virtual SCSI controller under most circumstances. In some cases, changing to the VMware Paravirtual SCSI controller may result in better I/O performance as well as reduced CPU utilization on the VM. Also, configure the SCSI controller driver in the guest operating system to a large enough queue.
Thin provisioning of storage, from both Dell Technologies Unity storage and virtual disks created as part of a virtual machine, allows for increased space efficiency in the storage environment. Thinly provisioned storage can be configured with substantial sizes but will only occupy the storage capacity required to accommodate the actual storage needs. This ability reduces upfront storage costs in many cases and allows for a more manageable and predictable storage growth over time.
When creating a virtual machine, one or more virtual disks are created as part of the virtual hardware of that virtual machine. There are three virtual disk formats to choose from:
Thick provision lazy zeroed: A small amount of space is used for the virtual disk at the time of creation. New blocks of data are only allocated during write operations. However, before data is written to new blocks, vSphere will first zero the block to ensure write integrity. This process introduces additional I/O and latency when writes occur and could potentially affect latency-sensitive applications.
Thick provision eager zeroed: The space required for the virtual disk is fully allocated at the time of creation. All data blocks for the virtual disk are zeroed during creation. This format takes longer to prepare than other formats, but because all data blocks have been zeroed, there are no I/O penalties as found with other formats. However, there is no realized space efficiency with this format either, since all space has been consumed in the zeroing process.
Thin provisioned: This format does not allocate all the logical space for the virtual disk at creation. Rather, logical space is allocated on demand during the first write issued to the block. Like the thick provision lazy zeroed disk, blocks are zeroed prior to first write, introducing additional I/O and latency.
The default virtual disk format is thick provision lazy zeroed. The best practice is to use the default virtual disk format unless specific needs dictate the use of thick provisioned eager zeroed for performance or availability needs including Microsoft Cluster Service (MSCS) and VMware Fault Tolerance (FT).
With the release of vSphere 8.0, VMware has improved the first-write process when using thin provisioned VMDKs. While VMware still recommends using Eager Zeroed Thick (EZT) virtual disks for maximum performance, this new method should decrease much of