VMware vSphere Best Practices

John Borhek VMware, VMware vSphere March 9, 2022

In this post I have created a general-purpose Best Practices guideline for VMware vSphere, including references. I base these Best Practices recommendations on my personal, and VMsources collective experience, in dealing with hundreds (if not thousands, at this point) of unique client environments over the last decade.

My intent is to help VMware users of all skills and experience levels avoid some of the “gotcha’s” that I have seen, experienced, or heard about from other users.

If you have a Best Practice you would like to see included in this list, or if you feel any of my Best Practices are mis-stated, I welcome input; please contact me by email or phone.

Sincerely,

John Borhek,

Lead Solutions Architect

VMsources Cloud & Infrastructure

Email: john@vmsources.com
Website: https://vmsources.com
Mobile: +1 928.606.0483
Office: +1 215.764.6442 X1001

VMware vSphere Best Practices 3
The DO’s 3
The DO NOT’s 6
vSphere Firewalls 7
Understanding the vCenter VCSA Firewall 7
Example VCSA firewall rules: 7
This example shows: 7
Understanding the ESXi Firewall 8
Example ESXi Firewall rule for client communication: 8
Example ESXi Firewall Rule for AD 9
Example ESXi Firewall rule for vSphere Management Network: 9
These examples show: 9
Endnotes and References 10

VMware vSphere Best Practices

The DO’s

DO use a secure password manager to generate and store strong passwords for all your vSphere and Infrastructure assets
DO set strong passwords for all your vSphere and Infrastructure host and device accounts (Such as: root, SSO administrator, etc.)
DO set vCenter VCSA root and SSO administrator password expiration policy and update the password as specified in that policy.
DO configure vCenter VCSA backups using the VAMI backup utility^[1]
DO configure forward lookup DNS for ESXi Hosts and forward+reverse lookup DNS for vCenter VCSA^[2]
DO use DNS to register/access your VMware vSphere assets such as vCenter and ESXi.
DO Enable Lockdown Mode on ESXi Hosts.^[3]
DO use the ESXi and VCSA firewall to restrict access to specific hosts/networks.^[4] (See: vSphere Firewalls)
DO restrict the vSphere Management Network access, allowing only necessary communications (Such as: NTP, AD, Client) to other networks on the Layer 3 firewall/router.^[5]
DO disable SSH access for the ESXi Hosts and vCenter VCSA whenever not actively using SSH for administration.
DO create specific vCenter Roles per required service (Such as: Veeam Backup and Replication), allowing only the specific privilege(s) required by the service and as published by the OEM of the service.^[6]
DO create Service Accounts on your authentication directory or SSO for vSphere associated services
DO create vCenter Permission(s) associating the service Role with a Service Account, only for the vSphere assets required (Such as: Datacenter, Cluster, Resource Pool, etc.)^[7]
DO minimize use of Virtual Machine Remote Console (VMRC) in all forms (Such as: VMRC extension, Web Console) to ONLY when out-of-band access is required for a VM, using in-band access (Such as: RDP, SSH) for all other administrative access to VMs.^[8]
DO Configure vCenter VCSA email settings.^[9]
DO configure vCenter VCSA alarms with a recipient email address.^[10]
DO create Customization Specifications for VM Deployment and system preparation.^[11]
DO redirect ESXi logfiles to a persistent disk when logs are stored on non-persistent storage^[12]
DO create a persistent scratch location^[13]
DO use vNetwork Distributed Switches for VM and Client Networks if they are a licensed feature.
DO use VLANs to separate networking on Virtual Switches.^[14]
DO use a minimum of 2 NICs per Virtual Switch
DO set virtual Switch Security Policy to reject for Promiscuous Mode, MAC Address Changes, Forged Transmits.^[15]
DO use Beacon Probing as a failover detection method only if there are three or more NICs attached to a Virtual Switch.^[16]
DO use VM Templates to deploy prepared “Golden Imaged” when new VMs are required.
DO set MAC addressees manually (only if required) using the Edit Settings property of the VM.^[17]
DO use VMware Paravirtualized adapters/drivers such as pvscsi and vmxnet3 wherever possible on VMs.^[18]
DO configure additional virtual SCSI adapters per additional virtual disk (up to 4 SCSI adapters for 4 disks).
DO remove unnecessary hardware (Such as: Floppy, CD/DVD, USB) from VM configuration if those devices are not actively being used.
DO provision VM Templates as “thin”.^[19]
DO provision working VMs as either “thin” or “lazy zeroed thick”.xiv
DO provision appropriate use-case disks (Such as: Databases, Transaction Logs and Quorum disks) as “Eager-zeroed”.xiv
DO enable DRS to Fully Automated (if licensed and available). If automatic migration is not desirable, set the migration slider all the way to “conservative,” as this will only allow affinity rules and ESXi host maintenance to take place.
DO configure Affinity Rules to separate Domain Controllers where DRS is enabled.^[20]
DO create folders to organize VMs and delegate access using Permissions
DO create Resource Pools to reserve or limit Compute availability to VMs
DO configure HA advanced options to specify at least two additional Isolation Ping Addresses on your vSphere Management Network.^[21]
DO set HA to shut-down VMs in case of ESXi Host isolation (only if you have also set additional HA Isolation Ping Addresses)
DO set VM Overrides/VM Restart Priority to prioritize specific VMs (Such as: Domain Controllers).^[22]
DO create separate VMkernel(s) for each service (Such as: Management, iSCSI, vMotion, Fault Tolerance, vSAN)
DO use the Software iSCSI adapter/HBA in preference to dedicating a physical NIC to iSCSI as this practice allows for maximum management control.
DO implement port-binding when using the Software iSCSI adapter/HBA iSCSI.^[23]
DO use Jumbo Frames for: iSCSI, vSAN, vMotion, and Fault Tolerance networks/VMkernels.
DO test Jumbo Frames wherever in use using the command: vmkping -I vmkX -d -s 8972 <IP of target> ^[24]
DO check the VMware hardware compatibility list: https://www.vmware.com/go/hcl to make sure your hardware is compatible with the version of VMware vSphere you are installing or upgrading to.
DO use the OEM Customized Installer CDs for the ESXi ISO specific to your server hardware to install or upgrade ESXi. Vendor-customized ISOs are usually available for: Dell, HPE, Cisco, Lenovo, NEC, Fujitsu and more.

The DO NOT’s

DO NOT let root or SSO administrator passwords expire/age out.
DO NOT pervasively access vSphere assets using root or SSO administrator accounts.
DO NOT use AD or directory access for vSphere assets without multi-factor authentication configured and enforced.
DO NOT spoof MAC addresses (if avoidable) using the network driver within the Guest OS of the VM.
DO NOT leave removable media devices (Such as: Floppy and CD/DVD) connected to VMs after use.
DO NOT place iSCSI or vSAN networks on a vNetwork Distributed Switch if avoidable.
DO NOT configure unnecessary CPU or Memory reservations for VMs as that will hinder the ability of other VMs to access resources
DO NOT use VM Affinity as a means of load-balancing in a DRS cluster, this defeats the purpose of DRS

vSphere Firewalls

Understanding the vCenter VCSA Firewall

The vCenter VCSA Firewall is configured per IP or Network (USING CIDR Notation) to Accept or Reject all connections. Be sure to define your Accepted connections first.

Example VCSA firewall rules:

This example shows:

172.20.100.0/24
- Accept the entire VMware vSphere management LAN (necessary for communication with ESXi Hosts, VMware components, and backup platforms)
192.168.99.111/24
- Accept a single host IP address on a common network (such one workstation on an office LAN)
192.168.50.10/32, 192.168.50.11/32
- Accept two single host IP addresses on a common network (such as company AD Domain Controllers)
0.0.0.0/0
- Reject all IP addresses not explicitly Accepted above

Understanding the ESXi Firewall

The ESXi Firewall is configured per service. The reality is that, even if your primary connection to vSphere is through vCenter, you still need to enable a couple of rules on the ESXi Firewall because the VMware Remote Console (VMRC) passes directly from the ESXi Host to the client.

Services necessary for client communication are: vSphere Web Client (443,902) and SSH (22) access (only if you plan on enabling SSH from time to time for administrative or support purposes).

You should allow only services necessary for client communication to pass from the ESXi Host to authorized administrators.

All other enabled services (has a checkbox to the left of the ESXi Firewall rule) should be allowed to the vSphere Management Network, and/or other specific network/Host IP as required by the specific service/group, such as AD or NTP on a per-service/group basis.

Example ESXi Firewall rule for client communication:

Example ESXi Firewall Rule for AD

Example ESXi Firewall rule for vSphere Management Network:

These examples show:

192.168.50.10, 192.168.50.11
- Allow communication with AD Domain Controllers which may not be on the vSphere management network
192.168.99.111
- Allow communication with a single host IP address on a common network (such one workstation on an office LAN)
172.20.100.0/24
- Allow the entire VMware vSphere management LAN (necessary for communication with ESXi Hosts, VMware components, and backup platforms)

Endnotes and References

Tags: Best Practices, ESXi, vCenter, VCSA, VMware vSphere

VMware vSphere Best Practices

Contents

VMware vSphere Best Practices

The DO’s

The DO NOT’s

vSphere Firewalls

Understanding the vCenter VCSA Firewall

Example VCSA firewall rules:

This example shows:

Understanding the ESXi Firewall

Example ESXi Firewall rule for client communication:

Example ESXi Firewall Rule for AD

Example ESXi Firewall rule for vSphere Management Network:

These examples show:

Endnotes and References

About: John Borhek

Leave a Reply Cancel reply