VMware ESXi Upgrade

02 APR 2020
Modified on 30 APR 2020
VMware vSphere 7.0
VMware ESXi 7.0
VMware ESXi Upgrade

You can find the most up-to-date technical documentation on the VMware website at:

https://docs.vmware.com/

If you have comments about this documentation, submit your feedback to

[email protected]

VMware, Inc.
3401 Hillview Ave.
Palo Alto, CA 94304
www.vmware.com

©
Copyrigh 2018-2020 VMware, Inc. All rights reserved. Copyright and trademark information.
t

VMware,
2
 Contents

1 About VMware ESXi Upgrade 5

Updated Information 6

2 vCenter Server Upgrade Options 7

Overview of the vSphere Upgrade Process 7
Overview of the ESXi Host Upgrade Process 9
Upgrading Virtual Machines and VMware Tools
11

3 Upgrading ESXi Hosts 12

ESXi Requirements 12
ESXi Hardware Requirements 12
Supported Remote Management Server Models and Firmware Versions 15
Recommendations for Enhanced ESXi Performance 15
Incoming and Outgoing Firewall Ports for ESXi Hosts 16
Required Free Space for System Logging 19
VMware Host Client System Requirements 20
ESXi Passwords and Account Lockout 20
Before Upgrading ESXi Hosts 22
Upgrading Hosts That Have Third-Party Custom VIBs 24
Media Options for Booting the ESXi Installer 24
Using Remote Management Applications 34
Download the ESXi Installer 34
Storage Device Names and Identifiers 35
Upgrade Hosts Interactively 36
Installing or Upgrading Hosts by Using a Script 37
Enter Boot Options to Start an Installation or Upgrade Script 38
Boot Options 39
About Installation and Upgrade Scripts 40
Install or Upgrade ESXi from a CD or DVD by Using a Script 51
Install or Upgrade ESXi from a USB Flash Drive by Using a Script 52
Performing a Scripted Installation or Upgrade of ESXi by Using PXE to Boot the Installer 53
PXE Booting the ESXi Installer 54
Overview of the PXE Boot Installation Process 54
PXE Boot the ESXi Installer Using TFTP 56
PXE Boot the ESXi Installer Using a Web Server 58
Upgrading Hosts by Using ESXCLI Commands 61
VIBs, Image Profiles, and Software Depots 61

VMware,
3
VMware ESXi

Understanding Acceptance Levels for VIBs and Hosts 62

Determine Whether an Update Requires a Host to Be in Maintenance Mode or to Be Rebooted 64
Place a Host in Maintenance Mode 65
Update a Host with Individual VIBs 67
Upgrade or Update a Host with Image Profiles 68
Update ESXi Hosts by Using Zip Files 71
Remove VIBs from a Host 72
Adding Third-Party Extensions to Hosts with an ESXCLI Command 74
Perform a Dry Run of an ESXCLI Installation or Upgrade 74
Display the Installed VIBs and Profiles That Will Be Active After the Next Host Reboot 75
Display the Image Profile and Acceptance Level of the Host 75
After You Upgrade ESXi Hosts 76
About ESXi Evaluation and Licensed Modes 76
Licensing ESXi Hosts After Upgrade 77
Run the Secure Boot Validation Script on an Upgraded ESXi Host 77
Required Free Space for System Logging 78
Configure Syslog on ESXi Hosts 79

4 Using vSphere Auto Deploy to Reprovision Hosts 81

Introduction to vSphere Auto Deploy 81
Preparing for vSphere Auto Deploy 84
Prepare Your System for vSphere Auto Deploy 84
Using vSphere Auto Deploy Cmdlets 87
Set Up Bulk Licensing 88
Reprovisioning Hosts 89
Reprovision Hosts with Simple Reboot Operations 90
Reprovision a Host with a New Image Profile by Using PowerCLI 90
Write a Rule and Assign a Host Profile to Hosts 92
Test and Repair Rule Compliance 93

5 Collect Logs to Troubleshoot ESXi Hosts 96

VMware,
4
 1
About VMware ESXi Upgrade

VMware ESXi Upgrade describes how to upgrade VMware ESXi™ to the current version.

Intended Audience
VMware ESXi Upgrade is for anyone who needs to upgrade from earlier versions of ESXi. These topics
are for experienced Microsoft Windows or Linux system administrators who are familiar with virtual
machine technology and data center operations.

VMware,
5
Updated Information

This VMware ESXi Upgrade guide is updated with each release of the product or when necessary.

This table provides the update history of the VMware ESXi Upgrade guide.

Revision Description

30 APR 2020 n Updated local disk size values for a boot partition with a VMFS datastore in ESXi Hardware Requirements.
n Added ESXi 7.0 rollback information in ESXi Hardware Requirements.

02 APR 2020 Initial release.

VMware,
6
 2
vCenter Server Upgrade Options

vCenter Server 7.0 provides many options for upgrading your vCenter Server deployment. For a
successful vCenter Server upgrade, you must understand the upgrade options, the configuration details
that impact the upgrade process, and the sequence of tasks.

The two core components of vSphere are VMware ESXi™ and VMware vCenter Server™. ESXi is the
virtualization platform on which you can create and run virtual machines and virtual appliances. vCenter
Server is a service that acts as a central administrator for ESXi hosts connected in a network. You use the
vCenter Server system to pool and manage the resources of multiple hosts. vCenter Server appliance is
a preconfigured virtual machine optimized to run vCenter Server.

You can upgrade existing vCenter Server deployments using either an embedded or an external Platform
Services Controller to a deployment consisting of a vCenter Server appliance.

This chapter includes the following topics:

n Overview of the vSphere Upgrade Process

Overview of the vSphere Upgrade Process

vSphere is a sophisticated product with multiple components to upgrade. Understanding the required
sequence of tasks is vital for a successful vSphere upgrade.

VMware,
7
VMware ESXi

Figure 2-1. Overview of vSphere Upgrade Tasks

Start vSphere upgrade

Back up your configuration

Upgrade vCenter Server

Upgrade ESXi hosts

Upgrade virtual machines

Upgrade to vSphere 7.0 complete

Upgrading vSphere includes the following tasks:

1 Read the vSphere release notes.

2 Verify that you have backed up your configuration.

3 If your vSphere system includes VMware solutions or plug-ins, verify that they are compatible with the
vCenter Server appliance version to which you are upgrading. See VMware Product Interoperability
Matrix at http://www.vmware.com/resources/compatibility/sim/interop_matrix.php.

4 Upgrade vCenter Server.

For detailed instructions, see vCenter Server Upgrade

5 Upgrade your ESXi hosts. See Overview of the ESXi Host Upgrade Process.

6 To ensure sufficient disk storage for log files, consider setting up a syslog server for remote
logging. Setting up logging on a remote host is especially important for hosts with a limited amount
of local storage.

See Required Free Space for System Logging and Configure Syslog on ESXi Hosts.

7 Upgrade your VMs manually or by using vSphere Lifecycle Manager, to perform an orchestrated
upgrade.

See Upgrading Virtual Machines and VMware Tools

VMware,
8
VMware ESXi

Overview of the ESXi Host Upgrade Process

VMware provides several ways to upgrade ESXi hosts with version 6.5 and version 6.7 to ESXi version
7.0.

The details and level of support for an upgrade to ESXi 7.0 depend on the host to be upgraded and the
upgrade method that you use. Verify that the upgrade path from your current version of ESXi to the
version to which you are upgrading, is supported. For more information, see the VMware Product
Interoperability Matrices at http://www.vmware.com/resources/compatibility/sim/interop_matrix.php.

You can upgrade an ESXi host with version 6.5 or 6.7 by using an interactive upgrade from a CD, DVD, or
USB, a scripted upgrade, ESXCLI, or vSphere Lifecycle Manager. When you upgrade an ESXi 6.5 or 6.7
host that has custom VIBs to version 7.0, all supported custom VIBs are migrated. For more information,
see Upgrading Hosts That Have Third-Party Custom VIBs.

Figure 2-2. Overview of the ESXi Host Upgrade Process

Start ESXi upgrade

Verify requirements are met

Choose
your
upgrade
method

Prepare for ESXi host upgrade Prepare for ESXI host Prepare for ESXi host upgrade
upgrade with Auto Deploy with vSphere Lifecycle Manager

Upgrade ESXi hosts using

Upgrade ESXi hosts using
the GUI, script, or CLI Upgrade ESXi hosts
vSphere Lifecycle Manager
using Auto Deploy

Perform post-upgrade tasks

Upgrade to ESXi 7.0 complete

VMware,
9
VMware ESXi

The following high-level steps are for upgrading ESXi.

1 Verify that your system meets the upgrade requirements. See ESXi Requirements.

2 Prepare your environment before upgrading. See Before Upgrading ESXi Hosts.

3 Determine where you want to locate and boot the ESXi installer. See Media Options for Booting the
ESXi Installer. If you are PXE-booting the installer, verify that your preboot execution environment
(PXE) and network infrastructure is properly set up. See PXE Booting the ESXi Installer.

4 Upgrade ESXi. See Chapter 3 Upgrading ESXi Hosts

5 After upgrading ESXi hosts, you must reconnect the hosts to the vCenter Server and reapply the
licenses. See After You Upgrade ESXi Hosts.

The following methods are supported for a direct upgrade to ESXi 7.0.

n Use the interactive graphical user interface (GUI) installer from a CD, DVD, or USB drive.

n Perform a scripted upgrade.

n Use ESXCLI.

n Use vSphere Auto Deploy. If the ESXi host is deployed by using vSphere Auto Deploy, you can use
vSphere Auto Deploy to reprovision the host with a 7.0 image.

n Use the vSphere Lifecycle Manager.

Graphical User Interface (GUI) Installer

You can upgrade interactively by using an ESXi installer ISO image on a CD, DVD, or USB flash drive
or by specifying a PXE. This method is appropriate for deployments with a few hosts. If during the
installation process, you select a target disk that contains an ESXi installation, the installer upgrades
the host to ESXi version 7.0. The installer also gives you the option to migrate some existing host
settings and configuration files and to preserve the existing VMFS datastore. See Upgrade Hosts
Interactively.

Perform a Scripted Upgrade

You can use the ESXi 7.0 installer from a CD, DVD, or USB flash drive or by specifying a PXE to do a
scripted upgrade. This method is an efficient way to deploy multiple hosts. For more information, see
Installing or Upgrading Hosts by Using a Script.

ESXCLI

You can use ESXCLI to upgrade ESXi 6.5 hosts or ESXi 6.7 hosts to ESXi 7.0 hosts. See Upgrading
Hosts by Using ESXCLI Commands .

vSphere Auto Deploy

If an ESXi host is deployed with vSphere Auto Deploy, you can use vSphere Auto Deploy to
reprovision the host and reboot it with a new image profile. Such profile contains an ESXi upgrade or
patch, a host configuration profile, and optionally, third-party drivers or management agents that are

VMware,
1
VMware ESXi

provided by VMware partners. You can build custom images by using vSphere ESXi Image Builder
CLI. For more information, see Chapter 4 Using vSphere Auto Deploy to Reprovision Hosts .

vSphere Lifecycle Manager

vSphere Lifecycle Manager is a vCenter Server service for installing, upgrading, and updating ESXi
hosts. By using images and baselines, vSphere Lifecycle Manager enables centralized and simplified
lifecycle management for multiple ESXi hosts at a cluster level. For more information about
performing orchestrated installations, upgrades, and updates, see the Managing Host and Cluster
Lifecycle documentation.

Upgrading Virtual Machines and VMware Tools

After you upgrade an ESXi host, you can upgrade the virtual machines on the host to take advantage of
new features.

You have the following tools for upgrading virtual machines.

vSphere Client

You can use the vSphere Client to upgrade a virtual machine step by step. For more information
about upgrading virtual machines, see the vSphere Virtual Machine Administration documentation.

vSphere Lifecycle Manager

You can use the vSphere Lifecycle Manager to upgrade the virtual machine hardware and VMware
Tools versions of the virtual machines in your environment. The vSphere Lifecycle Manager
automates the upgrade process and verifies that the steps occur in the correct order. For more
information, see the Managing Host and Cluster Lifecycle documentation.

VMware,
1
 3
Upgrading ESXi Hosts

After you upgrade vCenter Server, upgrade your ESXi hosts. You can upgrade ESXi 6.5 and 6.7
hosts directly to ESXi 7.0.

To upgrade hosts, you can use the tools and methods that are described in Overview of the ESXi
Host Upgrade Process.

Caution If you upgrade hosts managed by vCenter Server, you must upgrade vCenter Server before
you upgrade the ESXi hosts. If you do not upgrade your environment in the correct order, you can lose
data and lose access to servers.

This chapter includes the following topics:

n ESXi Requirements

n Before Upgrading ESXi Hosts

n Storage Device Names and Identifiers

n Upgrade Hosts Interactively

n Installing or Upgrading Hosts by Using a Script

n PXE Booting the ESXi Installer

n Upgrading Hosts by Using ESXCLI Commands

n After You Upgrade ESXi Hosts

ESXi Requirements
To install or upgrade ESXi, your system must meet specific hardware and software requirements.

ESXi Hardware Requirements

Make sure that the host meets the minimum hardware configurations supported by ESXi 7.0.

VMware,
1
VMware ESXi

Hardware and System Resources

To install or upgrade ESXi, your hardware and system resources must meet the following requirements:

n Supported server platform. For a list of supported platforms, see the VMware Compatibility Guide at
http://www.vmware.com/resources/compatibility.

n ESXi 7.0 requires a host with at least two CPU cores.

n 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.

n ESXi 7.0 requires the NX/XD bit to be enabled for the CPU in the BIOS.

n ESXi 7.0 requires a minimum of 4 GB of physical RAM. Provide at least 8 GB of RAM to run virtual
machines in typical production environments.

n To support 64-bit virtual machines, support for hardware virtualization (Intel VT-x or AMD RVI)
must be enabled on x64 CPUs.

n 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.

n ESXi 7.0 requires a boot disk of at least 8 GB for USB or SD devices, and 32 GB for other device
types such as HDD, SSD, or NVMe. A boot device must not be shared between ESXi hosts.

n SCSI disk or a local, non-network, RAID LUN with unpartitioned space for the virtual machines.

n 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.

Storage Systems
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.

VMware 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.

VMware,
1
 VMware ESXi

Storage Requirements for ESXi 7.0 Installation or Upgrade

Installing ESXi 7.0 requires a boot device that is a minimum of 8 GB for USB or SD devices, and 32 GB
for other device types. Upgrading to ESXi 7.0 requires a boot device that is a minimum of 4 GB. When
booting from a local disk, SAN or iSCSI LUN, 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, VM-tools, and core dump
destination.

The recommended ESXi 7.0 install options are the following:

n An 8 GB USB or SD and an additional 32 GB local disk. The ESXi boot partitions reside on the USB
or SD and the ESX-OSData volume resides on the local disk.

n A local disk with a minimum of 32 GB. The disk contains the boot partitions and ESX-OSData volume.

n A local disk of 142 GB or larger. The disk contains the boot partitions, ESX-OSData volume, and
VMFS datastore.

The ESXi 7.0 system storage volumes can occupy up to 138 GB of disk space. A VMFS datastore is only
created if the local disk device has at least 4 GB additional free space. To share a boot device with a
local VMFS datastore, you need to use a local disk of 142 GB or larger.

If a local disk cannot be found, then ESXi 7.0 operates in degraded mode where certain functionality is
disabled and the /scratch partition is on the RAM disk, linked to /tmp. You can reconfigure /scratch to
use a separate disk or LUN. For best performance and memory optimization, do not run ESXi in
degraded mode.

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.

Note Rollback to an earlier version of ESXi is not possible due to the repartitioning process of the boot
device. To use an earlier version of ESXi after upgrading to version 7.0, you must create a backup of
the boot device before the upgrade, and restore the ESXi boot device from the backup.

Due to the I/O sensitivity of USB and SD devices, the installer only creates a VMFS-L locker partition on
these devices to store VM-tools and core dump files. When installing or upgrading on USB or SD devices,
the installer attempts to allocate an ESX-OSData region on an available local disk. A datastore is used
for /scratch, if there is no available space. If no local disk or datastore is found, /scratch is placed on
the RAM disk. After the installation or 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.

Although an 8 GB USB or SD device is sufficient for a minimal installation, you should use a larger
device. The additional space is used for an expanded core dump file and the extra flash cells of a high-
quality USB flash drive can prolong the life of the boot media. Use a 32 GB or larger high-quality USB
flash drive. See Knowledge Base article http://kb.vmware.com/kb/2004784.

VMware,
1
 VMware ESXi

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.

ESXi 7.0 Installation on M.2 and Other Non-USB Low-End Flash Media
Unlike USB flash devices, the ESXi installer creates system storage volumes and a VMFS datastore on
M.2 and other non-USB low-end flash media. If you deploy a virtual machine or migrate a virtual machine
to this boot device datastore, the boot device can be worn out quickly depending on the endurance of the
flash device and the characteristics of the workload. As even read-only workloads can cause problems on
low-end flash devices, you should install ESXi only on high-endurance flash media.

Important If you install ESXi on M.2 or other non-USB low-end flash media, delete the VMFS datastore
on the device immediately after installation. For more information on removing VMFS datastores, see the
vSphere Storage documentation.

Supported Remote Management Server Models and Firmware

Versions
You can use remote management applications to install or upgrade ESXi, or to manage hosts remotely.

Table 3-1. Supported Remote Management Server Models and Minimum Firmware Versions
Remote Management Server Model Firmware Version Java

Dell DRAC 7 1.30.30 (Build 43) 1.7.0_60-b19

Dell DRAC 6 1.54 (Build 15), 1.70 (Build 21) 1.6.0_24

Dell DRAC 5 1.0, 1.45, 1.51 1.6.0_20,1.6.0_203

Dell DRAC 4 1.75 1.6.0_23

HP ILO 1.81, 1.92 1.6.0_22, 1.6.0_23

HP ILO 2 1.8, 1.81 1.6.0_20, 1.6.0_23

HP ILO 3 1.28 1.7.0_60-b19

HP ILO 4 1.13 1.7.0_60-b19

IBM RSA 2 1.03, 1.2 1.6.0_22

Recommendations for Enhanced ESXi Performance

To enhance performance, install or upgrade ESXi on a robust system with more RAM than the minimum
required and with multiple physical disks.

For ESXi system requirements, see ESXi Hardware Requirements.

VMware,
1
 VMware ESXi

Table 3-2. Recommendations for Enhanced Performance

System Element Recommendation

RAM ESXi hosts require more RAM than typical servers. Provide at
least 8 GB of RAM to take full advantage of ESXi features and
run virtual machines in typical production environments. An
ESXi host must have sufficient RAM to run concurrent virtual
machines. The following examples are provided to help you
calculate the RAM required by the virtual machines running on
the ESXi host.
Operating four virtual machines with Red Hat Enterprise Linux or
Windows XP requires at least 3 GB of RAM for baseline
performance. This figure includes 1024 MB for the virtual
machines, 256 MB minimum for each operating system as
recommended by vendors.
Running these four virtual machines with 512 MB RAM requires
that the ESXi host have 4 GB RAM, which includes 2048 MB
for the virtual machines.
These calculations do not include possible memory savings from
using variable overhead memory for each virtual machine. See
vSphere Resource Management.

Dedicated Fast Ethernet adapters for virtual machines Place the management network and virtual machine networks
on different physical network cards. Dedicated Gigabit Ethernet
cards for virtual machines, such as Intel PRO 1000 adapters,
improve throughput to virtual machines with high network traffic.

Disk location Place all data that your virtual machines use on physical disks
allocated specifically to virtual machines. Performance is better
when you do not place your virtual machines on the disk
containing the ESXi boot image. Use physical disks that are
large enough to hold disk images that all the virtual machines
use.

VMFS6 partitioning The ESXi installer creates the initial VMFS volumes on the first
blank local disk found. To add disks or modify the original
configuration, use the vSphere Client. This practice ensures that
the starting sectors of partitions are 64K-aligned, which
improves storage performance.

Note For SAS-only environments, the installer might not format

the disks. For some SAS disks, it is not possible to identify
whether the disks are local or remote. After the installation, you
can use the vSphere Client to set up VMFS.

Processors
Faster processors improve ESXi performance. For certain
workloads, larger caches improve ESXi performance.
Hardware compatibility Use devices in your server that are supported by ESXi 7.0
drivers. See the Hardware Compatibility Guide at http://
www.vmware.com/resources/compatibility.

Incoming and Outgoing Firewall Ports for ESXi Hosts

The vSphere Client and the VMware Host Client allow you to open and close firewall ports for each
service or to allow traffic from selected IP addresses.

VMware,
1
 VMware ESXi

The following table lists the firewalls for services that are installed by default. If you install other VIBs on
your host, additional services and firewall ports might become available. The information is primarily for
services that are visible in the vSphere Client but the table includes some other ports as well.

Table 3-3. Incoming Firewall Connections

Protoc
Port ol Service Description

5988 TCP CIM Server Server for CIM (Common Information Model).

5989 TCP CIM Secure Server Secure server for CIM.

427 TCP, CIM SLP The CIM client uses the Service Location Protocol, version 2 (SLPv2) to find
UDP CIM servers.

546 DHCPv6 DHCP client for IPv6.

8301, 8302 UDP DVSSync DVSSync ports are used for synchronizing states of distributed virtual ports
between hosts that have VMware FT record/replay enabled. Only hosts that
run primary or backup virtual machines must have these ports open. On hosts
that are not using VMware FT these ports do not have to be open.

902 TCP NFC Network File Copy (NFC) provides a file-type-aware FTP service for vSphere
components. ESXi uses NFC for operations such as copying and moving data
between datastores by default.

12345, 23451 UDP vSAN Clustering VMware vSAN Cluster Monitoring and Membership Directory Service. Uses
Service UDP-based IP multicast to establish cluster members and distribute vSAN
metadata to all cluster members. If disabled, vSAN does not work.

68 UDP DHCP Client DHCP client for IPv4.

53 UDP DNS Client DNS client.

8200, 8100, TCP, Fault Tolerance Traffic between hosts for vSphere Fault Tolerance (FT).
8300 UDP

6999 UDP NSX Distributed NSX Virtual Distributed Router service. The firewall port associated with this
Logical Router service is opened when NSX VIBs are installed and the VDR module is
Service created. If no VDR instances are associated with the host, the port does not
have to be open.
This service was called NSX Distributed Logical Router in earlier versions of
the product.

2233 TCP vSAN Transport vSAN reliable datagram transport. Uses TCP and is used for vSAN storage
IO. If disabled, vSAN does not work.

161 UDP SNMP Server Allows the host to connect to an SNMP server.

22 TCP SSH Server Required for SSH access.

8000 TCP vMotion Required for a virtual machine migration with vMotion. ESXi hosts listen on
port 8000 for TCP connections from remote ESXi hosts for vMotion traffic.

8080 TCP vsanvp vSAN VASA Vendor Provider. Used by the Storage Management Service
(SMS) that is part of vCenter to access information about vSAN storage
profiles, capabilities, and compliance. If disabled, vSAN Storage Profile Based
Management (SPBM) does not work.

80 TCP vSphere Web Access Welcome page, with download links for different interfaces.

5900 -5964 TCP RFB protocol

VMware,
1
 VMware ESXi

Table 3-3. Incoming Firewall Connections (continued)

Protoc
Port ol Service Description

80, 9000 TCP vSphere Lifecycle

Manager

9080 TCP I/O Filter Service Used by the I/O Filters storage feature.

Table 3-4. Outgoing Firewall Connections

Port Protocol Service Description

427 TCP, UDP CIM SLP The CIM client uses the Service Location Protocol, version 2
(SLPv2) to find CIM servers.

547 TCP, UDP DHCPv6 DHCP client for IPv6.

8301, 8302 UDP DVSSync DVSSync ports are used for synchronizing states of distributed
virtual ports between hosts that have VMware FT record/replay
enabled. Only hosts that run primary or backup virtual machines
must have these ports open. On hosts that are not using VMware
FT these ports do not have to be open.

44046, 31031 TCP HBR Used for an ongoing replication traffic by vSphere Replication and
VMware Site Recovery Manager.

902 TCP NFC Network File Copy (NFC) provides a file-type-aware FTP service
for vSphere components. ESXi uses NFC for operations such
as copying and moving data between datastores by default.

9 UDP WOL Used by Wake on LAN.

12345 23451 UDP vSAN Clustering Cluster Monitoring, Membership, and Directory Service used by
Service vSAN.

68 UDP DHCP Client DHCP client.

53 TCP, UDP DNS Client DNS client.

80, 8200, 8100, 8300 TCP, UDP Fault Tolerance Supports VMware Fault Tolerance.

3260 TCP Software iSCSI Client Supports software iSCSI.

6999 UDP NSX Distributed The firewall port associated with this service is opened when NSX
Logical Router VIBs are installed and the VDR module is created. If no VDR
Service instances are associated with the host, the port does not have to
be open.

5671 TCP rabbitmqproxy A proxy running on the ESXi host. This proxy allows
applications that are running inside virtual machines to
communicate with the AMQP brokers that are running in the
vCenter network domain.
The virtual machine does not have to be on the network, that is,
no NIC is required. Ensure that outgoing connection IP addresses
include at least the brokers in use or future. You can add brokers
later to scale up.
2233 TCP vSAN Transport Used for RDT traffic (Unicast peer to peer communication)
between vSAN nodes.

8000 TCP vMotion Required for virtual machine migration with vMotion.

VMware,
1
 VMware ESXi

Table 3-4. Outgoing Firewall Connections (continued)

Port Protocol Service Description

902

UDP VMware vCenter vCenter Server agent.

8080 TCP vsanvp Used for vSAN Vendor Provider traffic.

80, 9000 TCP vSphere Lifecycle

Manager

Table 3-5. Firewall Ports for Services That Are Not Visible in the UI by Default
Proto
Port col Service Comment

5900 -5964 TCP RFB protocol The RFB protocol is a simple protocol for remote access to graphical user
interfaces.

8889 TCP OpenWSMAN Web Services Management (WS-Management is a DMTF open standard for
Daemon the management of servers, devices, applications, and Web services.

Required Free Space for System Logging

If you used Auto Deploy to install your ESXi 7.0 host, or if you set up a log directory separate from the
default location in a scratch directory on the VMFS volume, you might need to change your current log
size and rotation settings to ensure that enough space is available for system logging .

All vSphere components use this infrastructure. The default values for log capacity in this infrastructure
vary, depending on the amount of storage available and on how you have configured system logging.
Hosts that are deployed with Auto Deploy store logs on a RAM disk, which means that the amount of
space available for logs is small.

If your host is deployed with Auto Deploy, reconfigure your log storage in one of the following ways:

n Redirect logs over the network to a remote collector.

n Redirect logs to a NAS or NFS store.

If you redirect logs to non-default storage, such as a NAS or NFS store, you might also want to
reconfigure log sizing and rotations for hosts that are installed to disk.

You do not need to reconfigure log storage for ESXi hosts that use the default configuration, which stores
logs in a scratch directory on the VMFS volume. For these hosts, ESXi 7.0 configures logs to best suit
your installation, and provides enough space to accommodate log messages.

VMware,
1
 VMware ESXi

Table 3-6. Recommended Minimum Size and Rotation Configuration for hostd, vpxa, and
fdm Logs
Number of Rotations to
Log Maximum Log File Size Preserve Minimum Disk Space Required

Management Agent (hostd) 10 MB 10 100 MB

VirtualCenter Agent (vpxa) 5 MB 10 50 MB

vSphere HA agent (Fault 5 MB 10 50 MB

Domain Manager, fdm)

For information about setting up and configuring syslog and a syslog server and installing vSphere Syslog
Collector, see the vCenter Server Installation and Setup documentation.

VMware Host Client System Requirements

Make sure that your browser supports the VMware Host Client.

The following guest operating systems and Web browser versions are supported for the VMware Host
Client.

Supported Browsers Mac OS Windows Linux

Google Chrome 50+ 50+ 50+

Mozilla Firefox 45+ 45+ 45+

Microsoft Internet Explorer N/A 11+ N/A

Microsoft Edge N/A 38+ N/A

Safari 9.0+ N/A N/A

ESXi Passwords and Account Lockout

For ESXi hosts, you have to use a password with predefined requirements. You can change the
required length and character class requirement or allow pass phrases using the
Security.PasswordQualityControl advanced option. You can also set the number of passwords to
remember for each user using the Security.PasswordHistory advanced option.

Note The default requirements for ESXi passwords can change from one release to the next. You
can check and change the default password restrictions using the Security.PasswordQualityControl
advanced option.

ESXi Passwords
ESXi enforces password requirements for access from the Direct Console User Interface, the ESXi Shell,
SSH, or the VMware Host Client.

n By default, you have to include a mix of characters from four character classes: lowercase letters,
uppercase letters, numbers, and special characters such as underscore or dash when you create a
password.

n By default, password length is more than 7 and less than 40.

VMware,
2
 VMware ESXi

n Passwords cannot contain a dictionary word or part of a dictionary word.

Note An uppercase character that begins a password does not count toward the number of character
classes used. A number that ends a password does not count toward the number of character classes
used.

Example ESXi Passwords

The following password candidates illustrate potential passwords if the option is set as follows.

retry=3 min=disabled,disabled,disabled,7,7

With this setting, passwords with one or two character classes and pass phrases are not allowed,
because the first three items are disabled. Passwords from three- and four-character classes require
seven characters. See the pam_passwdqc man page for details.

With these settings, the following passwords are allowed.

n xQaTEhb!: Contains eight characters from three character classes.

n xQaT3#A: Contains seven characters from four character classes.

The following password candidates do not meet requirements.

n Xqat3hi: Begins with an uppercase character, reducing the effective number of character classes to
two. The minimum number of required character classes is three.

n xQaTEh2: Ends with a number, reducing the effective number of character classes to two. The
minimum number of required character classes is three.

ESXi Pass Phrase

Instead of a password, you can also use a pass phrase. However, pass phrases are disabled by
default. You can change this default or other settings, by using the Security.PasswordQualityControl
advanced option from the vSphere Client.

For example, you can change the option to the following.

retry=3 min=disabled,disabled,16,7,7

This example allows pass phrases of at least 16 characters and at least three words, separated by
spaces.

For legacy hosts, changing the /etc/pamd/passwd file is still supported, but changing the file is
deprecated for future releases. Use the Security.PasswordQualityControl advanced option instead.

Changing Default Password Restrictions

You can change the default restriction on passwords or pass phrases by using the
Security.PasswordQualityControl advanced option for your ESXi host. See vCenter Server and Host
Management documentation for information on setting ESXi advanced options.

VMware,
2
VMware ESXi

You can change the default, for example, to require a minimum of 15 characters and a minimum number
of four words, as follows:

retry=3 min=disabled,disabled,15,7,7 passphrase=4

See the man page for pam_passwdqc for details.

Note Not all possible combinations of password options have been tested. Perform additional testing
after you change the default password settings.

ESXi Account Lockout Behavior

Account locking is supported for access through SSH and through the vSphere Web Services SDK. The
Direct Console Interface (DCUI) and the ESXi Shell do not support account lockout. By default, a
maximum of five failed attempts is allowed before the account is locked. The account is unlocked after 15
minutes by default.

Configuring Login Behavior

You can configure the login behavior for your ESXi host with the following advanced options:

n Security.AccountLockFailures. Maximum number of failed login attempts before a user's account is

locked. Zero disables account locking.

n Security.AccountUnlockTime . Number of seconds that a user is locked out.

n Security.PasswordHistory. Number of passwords to remember for each user. Zero disables

password history.

See the vCenter Server and Host Management documentation for information on setting ESXi advanced
options.

Before Upgrading ESXi Hosts

For a successful upgrade of your ESXi hosts, understand and prepare for the changes that are involved.

For a successful ESXi upgrade, follow these best practices:

1 Make sure that you understand the ESXi upgrade process, the effect of that process on your existing
deployment, and the preparation required for the upgrade.

n If your vSphere system includes VMware solutions or plug-ins, make sure they are compatible
with the vCenter Server version that you are upgrading to. See the VMware Product
Interoperability Matrix at http://www.vmware.com/resources/compatibility/sim/interop_matrix.php.

n Read Overview of the ESXi Host Upgrade Process to understand the upgrade scenarios that are
supported, and the options and tools that are available to perform the upgrade.

n Read the VMware vSphere Release Notes for known installation issues.

VMware,
2
VMware ESXi

2 Prepare the system for the upgrade.

n Make sure that the current ESXi version is supported for the upgrade. See Overview of the ESXi
Host Upgrade Process.

n Make sure that the system hardware complies with ESXi requirements. See ESXi Requirements
and VMware Compatibility Guide at http://www.vmware.com/resources/compatibility/search.php.
Check for system compatibility, I/O compatibility with network and host bus adapter (HBA) cards,
storage compatibility, and backup software compatibility.

n Make sure that sufficient disk space is available on the host for the upgrade.

n If a SAN is connected to the host, detach the Fibre Channel system before continuing with the
upgrade. Do not disable HBA cards in the BIOS.

3 Back up the host before performing an upgrade. If the upgrade fails, you can restore the host.

4 If you are using Auto Deploy to provision hosts, the user who is running the process must have local
administrator privileges on the ESXi host that is being provisioned. By default the installation process
has these privileges and certificate provisioning happens as expected. However, if you are using
another method than the installer, you must run it as a user who has the local administrator privileges.

5 Depending on the upgrade option you choose, you might need to migrate or power off all virtual
machines on the host. See the instructions for your upgrade method.

n For an interactive upgrade from CD, DVD, or USB drive: see Upgrade Hosts Interactively.

n For a scripted upgrade: see Installing or Upgrading Hosts by Using a Script.

n For vSphere Auto Deploy: see Chapter 4 Using vSphere Auto Deploy to Reprovision Hosts . If the
ESXi 6.5x or 6.7.x host was deployed by using vSphere Auto Deploy, you can use vSphere Auto
Deploy to reprovision the host with a 7.0 image.

n For the esxcli command method: see Upgrading Hosts by Using ESXCLI Commands .

6 Plan for the tasks that must be performed after the ESXi host upgrade:

n Test the system to ensure that the upgrade completed successfully.

n Apply a host's licenses. See Licensing ESXi Hosts After Upgrade.

n Consider setting up a syslog server for remote logging, to ensure sufficient disk storage for log
files. Setting up logging on a remote host is especially important for hosts with limited local
storage. vSphere Syslog Collector is included as a service in vCenter Server 6.0 and can be used
to collect logs from all hosts. See Required Free Space for System Logging. For information
about setting up and configuring syslog and a syslog server, setting up syslog from the host
profiles interface, and installing vSphere Syslog Collector, see the vCenter Server Installation and
Setup documentation.

7 If the upgrade was unsuccessful and you backed up the host, you can restore the host.

VMware,
2
 VMware ESXi

Upgrading Hosts That Have Third-Party Custom VIBs

A host can have custom virtual infrastructure bundles (VIBs) installed, for example, third-party drivers or
management agents. When you upgrade an ESXi host to 7.0, all supported custom VIBs are migrated,
regardless of whether the VIBs are included in the installer ISO.

If the host or the installer ISO image contains a VIB that creates a conflict and prevents the upgrade, an
error message identifies the VIB that created the conflict. To upgrade the host, take one of the following
actions:

n Remove the VIB that created the conflict from the ESXi host and retry the upgrade. You can remove a
VIB from the host by using esxcli commands. For more information, see Remove VIBs from a Host .

n Use the vSphere ESXi Image Builder CLI to create a custom installer ISO image that resolves the
conflict. For more information about vSphere ESXi Image Builder CLI, see the vCenter Server
Installation and Setup documentation.

Media Options for Booting the ESXi Installer

The ESXi installer must be accessible to the system on which you are installing ESXi.

The following boot media are supported for the ESXi installer:

n Boot from a CD/DVD. See Download and Burn the ESXi Installer ISO Image to a CD or DVD.

n Boot from a USB flash drive. See Format a USB Flash Drive to Boot the ESXi Installation or Upgrade.

n PXE boot from the network. PXE Booting the ESXi Installer

n Boot from a remote location using a remote management application. See Using Remote
Management Applications

Download and Burn the ESXi Installer ISO Image to a CD or DVD

If you do not have an ESXi installation CD/DVD, you can create one.

You can also create an installer ISO image that includes a custom installation script. See Create an
Installer ISO Image with a Custom Installation or Upgrade Script.

Procedure

1 Download the ESXi installer from the VMware website at https://my.vmware.com/web/vmware/

downloads.

ESXi is listed under data center & Cloud Infrastructure.

2 Confirm that the md5sum is correct.

See the VMware Web site topic Using MD5 Checksums at http://www.vmware.com/download/
md5.html.

3 Burn the ISO image to a CD or DVD.

VMware,
2
VMware ESXi

Format a USB Flash Drive to Boot the ESXi Installation or Upgrade

You can format a USB flash drive to boot the ESXi installation or upgrade.

Note The ks.cfg file that contains the installation script cannot be on the same USB flash drive that you
are using to boot the installation or upgrade.

Prerequisites

n A Linux host with a superuser access to it.

n A USB flash drive.

n The ESXi ISO image, VMware-VMvisor-Installer- version_number-

build_number.x86_64.iso, which includes the isolinux.cfg file.
n A Syslinux 3.86 package.

Procedure

1 Determine how your USB flash drive is detected.

Usually the USB flash drive is detected as

/dev/sdb.
a At the command line, run the command for displaying the current log messages.

tail -f /var/log/messages

b Plug in your USB flash drive.

You see several messages that identify the USB flash drive in a format similar to the following
message.

Oct 25 13:25:23 ubuntu kernel: [ 712.447080] sd 3:0:0:0: [sdb] Attached SCSI removable disk

In this example, sdb identifies the USB device. If your device is identified differently, use that
identification, in place of sdb.

2 Create a partition table on the USB flash device.

/sbin/fdisk /dev/sdb

a Enter d to delete partitions until they are all deleted.

b Enter n to create a primary partition 1 that extends over the entire disk.

c Enter t to set the type to an appropriate setting for the FAT32 file system, such as

c. d Enter a to set the active flag on partition 1.

VMware,
2
VMware ESXi

e Enter p to print the partition table.

The result can be similar to the following message.

Disk /dev/sdb: 2004 MB, 2004877312 bytes

255 heads, 63 sectors/track, 243 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdb1 1 243 1951866 c W95 FAT32 (LBA)

f Enter w to write the partition table and exit the application.

3 Format the USB flash drive with the Fat32 file system.

/sbin/mkfs.vfat -F 32 -n USB /dev/sdb1

4 Install the Syslinux bootloader on the USB flash drive.

The locations of the Syslinux executable file and the mbr.bin file might vary for the different Syslinux
versions. The following commands are default.

/usr/bin/syslinux /dev/sdb1
cat /usr/lib/syslinux/mbr/mbr.bin > /dev/sdb

5 Create a destination directory and mount the USB flash drive to it.

mkdir /usbdisk
mount /dev/sdb1 /usbdisk

6 Create a destination directory and mount the ESXi installer ISO image to it.

mkdir /esxi_cdrom
mount -o loop VMware-VMvisor-Installer-6.x.x-XXXXXX.x86_64.iso /esxi_cdrom

7 Copy the contents of the ISO image to the USB flash drive.

cp -r /esxi_cdrom/* /usbdisk

8 Rename the isolinux.cfg file to syslinux.cfg.

mv /usbdisk/isolinux.cfg /usbdisk/syslinux.cfg

9 In the /usbdisk/syslinux.cfg file, edit the APPEND -c boot.cfg line to APPEND -c boot.cfg -p 1.

10 Unmount the USB flash drive.

umount /usbdisk

11 Unmount the installer ISO image.

umount /esxi_cdrom

VMware,
2
 VMware ESXi

Results

The USB flash drive can boot the ESXi installer.

Create a USB Flash Drive to Store the ESXi Installation Script or Upgrade
Script
You can use a USB flash drive to store the ESXi installation script or upgrade script that is used during
scripted installation or upgrade of ESXi.

When multiple USB flash drives are present on the installation machine, the installation software
searches for the installation or upgrade script on all attached USB flash drives.

The instructions in this procedure assume that the USB flash drive is detected as /dev/sdb.

Note Do not store the ks file containing the installation or upgrade script on the same USB flash drive
that you are using to boot the installation or upgrade.

Prerequisites

n Linux machine

n ESXi installation or upgrade script, the ks.cfg kickstart file

n USB flash drive

Procedure

1 Attach the USB flash drive to a Linux machine that has access to the installation or upgrade script.

2 Create a partition table.

/sbin/fdisk /dev/sdb
a Type d to delete partitions until they are all deleted.

b Type n to create primary partition 1 that extends over the entire disk.

c Type t to set the type to an appropriate setting for the FAT32 file system, such as

c. d Type p to print the partition table.

The result should be similar to the following text:

Disk /dev/sdb: 2004 MB, 2004877312 bytes

255 heads, 63 sectors/track, 243 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdb1 1 243 1951866 c W95 FAT32 (LBA)

e Type w to write the partition table and quit.

3 Format the USB flash drive with the Fat32 file system.

/sbin/mkfs.vfat -F 32 -n USB /dev/sdb1

VMware,
2
 VMware ESXi

4 Mount the USB flash drive.

mount /dev/sdb1 /usbdisk

5 Copy the ESXi installation script to the USB flash drive.

cp ks.cfg /usbdisk

6 Unmount the USB flash drive.

Results

The USB flash drive contains the installation or upgrade script for ESXi.

What to do next

When you boot the ESXi installer, point to the location of the USB flash drive for the installation or
upgrade script. See Enter Boot Options to Start an Installation or Upgrade Script and PXELINUX
Configuration Files.

Create an Installer ISO Image with a Custom Installation or Upgrade Script

You can customize the standard ESXi installer ISO image with your own installation or upgrade script.
This customization enables you to perform a scripted, unattended installation or upgrade when you boot
the resulting installer ISO image.

See also About Installation and Upgrade Scripts and About the boot.cfg File .

Prerequisites

n Linux machine

n The ESXi ISO image VMware-VMvisor-Installer- 6.x.x-XXXXXX.x86_64.iso,where 6.x.x is the

version of ESXi you are installing, and XXXXXX is the build number of the installer ISO image

n Your custom installation or upgrade script, the ks_cust.cfg kickstart file

Procedure

1 Download the ESXi ISO image from the VMware Web site.

2 Mount the ISO image in a folder:

mount -o loop VMware-VMvisor-Installer-6.x.x-XXXXXX.x86_64.iso /esxi_cdrom_mount

XXXXXX is the ESXi build number for the version that you are installing or upgrading to.

3 Copy the contents of cdrom to another folder:

cp -r /esxi_cdrom_mount /esxi_cdrom

4 Copy the kickstart file to

/esxi_cdrom. cp ks_cust.cfg
/esxi_cdrom

VMware,
2
 VMware ESXi

5 (Optional) Modify the boot.cfg file to specify the location of the installation or upgrade script
by using the kernelopt option.

You must use uppercase characters to provide the path of the script, for example,

kernelopt=runweasel ks=cdrom:/KS_CUST.CFG

For UEFI boot, you must modify the boot.cfg file located in /efi/boot/.

The installation or upgrade becomes completely automatic, without the need to specify the kickstart
file during the installation or upgrade.

6 Recreate the ISO image using the mkisofs or the genisoimage command.

Command Syntax

mkisofs mkisofs -relaxed-filenames -J -R -o custom_esxi.iso -b

isolinux.bin -c boot.cat -no-emul-boot -boot-load-size 4 -boot-
info-table -eltorito-alt-boot -eltorito-platform efi -b
efiboot.img -no-emul-boot /esxi_cdrom

genisoimage genisoimage -relaxed-filenames -J -R -o custom_esxi.iso -b

isolinux.bin -c boot.cat -no-emul-boot -boot-load-size 4 -boot-
info-table -eltorito-alt-boot -e efiboot.img -no-emul-boot /
esxi_cdrom

You can use this ISO image for regular boot or UEFI secure boot.

Results

The ISO image includes your custom installation or upgrade script.

What to do next

Install ESXi from the ISO image.

PXE Booting the ESXi Installer

You can use the preboot execution environment (PXE) to boot a host from a network interface on hosts
with legacy BIOS or using UEFI.

ESXi is distributed in an ISO format that is used to install to flash memory or to a local hard drive. You can
extract the files and boot by using PXE.

PXE uses Dynamic Host Configuration Protocol (DHCP) and Trivial File Transfer Protocol (TFTP) to boot
an operating system over a network.

PXE booting requires some network infrastructure and a machine with a PXE-capable network adapter.
Most machines that can run ESXi have network adapters that can PXE boot.

Note PXE booting with legacy BIOS firmware is possible only over IPv4. PXE booting with UEFI
firmware is possible with either IPv4 or IPv6.

VMware,
2
VMware ESXi

Sample DHCP Configurations

To PXE boot the ESXi installer, the DHCP server must send the address of the TFTP server and the
filename of the initial boot loader to the ESXi host.

When the target machine first boots, it broadcasts a packet across the network requesting information to
boot itself. The DHCP server responds. The DHCP server must be able to determine whether the target
machine is allowed to boot and the location of the initial boot loader binary, typically a file on a TFTP
server.

Caution Do not set up a second DHCP server if your network already has one. If multiple DHCP servers
respond to DHCP requests, machines can obtain incorrect or conflicting IP addresses, or can fail to
receive the proper boot information. Talk to a network administrator before setting up a DHCP server. For
support on configuring DHCP, contact your DHCP server vendor.

Many DHCP servers can PXE boot hosts. If you are using a version of DHCP for Microsoft Windows, see
the DHCP server documentation to determine how to pass the next-server and filename arguments to
the target machine.
Example of Booting Using TFTP with IPv4
This example shows how to configure an ISC DHCP server to boot ESXi using a TFTP server at IPv4
address xxx.xxx.xxx.xxx.

#
# ISC DHCP server configuration file snippet. This is not a complete
# configuration file; see the ISC server documentation for details on
# how to configure the DHCP server.
#
allow booting;
allow bootp;
option client-system-arch code 93 = unsigned integer 16;
class "pxeclients" {
match if substring(option vendor-class-identifier, 0, 9) = "PXEClient";
next-server xxx.xxx.xxx.xxx;
if option client-system-arch = 00:07 or option client-system-arch = 00:09 {
filename = "mboot.efi";
} else {
filename = "pxelinux.0";
}
}

When a machine attempts to PXE boot, the DHCP server provides an IP address and the location of the
pxelinux.0 or mboot.efi binary file on the TFTP server.
Example of Booting Using TFTP with IPv6
This example shows how to configure an ISC DHCPv6 server to boot ESXi using a TFTP server at IPv6
address xxxx:xxxx:xxxx:xxxx::xxxx.

#
# ISC DHCPv6 server configuration file snippet. This is not a complete
# configuration file; see the ISC server documentation for details on

VMware,
3
VMware ESXi

# how to configure the DHCP server.

#
allow booting;
allow bootp;
option dhcp6.bootfile-url code 59 = string;
option dhcp6.bootfile-url "tftp://[xxxx:xxxx:xxxx:xxxx::xxxx]/mboot.efi";

When a machine attempts to PXE boot, the DHCP server provides an IP address and the location of the
mboot.efi binary file on the TFTP server.
Example of Booting Using HTTP with IPv4
This example shows how to configure an ISC DHCP server to boot ESXi using a Web server at IPv4
address xxx.xxx.xxx.xxx. The example uses gPXELINUX for legacy BIOS hosts and iPXE for UEFI hosts.

#
# ISC DHCPv6 server configuration file snippet. This is not a complete
# configuration file; see the ISC server documentation for details on
# how to configure the DHCP server.
#
allow booting;
allow bootp;
option client-system-arch code 93 = unsigned integer 16;
class "pxeclients" {
match if substring(option vendor-class-identifier, 0, 9) = "PXEClient"; next-
server xxx.xxx.xxx.xxx;
if option client-system-arch = 00:07 or option client-system-arch = 00:09
{ if exists user-class and option user-class = "iPXE" {
# Instruct iPXE to load mboot.efi as secondary bootloader
filename = "mboot.efi";
} else {
# Load the snponly.efi configuration of iPXE as initial bootloader
filename = "snponly.efi";
}
} else {
filename "gpxelinux.0";
}
}

When a machine attempts to PXE boot, the DHCP server provides an IP address and the location of
the gpxelinux.0 or snponly.efi binary file on the TFTP server. In the UEFI case, iPXE then asks
the DHCP server for the next file to load, and this time the server returns mboot.efi as the
filename.
Example of Booting Using HTTP with IPv6
This example shows how to configure an ISC DHCPv6 server to boot ESXi using a TFTP server at IPv6
address xxxx:xxxx:xxxx:xxxx::xxxx.

#
# ISC DHCPv6 server configuration file snippet. This is not a complete
# configuration file; see the ISC server documentation for details on
# how to configure the DHCP server.
#
allow booting;
allow bootp;

VMware,
3
 VMware ESXi

option dhcp6.bootfile-url code 59 = string;

if exists user-class and option user-class = "iPXE" {
# Instruct iPXE to load mboot.efi as secondary bootloader
option dhcp6.bootfile-url "tftp://[xxxx:xxxx:xxxx:xxxx::xxxx]/mboot.efi";
} else {
# Load the snponly.efi configuration of iPXE as initial bootloader
option dhcp6.bootfile-url "tftp://[xxxx:xxxx:xxxx:xxxx::xxxx]/snponly.efi";
}

When a machine attempts to PXE boot, the DHCP server provides an IP address and the location of the
snponly.efi (iPXE) binary file on the TFTP server. iPXE then asks the DHCP server for the next file to
load, and this time the server returns mboot.efi as the filename.

PXELINUX Configuration Files

You need a PXELINUX configuration file to boot the ESXi installer on a legacy BIOS system. The
configuration file defines the menu displayed to the target ESXi host as it starts and contacts the TFTP
server for all SYSLINUX configurations, including PXELINUX and gPXELINUX.

This section gives general information about PXELINUX configuration files. For examples, see Sample
DHCP Configurations.

For syntax details, see the SYSLINUX website at http://www.syslinux.org/.

Required Files
In the PXE configuration file, you must include paths to the following files:

n mboot.c32 is the boot loader.

n boot.cfg is the boot loader configuration file.

See About the boot.cfg File
Filename for the PXE Configuration File
For the filename of the PXE configuration file, select one of the following options:

n 01-mac_address_of_target_ESXi_host. For example, 01-23-45-67-89-0a-bc

n The target ESXi host IP address in a hexadecimal notation.

n default

The initial boot file, pxelinux.0 or gpxelinux.0, tries to load a PXE configuration file in the following
order:

1 It tries with the MAC address of the target ESXi host, prefixed with its ARP type code, which is 01 for
Ethernet.

2 If that attempt fails, it tries with the hexadecimal notation of target ESXi system IP address.

3 Ultimately, it tries to load a file named default.

File Location for the PXE Configuration File
Save the file in /tftpboot/pxelinux.cfg/ on the TFTP server.

VMware,
3
VMware ESXi

For example, you might save the file on the TFTP server at /tftpboot/pxelinux.cfg/01-00-21-5a-
ce-40-f6. The MAC address of the network adapter on the target ESXi host is 00-21-5a-ce-40-f6.

PXE Boot Background Information

Understanding the PXE boot process can help you during troubleshooting.
TFTP Server
Trivial File Transfer Protocol (TFTP) is similar to the FTP service, and is typically used only for network
booting systems or loading firmware on network devices such as routers. TFTP is available on Linux and
Windows.

n Most Linux distributions include a copy of the tftp-hpa server. If you require a supported solution,
purchase a supported TFTP server from your vendor of choice. You can also acquire a TFTP
server from one of the packaged appliances on the VMware Marketplace.

n If your TFTP server runs on a Microsoft Windows host, use tftpd32 version 2.11 or later. See http://
tftpd32.jounin.net/.
SYSLINUX, PXELINUX, and gPXELINUX
If you are using PXE in a legacy BIOS environment, you must understand the different boot
environments.

n SYSLINUX is an open-source boot environment for machines that run legacy BIOS firmware. The
ESXi boot loader for BIOS systems, mbootc.32, runs as a SYSLINUX plugin. You can configure
SYSLINUX to boot from several types of media, including disk, ISO image, and network. You can
find
the SYSLINUX package at http://www.kernel.org/pub/linux/utils/boot/syslinux/.

n PXELINUX is a SYSXLINUX configuration for booting from a TFTP server according to the PXE
standard. If you use PXELINUX to boot the ESXi installer, the pxelinux.0 binary file,
mboot.c32, the configuration file, the kernel, and other files are transferred by TFTP.

n gPXELINUX is a hybrid configuration that includes both PXELINUX and gPXE and supports booting
from a Web server. gPXELINUX is part of the SYSLINUX package. If you use gPXELINUX to boot the
ESXi installer, only the gpxelinux.0 binary file, mboot.c32, and the configuration file are transferred
by TFTP. The remaining files are transferred by HTTP. HTTP is typically faster and more reliable than
TFTP, especially for transferring large amounts of data on a heavily loaded network.

Note VMware currently builds the mboot.c32 plugin to work with SYSLINUX version 3.86 and tests PXE
booting only with that version. Other versions might be incompatible. For support of third-party agents that
you use to set up your PXE booting infrastructure, contact the vendor.

UEFI PXE and iPXE

Most UEFI firmware natively includes PXE support that allows booting from a TFTP server. The firmware
can directly load the ESXi boot loader for UEFI systems, mboot.efi. Additional software such as
PXELINUX is not required.

VMware,
3
VMware ESXi

iPXE can also be useful for UEFI systems that do not include PXE in firmware and for older UEFI systems
with bugs in their PXE support. For such cases, you can try installing iPXE on a USB flash drive and
booting from there.

Note Apple Macintosh products do not include PXE boot support. They include support for network
booting through an Apple-specific protocol instead.

Alternative Approaches to PXE Booting

Alternative approaches to PXE booting different software on different hosts are also possible, for
example:

n Configuring the DHCP server to provide different initial boot loader filenames to different hosts
depending on MAC address or other criteria. See your DCHP server's documentation.

n Approaches using iPXE as the initial bootloader with an iPXE configuration file that selects the next
bootloader based on the MAC address or other criteria.

Installing and Booting ESXi with Software FCoE

You can install and boot ESXi from an FCoE LUN using VMware software FCoE adapters and network
adapters with FCoE offload capabilities. Your host does not require a dedicated FCoE HBA.

The boot LUN must not be shared between hosts and must have a size of minimum of 32 GB. See the
vSphere Storage documentation for information about installing and booting ESXi with software FCoE.

Using Remote Management Applications

Remote management applications allow you to install ESXi on servers that are in remote locations.

Remote management applications supported for installation include HP Integrated Lights-Out (iLO), Dell
Remote Access Card (DRAC), IBM management module (MM), and Remote Supervisor Adapter II (RSA
II). For a list of currently supported server models and remote management firmware versions, see
Supported Remote Management Server Models and Firmware Versions. For support on remote
management applications, contact the vendor.

You can use remote management applications to do both interactive and scripted installations of ESXi
remotely.

If you use remote management applications to install ESXi, the virtual CD might encounter corruption
problems with systems or networks operating at peak capacity. If a remote installation from an ISO image
fails, complete the installation from the physical CD media.

Download the ESXi Installer

Download the installer for ESXi.

Prerequisites

Create a My VMware account at https://my.vmware.com/web/vmware/.

VMware,
3
VMware ESXi

Procedure

1 Download the ESXi installer from the VMware website at https://my.vmware.com/web/vmware/

downloads.

ESXi is listed under data center & Cloud Infrastructure.

2 Confirm that the md5sum is correct.

See the VMware Web site topic Using MD5 Checksums at http://www.vmware.com/download/
md5.html.

Storage Device Names and Identifiers

In the ESXi environment, each storage device is identified by several names.

Device Identifiers
Depending on the type of storage, the ESXi host uses different algorithms and conventions to generate
an identifier for each storage device.

Storage-provided identifiers

The ESXi host queries a target storage device for the device name. From the returned metadata, the
host extracts or generates a unique identifier for the device. The identifier is based on specific storage
standards, is unique and persistent across all hosts, and has one of the following formats:

n naa.xxx

n eui.xxx

n t10.xxx

Path-based identifier

When the device does not provide an identifier, the host generates an mpx.path name, where path
represents the first path to the device, for example, mpx.vmhba1:C0:T1:L3. This identifier can
be used in the same way as the storage-provided identifies.

The mpx.path identifier is created for local devices on the assumption that their path names are
unique. However, this identifier is not unique or persistent, and can change after every system restart.

Typically, the path to the device has the following format:

vmhbaAdapter:CChannel:TTarget:LLUN

n vmhbaAdapter is the name of the storage adapter. The name refers to the physical adapter on
the host, not to the SCSI controller used by the virtual machines.

n CChannel is the storage channel number.

Software iSCSI adapters and dependent hardware adapters use the channel number to show
multiple paths to the same target.

VMware,
3
 VMware ESXi

n TTarget is the target number. Target numbering is determined by the host and might change
when the mappings of targets visible to the host change. Targets that are shared by different
hosts might not have the same target number.

n LLUN is the LUN number that shows the position of the LUN within the target. The LUN number
is provided by the storage system. If a target has only one LUN, the LUN number is always zero
(0).

For example, vmhba1:C0:T3:L1 represents LUN1 on target 3 accessed through the storage adapter
vmhba1 and channel 0.

Legacy identifier

In addition to the device-provided identifiers or mpx.path identifiers, ESXi generates an alternative

legacy name for each device. The identifier has the following format:

vml.number

The legacy identifier includes a series of digits that are unique to the device. The identifier can be
derived in part from the metadata obtained through the SCSI INQUIRY command. For nonlocal
devices that do not provide SCSI INQUIRY identifiers, the vml.number identifier is used as the only
available unique identifier.

Example: Displaying Device Names in the vSphere CLI

You can use the esxcli storage core device list command to display all device names in the
vSphere CLI. The output is similar to the following example:

# esxcli storage core device list

naa.XXX
Display Name: DGC Fibre Channel Disk(naa.XXX)
...
Other UIDs: vml.000XXX
mpx.vmhba1:C0:T0:L0
Display Name: Local VMware Disk (mpx.vmhba1:C0:T0:L0)
...
Other UIDs: vml.0000000000XYZ

Upgrade Hosts Interactively

To upgrade ESXi 6.5 hosts or ESXi 6.7 hosts to ESXi 7.0, you can boot the ESXi installer from a CD,
DVD, or USB flash drive.

Before upgrading, consider disconnecting the network storage. This action decreases the time it takes the
installer to search for available disk drives. When you disconnect network storage, any files on the
disconnected disks are unavailable at installation. Do not disconnect a LUN that contains an existing
ESXi installation.

VMware,
3
VMware ESXi

Prerequisites

n Verify that the ESXi installer ISO in one of the following locations.

n On CD or DVD. If you do not have the installation CD or DVD, you can create one. See Download
and Burn the ESXi Installer ISO Image to a CD or DVD

n On a USB flash drive. See Format a USB Flash Drive to Boot the ESXi Installation or Upgrade

Note You can also use PXE to boot the ESXi installer to run an interactive installation or a scripted
installation. See PXE Booting the ESXi Installer.

n Verify that the server hardware clock is set to UTC. This setting is in the system BIOS.

n ESXi Embedded must not be on the host. ESXi Installable and ESXi Embedded cannot exist on the
same host.

n If you are upgrading an ESXi host, supported custom VIBs that are not included in the ESXi installer
ISO are migrated. See Upgrading Hosts That Have Third-Party Custom VIBs

n See your hardware vendor documentation for information about changing the boot order.

Procedure

1 Insert the ESXi installer CD or DVD in the CD-ROM or DVD-ROM drive, or attach the Installer USB
flash drive and restart the machine.

2 Set the BIOS to boot from the CD-ROM device or the USB flash drive.

3 In the Select a Disk panel, select the drive on which to install or upgrade ESXi and press Enter.

Press F1 for information about the selected disk.

Note Do not rely on the disk order in the list to select a disk. The disk order is determined by the
BIOS. On systems where drives are continuously being added and removed, they might be out of
order.

4 Upgrade or install ESXi if the installer finds an existing ESXi installation and VMFS datastore.

If an existing VMFS datastore cannot be preserved, you can choose only to install ESXi and overwrite
the existing VMFS datastore, or to cancel the installation. If you choose to overwrite the existing
VMFS datastore, back up the datastore first.

5 Press F11 to confirm and start the upgrade.

6 Remove the installation CD or DVD or USB flash drive when the upgrade is complete.

7 Press Enter to reboot the host.

8 Set the first boot device to be the drive which you selected previously when you upgraded ESXi.

Installing or Upgrading Hosts by Using a Script

You can quickly deploy ESXi hosts by using scripted, unattended installations or upgrades. Scripted
installations or upgrades provide an efficient way to deploy multiple hosts.

VMware,
3
 VMware ESXi

The installation or upgrade script contains the installation settings for ESXi. You can apply the script to all
hosts that you want to have a similar configuration.

For a scripted installation or upgrade, you must use the supported commands to create a script. You can
edit the script to change settings that are unique for each host.

The installation or upgrade script can reside in one of the following locations:

n FTP server

n HTTP/HTTPS server

n NFS server

n USB flash drive

n CD-ROM drive

Enter Boot Options to Start an Installation or Upgrade Script

You can start an installation or upgrade script by typing boot options at the ESXi installer boot command
line.

At boot time you might need to specify options to access the kickstart file. You can enter boot options by
pressing Shift+O in the boot loader. For a PXE boot installation, you can pass options through the
kernelopts line of the boot.cfg file. See About the boot.cfg File and PXE Booting the ESXi Installer.

To specify the location of the installation script, set the ks=filepath option, where filepath is indicates the
location of your Kickstart file. Otherwise, a scripted installation or upgrade cannot start. If ks=filepath is
omitted, the text installer is run.

Supported boot options are listed in Boot Options .

Procedure

1 Start the host.

2 When the ESXi installer window appears, press Shift+O to edit boot options.

3 At the runweasel command prompt, type

ks=location of installation script plus boot command-line options.

VMware,
3
 VMware ESXi

Example: Boot Option

You type the following boot options:

ks=http://00.00.00.00/kickstart/ks-osdc-pdp101.cfg nameserver=00.00.0.0 ip=00.00.00.000

netmask=255.255.255.0 gateway=00.00.00.000

Boot Options
When you perform a scripted installation, you might need to specify options at boot time to access the
kickstart file.

Supported Boot Options

Table 3-7. Boot Options for ESXi Installation
Boot Option Description

BOOTIF=hwtype-MAC address Similar to the netdevice option, except in the PXELINUX format
as described in the IPAPPEND option under SYSLINUX at the
syslinux.org site.

gateway=ip address Sets this network gateway as the default gateway to be used for
downloading the installation script and installation media.

ip=ip address Sets up a static IP address to be used for downloading the

installation script and the installation media. Note: the PXELINUX
format for this option is also supported. See the IPAPPEND
option under SYSLINUX at the syslinux.org site.

ks=cdrom:/path Performs a scripted installation with the script at path, which

resides on the CD in the CD-ROM drive. Each CDROM is
mounted and checked until the file that matches the path is
found.

Important If you have created an installer ISO image with a

custom installation or upgrade script, you must use uppercase
characters to provide the path of the script, for example,
ks=cdrom:/KS_CUST.CFG.

ks=file://path
Performs a scripted installation with the script at path.
ks=protocol://serverpath Performs a scripted installation with a script located on the
network at the given URL. protocol can be http, https, ftp, or
nfs. An example using NFS protocol is ks=nfs://host/porturl-
path. The format of an NFS URL is specified in RFC 2224.

ks=usb Performs a scripted installation, accessing the script from an

attached USB drive. Searches for a file named ks.cfg. The file
must be located in the root directory of the drive. If multiple USB
flash drives are attached, they are searched until the ks.cfg file
is found. Only FAT16 and FAT32 file systems are supported.

ks=usb:/path Performs a scripted installation with the script file at the specified
path, which resides on USB.

VMware,
3
 VMware ESXi

Table 3-7. Boot Options for ESXi Installation (continued)

Boot Option Description

ksdevice=device

Tries to use a network adapter device when looking for an

installation script and installation media. Specify as a MAC
address, for example, 00:50:56:C0:00:01. This location can also
be a vmnicNN name. If not specified and files need to be
retrieved over the network, the installer defaults to the first
nameserver=ip address Specifies a domain name server to be used for downloading the
installation script and installation media.

netdevice=device Tries to use a network adapter device when looking for an

installation script and installation media. Specify as a MAC
address, for example, 00:50:56:C0:00:01. This location can also
be a vmnicNN name. If not specified and files need to be
retrieved over the network, the installer defaults to the first
discovered network adapter that is plugged in.

netmask=subnet mask Specifies subnet mask for the network interface that downloads
the installation script and the installation media.

vlanid=vlanid Configure the network card to be on the specified VLAN.

About Installation and Upgrade Scripts

The installation/upgrade script is a text file, for example ks.cfg, that contains supported commands.
The command section of the script contains the ESXi installation options. This section is required and
must appear first in the script.

Locations Supported for Installation or Upgrade Scripts

In scripted installations and upgrades, the ESXi installer can access the installation or upgrade script,
also called the kickstart file, from several locations.

The following locations are supported for the installation or upgrade script:

n CD/DVD. See Create an Installer ISO Image with a Custom Installation or Upgrade Script.

n USB Flash drive. See Create a USB Flash Drive to Store the ESXi Installation Script or Upgrade
Script.

n A network location accessible through the following protocols: NFS, HTTP, HTTPS, FTP

Path to the Installation or Upgrade Script

You can specify the path to an installation or upgrade script.

ks=http://XXX.XXX.XXX.XXX/kickstart/KS.CFG is the path to the ESXi installation script, where

XXX.XXX.XXX.XXX is the IP address of the machine where the script resides. See About Installation and
Upgrade Scripts.

To start an installation script from an interactive installation, you enter the ks= option manually. See Enter
Boot Options to Start an Installation or Upgrade Script.

VMware,
4
 VMware ESXi

Installation and Upgrade Script Commands

To modify the default installation or upgrade script or to create your own script, use supported
commands. Use supported commands in the installation script, which you specify with a boot command
when you boot the installer.

To determine which disk to install or upgrade ESXi on, the installation script requires one of the
following commands: install, upgrade, or installorupgrade. The install command creates the
default partitions, including a VMFS datastore that occupies all available space after the other
partitions are
created.

accepteula or vmaccepteula (Required)

Accepts the ESXi license agreement.

clearpart (Optional)
Clears any existing partitions on the disk. Requires the install command to be specified. Carefully
edit the clearpart command in your existing scripts.

--drives= Remove partitions on the specified drives.

--alldrives Ignores the --drives= requirement and allows clearing of partitions on

every drive.

--ignoredrives= Removes partitions on all drives except those specified. Required unless
the --drives= or --alldrives flag is specified.

--overwritevmfs Allows overwriting of VMFS partitions on the specified drives. By default,

overwriting VMFS partitions is not allowed.

--firstdisk= disk-
Partitions the first eligible disk found. By default, the eligible disks are set to
type1 [disk-type2,...] the following order:

1 Locally attached storage (local)

2 Network storage (remote)

3 USB disks (usb)

You can change the order of the disks by using a comma-separated list
appended to the argument. If you provide a filter list, the default settings are
overridden. You can combine filters to specify a particular disk, including
esx for the first disk with ESXi installed on it, model and vendor information,
or the name of the VMkernel device driver. For example, to prefer a disk
with the model name ST3120814A and any disk that uses the mptsas
driver rather than a normal local disk, the argument is
--firstdisk=ST3120814A,mptsas,local. You can use localesx for
local storage that contains ESXi image or remoteesx for remote
storage that contains ESXi image.

VMware,
4
 VMware ESXi

dryrun (Optional)
Parses and checks the installation script. Does not perform the installation.

install
Specifies that this is a fresh installation. Either the install, upgrade, or installorupgrade
command is required to determine which disk to install or upgrade ESXi on.

--disk= or --drive= Specifies the disk to partition. In the command --disk=diskname, the
diskname can be a disk name or a full disk filesystem path in ESXi, for
example:

n Disk name: --disk=naa.6d09466044143600247aee55ca2a6405 or

n Device path: --disk=/vmfs/devices/disks/mpx.vmhba1:C0:T0:L0

For accepted disk name formats, see Disk Device Names.

--firstdisk= disk- Partitions the first eligible disk found. By default, the eligible disks are set to
type1, [disk- the following order:

type2,...] 1 Locally attached storage (local)

2 Network storage (remote)

3 USB disks (usb)

You can change the order of the disks by using a comma-separated list
appended to the argument. If you provide a filter list, the default settings are
overridden. You can combine filters to specify a particular disk, including
esx for the first disk with ESX installed on it, model and vendor information,
or the name of the VMkernel device driver. For example, to prefer a disk
with the model name ST3120814A and any disk that uses the mptsas
driver rather than a normal local disk, the argument is
--firstdisk=ST3120814A,mptsas,local. You can use localesx for
local storage that contains ESXi image or remoteesx for remote
storage that contains ESXi image.

--ignoressd Excludes solid-state disks from eligibility for partitioning. This option can
be used with the install command and the --firstdisk option. This
option takes precedence over the --firstdisk option. This option is
invalid with the --drive or --disk options and with the upgrade and
installorupgrade commands. See the vSphere Storage documentation
for more information about preventing SSD formatting during auto-
partitioning.

--overwritevsan You must use the --overwritevsan option when you install ESXi on a disk,
either SSD or HDD (magnetic), that is in a vSAN disk group. If you use this
option and no vSAN partition is on the selected disk, the installation fails.

VMware,
4
 VMware ESXi

When you install ESXi on a disk that is in vSAN disk group, the result
depends on the disk that you select:

n If you select an SSD, the SSD and all underlying HDDs in the same
disk group is wiped.

n If you select an HDD, and the disk group size is greater than two, only
the selected HDD is wiped.

n If you select an HDD disk, and the disk group size is two or less, the
SSD and the selected HDD is wiped.

For more information about managing vSAN disk groups, see the vSphere
Storage documentation.

--overwritevmfs Required to overwrite an existing VMFS datastore on the disk before

installation.

--preservevmfs Preserves an existing VMFS datastore on the disk during installation.

--novmfsondisk Prevents a VMFS partition from being created on this disk. Must be used
with --overwritevmfs if a VMFS partition exists on the disk.

installorupgrade
Either the install, upgrade, or installorupgrade command is required to determine which disk to
install or upgrade ESXi on.

--disk= or --drive= Specifies the disk to partition. In the command --disk=diskname, the
diskname can be a disk name or a full disk filesystem path in ESXi, for
example:

n Disk name: --disk=naa.6d09466044143600247aee55ca2a6405 or

n Device path: --disk=/vmfs/devices/disks/mpx.vmhba1:C0:T0:L0

For accepted disk name formats, see Disk Device Names.

--firstdisk= disk-
Partitions the first eligible disk found. By default, the eligible disks are set to
type1, [disk- the following order:
type2,...] 1 Locally attached storage (local)

2 Network storage (remote)

3 USB disks (usb)

You can change the order of the disks by using a comma-separated list
appended to the argument. If you provide a filter list, the default settings are
overridden. You can combine filters to specify a particular disk, including
esx for the first disk with ESX installed on it, model and vendor information,
or the name of the VMkernel device driver. For example, to prefer a disk
with the model name ST3120814A and any disk that uses the mptsas

VMware,
4
 VMware ESXi

driver rather than a normal local disk, the argument is

--firstdisk=ST3120814A,mptsas,local. You can use localesx for
local storage that contains ESXi image or remoteesx for remote
storage that contains ESXi image.

--overwritevsan You must use the --overwritevsan option when you install ESXi on a disk,
either SSD or HDD (magnetic), that is in a vSAN disk group. If you use this
option and no vSAN partition is on the selected disk, the installation fails.
When you install ESXi on a disk that is in a vSAN disk group, the result
depends on the disk that you select:

n If you select an SSD, the SSD and all underlying HDDs in the same
disk group is wiped.

n If you select an HDD, and the disk group size is greater than two, only
the selected HDD is wiped.
n If you select an HDD disk, and the disk group size is two or less, the
SSD and the selected HDD is wiped.

For more information about managing vSAN disk groups, see the vSphere
Storage documentation.

--overwritevmfs Install ESXi if a VMFS partition exists on the disk, but no ESX or ESXi
installation exists. Unless this option is present, the installer fails if a VMFS
partition exists on the disk, but an ESX or ESXi installation is missing.

keyboard (Optional)
Sets the keyboard type for the system.

keyboardType Specifies the keyboard map for the selected keyboard type. keyboardType
must be one of the following types.

n Belgian

n Brazilian

n Croatian

n Czechoslovakian

n Danish

n Estonian

n Finnish

n French

n German

n Greek

VMware,
4
 VMware ESXi

n Icelandic

n Italian

n Japanese

n Latin American

n Norwegian

n Polish

n Portuguese

n Russian

n Slovenian

n Spanish

n Swedish

n Swiss French

n Swiss German

n Turkish

n Ukrainian

n United Kingdom

n US Default

n US Dvorak

serialnum or vmserialnum (Optional)

Deprecated in ESXi 5.0.x. Supported in ESXi 5.1 and later. Configures licensing. If not included, ESXi
installs in evaluation mode.

--esx=<license-key>
Specifies the vSphere license key to use. The format is 5 five-
character groups (XXXXX-XXXXX-XXXXX-XXXXX-XXXXX).

network (Optional)
Specifies a network address for the system.

--bootproto=[dhcp|static] Specifies whether to obtain the network settings from DHCP or set them
manually.

--device= Specifies either the MAC address of the network card or the device name,
in the form vmnicNN, as in vmnic0. This option refers to the uplink device
for the virtual switch.

VMware,
4
 VMware ESXi

--ip= Sets an IP address for the machine to be installed, in the form

xxx.xxx.xxx.xxx. Required with the --bootproto=static option and
ignored otherwise.

--gateway= Designates the default gateway as an IP address, in the form

xxx.xxx.xxx.xxx. Used with the --bootproto=static option.

--nameserver= Designates the primary name server as an IP address. Used with the --
bootproto=static option. Omit this option if you do not intend to use DNS.

The --nameserver option can accept two IP addresses. For example:

-- nameserver="10.126.87.104[,10.126.87.120]"

--netmask= Specifies the subnet mask for the installed system, in the form
255.xxx.xxx.xxx. Used with the --bootproto=static option.

--hostname= Specifies the host name for the installed system.

--vlanid= vlanid Specifies which VLAN the system is on. Used with either the
--bootproto=dhcp or --bootproto=static option. Set to an integer from 1
to 4096.

--addvmportgroup=(0|1) Specifies whether to add the VM Network port group, which is used by
virtual machines. The default value is 1.

paranoid (Optional)
Causes warning messages to interrupt the installation. If you omit this command, warning messages are
logged.

part or partition (Optional)

Creates an extra VMFS datastore on the system. Only one datastore per disk can be created.
Cannot be used on the same disk as the install command. Only one partition can be specified
per disk and it can only be a VMFS partition.

datastore name Specifies where the partition is to be mounted.

--ondisk= or --ondrive= Specifies the disk or drive where the partition is created.

--firstdisk= Partitions the first eligible disk found. By default, the eligible disks are set to
disk-type1, the following order:
[disk-type2,...] 1 Locally attached storage (local)

2 Network storage (remote)

3 USB disks (usb)

You can change the order of the disks by using a comma-separated list
appended to the argument. If you provide a filter list, the default settings are
overridden. You can combine filters to specify a particular disk, including
esx for the first disk with ESX installed on it, model and vendor information,

VMware,
4
 VMware ESXi

or the name of the VMkernel device driver. For example, to prefer a disk
with the model name ST3120814A and any disk that uses the mptsas
driver rather than a normal local disk, the argument is
--firstdisk=ST3120814A,mptsas,local. You can use localesx for local
storage that contains ESXi image or remoteesx for remote storage that
contains ESXi image.

reboot (Optional)
Reboots the machine after the scripted installation is complete.

<--noeject> The CD is not ejected after the installation.

rootpw (Required)
Sets the root password for the system.

--iscrypted Specifies that the password is encrypted.

password Specifies the password value.

upgrade
Either the install, upgrade, or installorupgrade command is required to determine which disk to
install or upgrade ESXi on.

--disk= or --drive= Specifies the disk to partition. In the command --disk=diskname, the
diskname can be a disk name or a full disk filesystem path in ESXi, for
example:

n Disk name: --disk=naa.6d09466044143600247aee55ca2a6405 or

n Device path: --disk=/vmfs/devices/disks/mpx.vmhba1:C0:T0:L0

For accepted disk name formats, see Disk Device Names.

--firstdisk= disk- Partitions the first eligible disk found. By default, the eligible disks are set to
type1, [disk- the following order:

type2,...] 1 Locally attached storage (local)

2 Network storage (remote)

3 USB disks (usb)

You can change the order of the disks by using a comma-separated list
appended to the argument. If you provide a filter list, the default settings are
overridden. You can combine filters to specify a particular disk, including
esx for the first disk with ESX installed on it, model and vendor information,
or the name of the VMkernel device driver. For example, to prefer a disk
with the model name ST3120814A and any disk that uses the mptsas

VMware,
4
 VMware ESXi

driver rather than a normal local disk, the argument is

--firstdisk=ST3120814A,mptsas,local. You can use localesx for
local storage that contains ESXi image or remoteesx for remote
storage that contains ESXi image.

%include or include (Optional)

Specifies another installation script to parse. This command is treated similarly to a multiline command,
but takes only one argument.

filename For example: %include part.cfg

%pre (Optional)
Specifies a script to run before the kickstart configuration is evaluated. For example, you can use it to
generate files for the kickstart file to include.

--interpreter
Specifies an interpreter to use. The default is busybox.
=[python|busybox]

%post (Optional)
Runs the specified script after package installation is complete. If you specify multiple %post sections,
they run in the order that they appear in the installation script.

--interpreter Specifies an interpreter to use. The default is busybox.

=[python|busybox]

--timeout=secs Specifies a timeout for running the script. If the script is not finished when
the timeout expires, the script is forcefully stopped.

--ignorefailure If true, the installation is considered a success even if the %post script
=[true|false] stops with an error.

%firstboot
Creates an init script that runs only during the first boot. The script has no effect on subsequent
boots. If multiple %firstboot sections are specified, they run in the order that they appear in the
kickstart file.

Note You cannot check the semantics of %firstboot scripts until the system is booting for the first time.
A %firstboot script might contain potentially catastrophic errors that are not exposed until after the
installation is complete.

Important The %firstboot script does not run, if secure boot is enabled on the ESXi host.

--interpreter
Specifies an interpreter to use. The default is busybox.

VMware,
4
VMware ESXi

=[python|busybox]

Note You cannot check the semantics of the %firstboot script until the system boots for the first time.
If the script contains errors, they are not exposed until after the installation is complete.

Disk Device Names

The install, upgrade, and installorupgrade installation script commands require the use of disk
device names.

Table 3-8. Disk Device Names

Format Example Description

NAA naa.6d09466044143600247aee55ca2a6405 SCSI INQUIRY identifier

EUI eui.3966623838646463 SCSI INQUIRY identifier

T10 t10.SanDisk00Cruzer_Blade000000004C53000117 SCSI INQUIRY identifier

1118101244
VML vml.00025261 Legacy VMkernel identifier

MPX mpx.vmhba0:C0:T0:L0 Path-based identifier

For more information on storage device names, see Storage Device Names and Identifiers.

Storage Device Names and Identifiers

In the ESXi environment, each storage device is identified by several names.

Device Identifiers
Depending on the type of storage, the ESXi host uses different algorithms and conventions to generate
an identifier for each storage device.

Storage-provided identifiers

The ESXi host queries a target storage device for the device name. From the returned metadata, the
host extracts or generates a unique identifier for the device. The identifier is based on specific storage
standards, is unique and persistent across all hosts, and has one of the following formats:

n naa.xxx

n eui.xxx

n t10.xxx

Path-based identifier

When the device does not provide an identifier, the host generates an mpx.path name, where path
represents the first path to the device, for example, mpx.vmhba1:C0:T1:L3. This identifier can
be used in the same way as the storage-provided identifies.

The mpx.path identifier is created for local devices on the assumption that their path names are
unique. However, this identifier is not unique or persistent, and can change after every system restart.

VMware,
4
VMware ESXi

Typically, the path to the device has the following format:

vmhbaAdapter:CChannel:TTarget:LLUN

n vmhbaAdapter is the name of the storage adapter. The name refers to the physical adapter on
the host, not to the SCSI controller used by the virtual machines.

n CChannel is the storage channel number.

Software iSCSI adapters and dependent hardware adapters use the channel number to show
multiple paths to the same target.

n TTarget is the target number. Target numbering is determined by the host and might change
when the mappings of targets visible to the host change. Targets that are shared by different
hosts might not have the same target number.

n LLUN is the LUN number that shows the position of the LUN within the target. The LUN number
is provided by the storage system. If a target has only one LUN, the LUN number is always zero
(0).

For example, vmhba1:C0:T3:L1 represents LUN1 on target 3 accessed through the storage adapter
vmhba1 and channel 0.

Legacy identifier

In addition to the device-provided identifiers or mpx.path identifiers, ESXi generates an alternative

legacy name for each device. The identifier has the following format:

vml.number

The legacy identifier includes a series of digits that are unique to the device. The identifier can be
derived in part from the metadata obtained through the SCSI INQUIRY command. For nonlocal
devices that do not provide SCSI INQUIRY identifiers, the vml.number identifier is used as the only
available unique identifier.

Example: Displaying Device Names in the vSphere CLI

You can use the esxcli storage core device list command to display all device names in the
vSphere CLI. The output is similar to the following example:

# esxcli storage core device list

naa.XXX
Display Name: DGC Fibre Channel Disk(naa.XXX)
...
Other UIDs: vml.000XXX
mpx.vmhba1:C0:T0:L0
Display Name: Local VMware Disk (mpx.vmhba1:C0:T0:L0)
...
Other UIDs: vml.0000000000XYZ

About the boot.cfg File

The boot loader configuration file boot.cfg specifies the kernel, the kernel options, and the boot modules
that the mboot.c32 or mboot.efi boot loader uses in an ESXi installation.

VMware,
5
 VMware ESXi

The boot.cfg file is provided in the ESXi installer. You can modify the kernelopt line of the boot.cfg file
to specify the location of an installation script or to pass other boot options.

The boot.cfg file has the following syntax:

# boot.cfg -- mboot configuration file

#
# Any line preceded with '#' is a comment.

title=STRING
prefix=DIRPATH
kernel=FILEPATH
kernelopt=STRING
modules=FILEPATH1 --- FILEPATH2 ... --- FILEPATHn

# Any other line must remain unchanged.

The commands in boot.cfg configure the boot loader.

Table 3-9. Commands in boot.cfg.

Command Description

title=STRING Sets the boot loader title to STRING.

prefix=STRING (Optional) AddsDIRPATH/ in front of every FILEPATH in the

kernel= and modules= commands that do not already start
with / or with http://.

kernel=FILEPATH Sets the kernel path to FILEPATH.

kernelopt=STRING Appends STRING to the kernel boot options.

modules=FILEPATH1 --- FILEPATH2... --- FILEPATHn Lists the modules to be loaded, separated by three hyphens
(---).

See Create an Installer ISO Image with a Custom Installation or Upgrade Script and PXE Booting the
ESXi Installer.

Install or Upgrade ESXi from a CD or DVD by Using a Script

You can install or upgrade ESXi from a CD-ROM or DVD-ROM drive by using a script that specifies the
installation or upgrade options.

You can start the installation or upgrade script by entering a boot option when you start the host. You can
also create an installer ISO image that includes the installation script. With an installer ISO image, you
can perform a scripted, unattended installation when you boot the resulting installer ISO image. See
Create an Installer ISO Image with a Custom Installation or Upgrade Script.

Prerequisites

Before you run the scripted installation or upgrade, verify that the following prerequisites are met:

n The system on which you are installing or upgrading meets the hardware requirements. See ESXi
Hardware Requirements.

VMware,
5
 VMware ESXi

n You have the ESXi installer ISO on an installation CD or DVD . See Download and Burn the
ESXi Installer ISO Image to a CD or DVD.

n The default installation or upgrade script (ks.cfg) or a custom installation or upgrade script
is accessible to the system. See About Installation and Upgrade Scripts.

n You have selected a boot command to run the scripted installation or upgrade. See Enter Boot
Options to Start an Installation or Upgrade Script. For a complete list of boot commands, see Boot
Options .

Procedure

1 Boot the ESXi installer from the local CD-ROM or DVD-ROM drive.

2 When the ESXi installer window appears, press Shift+O to edit boot options.

3 Type a boot option that calls the default installation or upgrade script or an installation or upgrade
script file that you created.

The boot option has the form ks=.

4 Press Enter.

Results

The installation, upgrade, or migration runs, using the options that you specified.

Install or Upgrade ESXi from a USB Flash Drive by Using a Script

You can install or upgrade ESXi from a USB flash drive by using a script that specifies the installation or
upgrade options.

Supported boot options are listed in Boot Options .

Prerequisites

Before running the scripted installation or upgrade, verify that the following prerequisites are met:

n The system that you are installing or upgrading to ESXi meets the hardware requirements for the
installation or upgrade. See ESXi Hardware Requirements.

n You have the ESXi installer ISO on a bootable USB flash drive. See Format a USB Flash Drive
to Boot the ESXi Installation or Upgrade.

VMware,
5
 VMware ESXi

n The default installation or upgrade script (ks.cfg) or a custom installation or upgrade script
is accessible to the system. See About Installation and Upgrade Scripts.

n You have selected a boot option to run the scripted installation, upgrade, or migration. See Enter Boot
Options to Start an Installation or Upgrade Script.

Procedure

1 Boot the ESXi installer from the USB flash drive.

2 When the ESXi installer window appears, press Shift+O to edit boot options.

3 Type a boot option that calls the default installation or upgrade script or an installation or upgrade
script file that you created.

The boot option has the form ks=.

4 Press Enter.

Results

The installation, upgrade, or migration runs, using the options that you specified.

Performing a Scripted Installation or Upgrade of ESXi by Using

PXE to Boot the Installer
ESXi 7.0 provides many options for using PXE to boot the installer and using an installation or upgrade
script.

n For information about setting up a PXE infrastructure, see PXE Booting the ESXi Installer.

n For information about creating and locating an installation script, see About Installation and Upgrade
Scripts.

n For specific procedures to use PXE to boot the ESXi installer and use an installation script, see one
of the following topics:

n PXE Boot the ESXi Installer Using a Web Server

n PXE Boot the ESXi Installer Using TFTP

n For information about using vSphere Auto Deploy to perform a scripted upgrade by using PXE to
boot, see Chapter 4 Using vSphere Auto Deploy to Reprovision Hosts .

VMware,
5
 VMware ESXi

PXE Booting the ESXi Installer

You can use the preboot execution environment (PXE) to boot a host from a network interface on hosts
with legacy BIOS or using UEFI.

ESXi is distributed in an ISO format that is used to install to flash memory or to a local hard drive. You can
extract the files and boot by using PXE.

PXE uses Dynamic Host Configuration Protocol (DHCP) and Trivial File Transfer Protocol (TFTP) to boot
an operating system over a network.

PXE booting requires some network infrastructure and a machine with a PXE-capable network adapter.
Most machines that can run ESXi have network adapters that can PXE boot.

Note PXE booting with legacy BIOS firmware is possible only over IPv4. PXE booting with UEFI
firmware is possible with either IPv4 or IPv6.

Overview of the PXE Boot Installation Process

Some of the details of the PXE boot process vary depending on whether the target host is using legacy
BIOS or UEFI firmware, and whether the boot process uses TFTP only or TFTP plus HTTP.

When you boot the target host, it interacts with the different servers in the environment to get the network
adapter, boot loader, kernel, IP address for the kernel, and finally the installation script. When all
components are in place, installation starts, as shown in the following illustration.

VMware,
5
VMware ESXi

Figure 3-1. Overview of PXE Boot Installation Process

ESXi target host

Give me an IP
UDP for the network
IP & TFTP server adapter
DHCP
server

UDP Give me the network boot loader

mboot and supporting files
TFTP
server

TCP or UDP Give me the kernel

Web server kernel
or TFTP
server

UDP Give me the IP for the kernel

IP
DHCP server

TCP Give me an installation script Installer

ks.cfg starts
script
depot

ESXi host

The interaction between the ESXi host and other servers proceeds as follows:

1 The user boots the target ESXi host.

2 The target ESXi host makes a DHCP request.

3 The DHCP server responds with the IP information and the location of the TFTP server.

4 The ESXi host contacts the TFTP server and requests the file that the DHCP server specified.

5 The TFTP server sends the network boot loader, and the ESXi host runs it. The initial boot loader
might load additional boot loader components from the TFTP server.

6 The boot loader searches for a configuration file on the TFTP server, downloads the kernel and other
ESXi components from the HTTP server or the TFTP server and boots the kernel on the ESXi host.

7 The installer runs interactively or using a kickstart script, as specified in the configuration file.

VMware,
5
VMware ESXi

PXE Boot the ESXi Installer Using TFTP

You can use a TFTP server to PXE boot the ESXi installer. The process differs slightly depending on
whether you use UEFI or boot from a legacy BIOS. Because most environments include ESXi hosts that
support UEFI boot and hosts that support only legacy BIOS, this topic discusses prerequisites and steps
for both types of hosts.

n For legacy BIOS machines, the procedure supports booting multiple different versions of the ESXi
installer by using the same pxelinux.0 or gpxelinux.0 initial boot loader for all target machines,
but potentially different PXELINUX configuration files depending on the target machine's MAC
address.

n For UEFI machines, the procedure supports booting multiple different versions of the ESXi installer by
using the same mboot.efi initial boot loader for all target machines, but potentially different
boot.cfg files depending on the target machine's MAC address.

Prerequisites

Verify that your environment meets the following prerequisites.

n ESXi installer ISO image, downloaded from the VMware Web site.

n Target host with a hardware configuration that is supported for your version of ESXi. See the VMware
Compatibility Guide.

n Network adapter with PXE support on the target ESXi host.

n DHCP server configured for PXE booting. See Sample DHCP Configurations.

n TFTP server.

n Network security policies to allow TFTP traffic (UDP port 69).

n For legacy BIOS, you can use only IPv4 networking. For UEFI PXE boot, you can use IPv4 or IPv6
networking.

n (Optional) Installation script (kickstart file).

n Use a native VLAN in most cases. If you want to specify the VLAN ID to be used with PXE booting,
check that your NIC supports VLAN ID specification.

For legacy BIOS systems, version 3.86 of the SYSLINUX package, available from https://
www.kernel.org/pub/linux/utils/boot/syslinux/.

Procedure

1 Configure the DHCP server for TFTP boot.

VMware,
5
VMware ESXi

2 (Legacy BIOS only) Obtain and configure PXELINUX:

a Obtain SYSLINUX version 3.86, unpack it, and copy the pxelinux.0 file to the top-level
/ tftpboot directory on your TFTP server.

b Create a PXELINUX configuration file using the following code model.

ESXi-6.x.x-XXXXXX is the name of the TFTP subdirectory that contains the ESXi installer files.

DEFAULT install
NOHALT 1
LABEL install
KERNEL ESXi-6.x.x-XXXXXX/mboot.c32
APPEND -c ESXi-6.x.x-XXXXXX/boot.cfg
IPAPPEND 2

c Save the PXELINUX file in the /tftpboot/pxelinux.cfg directory on your TFTP server with
a filename that will determine whether all hosts boot this installer by default:

Option Description

Same installer Name the file default if you want for all host to boot this ESXi installer by
default.

Different installers Name the file with the MAC address of the target host machine (01-
mac_address_of_target_ESXi_host) if you want only a specific host to boot with
this file, for example, 01-23-45-67-89-0a-bc.

3 (UEFI only) Copy the file efi/boot/bootx64.efi from the ESXi installer ISO image to /tftpboot/
mboot.efi on your TFTP server.

Note Newer versions of mboot.efi can generally boot older versions of ESXi, but older versions of
mboot.efi might be unable to boot newer versions of ESXi. If you plan to configure different hosts to
boot different versions of the ESXi installer, use the mboot.efi from the newest version.

4 Create a subdirectory of your TFTP server's top-level /tftpboot directory and name it after
the version of ESXi it will hold, for example, /tftpboot/ESXi-6.x.x-xxxxx.

5 Copy the contents of the ESXi installer image to the directory you just created.

6 Modify the boot.cfg file

a Add the following line:

prefix=ESXi-6.x.x-xxxxxx

Here, ESXi-6.x.x-xxxxxx is the pathname of the installer files relative to the TFTP server's root
directory.

b If the filenames in the kernel= and modules= lines begin with a forward slash (/) character,
delete that character.

VMware,
5
VMware ESXi

7 (Optional) For a scripted installation, in the boot.cfg file, add the kernelopt option to the line after
the kernel command, to specify the location of the installation script.

Use the following code as a model, where XXX.XXX.XXX.XXX is the IP address of the server where
the installation script resides, and esxi_ksFiles is the directory that contains the ks.cfg file.

kernelopt=ks=http://XXX.XXX.XXX.XXX/esxi_ksFiles/ks.cfg

8 (UEFI only) Specify whether you want for all UEFI hosts to boot the same installer.

Option Description

Same installer Copy or link the boot.cfg file to /tftpboot/boot.cfg

Different installers a Create a subdirectory of /tftpboot named after the MAC address of the
target host machine (01-mac_address_of_target_ESXi_host), for example,
01-23-45-67-89-0a-bc.
b Place a copy of (or a link to) the host's boot.cfg file in that directory,
for example, /tftpboot/01-23-45-67-89-0a-bc/boot.cfg.

PXE Boot the ESXi Installer Using a Web Server

You can use a Web server to PXE boot the ESXi installer. Because most environments include ESXi
hosts that support UEFI boot and hosts that support only legacy BIOS, this topic discusses prerequisites
and steps for both types of hosts.

n For legacy BIOS machines, the procedure supports booting multiple different versions of the ESXi
installer by using the same pxelinux.0 or gpxelinux.0 initial boot loader for all target machines,
but potentially different PXELINUX configuration files depending on the target machine's MAC
address.

n For UEFI machines, the procedure supports booting multiple different versions of the ESXi installer by
using the same mboot.efi initial boot loader for all target machines, but potentially different
boot.cfg files depending on the target machine's MAC address.

Prerequisites

Verify that your environment has the following components:

n ESXi installer ISO image, downloaded from the VMware Web site.

n Target host with a hardware configuration that is supported for your version of ESXi. See the VMware
Compatibility Guide.

n Network adapter with PXE support on the target ESXi host.

n DHCP server configured for PXE booting. See Sample DHCP Configurations.

n TFTP server.

n Network security policies to allow TFTP traffic (UDP port 69).

n For legacy BIOS, you can use only IPv4 networking. For UEFI PXE boot, you can use IPv4 or IPv6
networking.

VMware,
5
VMware ESXi

n (Optional) Installation script (kickstart file).

n Use a native VLAN in most cases. If you want to specify the VLAN ID to be used with PXE booting,
check that your NIC supports VLAN ID specification.

Verify that your environment also meets the following prerequisites required for PXE boot using a Web
Server:

n Verify that the HTTP Web server is accessible by your target ESXi hosts.

n (UEFI) Obtain iPXE, available at http://ipxe.org.

n (Legacy BIOS) Obtain version 3.86 of the SYSLINUX package, available from https://
www.kernel.org/pub/linux/utils/boot/syslinux/.

Procedure

1 Configure the DHCP server for HTTP boot.

2 (UEFI only) Obtain and configure iPXE:

a Obtain the iPXE source code, as described at http://ipxe.org/download.

b Follow the instructions on that page, but use the following make command:

make bin-x86_64-efi/snponly.efi

c Copy the resulting file snponly.efi to /tftpboot directory on your TFTP server.

3 (UEFI only) Copy the file efi/boot/bootx64.efi from the ESXi installer ISO image to /tftpboot/
mboot.efi on your TFTP server.

Note Newer versions of mboot.efi can generally boot older versions of ESXi, but older versions of
mboot.efi might be unable to boot newer versions of ESXi. If you plan to configure different hosts to
boot different versions of the ESXi installer, use the mboot.efi from the newest version.

VMware,
5
VMware ESXi

4 (Legacy BIOS only) Obtain and configure PXELINUX:

a Obtain SYSLINUX version 3.86, unpack it, and copy the gpxelinux.0 file to the top-
level / tftpboot directory on your TFTP server.

b Create a PXELINUX configuration file using the following code model.

ESXi-6.x.x-XXXXXX is the name of the TFTP subdirectory that contains the ESXi installer files.

DEFAULT install
NOHALT 1
LABEL install
KERNEL ESXi-6.x.x-XXXXXX/mboot.c32
APPEND -c ESXi-6.x.x-XXXXXX/boot.cfg
IPAPPEND 2

c Save the PXELINUX file in the /tftpboot/pxelinux.cfg directory on your TFTP server with
a filename that will determine whether all hosts boot this installer by default:

Option Description

Same installer Name the file default if you want for all host to boot this ESXi installer by
default.

Different installers Name the file with the MAC address of the target host machine (01-
mac_address_of_target_ESXi_host) if you want only a specific host to boot with
this file, for example, 01-23-45-67-89-0a-bc.

5 Create a directory on your HTTP server named for the version of ESXi it will hold, for
example, /var/www/html/ESXi-6.x.x-XXXXXX.

6 Copy the contents of the ESXi installer image to the directory you just created.

7 Modify the boot.cfg file

a Add the following line:

prefix=http://XXX.XXX.XXX.XXX/ESXi-6.x.x-XXXXXX

where http://XXX.XXX.XXX.XXX/ESXi-6.x.x-XXXXXX is the location of the installer files on the

HTTP server.

b If the filenames in the kernel= and modules= lines begin with a forward slash (/) character,
delete that character.

8 (Optional) For a scripted installation, in the boot.cfg file, add the kernelopt option to the line after
the kernel command, to specify the location of the installation script.

Use the following code as a model, where XXX.XXX.XXX.XXX is the IP address of the server where
the installation script resides, and esxi_ksFiles is the directory that contains the ks.cfg file.

kernelopt=ks=http://XXX.XXX.XXX.XXX/esxi_ksFiles/ks.cfg

VMware,
6
VMware ESXi

9 (UEFI only) Specify whether you want for all UEFI hosts to boot the same installer.

Option Description

Same installer Copy or link the boot.cfg file to /tftpboot/boot.cfg

Different installers a Create a subdirectory of /tftpboot named after the MAC address of the
target host machine (01-mac_address_of_target_ESXi_host), for example,
01-23-45-67-89-0a-bc.
b Place a copy of (or a link to) the host's boot.cfg file in that directory,
for example, /tftpboot/01-23-45-67-89-0a-bc/boot.cfg.

Upgrading Hosts by Using ESXCLI Commands

By using ESXCLI, you can upgrade an ESXi 6.5 host or ESXi 6.7 host to version 7.0 and update or patch
ESXi 6.5, ESXi 6.7, and ESXi 7.0 hosts.

vSphere 7.0 introduces components, base images, and add-ons as new software deliverables that you
can use to update or patch ESXi 7.0 hosts. For information about managing components, base images,
and add-ons on ESXi, see ESXCLI Concepts and Examples.

To use ESXCLI commands, you must install Standalone ESXCLI. For more information about installing
and using ESXCLI, see the following documents.

n Getting Started with ESXCLI

n ESXCLI Reference

Note If you press Ctrl+C while an esxcli command is running, the command-line interface exits to a
new prompt without displaying a message. However, the command continues to run to completion.

For ESXi hosts deployed with vSphere Auto Deploy, the tools VIB must be part of the base booting image
used for the initial Auto Deploy installation. The tools VIB cannot be added separately later.

VIBs, Image Profiles, and Software Depots

Upgrading ESXi with esxcli commands requires an understanding of VIBs, image profiles, and software
depots.

The following technical terms are used throughout the vSphere documentation set in discussions of
installation and upgrade tasks.

VIB

A VIB is an ESXi software package. VMware and its partners package solutions, drivers, CIM
providers, and applications that extend the ESXi platform as VIBs. VIBs are available in software
depots. You can use VIBs to create and customize ISO images or to upgrade ESXi hosts by installing
VIBs asynchronously onto the hosts.

Image Profile

VMware,
6
VMware ESXi

An image profile defines an ESXi image and consists of VIBs. An image profile always includes a
base VIB, and might include more VIBs. You examine and define an image profile by using vSphere
ESXi Image Builder.

Software Depot

A software depot is a collection of VIBs and image profiles. The software depot is a hierarchy of files
and folders and can be available through an HTTP URL (online depot) or a ZIP file (offline depot).
VMware and VMware partners make depots available. Companies with large VMware installations
might create internal depots to provision ESXi hosts with vSphere Auto Deploy, or to export an ISO
for ESXi installation.

Understanding Acceptance Levels for VIBs and Hosts

Each VIB is released with an acceptance level that cannot be changed. The host acceptance level
determines which VIBs can be installed to a host.

The acceptance level applies to individual VIBs installed by using the esxcli software vib
install and esxcli software vib update commands, to VIBs installed using vSphere Lifecycle
Manager, and to VIBs in image profiles.

The acceptance level of all VIBs on a host must be at least as high as the host acceptance level. For
example, if the host acceptance level is VMwareAccepted, you can install VIBs with acceptance levels of
VMwareCertified and VMwareAccepted, but you cannot install VIBs with acceptance levels of
PartnerSupported or CommunitySupported. To install a VIB with a restrictive acceptance level that is less
than the acceptance level of the host, you can change the setting of the host by using the vSphere Client
or by running esxcli software acceptance commands.

Setting host acceptance levels is a best practice that allows you to specify which VIBs can be installed on
a host and used with an image profile, and the level of support you can expect for a VIB. For example,
you might set a more restrictive acceptance level for hosts in a production environment than for hosts in a
testing environment.

VMware supports the following acceptance levels.

VMwareCertified

The VMwareCertified acceptance level has the most stringent requirements. VIBs with this level go
through thorough testing fully equivalent to VMware in-house Quality Assurance testing for the same
technology. Today, only I/O Vendor Program (IOVP) program drivers are published at this level.
VMware takes support calls for VIBs with this acceptance level.

VMwareAccepted

VIBs with this acceptance level go through verification testing, but the tests do not fully test every
function of the software. The partner runs the tests and VMware verifies the result. Today, CIM
providers and PSA plug-ins are among the VIBs published at this level. VMware directs support calls
for VIBs with this acceptance level to the partner's support organization.

PartnerSupported

VMware,
6
 VMware ESXi

VIBs with the PartnerSupported acceptance level are published by a partner that VMware trusts. The
partner performs all testing. VMware does not verify the results. This level is used for a new or
nonmainstream technology that partners want to enable for VMware systems. Today, driver VIB
technologies such as Infiniband, ATAoE, and SSD are at this level with nonstandard hardware drivers.
VMware directs support calls for VIBs with this acceptance level to the partner's support organization.

CommunitySupported

The CommunitySupported acceptance level is for VIBs created by individuals or companies outside
of VMware partner programs. VIBs at this level have not gone through any VMware-approved testing
program and are not supported by VMware Technical Support or by a VMware partner.

Table 3-10. VIB Acceptance Levels Required to Install on Hosts

CommunitySupported
Host Acceptance Level VMwareCertified VIB VMwareAccepted VIB PartnerSupported VIB VIB

VMwareCertified x

VMwareAccepted x x

PartnerSupported x x x

CommunitySupported x x x x

Match a Host Acceptance Level with an Update Acceptance Level

You can change the host acceptance level to match the acceptance level for a VIB or image profile that
you want to install. The acceptance level of all VIBs on a host must be at least as high as the host
acceptance level.

Use this procedure to determine the acceptance levels of the host and the VIB or image profile to install,
and to change the acceptance level of the host, if necessary for the update.

When you specify a target server by using --server=<server_name>, the server prompts you for a user
name and password. Other connection options, such as a configuration file or session file, are supported.
For a list of connection options, see Getting Started with ESXCLI, or run esxcli --help at the ESXCLI
command prompt.

Prerequisites

Install ESXCLI. See Getting Started with ESXCLI. For troubleshooting, run esxcli commands in the
ESXi Shell.

VMware,
6
 VMware ESXi

Procedure

1 Retrieve the acceptance level for the VIB or image profile.

Option Description

List information for all VIBs esxcli --server=<server_name> software sources vib list --
depot=<depot_URL>

List information for a specified VIB esxcli --server=<server_name> software sources vib list --
viburl=<vib_URL>

List information for all image profiles esxcli --server=<server_name> software sources profile list --
depot=<depot_URL>

List information for a specified

esxcli --server=<server_name> software sources profile get --
image profile depot=<depot_URL> --profile=<profile_name>

2 Retrieve the host acceptance level.

esxcli --server=<server_name> software acceptance get

3 (Optional) If the acceptance level of the VIB is more restrictive than the acceptance level of the host,
change the acceptance level of the host.

esxcli --server=<server_name> software acceptance set --level=<acceptance_level>

The acceptance_level can be VMwareCertified, VMwareAccepted, PartnerSupported, or

CommunitySupported. The values for acceptance_level are case-sensitive.

Note You can use the --force option for the esxcli software vib or esxcli software
profile command to add a VIB or image profile with a lower acceptance level than the host.
A
warning will appear. Because your setup is no longer consistent, the warning is repeated when you
install VIBs, remove VIBs, and perform certain other operations on the host.

Determine Whether an Update Requires a Host to Be in

Maintenance Mode or to Be Rebooted
VIBs that you can install with a live install do not require the host to be rebooted, but might require the
host to be placed in maintenance mode. Other VIBs and profiles might require the host to be rebooted
after the installation or update.

When you specify a target server by using --server=<server_name>, the server prompts you for a user
name and password. Other connection options, such as a configuration file or session file, are supported.
For a list of connection options, see Getting Started with ESXCLI, or run esxcli --help at the ESXCLI
command prompt.

VMware,
6
VMware ESXi

Prerequisites

Install ESXCLI. See Getting Started with ESXCLI. For troubleshooting, run esxcli commands in the
ESXi Shell.

Procedure

1 Check whether the VIB or image profile that you want to install requires the host to be placed in
maintenance mode or to be rebooted after the installation or update.

Run one of the following commands.

Option Description

Check the VIB esxcli --server=<server_name> software sources vib get -v

<absolute_path_to_vib>

Check the VIBs in a depot esxcli --server=<server_name> software sources vib get --
depot=<depot_name>

Check the image profile in a depot esxcli --server=<server_name> software sources profile get --
depot=<depot_name>

2 Review the return values.

The return values, which are read from the VIB metadata, indicate whether the host must be in
maintenance mode before installing the VIB or image profile, and whether installing the VIB or profile
requires the host to be rebooted.

Note vSphere Lifecycle Manager relies on an internal ESXi software scan API to determine whether
maintenance mode is required or not. When you install a VIB on a live system, if the value for Live-
Install-Allowed is set to false, the installation result instructs vSphere Lifecycle Manager to reboot
the host. When you remove a VIB from a live system, if the value for Live-Remove-Allowed is set to
false, the removal result instructs vSphere Lifecycle Manager to reboot the host. In either case, when
the remediation starts, vSphere Lifecycle Manager automatically puts the host into maintenance
mode.

What to do next

If necessary, place the host in maintenance mode. See Place a Host in Maintenance Mode. If a reboot is
required, and if the host belongs to a VMware HA cluster, remove the host from the cluster or disable HA
on the cluster before the installation or update. Also, place the host in maintenance mode to minimize
boot disk activity during the upgrade.

Place a Host in Maintenance Mode

Some installation and update operations that use live install require the host to be in maintenance mode.

Maintenance mode is required when an update operation requires a reboot. However, you only put the
host in maintenance mode manually when you use esxcli commands for update and upgrade operations.

VMware,
6
VMware ESXi

To determine whether an upgrade operation requires the host to be in maintenance mode, see Determine
Whether an Update Requires a Host to Be in Maintenance Mode or to Be Rebooted

Note If the host is a member of a vSAN cluster, and any virtual machine object on the host uses the
"Number of failures to tolerate=0" setting in its storage policy, the host might experience unusual delays
when entering maintenance mode. The delay occurs because vSAN has to evacuate this object from the
host for the maintenance operation to complete successfully.

When you specify a target server by using --server=<server_name>, the server prompts you for a user
name and password. Other connection options, such as a configuration file or session file, are supported.
For a list of connection options, see Getting Started with ESXCLI, or run esxcli --help at the ESXCLI
command prompt.

Prerequisites

Install ESXCLI. See Getting Started with ESXCLI. For troubleshooting, run esxcli commands in the
ESXi Shell.

Procedure

1 Check whether the host is in maintenance mode.

esxcli --server=<server_name> system maintenanceMode get

2 Power off each virtual machine running on the ESXi host.

Note You can list all running virtual machines and retrieve the World ID of each one by running the
following command.

esxcli --server=<server_name> vm process list

Option
To shut down the guest operating esxcli --server=<server_name> vm process kill --type soft --
system and then power off the virtual world-id <vm_ID>
machine

To power off the virtual machine esxcli --server=<server_name> vm process kill --type hard --
immediately world-id <vm_ID>

To force the power off operation

esxcli --server=<server_name> vm process kill --type force --
world-id <vm_ID>

Alternatively, to avoid powering off virtual machines, you can migrate them to another host. See the
topic Migrating Virtual Machines in the vCenter Server and Host Management documentation.

3 Place the host in maintenance mode.

esxcli --server=<server_name> system maintenanceMode set --enable true

VMware,
6
VMware ESXi

4 Verify that the host is in maintenance mode.

esxcli --server=<server_name> system maintenanceMode get

Update a Host with Individual VIBs

You can update a host with VIBs stored in a software depot that is accessible through a URL or in an
offline ZIP depot.

Important If you are updating ESXi from a zip bundle in a VMware-supplied depot, either online from
the VMware Web site or downloaded locally, VMware supports only the update method specified for
VMware-supplied depots in the topic Upgrade or Update a Host with Image Profiles .

When you specify a target server by using --server=<server_name>, the server prompts you for a user
name and password. Other connection options, such as a configuration file or session file, are supported.
For a list of connection options, see Getting Started with ESXCLI, or run esxcli --help at the ESXCLI
command prompt.

Prerequisites

n Install ESXCLI. See Getting Started with ESXCLI. For troubleshooting, run esxcli commands in the
ESXi Shell.

n Determine whether the update requires the host to be in maintenance mode or to be rebooted. If
necessary, place the host in maintenance mode.

See Determine Whether an Update Requires a Host to Be in Maintenance Mode or to Be Rebooted.

See Place a Host in Maintenance Mode.

n If the update requires a reboot, and if the host belongs to a VMware HA cluster, remove the host from
the cluster or disable HA on the cluster.

Procedure

1 Determine which VIBs are installed on the host.

esxcli --server=<server_name> software vib list

2 Find out which VIBs are available in the depot.

Option Description

From a depot accessible by URL esxcli --server=<server_name> software sources vib list --
depot=http://<web_server>/<depot_name>

From a local depot ZIP file esxcli --server=<server_name> software sources vib list --
depot=<absolute_path_to_depot_zip_file>

You can specify a proxy server by using the --proxy option.

VMware,
6
 VMware ESXi

3 Update the existing VIBs to include the VIBs in the depot or install new VIBs.

Option Description

Update VIBs from a depot

esxcli --server=<server_name> software vib update --
accessible by URL depot=http://<web_server>/<depot_name>

Update VIBs from a local depot ZIP

esxcli --server=<server_name> software vib update --
file depot=<absolute_path_to_depot_ZIP_file>

Install all VIBs from a ZIP file on a

esxcli --server=<server_name> software vib install --depot
specified offline depot (includes both <path_to_VMware_vib_ZIP_file>\<VMware_vib_ZIP_file> --depot
VMware VIBs and partner-supplied <path_to_partner_vib_ZIP_file>\<partner_vib_ZIP_file>
VIBs)

Options for the update and install commands allow you to perform a dry run, to specify a specific
VIB, to bypass the acceptance level verification, and so on. Do not bypass verification on production
systems. See the ESXCLI Reference.

4 Verify that the VIBs are installed on your ESXi host.

esxcli --server=<server_name> software vib list

Upgrade or Update a Host with Image Profiles

You can upgrade or update a host with image profiles stored in a software depot that is accessible
through a URL or in an offline ZIP depot.

You can use the esxcli software profile update or esxcli software profile install
command to upgrade or update an ESXi host.

When you upgrade or update a host, the esxcli software profile update or
esxcli software profile install command applies a later version (major or minor) of a full image
profile onto the host. After this operation and a reboot, the host can join a vCenter Server
environment of the same or later version.

The esxcli software profile update command brings the entire content of the ESXi host image to
the same level as the corresponding upgrade method using an ISO installer. However, the ISO installer
performs a pre-upgrade check for potential problems, such as insufficient memory or unsupported
devices. The esxcli upgrade method only performs such checks when upgrading from ESXi 6.7 Update
1 or later to a newer version.

For more about the ESXi upgrade process and methods, see Overview of the ESXi Host Upgrade
Process.

Important If you are upgrading or updating ESXi from a zip bundle in a VMware-supplied depot,
either online from the VMware website or downloaded locally, VMware supports only the update
command esxcli software profile update --depot=<depot_location> --profile=<profile_name>.

VMware,
6
VMware ESXi

When you specify a target server by using --server=<server_name>, the server prompts you for a user
name and password. Other connection options, such as a configuration file or session file, are supported.
For a list of connection options, see Getting Started with ESXCLI, or run esxcli --help at the ESXCLI
command prompt.

Note Options to the update and install commands allow you to perform a dry run, to bypass
acceptance level verification, to ignore hardware compatibility check warnings, and so on. The option to
bypass hardware compatibility check warnings is only available for ESXi 6.7 Update 1 or later. Do not
bypass verification on production systems.

For options help, type esxcli software profile install --help or esxcli software profile
update --help. For the complete listing of available command-line options, see the ESXCLI
Reference.

Prerequisites

n Install Standalone ESXCLI. See Getting Started with ESXCLI. For troubleshooting, run esxcli
commands in the ESXi Shell.

n Determine whether the update requires the host to be in maintenance mode or to be rebooted. If
necessary, place the host in maintenance mode.

See Determine Whether an Update Requires a Host to Be in Maintenance Mode or to Be Rebooted.

See Place a Host in Maintenance Mode.

Important When you use ESXCLI to update or upgrade the host, put the host manually in
maintenance mode to ensure that the boot disk is not actively in use before the upgrade begins.

n If the update requires a reboot, and if the host belongs to a VMware HA cluster, remove the host from
the cluster or disable HA on the cluster.

Procedure

1 Determine which VIBs are installed on the host.

esxcli --server=<server_name> software vib list

2 Determine which image profiles are available in the depot.

esxcli --server=<server_name> software sources profile list --depot=http://<web_server>/

<depot_name>

You can specify a proxy server by using the --proxy option.

VMware,
6
VMware ESXi

3 Update the existing image profile to include the VIBs or install new VIBs.

Important The software profile update command updates existing VIBs with the
corresponding VIBs from the specified profile, but does not affect other VIBs installed on the
target server. The software profile install command installs the VIBs present in the depot
image profile, and removes any other VIBS installed on the target server.

Option Description

Update the image profile from a

esxcli software profile update --depot=<depot_location> --
VMware-supplied ZIP bundle, in a profile=<profile_name>
depot, accessible online from the
VMware Web site or downloaded to Important This is the only update method that VMware supports for zip bundles
a local depot supplied by VMware.

VMware-supplied ZIP bundle names take the form: VMware-ESXi-

<version_number>-<build_number>-depot.zip.
The profile name for VMware-supplied zip bundles takes one of the following
forms.
n ESXi-<version_number>-<build_number>-standard

n ESXi-<version_number>-<build_number>-notools (does not include

VMware Tools)

Update the image profile from a

esxcli --server=<server_name> software profile update --
depot accessible by URL depot=http://<web_server>/<depot_name> --profile=<profile_name>

Update the image profile from ZIP

esxcli --server=<server_name> software profile update --
file stored locally on the target depot=file:///<path_to_profile_ZIP_file>/<profile_ZIP_file> --
server profile=<profile_name>

Update the image profile from a ZIP

esxcli --server=<server_name> software profile update --
file on the target server, copied into a depot=<datastore_name>/<profile_ZIP_file > --
datastore profile=<profile_name>

Update the image profile from a ZIP

esxcli --server=<server_name> software profile update --
file copied locally and applied on the depot=/<root_dir>/<path_to_profile_ZIP_file>/
target server <profile_ZIP_file> --profile=<profile_name>

Install all new VIBs in a

esxcli --server=<server_name> software profile install --
specified profile accessible by depot=http://<web_server>/<depot_name> --profile=<profile_name>
URL

Install all new VIBs in a specified

esxcli --server=<server_name> software profile install --
profile from a ZIP file stored depot=file:///<path_to_profile_ZIP_file>/<profile_ZIP_file> --
locally on the target. profile=<profile_name>

VMware,
7
VMware ESXi

Option Description

Install all new VIBs from a ZIP file

esxcli --server=<server_name> software profile install
on the target server, copied into a -- depot=<datastore_name>/<profile_ZIP_file> --
datastore profile=<profile_name>

Install all new VIBs from a ZIP

esxcli --server=<server_name> software profile install --
file copied locally and applied on depot=/<root_dir>/<path_to_profile_ZIP_file>/
the target server <profile_ZIP_file> --profile=<profile_name>

4 Verify that the VIBs are installed on your ESXi host.

esxcli --server=<server_name> software vib list

Update ESXi Hosts by Using Zip Files

You can update hosts with VIBs or image profiles by downloading a ZIP file of a depot.

VMware partners prepare third-party VIBs to provide management agents or asynchronously released
drivers.

Important If you are updating ESXi from a zip bundle in a VMware-supplied depot, either online from
the VMware Web site or downloaded locally, VMware supports only the update method specified for
VMware-supplied depots in the topic Upgrade or Update a Host with Image Profiles .

The esxcli software vib update and esxcli software vib install commands are not
supported for upgrade operations. See Upgrade or Update a Host with Image Profiles .

When you specify a target server by using --server=<server_name>, the server prompts you for a user
name and password. Other connection options, such as a configuration file or session file, are supported.
For a list of connection options, see Getting Started with ESXCLI, or run esxcli --help at the ESXCLI
command prompt.

Prerequisites

n Install ESXCLI. See Getting Started with ESXCLI. For troubleshooting, run esxcli commands in the
ESXi Shell.

n Download the ZIP file of a depot bundle from a third-party VMware partner.

n Determine whether the update requires the host to be in maintenance mode or to be rebooted. If
necessary, place the host in maintenance mode.

See Determine Whether an Update Requires a Host to Be in Maintenance Mode or to Be Rebooted.

See Place a Host in Maintenance Mode.

n If the update requires a reboot, and if the host belongs to a VMware HA cluster, remove the host from
the cluster or disable HA on the cluster.

VMware,
7
VMware ESXi

Procedure

u Install the ZIP file.

esxcli --server=<server_name> software vib update --depot=/<path_to_vib_ZIP>/<ZIP_file_name>.zip

Remove VIBs from a Host

You can uninstall third-party VIBs or VMware VIBs from your ESXi host.

VMware partners prepare third-party VIBs to provide management agents or asynchronously released
drivers.

Install ESXCLI. See Getting Started with ESXCLI. For troubleshooting, run esxcli commands in the
ESXi Shell.

Prerequisites

n If the removal requires a reboot, and if the host belongs to a VMware HA cluster, disable HA for the
host.

n Determine whether the update requires the host to be in maintenance mode or to be rebooted. If
necessary, place the host in maintenance mode.

See Determine Whether an Update Requires a Host to Be in Maintenance Mode or to Be Rebooted.

See Place a Host in Maintenance Mode.

Important To ensure that the boot disk is not actively in use when you use ESXCLI to update or
upgrade the host, put the host manually in maintenance mode.

n Install ESXCLI. See Getting Started with ESXCLI. For troubleshooting, run esxcli commands in the
ESXi Shell.

VMware,
7
VMware ESXi

Procedure

1 Power off each virtual machine running on the ESXi host.

Note You can list all running virtual machines and retrieve the World ID of each one by running the
following command.

esxcli --server=<server_name> vm process list

Option Command

To shut down the guest operating

esxcli --server=<server_name> vm process kill --type soft --
system and then power off the world-id <vm_ID>
virtual machine

To power off the virtual

esxcli --server=<server_name> vm process kill --type hard --
machine immediately world-id <vm_ID>

To force the power off operation esxcli --server=<server_name> vm process kill --type force --
world-id <vm_ID>

Alternatively, to avoid powering off virtual machines, you can migrate them to another host. See the
topic Migrating Virtual Machines in the vCenter Server and Host Management documentation.

2 Place the host in maintenance mode.

esxcli --server=<server_name> system maintenanceMode set --enable true

3 If necessary, shut down or migrate virtual machines.

4 Determine which VIBs are installed on the host.

esxcli --server=<server_name> software vib list

5 Remove the VIB.

esxcli --server=<server_name> software vib remove --vibname=<name>

Specify one or more VIBs to remove in one of the following forms.

n <name>

n <name>:<version>

n <vendor>:<name>

n <vendor>:<name>:<version>

VMware,
7
VMware ESXi

For example, the command to remove a VIB specified by vendor, name and version can take the
following form.

esxcli –-server myEsxiHost software vib remove --vibname=PatchVendor:patch42:version3

Note The remove command supports several more options. See the ESXCLI Reference.

Adding Third-Party Extensions to Hosts with an ESXCLI

Command
You can use the esxcli software vib command to add a third-party extension released as a VIB
package to the system. When you use this command, the VIB system updates the firewall rule set and
refreshes the host daemon after you reboot the system.

Otherwise, you can use a firewall configuration file to specify port rules for host services to enable
for the extension. The vSphere Security documentation discusses how to add, apply, and refresh a
firewall rule set and lists the esxcli network firewall commands.

Perform a Dry Run of an ESXCLI Installation or Upgrade

You can use the --dry-run option to preview the results of an installation or upgrade operation. A dry run
of the installation or update procedure does not make any changes, but reports the VIB-level operations
that will be performed if you run the command without the --dry-run option.

When you specify a target server by using --server=<server_name>, the server prompts you for a user
name and password. Other connection options, such as a configuration file or session file, are supported.
For a list of connection options, see Getting Started with ESXCLI, or run esxcli --help at the ESXCLI
command prompt.

Prerequisites

Install ESXCLI. See Getting Started with ESXCLI. For troubleshooting, run esxcli commands in the
ESXi Shell.

Procedure

1 Enter the installation or upgrade command, adding the --dry-run option.

n esxcli --server=<server_name> software vib install --dry-run

n esxcli --server=<server_name> software vib update --dry-run

n esxcli --server=<server_name> software profile install --dry-run

n esxcli --server=<server_name> software profile update --dry-run

2 Review the output that is returned.

The output shows which VIBs will be installed or removed and whether the installation or update
requires a reboot.

VMware,
7
 VMware ESXi

Display the Installed VIBs and Profiles That Will Be Active After
the Next Host Reboot
You can use the --rebooting-image option to list the VIBs and profiles that are installed on the host and
will be active after the next host reboot.

When you specify a target server by using --server=<server_name>, the server prompts you for a user
name and password. Other connection options, such as a configuration file or session file, are supported.
For a list of connection options, see Getting Started with ESXCLI, or run esxcli --help at the ESXCLI
command prompt.

Prerequisites

Install ESXCLI. See Getting Started with ESXCLI. For troubleshooting, run esxcli commands in the
ESXi Shell.

Procedure

1 Enter one of the following commands.

Option Description

For VIBs esxcli --server=<server_name> software vib list --rebooting-

image

For Profiles
esxcli --server=<server_name> software profile get --rebooting-
image

2 Review the output that is returned.

The output displays information for the ESXi image that will become active after the next reboot. If the
pending-reboot image has not been created, the output returns nothing.

Display the Image Profile and Acceptance Level of the Host

You can use the software profile get command to display the currently installed image profile and
acceptance level for the specified host.

This command also shows details of the installed image profile history, including profile modifications.

When you specify a target server by using --server=<server_name>, the server prompts you for a user
name and password. Other connection options, such as a configuration file or session file, are supported.
For a list of connection options, see Getting Started with ESXCLI, or run esxcli --help at the ESXCLI
command prompt.

Prerequisites

Install ESXCLI. See Getting Started with ESXCLI. For troubleshooting, run esxcli commands in the
ESXi Shell.

VMware,
7
VMware ESXi

Procedure

1 Enter the following command.

esxcli --server=<server_name> software profile get

2 Review the output.

After You Upgrade ESXi Hosts

To complete a host upgrade, you ensure that the host is reconnected to its managing vCenter Server
system and reconfigured if necessary. You also check that the host is licensed correctly.

After you upgrade an ESXi host, take the following actions:

n View the upgrade logs. You can use the vSphere Client to export the log files.

n If a vCenter Server system manages the host, you must reconnect the host to vCenter Server by
right-clicking the host in the vCenter Server inventory and selecting Connect.

n When the upgrade is complete, the ESXi host is in evaluation mode. The evaluation period is 60
days. You must assign a vSphere 7.0 license before the evaluation period expires. You can
upgrade existing licenses or acquire new ones from My VMware. Use the vSphere Client to
configure the licensing for the hosts in your environment. See the vCenter Server and Host
Management documentation for details about managing licenses in vSphere.

n The host sdX devices might be renumbered after the upgrade. If necessary, update any scripts that
reference sdX devices.

n Upgrade virtual machines on the host. See Upgrading Virtual Machines and VMware Tools.

n Set up the vSphere Authentication Proxy service. Earlier versions of the vSphere Authentication
Proxy are not compatible with vSphere 7.0. See the vSphere Security documentation for details about
configuring the vSphere Authentication Proxy service.

About ESXi Evaluation and Licensed Modes

You can use evaluation mode to explore the entire set of features for ESXi hosts. The evaluation mode
provides the set of features equal to a vSphere Enterprise Plus license. Before the evaluation mode
expires, you must assign to your hosts a license that supports all the features in use.

For example, in evaluation mode, you can use vSphere vMotion technology, the vSphere HA feature, the
vSphere DRS feature, and other features. If you want to continue using these features, you must assign a
license that supports them.

The installable version of ESXi hosts is always installed in evaluation mode. ESXi Embedded is
preinstalled on an internal storage device by your hardware vendor. It might be in evaluation mode or
prelicensed.

The evaluation period is 60 days and begins when you turn on the ESXi host. At any time during the 60-
day evaluation period, you can convert from licensed mode to evaluation mode. The time available in the
evaluation period is decreased by the time already used.

VMware,
7
VMware ESXi

For example, suppose that you use an ESXi host in evaluation mode for 20 days and then assign a
vSphere Standard Edition license key to the host. If you set the host back in evaluation mode, you can
explore the entire set of features for the host for the remaining evaluation period of 40 days.

For information about managing licensing for ESXi hosts, see the vCenter Server and Host Management
documentation.

Licensing ESXi Hosts After Upgrade

After you upgrade to ESXi 7.0, you must apply a vSphere 7.x license.

If you upgrade an ESXi host to a version that starts with the same number, you do not need to replace the
existing license with a new one. For example, if you upgrade a host from ESXi 6.5 to 6.7, you can use the
same license for the host.

If you upgrade an ESXi host to a version that starts with a different number, you must apply a new
license. For example, if you upgrade an ESXi host from 6.x to 7.x, you need to license the host with a
vSphere 7 license.

When you upgrade ESXi 6.5 or ESXi 6.7 hosts to ESXi 7.0 hosts, the hosts are in a 60-day evaluation
mode period until you apply the correct vSphere 7.0 licenses. See About ESXi Evaluation and Licensed
Modes.

You can acquire vSphere 7.x licenses from My VMware. After you have vSphere 7.x licenses, you must
assign them to all upgraded ESXi 7.0 hosts by using the license management functionality in the vSphere
Client. See the vCenter Server and Host Management documentation for details. If you use the scripted
method to upgrade to ESXi 7.0, you can provide the license key in the kickstart (ks) file.

Run the Secure Boot Validation Script on an Upgraded ESXi Host

After you upgrade an ESXi host from an older version of ESXi that did not support UEFI secure boot, you
might be able to enable secure boot. Whether you can enable secure boot depends on how you
performed the upgrade and whether the upgrade replaced all the existing VIBs or left some VIBs
unchanged. You can run a validation script after you perform the upgrade to determine whether the
upgraded installation supports secure boot.

For secure boot to succeed, the signature of every installed VIB must be available on the system. Older
versions of ESXi do not save the signatures when installing VIBs.

n If you upgrade using ESXCLI commands, the old version of ESXi performs the installation of the new
VIBs, so their signatures are not saved and secure boot is not possible.

n If you upgrade using the ISO, new VIBs do have their signatures saved. This is true also for vSphere
Lifecycle Manager upgrades that use the ISO.

n If old VIBs remain on the system, the signatures of those VIBs are not available and secure boot is
not possible.

n If the system uses a third-party driver, and the VMware upgrade does not include a new version
of the driver VIB, then the old VIB remains on the system after upgrade.

VMware,
7
 VMware ESXi

n In rare cases, VMware might drop ongoing development of a specific VIB without providing a new
VIB that replaces or obsoletes it, so the old VIB remains on the system after upgrade.

Note UEFI secure boot also requires an up-to-date bootloader. This script does not check for an up-to-
date bootloader.

Prerequisites

n Verify that the hardware supports UEFI secure boot.

n Verify that all VIBs are signed with an acceptance level of at least PartnerSupported. If you include
VIBs at the CommunitySupported level, you cannot use secure boot.

Procedure

1 Upgrade the ESXi and run the following command.

/usr/lib/vmware/secureboot/bin/secureBoot.py -c

2 Check the output.

The output either includes Secure boot can be enabled or Secure boot CANNOT be enabled.

Required Free Space for System Logging

If you used Auto Deploy to install your ESXi 7.0 host, or if you set up a log directory separate from the
default location in a scratch directory on the VMFS volume, you might need to change your current log
size and rotation settings to ensure that enough space is available for system logging .

All vSphere components use this infrastructure. The default values for log capacity in this infrastructure
vary, depending on the amount of storage available and on how you have configured system logging.
Hosts that are deployed with Auto Deploy store logs on a RAM disk, which means that the amount of
space available for logs is small.

If your host is deployed with Auto Deploy, reconfigure your log storage in one of the following ways:

n Redirect logs over the network to a remote collector.

n Redirect logs to a NAS or NFS store.

If you redirect logs to non-default storage, such as a NAS or NFS store, you might also want to
reconfigure log sizing and rotations for hosts that are installed to disk.

You do not need to reconfigure log storage for ESXi hosts that use the default configuration, which stores
logs in a scratch directory on the VMFS volume. For these hosts, ESXi 7.0 configures logs to best suit
your installation, and provides enough space to accommodate log messages.

VMware,
7
 VMware ESXi

Table 3-11. Recommended Minimum Size and Rotation Configuration for hostd, vpxa, and fdm
Logs
Number of Rotations to
Log Maximum Log File Size Preserve Minimum Disk Space Required

Management Agent (hostd) 10 MB 10 100 MB

VirtualCenter Agent (vpxa) 5 MB 10 50 MB

vSphere HA agent (Fault 5 MB 10 50 MB

Domain Manager, fdm)

For information about setting up and configuring syslog and a syslog server and installing vSphere Syslog
Collector, see the vCenter Server Installation and Setup documentation.

Configure Syslog on ESXi Hosts

You can use the vSphere Client or the esxcli system syslog command to configure the syslog
service.

For information about using the esxcli system syslog command and other ESXCLI commands, see
Getting Started with ESXCLI.

Procedure

1 Browse to the host in the vSphere Client inventory.

2 Click Configure.

3 Under System, click Advanced System Settings.

4 Click Edit.

5 Filter for syslog.

6 To set up logging globally, select the setting to change and enter the value.

Option Description

Syslog.global.defaultRotate Maximum number of archives to keep. You can set this number globally and for
individual subloggers.

Syslog.global.defaultSize Default size of the log, in KB, before the system rotates logs. You can set this
number globally and for individual subloggers.

Syslog.global.LogDir Directory where logs are stored. The directory can be on mounted NFS or VMFS
volumes. Only the /scratch directory on the local file system is persistent across
reboots. Specify the directory as [datastorename] path_to_file, where the path is
relative to the root of the volume backing the datastore. For example, the path
[storage1] /systemlogs maps to the path /vmfs/volumes/storage1/
systemlogs.

VMware,
7
VMware ESXi

Option Description

Syslog.global.logDirUnique

Selecting this option creates a subdirectory with the name of the ESXi host under
the directory specified by Syslog.global.LogDir. A unique directory is useful if the
Syslog.global.LogHost Remote host to which syslog messages are forwarded and port on which the
remote host receives syslog messages. You can include the protocol and the port,
for example, ssl://hostName1:1514. UDP (only on port 514), TCP, and SSL are
supported. The remote host must have syslog installed and correctly configured to
receive the forwarded syslog messages. See the documentation for the syslog
service installed on the remote host for information on configuration.

7 (Optional) To overwrite the default log size and log rotation for any of the

logs: a Click the name of the log that you want to customize.

b Enter the number of rotations and the log size you want.

8 Click OK.

Results

Changes to the syslog options take effect immediately.

VMware,
8
 4
Using vSphere Auto Deploy to
Reprovision Hosts

If a host was deployed using vSphere Auto Deploy, you can use vSphere Auto Deploy to reprovision the
host with a new image profile that contains a different version of ESXi. You can use vSphere ESXi Image
Builder to create and manage image profiles.

Note If you upgrade the host to use an ESXi 6.0 or later image, the vSphere Auto Deploy server
provisions the ESXi host with certificates that are signed by VMCA. If you are currently using custom
certificates, you can set up the host to use the custom certificates after the upgrade. See vSphere
Security.

The vSphere Auto Deploy server is automatically upgraded if you upgrade the corresponding vCenter
Server system. Starting with version 6.0, the vSphere Auto Deploy server is always on the same
management node as the vCenter Server system.

This chapter includes the following topics:

n Introduction to vSphere Auto Deploy

n Preparing for vSphere Auto Deploy

n Reprovisioning Hosts

Introduction to vSphere Auto Deploy

When you start a physical host that is set up for vSphere Auto Deploy, vSphere Auto Deploy uses PXE
boot infrastructure in conjunction with vSphere host profiles to provision and customize that host. No state
is stored on the host itself. Instead, the vSphere Auto Deploy server manages state information for each
host.

State Information for ESXi Hosts

vSphere Auto Deploy stores the information for the ESXi hosts to be provisioned in different locations.
Information about the location of image profiles and host profiles is initially specified in the rules that map
machines to image profiles and host profiles.

VMware,
8
 VMware ESXi

Table 4-1. vSphere Auto Deploy Stores Information for Deployment

Information Type Description Source of Information

Image state The executable software to run on an ESXi host. Image profile, created with vSphere ESXi Image
Builder.

Configuration state The configurable settings that determine how the Host profile, created by using the host profile UI.
host is configured, for example, virtual switches and Often comes from a template host.
their settings, driver settings, boot parameters, and
so on.

Dynamic state The runtime state that is generated by the running Host memory, lost during reboot.
software, for example, generated private keys or
runtime databases.

Virtual machine The virtual machines stored on a host and virtual Virtual machine information sent by vCenter Server to
state machine autostart information (subsequent vSphere Auto Deploy must be available to supply
boots only). virtual machine information to vSphere Auto Deploy.

User input State that is based on user input, for example, an IP Host customization information, stored by vCenter
address that the user provides when the system Server during first boot.
starts up, cannot automatically be included in the You can create a host profile that requires user
host profile. input for certain values.
When vSphere Auto Deploy applies a host profile that
requires user provided information, the host is placed
in maintenance mode. Use the host profile UI to
check the host profile compliance, and respond to the
prompt to customize the host.

vSphere Auto Deploy Architecture

The vSphere Auto Deploy infrastructure consists of several components.

For more information, watch the video "Auto Deploy Architecture":

Auto Deploy Architecture
(http://link.brightcove.com/services/player/bcpid2296383276001?
bctid=ref:video_auto_deploy_architecture)

VMware,
8
VMware ESXi

Figure 4-1. vSphere Auto Deploy Architecture

Auto Deploy
PowerCLI

Host profiles and

Host profile Image Builder
host
UI Rules Engine PowerCLI
customization
Image
Profiles

Auto Deploy
server
(Web server)

Fetch of predefined image

profiles and VIBs

Host profile Plug-in

engine

ESXi host
HTTP fetch of images/VIBs
and host profiles (iPXE VIBs and
boot and update) image profiles

Public depot

vSphere Auto Deploy server

Serves images and host profiles to ESXi hosts.

vSphere Auto Deploy rules engine

Sends information to the vSphere Auto Deploy server which image profile and which host profile to
serve to which host. Administrators use vSphere Auto Deploy to define the rules that assign image
profiles and host profiles to hosts.

Image profiles

Define the set of VIBs to boot ESXi hosts with.

n VMware and VMware partners make image profiles and VIBs available in public depots. Use
vSphere ESXi Image Builder to examine the depot and use the vSphere Auto Deploy rules
engine to specify which image profile to assign to which host.

n VMware customers can create a custom image profile based on the public image profiles and
VIBs in the depot and apply that image profile to the host.

Host profiles

VMware,
8
VMware ESXi

Define machine-specific configuration such as networking or storage setup. Use the host profile UI to
create host profiles. You can create a host profile for a reference host and apply that host profile to
other hosts in your environment for a consistent configuration.

Host customization

Stores information that the user provides when host profiles are applied to the host. Host
customization might contain an IP address or other information that the user supplied for that host.
For more information about host customizations, see the vSphere Host Profiles documentation.

Host customization was called answer file in earlier releases of vSphere Auto Deploy.

Preparing for vSphere Auto Deploy

Before you can start using vSphere Auto Deploy, you must prepare your environment. You start with
server setup and hardware preparation. You must configure the vSphere Auto Deploy service startup type
in the vCenter Server system that you plan to use for managing the hosts you provision, and install
PowerCLI.

n Prepare Your System for vSphere Auto Deploy

Before you can PXE boot an ESXi host with vSphere Auto Deploy, you must install prerequisite
software and set up the DHCP and TFTP servers that vSphere Auto Deploy interacts with.

n Using vSphere Auto Deploy Cmdlets

vSphere Auto Deploy cmdlets are implemented as Microsoft PowerShell cmdlets and included in
PowerCLI. Users of vSphere Auto Deploy cmdlets can take advantage of all PowerCLI features.

n Set Up Bulk Licensing

You can use the vSphere Client or ESXi Shell to specify individual license keys, or you can set up
bulk licensing by using PowerCLI cmdlets. Bulk licensing works for all ESXi hosts, but is especially
useful for hosts provisioned with vSphere Auto Deploy.

Prepare Your System for vSphere Auto Deploy

Before you can PXE boot an ESXi host with vSphere Auto Deploy, you must install prerequisite software
and set up the DHCP and TFTP servers that vSphere Auto Deploy interacts with.

If you want to manage vSphere Auto Deploy with PowerCLI cmdlets, see Set Up vSphere Auto Deploy
and Provision Hosts with vSphere PowerCLI.

Prerequisites

n Verify that the hosts that you plan to provision with vSphere Auto Deploy meet the hardware
requirements for ESXi. See ESXi Hardware Requirements.

n Verify that the ESXi hosts have network connectivity to vCenter Server and that all port requirements
are met. See vCenter Server Upgrade.

n Verify that you have a TFTP server and a DHCP server in your environment to send files and assign
network addresses to the ESXi hosts that Auto Deploy provisions. See #unique_70 and #unique_71.

VMware,
8
VMware ESXi

n Verify that the ESXi hosts have network connectivity to DHCP, TFTP, and vSphere Auto Deploy
servers.

n If you want to use VLANs in your vSphere Auto Deploy environment, you must set up the end to end
networking properly. When the host is PXE booting, the firmware driver must be set up to tag the
frames with proper VLAN IDs. You must do this set up manually by making the correct changes in
the UEFI/BIOS interface. You must also correctly configure the ESXi port groups with the correct
VLAN IDs. Ask your network administrator how VLAN IDs are used in your environment.

n Verify that you have enough storage for the vSphere Auto Deploy repository. The vSphere Auto
Deploy server uses the repository to store data it needs, including the rules and rule sets you create
and the VIBs and image profiles that you specify in your rules.

Best practice is to allocate 2 GB to have enough room for four image profiles and some extra space.
Each image profile requires approximately 400 MB. Determine how much space to reserve for the
vSphere Auto Deploy repository by considering how many image profiles you expect to use.

n Obtain administrative privileges to the DHCP server that manages the network segment you want to
boot from. You can use a DHCP server already in your environment, or install a DHCP server. For
your vSphere Auto Deploy setup, replace the gpxelinux.0 filename with snponly64.efi.vmw-
hardwired for UEFI or undionly.kpxe.vmw-hardwired for BIOS. For more information on DHCP
configurations, see Sample DHCP Configurations.

n Secure your network as for any other PXE-based deployment method. vSphere Auto Deploy transfers
data over SSL to prevent casual interference and snooping. However, the authenticity of the client or
the vSphere Auto Deploy server is not checked during a PXE boot.

n If you want to manage vSphere Auto Deploy with PowerCLI cmdlets, verify that Microsoft .NET
Framework 4.5 or 4.5.x and Windows PowerShell 3.0 or 4.0 are installed on a Windows machine.
See the vSphere PowerCLI User's Guide.

n Set up a remote Syslog server. See the vCenter Server and Host Management documentation for
Syslog server configuration information. Configure the first host you boot to use the remote Syslog
server and apply that host's host profile to all other target hosts. Optionally, install and use the
vSphere Syslog Collector, a vCenter Server support tool that provides a unified architecture for
system logging and enables network logging and combining of logs from multiple hosts.

n Install ESXi Dump Collector, set up your first host so that all core dumps are directed to ESXi Dump
Collector, and apply the host profile from that host to all other hosts.

n If the hosts that you plan to provision with vSphere Auto Deploy are with legacy BIOS, verify that the
vSphere Auto Deploy server has an IPv4 address. PXE booting with legacy BIOS firmware is possible
only over IPv4. PXE booting with UEFI firmware is possible with either IPv4 or IPv6.

Procedure

1 Navigate to Home > Auto Deploy.

By default, only the administrator role has privileges to use the vSphere Auto Deploy service.

2 On the Auto Deploy page, select your vCenter Server from the drop-down menu at the top.

VMware,
8
VMware ESXi

3 Click Enable Auto Deploy and Image Builder to activate the service.

If the Image Builder service is already active, select the Configure tab and click Enable Auto
Deploy Service.

The Software Depot page appears.

4 Configure the TFTP server.

a Click the Configure tab.

b Click Download TFTP Boot Zip to download the TFTP configuration file and unzip the file to the
directory in which your TFTP server stores files.

c (Optional) To use a proxy server, click Add on the Auto Deploy Runtime Summary pane
and enter a proxy server URL in the text box.

Using reverse proxy servers can offload the requests made to the vSphere Auto Deploy server.

5 Set up your DHCP server to point to the TFTP server on which the TFTP ZIP file is located.

a Specify the TFTP Server's IP address in DHCP option 66, frequently called next-server.

b Specify the boot filename, which is snponly64.efi.vmw-hardwired for UEFI or

undionly.kpxe.vmw-hardwired for BIOS in the DHCP option 67, frequently called boot-
filename.

6 Set each host you want to provision with vSphere Auto Deploy to network boot or PXE boot, following
the manufacturer's instructions.

7 (Optional) If you set up your environment to use Thumbprint mode, you can use your own Certificate
Authority (CA) by replacing the OpenSSL certificate rbd-ca.crt and the OpenSSL private key rbd-
ca.key with your own certificate and key file.

The files are in /etc/vmware-rbd/ssl/.

By default, vCenter Server 6.0 and later uses VMware Certificate Authority (VMCA).

Results

When you start an ESXi host that is set up for vSphere Auto Deploy, the host contacts the DHCP server
and is directed to the vSphere Auto Deploy server, which provisions the host with the image profile
specified in the active rule set.

VMware,
8
VMware ESXi

What to do next

n You can change the default configuration properties of the Auto Deploy Service. For more
information, see "Configuring vCenter Server" in the vCenter Server and Host Management
documentation.

n You can change the default configuration properties of the Image Builder Service. For more
information, see "Configuring vCenter Server" in the vCenter Server and Host Management
documentation.

n Define a rule that assigns an image profile and optional host profile, host location, or script bundle to
the host.

n (Optional) Configure the first host that you provision as a reference host. Use the storage, networking,
and other settings you want for your target hosts to share. Create a host profile for the reference host
and write a rule that assigns both the already tested image profile and the host profile to target hosts.

n (Optional) If you want to have vSphere Auto Deploy overwrite existing partitions, set up a reference
host to do auto partitioning and apply the host profile of the reference host to other hosts.

n (Optional) If you have to configure host-specific information, set up the host profile of the reference
host to prompt for user input. For more information about host customizations, see the vSphere Host
Profiles documentation.

Using vSphere Auto Deploy Cmdlets

vSphere Auto Deploy cmdlets are implemented as Microsoft PowerShell cmdlets and included in
PowerCLI. Users of vSphere Auto Deploy cmdlets can take advantage of all PowerCLI features.

Experienced PowerShell users can use vSphere Auto Deploy cmdlets just like other PowerShell cmdlets.
If you are new to PowerShell and PowerCLI, the following tips might be helpful.

You can type cmdlets, parameters, and parameter values in the PowerCLI shell.

n Get help for any cmdlet by running Get-Helpcmdlet_name.

n Remember that PowerShell is not case sensitive.

n Use tab completion for cmdlet names and parameter names.

n Format any variable and cmdlet output by using Format-List or Format-Table, or their short forms
fl or ft. For more information, run the Get-Help Format-List
cmdlet.

Passing Parameters by Name

You can pass in parameters by name in most cases and surround parameter values that contain spaces
or special characters with double quotes.

Copy-DeployRule -DeployRule testrule -ReplaceItem MyNewProfile

Most examples in the vCenter Server Installation and Setup documentation pass in parameters by name.

VMware,
8
VMware ESXi

Passing Parameters as Objects

You can pass parameters as objects if you want to perform scripting and automation. Passing in
parameters as objects is useful with cmdlets that return multiple objects and with cmdlets that return a
single object. Consider the following example.

1 Bind the object that encapsulates rule set compliance information for a host to a variable.

$tr = Test-DeployRuleSetCompliance MyEsxi42

2 View the itemlist property of the object to see the difference between what is in the rule set
and what the host is currently using.

$tr.itemlist

3 Remediate the host to use the revised rule set by using the Repair-DeployRuleSetCompliance
cmdlet with the variable.

Repair-DeployRuleSetCompliance $tr

The example remediates the host the next time you boot the host.

Set Up Bulk Licensing

You can use the vSphere Client or ESXi Shell to specify individual license keys, or you can set up bulk
licensing by using PowerCLI cmdlets. Bulk licensing works for all ESXi hosts, but is especially useful for
hosts provisioned with vSphere Auto Deploy.

Assigning license keys through the vSphere Client and assigning licensing by using PowerCLI cmdlets
function differently.

Assign license keys with the vSphere Client

You can assign license keys to a host when you add the host to the vCenter Server system or when
the host is managed by a vCenter Server system.

Assign license keys with LicenseDataManager PowerCLI

You can specify a set of license keys to be added to a set of hosts. The license keys are added to the
vCenter Server database. Each time a host is added to the vCenter Server system or reconnects to it,
the host is assigned a license key. A license key that is assigned through PowerCLI is treated as a
default license key. When an unlicensed host is added or reconnected, it is assigned the default
license key. If a host is already licensed, it keeps its license key.

The following example assigns licenses to all hosts in a data center. You can also associate licenses with
hosts and clusters.

The following example is for advanced PowerCLI users who know how to use PowerShell variables.

Prerequisites

Prepare Your System for vSphere Auto Deploy.

VMware,
8
VMware ESXi

Procedure

1 In a PowerCLI session, connect to the vCenter Server system you want to use and bind the
associated license manager to a variable.

Connect-VIServer -Server 192.XXX.X.XX -User username -Password password

$licenseDataManager = Get-LicenseDataManager

2 Run a cmdlet that retrieves the data center in which the hosts for which you want to use the bulk
licensing feature are located.

$hostContainer = Get-Datacenter -Name Datacenter-X

You can also run a cmdlet that retrieves a cluster to use bulk licensing for all hosts in a cluster, or
retrieves a folder to use bulk licensing for all hosts in a folder.

3 Create a LicenseData object and a LicenseKeyEntry object with associated type ID and license key.

$licenseData = New-Object VMware.VimAutomation.License.Types.LicenseData

$licenseKeyEntry = New-Object Vmware.VimAutomation.License.Types.LicenseKeyEntry
$licenseKeyEntry.TypeId = "vmware-vsphere”
$licenseKeyEntry.LicenseKey = "XXXXX-XXXXX-XXXXX-XXXXX-XXXXX"

4 Associate the LicenseKeys attribute of the LicenseData object you created in step 3 with the
LicenseKeyEntry object.

$licenseData.LicenseKeys += $licenseKeyEntry

5 Update the license data for the data center with the LicenseData object and verify that the license
is associated with the host container.

$licenseDataManager.UpdateAssociatedLicenseData($hostContainer.Uid, $licenseData)
$licenseDataManager.QueryAssociatedLicenseData($hostContainer.Uid)

6 Provision one or more hosts with vSphere Auto Deploy and assign them to the data center or to the
cluster that you assigned the license data to.

7 You can use the vSphere Client to verify that the host is successfully assigned to the default license
XXXXX-XXXXX-XXXXX-XXXXX-XXXXX.

Results

All hosts that you assigned to the data center are now licensed automatically.

Reprovisioning Hosts
vSphere Auto Deploy supports multiple reprovisioning options. You can perform a simple reboot or
reprovision with a different image profile or a different host profile.

A first boot using vSphere Auto Deploy requires that you set up your environment and add rules to the
rule set. See the topic "Preparing for vSphere Auto Deploy" in the vSphere installation and Setup
documentation.

VMware,
8
VMware ESXi

The following reprovisioning operations are available.

n Simple reboot.

n Reboot of hosts for which the user answered questions during the boot operation.

n Reprovision with a different image profile.

n Reprovision with a different host profile.

Reprovision Hosts with Simple Reboot Operations

A simple reboot of a host that is provisioned with vSphere Auto Deploy requires only that all prerequisites
are still met. The process uses the previously assigned image profile, host profile, custom script, and
vCenter Server location.

Prerequisites

n Verify that the setup you performed during the first boot operation is in place.

n Verify that all associated items like are available. An item can be an image profile, host profile,
custom script or vCenter Server inventory location.

n Verify that the host has the identifying information (asset tag, IP address) it had during previous boot
operations.

Procedure

1 Place the host in maintenance mode.

Host Type Action

Host is part of a DRS cluster VMware DRS migrates virtual machines to appropriate hosts when you place the
host in maintenance mode.

Host is not part of a DRS cluster You must migrate all virtual machines to different hosts and place each host in
maintenance mode.

2 Reboot the host.

Results

The host shuts down. When the host reboots, it uses the image profile that the vSphere Auto Deploy
server provides. The vSphere Auto Deploy server also applies the host profile stored on the vCenter
Server system.

Reprovision a Host with a New Image Profile by Using PowerCLI

You can use vSphere Auto Deploy to reprovision a host with a new image profile in a PowerCLI session
by changing the rule for the host and performing a test and repair compliance operation.

VMware,
9
 VMware ESXi

Several options for reprovisioning hosts exist.

n If the VIBs that you want to use support live update, you can use an esxcli software vib
command. In that case, you must also update the rule set to use an image profile that includes the
new VIBs.

n During testing, you can apply an image profile to an individual host with the Apply-
EsxImageProfile cmdlet and reboot the host so the change takes effect. The Apply-
EsxImageProfile cmdlet updates the association between the host and the image profile but
does not install VIBs on the host.

n In all other cases, use this procedure.

Prerequisites

n Verify that the image profile you want to use to reprovision the host is available. Use vSphere ESXi
Image Builder in a PowerCLI session. See "Using vSphere ESXi Image Builder CLI" in the vSphere
Installation and Setup documentation.

n Verify that the setup you performed during the first boot operation is in place.

Procedure

1 At the PowerShell prompt, run the Connect-VIServer PowerCLI cmdlet to connect to the vCenter
Server system that vSphere Auto Deploy is registered with.

Connect-VIServer ipv4_or_ipv6_address

The cmdlet might return a server certificate warning. In a production environment, make sure no
server certificate warnings result. In a development environment, you can ignore the warning.

2 Determine the location of a public software depot that contains the image profile that you want to use,
or define a custom image profile with vSphere ESXi Image Builder.

3 Run Add-EsxSoftwareDepot to add the software depot that contains the image profile to
the PowerCLI session.

Depot Type Cmdlet

Remote depot Run Add-EsxSoftwareDepot depot_url.

ZIP file a Download the ZIP file to a local file path or create a mount point local to the
PowerCLI machine.
b Run Add-EsxSoftwareDepot C:\file_path\my_offline_depot.zip.

4 Run Get-EsxImageProfile to see a list of image profiles, and decide which profile you want to
use.

VMware,
9
 VMware ESXi

5 Run Copy-DeployRule and specify the ReplaceItem parameter to change the rule that assigns
an image profile to hosts.

The following cmdlet replaces the current image profile that the rule assigns to the host with the
my_new_imageprofile profile. After the cmdlet completes, myrule assigns the new image profile to
hosts. The old version of myrule is renamed and hidden.

Copy-DeployRule myrule -ReplaceItem my_new_imageprofile

6 Test the rule compliance for each host that you want to deploy the image to.

a Verify that you can access the host for which you want to test rule set compliance.

Get-VMHost -Name ESXi_hostname

b Run the cmdlet that tests rule set compliance for the host, and bind the return value to a variable
for later use.

$tr = Test-DeployRuleSetCompliance ESXi_hostname

c Examine the differences between the contents of the rule set and configuration of the host.

$tr.itemlist

The system returns a table of current and expected items if the host for which you want to test the
new rule set compliance is compliant with the active rule set.

CurrentItem ExpectedItem
----------- ------------
my_old_imageprofile my_new_imageprofile

d Remediate the host to use the revised rule set the next time you boot the host.

Repair-DeployRuleSetCompliance $tr

7 Reboot the host to provision it with the new image profile.

Write a Rule and Assign a Host Profile to Hosts

vSphere Auto Deploy can assign a host profile to one or more hosts. The host profile might include
information about storage configuration, network configuration, or other characteristics of the host. If you
add a host to a cluster, that cluster's host profile is used.

In many cases, you assign a host to a cluster instead of specifying a host profile explicitly. The host uses
the host profile of the cluster.

Prerequisites

n Install PowerCLI and all prerequisite software. For information see vCenter Server Installation and
Setup.

VMware,
9
VMware ESXi

n Export the host profile that you want to use.

Procedure

1 In a PowerCLI session, run the Connect-VIServer cmdlet to connect to the vCenter Server system
that vSphere Auto Deploy is registered with.

Connect-VIServer ipv4_or_ipv6_address

The cmdlet might return a server certificate warning. In a production environment, make sure no
server certificate warnings result. In a development environment, you can ignore the warning.

2 Using the vSphere Client, set up a host with the settings you want to use and create a host profile
from that host.

3 Find the name of the host profile by running Get-VMhostProfile PowerCLI cmdlet, passing in the
ESXi host from which you create a host profile.

4 At the PowerCLI prompt, define a rule in which host profiles are assigned to hosts with certain
attributes, for example a range of IP addresses.

New-DeployRule -Name "testrule2" -Item my_host_profile -Pattern "vendor=Acme,Zven",

"ipv4=192.XXX.1.10-192.XXX.1.20"

The specified item is assigned to all hosts with the specified attributes. This example specifies a rule
named testrule2. The rule assigns the specified host profile my_host_profile to all hosts with an IP
address inside the specified range and with a manufacturer of Acme or Zven.

5 Add the rule to the rule set.

Add-DeployRule testrule2

By default, the working rule set becomes the active rule set, and any changes to the rule set become
active when you add a rule. If you use the NoActivate parameter, the working rule set does not
become the active rule set.

What to do next

n Assign a host already provisioned with vSphere Auto Deploy to the new host profile by performing
compliance test and repair operations on those hosts. For more information, see Test and Repair
Rule Compliance .

n Power on unprovisioned hosts to provision them with the host profile.

Test and Repair Rule Compliance

When you add a rule to the vSphere Auto Deploy rule set or modify one or more rules, hosts are not
updated automatically. vSphere Auto Deploy applies the new rules only when you test their rule
compliance and perform remediation.

VMware,
9
VMware ESXi

Prerequisites

n Prepare your system and install the Auto Deploy Server. For more information, see #unique_79.

n Verify that your infrastructure includes one or more ESXi hosts provisioned with vSphere Auto Deploy,
and that the host on which you installed PowerCLI can access those ESXi hosts.

Procedure

1 In a PowerCLI session, run the Connect-VIServer cmdlet to connect to the vCenter Server system
that vSphere Auto Deploy is registered with.

Connect-VIServer ipv4_or_ipv6_address

The cmdlet might return a server certificate warning. In a production environment, make sure no
server certificate warnings result. In a development environment, you can ignore the warning.

2 Use PowerCLI to check which vSphere Auto Deploy rules are currently available.

Get-DeployRule

The system returns the rules and the associated items and patterns.

3 Modify one of the available rules.

For example, you can change the image profile and the name of the rule.

Copy-DeployRule -DeployRule testrule -ReplaceItem MyNewProfile

You cannot edit a rule already added to the active rule set. Instead, you can copy the rule and replace
the item or pattern you want to change.

4 Verify that you can access the host for which you want to test rule set compliance.

Get-VMHost -Name MyEsxi42

5 Run the cmdlet that tests rule set compliance for the host, and bind the return value to a variable for
later use.

$tr = Test-DeployRuleSetCompliance MyEsxi42

6 Examine the differences between the contents of the rule set and configuration of the host.

$tr.itemlist

If the host for which you want to test the new rule set compliance is compliant with the active rule set,
the system returns a table of current and expected items.

CurrentItem ExpectedItem
----------- ------------
My Profile 25 MyNewProfile

VMware,
9
VMware ESXi

7 Remediate the host to use the revised rule set the next time you boot the host.

Repair-DeployRuleSetCompliance $tr

What to do next

If the rule you changed specified the inventory location, the change takes effect when you repair
compliance. For all other changes, reboot your host to have vSphere Auto Deploy apply the new rule and
to achieve compliance between the rule set and the host.

VMware,
9
 5
Collect Logs to
Troubleshoot ESXi Hosts

You can collect installation or upgrade log files for ESXi. If an installation or upgrade fails, checking the
log files can help you identify the source of the failure.

Solution

1 Enter the vm-support command in the ESXi Shell or through SSH.

2 Navigate to the /var/tmp/ directory.

3 Retrieve the log files from the .tgz file.

VMware,
9