Make sure that the host meets the minimum hardware configurations supported by ESXi 7.0.
Hardware and System Resources
To install or upgrade ESXi, your hardware and system resources must meet the following requirements:
- Supported server platform. For a list of supported platforms, see the VMware Compatibility Guide at http://www.vmware.com/resources/compatibility.
- ESXi 7.0 requires a host with at least two CPU cores.
- ESXi 7.0 supports a broad range of multi-core of 64-bit x86 processors. For a complete list of supported processors, see the VMware compatibility guide at http://www.vmware.com/resources/compatibility.
- ESXi 7.0 requires the NX/XD bit to be enabled for the CPU in the BIOS.
- ESXi 7.0 requires a minimum of 8 GB of physical RAM. Provide at least 8 GB of RAM to run virtual machines in typical production environments.
- To support 64-bit virtual machines, support for hardware virtualization (Intel VT-x or AMD RVI) must be enabled on x64 CPUs.
- One or more Gigabit or faster Ethernet controllers. For a list of supported network adapter models, see the VMware Compatibility Guide at http://www.vmware.com/resources/compatibility.
- ESXi 7.0 requires a boot disk of at least 32 GB of persistent storage such as HDD, SSD, or NVMe. Use USB, SD and non-USB flash media devices only for ESXi boot bank partitions. A boot device must not be shared between ESXi hosts.
- SCSI disk or a local, non-network, RAID LUN with unpartitioned space for the virtual machines.
- For Serial ATA (SATA), a disk connected through supported SAS controllers or supported on-board SATA controllers. SATA disks are considered remote, not local. These disks are not used as a scratch partition by default because they are seen as remote.
Note: You cannot connect a SATA CD-ROM device to a virtual machine on an ESXi host. To use the SATA CD-ROM device, you must use IDE emulation mode.
For a list of supported storage systems, see the VMware Compatibility Guide at http://www.vmware.com/resources/compatibility. For Software Fibre Channel over Ethernet (FCoE), see Installing and Booting ESXi with Software FCoE.
ESXi Booting Requirements
vSphere 7.0 supports booting ESXi hosts from the Unified Extensible Firmware Interface (UEFI). With UEFI, you can boot systems from hard drives, CD-ROM drives, or USB media.
vSphere Auto Deploy supports network booting and provisioning of ESXi hosts with UEFI.
ESXi can boot from a disk larger than 2 TB if the system firmware and the firmware on any add-in card that you are using support it. See the vendor documentation.
Storage Requirements for ESXi 7.0 Installation or Upgrade
For best performance of an ESXi 7.0 installation, use a persistent storage device that is a minimum of 32 GB for boot devices. Upgrading to ESXi 7.0 requires a boot device that is a minimum of 8 GB. When booting from a local disk, SAN or iSCSI LUN, at least a 32 GB disk is required to allow for the creation of system storage volumes, which include a boot partition, boot banks, and a VMFS-L based ESX-OSData volume. The ESX-OSData volume takes on the role of the legacy /scratch partition, locker partition for VMware Tools, and core dump destination.
Other options for best performance of an ESXi 7.0 installation are the following:
- A local disk of 128 GB or larger for optimal support of ESX-OSData. The disk contains the boot partition, ESX-OSData volume and a VMFS datastore.
- A device that supports the minimum of 128 terabytes written (TBW).
- A device that delivers at least 100 MB/s of sequential write speed.
- To provide resiliency in case of device failure, a RAID 1 mirrored device is recommended.
Legacy SD and USB devices are supported with the following limitations:
- SD and USB devices are supported for boot bank partitions. For best performance, also provide a separate persistent local device with a minimum of 32 GB to store the /scratch and VMware Tools partitions of the ESX-OSData volume. The optimal capacity for persistent local devices is 128 GB. The use of SD and USB devices for storing ESX-OSData partitions is being deprecated.
- Starting with ESXi 7.0 Update 3, if the boot device is a USB or SD card with no local persistent storage, such as HDD, SSD, or a NVMe device, the VMware Tools partition is automatically created on the RAM disk. For more information, see Knowledge Base article 83376.
- If you assign the /scratch partition to a USB or SD card with no local persistent storage, you see warnings to prevent you from creating or configuring partitions other than the boot bank partitions on flash media devices. For best performance, set the /scratch partition on the RAM disk. You can also configure and move the /scratch partition to a SAN or NFS. For more information, see Knowledge Base article 1033696.
- You must use an SD flash device that is approved by the server vendor for the particular server model on which you want to install ESXi on an SD flash storage device. You can find a list of validated devices on partnerweb.vmware.com.
- See Knowledge Base article 85685 on updated guidance for SD card or USB-based environments.
- To chose a proper SD or USB boot device, see Knowledge Base article 82515.
If a local disk cannot be found, or the boot media is a USB or SD device without an additional durable storage for persistent data, then the /scratch partition is on the RAM disk, linked to /tmp, and ESXi 7.0 operates in degraded mode.
When in degraded mode, you see a System Alert such as: ALERT: No persistent storage available for system logs and data. ESX is operating with limited system storage space, logs and system data will be lost on reboot.
When ESXi 7.0 operates in degraded mode, the consumption of RAM for logs might result in nonpersistent logs, possible failure to log or out of memory condition for temporary data. A possible side effect is slow booting due to the time spent for rebuilding of the disk state.
Use persistent storage of sufficient size to prevent degraded mode. You can reconfigure /scratch to use a separate disk or LUN.
The upgrade process to ESXi 7.0 repartitions the boot device and consolidates the original core dump, locker, and scratch partitions into the ESX-OSData volume.
- If a custom core dump destination is not configured, then the default core dump location is a file in the ESX-OSData volume.
- If the syslog service is configured to store log files on the 4 GB VFAT scratch partition, the log files in var/run/log are migrated to the ESX-OSData volume.
- VMware Tools are migrated from the locker partition and the partition is wiped.
- The core dump partition is wiped. The application core dump files that are stored on the scratch partition are deleted.
If you use USB or SD devices to perform an upgrade, the installer attempts to allocate an ESX-OSData region on an available local disk. A datastore is used for /scratch, if no space is available. If no local disk or datastore is found, /scratch is placed on the RAM disk. After the upgrade, reconfigure /scratch to use a persistent datastore or add a new disk for system storage volumes.
For more information on reconfiguring the /scratch partition, see the vCenter Server Installation and Setup documentation.
After upgrading to ESXi 7.0, you can add a new local disk and enable the setting
autoPartition=TRUE. After a reboot, the boot disk is partitioned. For more information on the boot options to configure the size of ESXi system partitions, see Knowledge Base article https://kb.vmware.com/s/article/81166.
In Auto Deploy installations, the installer attempts to allocate a scratch region on an available local disk or datastore. If no local disk or datastore is found, the /scratch partition is placed on the RAM disk. Reconfigure /scratch to use a persistent datastore after the installation.
For environments that boot from a SAN or use Auto Deploy, the ESX-OSData volume for each ESXi host must be set up on a separate SAN LUN. However, if /scratch is configured not to use ESX-OSData, you do not need to allocate a separate LUN for /scratch for each host. You can co-locate the scratch regions for multiple ESXi hosts onto a single LUN. The number of hosts assigned to any single LUN should be weighed against the LUN size and the I/O behavior of the virtual machines.