Enable ESXi Shell and SSH Access vSphere 5.5

Use the direct console user interface to enable the ESXi Shell.

Procedure
1 From the Direct Console User Interface, press F2 to access the System Customization menu.

2 Select Troubleshooting Options and press Enter.

3 From the Troubleshooting Mode Options menu, select a service to enable.
Enable ESXi Shell
Enable SSH

4 Press Enter to enable the service.

5 (Optional) Set the timeout for the ESXi Shell.

By default, timeouts for the ESXi Shell is 0 (disabled).
The availability timeout setting is the number of minutes that can elapse before you must log in after
the ESXi Shell is enabled. After the timeout period, if you have not logged in, the shell is disabled.

NOTE If you are logged in when the timeout period elapses, your session will persist. However, the
ESXi Shell will be disabled, preventing other users from logging in.

a From the Troubleshooting Mode Options menu, select Modify ESXi Shell and SSH timeouts and
press Enter.
b Enter the availability timeout in minutes.
The availability timeout is the number of minutes that can elapse before you must log in after the
ESXi Shell is enabled.
c Press Enter.
d Enter the idle timeout.

The idle timeout is the number of minutes that can elapse before the user is logged out of an idle
interactive sessions. Changes to the idle timeout apply the next time a user logs in to the ESXi Shell
and do not affect existing sessions.
6 Press Esc until you return to the main menu of the Direct Console User Interface.

Enable Lockdown Mode

To increase the security of your ESXi hosts, you can put them in lockdown mode.

When you enable lockdown mode, no users other than vpxuser have authentication permissions, nor can
they perform operations against the host directly. Lockdown mode forces all operations to be performed
through vCenter Server.

When a host is in lockdown mode, you cannot run vSphere CLI commands from an administration server,
from a script, or from vMA against the host. External software or management tools might not be able to
retrieve or modify information from the ESXi host.

NOTE Users with the DCUI Access privilege are authorized to log in to the Direct Console User Interface
(DCUI) when lockdown mode is enabled. When you disable lockdown mode using the DCUI, all users with
the DCUI Access privilege are granted the Administrator role on the host. You grant the DCUI Access
privilege in Advanced Settings

Enabling or disabling lockdown mode affects which types of users are authorized to access host services,
but it does not affect the availability of those services. In other words, if the ESXi Shell, SSH, or Direct
Console User Interface (DCUI) services are enabled, they will continue to run whether or not the host is in
lockdown mode.
You can enable lockdown mode using the Add Host wizard to add a host to vCenter Server, using the

vSphere Web Client to manage a host, or using the direct console user interface.

Lockdown mode is available only on ESXi hosts that you add to vCenter Server.

Procedure
1 In the direct console, select Configure Lockdown Mode and press Enter.
2 Press the spacebar to select Enable Lockdown Mode and press Enter.
3 Press Enter.
The host is in lockdown mode.

Enable Lockdown Mode Using the vSphere Web Client

Enable lockdown mode to require that all configuration changes go through vCenter Server. You can also
enable or disable lockdown mode through the Direct Console User Interface (DCUI).
Procedure
1 Browse to the host in the vSphere Web Client inventory.
2 Click the Manage tab and click Settings.
3 Under System, select Security Profile.
4 In the Lockdown Mode panel, click Edit.
5 Select Enable Lockdown Mode.

6 Click OK.

Configure Syslog on ESXi 5.5 Hosts

All ESXi hosts run a syslog service (vmsyslogd), which logs messages from the VMkernel and other system
components to log files.
You can use the vSphere Web Client or the esxcli system syslog vCLI command to configure the syslog
service.
For more information about using vCLI commands, see Getting Started with vSphere Command-Line Interfaces.

Procedure
1 In the vSphere Web Client inventory, select the host.
2 Click the Manage tab.
3 In the System panel, click Advanced System Settings.
4 Locate the Syslog section of the Advanced System Settings list.
5 To set up logging globally, select the setting to change and click the Edit icon.
6 (Optional) To overwrite the default log size and log rotation for any of the logs.
a Click the name of the log you that want to customize.
b Click the Edit icon and enter the number of rotations and log size you want.
7 Click OK.
Changes to the syslog options take effect immediately.

Install vSphere 5.5 PowerCLI

Before you can run Auto Deploy cmdlets to create and modify the rules and rule sets that govern Auto
Deploy behavior, you must install vSphere PowerCLI and all prerequisite software. The Auto Deploy
cmdlets are included with the PowerCLI installation.
You install vSphere PowerCLI and prerequisite software on a Microsoft Windows system. See the Microsoft
Web site for information about installing the Microsoft software. See the vSphere PowerCLI Installation Guide
for detailed instructions for PowerCLI installation.

Procedure
1 Verify that Microsoft .NET 2.0 is installed, or install it from the Microsoft Web site following the
instructions on that Web site.
2 Verify that Microsoft Powershell 2.0 is installed, or install it from the Microsoft Web site following the
instructions on that Web site.
3 Install vSphere vSphere PowerCLI, which includes the Auto Deploy cmdlets.

Understanding vSphere 5.5 Auto Deploy

vSphere Auto Deploy can provision hundreds of physical hosts with ESXi software. You can specify the
image to deploy and the hosts to provision with the image. Optionally, you can specify host profiles to
apply to the hosts, and a vCenter Server location (folder or cluster) for each host.

Introduction to Auto Deploy
When you start a physical host that is set up for Auto Deploy, Auto Deploy uses a 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 Auto Deploy server manages state information for each host.

State Information for ESXi Hosts
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.


Auto Deploy server 
Serves images and host profiles to ESXi hosts. The Auto Deploy server is at
the heart of the Auto Deploy infrastructure.

Auto Deploy rules engine
Tells the Auto Deploy server which image profile and which host profile to
serve to which host. Administrators use the Auto Deploy PowerCLI 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
VMware and VMware partners make image profiles and VIBs available
in public depots. Use the Image Builder PowerCLI to examine the depot
and the Auto Deploy rules engine to specify which image profile to
assign to which host.
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
Define machine-specific configuration such as networking or storage setup.
Administrators create host profiles by using the host profile UI. 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.

Rules and Rule Sets
You specify the behavior of the Auto Deploy server by using a set of rules written in Power CLI. The Auto
Deploy rules engine checks the rule set for matching host patterns to decide which items (image profile, host
profile, or vCenter Server location) to provision each host with.
The rules engine maps software and configuration settings to hosts based on the attributes of the host. For
example, you can deploy image profiles or host profiles to two clusters of hosts by writing two rules, each
matching on the network address of one cluster.
For hosts that have not yet been added to a vCenter Server system, the Auto Deploy server checks with the
rules engine before serving image profiles, host profiles, and inventory location information to hosts. For
hosts that are managed by a vCenter Server system, the image profile, host profile, and inventory location
that vCenter Server has stored in the host object is used. If you make changes to rules, you can use Auto
Deploy PowerCLI cmdlets to test and repair rule compliance. When you repair rule compliance for a host,
that host's image profile and host profile assignments are updated.
The rules engine includes rules and rule sets.

Rules 
Rules can assign image profiles and host profiles to a set of hosts, or specify
the location (folder or cluster) of a host on the target vCenter Server system.
A rule can identify target hosts by boot MAC address, SMBIOS information,
BIOS UUID, Vendor, Model, or fixed DHCP IP address. In most cases, rules
apply to multiple hosts. You create rules by using Auto Deploy PowerCLI
cmdlets. After you create a rule, you must add it to a rule set. Only two rule
sets, the active rule set and the working rule set, are supported. A rule can
belong to both sets, the default, or only to the working rule set. After you
add a rule to a rule set, you can no longer change the rule. Instead, you copy
the rule and replace items or patterns in the copy. By default, Auto Deploy
uses the name of the rule for the copy and hides the original rule.

Active Rule Set 
When a newly started host contacts the Auto Deploy server with a request
for an image profile, the Auto Deploy server checks the active rule set for
matching rules. The image profile, host profile, and vCenter Server inventory
location that are mapped by matching rules are then used to boot the host. If
more than one item of the same type is mapped by the rules, the Auto
Deploy server uses the item that is first in the rule set.

Working Rule Set 
The working rule set allows you to test changes to rules before making the
changes active. For example, you can use Auto Deploy PowerCLI cmdlets for
testing compliance with the working rule set. The test verifies that hosts
managed by a vCenter Server system are following the rules in the working
rule set. By default, cmdlets add the rule to the working rule set and activate
the rules. Use the NoActivate parameter to add a rule only to the working
rule set.
Active Rule Set When a newly started host contacts the Auto Deploy server with a request
for an image profile, the Auto Deploy server checks the active rule set for
matching rules. The image profile, host profile, and vCenter Server inventory
location that are mapped by matching rules are then used to boot the host. If
more than one item of the same type is mapped by the rules, the Auto
Deploy server uses the item that is first in the rule set.
Working Rule Set The working rule set allows you to test changes to rules before making the
changes active. For example, you can use Auto Deploy PowerCLI cmdlets for
testing compliance with the working rule set. The test verifies that hosts
managed by a vCenter Server system are following the rules in the working
rule set. By default, cmdlets add the rule to the working rule set and activate
the rules. Use the NoActivate parameter to add a rule only to the working
rule set.

Auto Deploy Boot Process
When you boot a host that you want to provision or reprovision with vSphere Auto Deploy, the Auto
Deploy infrastructure supplies the image profile and, optionally, a host profile and a vCenter Server location
for that host.
The boot process is different for hosts that have not yet been provisioned with Auto Deploy (first boot) and
for hosts that have been provisioned with Auto Deploy and added to a vCenter Server system (subsequent
boot).

First Boot Overview
When a host that has not yet been provisioned with vSphere Auto Deploy boots (first boot), the host
interacts with several Auto Deploy components.
1 When the administrator turns on a host, the host starts a PXE boot sequence.
The DHCP Server assigns an IP address to the host and instructs the host to contact the TFTP server.
2 The host contacts the TFTP server and downloads the iPXE file (executable boot loader) and an iPXE
configuration file.
3 iPXE starts executing.
The configuration file instructs the host to make a HTTP boot request to the Auto Deploy server. The
HTTP request includes hardware and network information.
4 In response, the Auto Deploy server performs these tasks:
a Queries the rules engine for information about the host.
b Streams the components specified in the image profile, the optional host profile, and optional
vCenter Server location information.
5 The host boots using the image profile.
If the Auto Deploy server provided a host profile, the host profile is applied to the host.
6 Auto Deploy adds the host to the vCenter Server system that Auto Deploy is registered with.
a If a rule specifies a target folder or cluster on the vCenter Server system, the host is placed in that
folder or cluster. The target folder must be under a data center.
b If no rule exists that specifies a vCenter Server inventory location, Auto Deploy adds the host to the
first datacenter displayed in the vSphere Web Client UI.
7 (Optional) If the host profile requires the user to specify certain information, such as a static IP address,
the host is placed in maintenance mode when the host is added to the vCenter Server system.
You must reapply the host profile and update the host customization to have the host exit maintenance
mode. When you update the host customization, answer any questions when prompted.
8 If the host is part of a DRS cluster, virtual machines from other hosts might be migrated to the host after
the host has successfully been added to the vCenter Server system.

Kikstart file for unattended install of ESXi 5.5

#
# Sample scripted installation file
#
# Accept the VMware End User License Agreement
vmaccepteula
# Set the root password for the DCUI and Tech Support Mode
rootpw mypassword
# Install on the first local disk available on machine
install --firstdisk --overwritevmfs
# Set the network to DHCP on the first network adapter
network --bootproto=dhcp --device=vmnic0
# A sample post-install script
%post --interpreter=python --ignorefailure=true
import time
stampFile = open('/finished.stamp', mode='w')
stampFile.write( time.asctime() )

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. The
install command replaces the autopart command that was used for scripted ESXi 4.1 installations.


accepteula or vmaccepteula (required)
Accepts the ESXi license agreement. This command functions as it did in ESXi 4.1.
clearpart (optional)
Compared to kickstart, the behavior of the ESXi clearpart command is different. Carefully edit the
clearpart command in your existing scripts.
Clears any existing partitions on the disk. Requires install command to be specified.
--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 Permits overwriting of VMFS partitions on the specified drives. By default,
overwriting VMFS partitions is not allowed.
--firstdisk=
disk-type1
[disk-type2,...]
Partitions the first eligible disk found. By default, the eligible disks are set to
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 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.
dryrun (optional)
Parses and checks the installation script. Does not perform the installation.
install
Specifies that this is a fresh installation. Replaces the deprecated autopart command used for ESXi 4.1
scripted installations. 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 in any of the forms shown in the following examples:
n Path: --disk=/vmfs/devices/disks/mpx.vmhba1:C0:T0:L0
n MPX name: --disk=mpx.vmhba1:C0:T0:L0
n VML name: --disk=vml.000000034211234


n vmkLUN UID: --disk=vmkLUN_UID
For accepted disk name formats, see “Disk Device Names,” on page 152.
--firstdisk=
disk-type1,
[disk-type2,...]
Partitions the first eligible disk found. By default, the eligible disks are set to
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 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.
--ignoressd Excludes solid-state disks (S--firstdiskSDs) 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 Virtual SAN disk group. If you use
this option and there is no Virtual SAN partition on the selected disk, the
installation will fail. When you install ESXi on a disk that is in Virtual SAN
disk group, the result depends on the disk you select:
n If you select an SSD, the SSD and all underlying HDDs in the same disk
group will be wiped.
n If you select an HDD, and the disk group size is greater than two, only
the selected HDD will be wiped.
n If you select an HDD disk, and the disk group size is two or less, the SSD
and the selected HDD will be wiped.
For more information about managing Virtual SAN 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 already 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 in any of the forms shown in the following examples:
n Path: --disk=/vmfs/devices/disks/mpx.vmhba1:C0:T0:L0
n MPX name: --disk=mpx.vmhba1:C0:T0:L0
n VML name: --disk=vml.000000034211234
n vmkLUN UID: --disk=vmkLUN_UID
For accepted disk name formats, see “Disk Device Names,” on page 152.
--firstdisk=
disk-type1,
[disk-type2,...]
Partitions the first eligible disk found. By default, the eligible disks are set to
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 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.
--overwritevsan You must use the --overwritevsan option when you install ESXi on a disk,
either SSD or HDD (magnetic), that is in a Virtual SAN disk group. If you use
this option and there is no Virtual SAN partition on the selected disk, the
installation will fail. When you install ESXi on a disk that is in Virtual SAN
disk group, the result depends on the disk you select:
n If you select an SSD, the SSD and all underlying HDDs in the same disk
group will be wiped.
n If you select an HDD, and the disk group size is greater than two, only
the selected HDD will be wiped.
n If you select an HDD disk, and the disk group size is two or less, the SSD
and the selected HDD will be wiped.
For more information about managing Virtual SAN 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 will fail if a
VMFS partition exists on the disk, but no ESX or ESXi installation exists.
--forcemigrate If a version 4.x host contains customizations, such as third-party VIBS or
drivers, that are not included in the installer .ISO, the installer exits with an
error describing the problem. The forcemigrate option overrides the error
and forces the upgrade.
If you are upgrading a 5.0.x host, supported custom VIBs on the host that are
not included in the ESXi installer ISO are migrated. If the host or the
installer .ISO contains a VIB that creates a conflict and prevents the upgrade,
an error message identifies the offending VIB. You can remove the VIB and
retry the upgrade, or use ESXI Image Builder to create a custom installer .ISO
that resolves the conflict. The forcemigrate option is not available.
See the vSphere Upgrade documentation for imformation about upgrading
hosts that have third-party custom VIBs.
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 Default
n Estonian
n Finnish
n French
n German
n Greek
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 US Dvorak
n Ukranian
n United Kingdom
serialnum or vmserialnum (optional)
Deprecated in ESXi 5.0.x. Supported in ESXi 5.1. 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)
Specify a network address for the system.
--bootproto=[dhcp|
static]
Specify 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 options refers to the uplink device for the
virtual switch.
--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 additional 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=
disk-type1,
[disk-type2,...]
Partitions the first eligible disk found. By default, the eligible disks are set to
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 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.
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 in any of the forms shown in the following examples:
n Path: --disk=/vmfs/devices/disks/mpx.vmhba1:C0:T0:L0
n MPX name: --disk=mpx.vmhba1:C0:T0:L0
n VML name: --disk=vml.000000034211234
n vmkLUN UID:--disk=vmkLUN_UID
For accepted disk name formats, see “Disk Device Names,” on page 152.
--firstdisk=
disk-type1,
[disk-type2,...]
Partitions the first eligible disk found. By default, the eligible disks are set to
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 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.
--deletecosvmdk If the system is being upgraded from ESX, remove the directory that contains
the old Service Console VMDK file, cos.vmdk, to reclaim unused space in the
VMFS datastore.
--forcemigrate If a version 4.x host contains customizations, such as third-party VIBS or
drivers, that are not included in the installer .ISO, the installer exits with an
error describing the problem. The forcemigrate option overrides the error
and forces the upgrade. If you are upgrading a 5.0.x host, supported custom
VIBs that are not included in the ESXi installer ISO are migrated. You do not
need to to use the forcemigrate option.
See the vSphere Upgrade documentation for imformation about upgrading
hosts that have third-party custom VIBs.
CAUTION Using the forcemigrate option might cause the upgraded host to
not boot properly, to exhibit system instability, or to lose functionality.
%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
=[python|busybox]
Specifies an interpreter to use. The default is 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
=[python|busybox]
Specifies an interpreter to use. The default is busybox.
--timeout=secs Specifies a timeout for running the script. If the script is not finished when
the timeout expires, the script is forcefully terminated.
--ignorefailure If true, the installation is considered a success even if the %post script
terminated with an error.
=[true|false]
%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.
--interpreter
=[python|busybox]
Specifies an interpreter to use. The default is 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.
Differences Between ESXi 4.x and ESXi 5.x Scripted Installation and Upgrade
Commands
Before you perform a scripted ESXi installation or upgrade, if you are familiar with ESXi version 4.x scripted
installation, note the differences between ESXi 4.x and ESXi 5.x scripted installation and upgrade
commands.
In ESXi 5.x, because the installation image is loaded directly into the host RAM when the host boots, you do
not need to include the location of the installation media in the installation script.
ESXi 5.x supports scripted upgrades in addition to scripted installation.
Command differences are noted in the following summary.
accepteula or
vmaccepteula
Only in ESXi
autopart Deprecated and replaced with install, upgrade, or installorupgrade.
auth or authconfig Not supported in ESXi 5.x.
bootloader Not supported in ESXi 5.x.
esxlocation Deprecated and unused in ESXi.
firewall Not supported in ESXi 5.x.
firewallport Not supported in ESXi 5.x.
install,
installorupgrade,
upgrade
These commands replace the deprecated autopart command. Use one of
these command to specify the disk to partition, and the part command to
create the vmfs datastore. installorupgrade and upgrade are newly
supported in ESXi 5.x.
serialnum Deprecated in ESXi 5.0.x. Supported in ESXi 5.1.
vmserialnum Deprecated in ESXi 5.0.x. Supported in ESXi 5.1.
timezone Not supported in ESXi 5.x.
virtualdisk Not supported in ESXi 5.x.
zerombr Not supported in ESXi 5.x.
%firstboot --level option not supported in ESXi 5.x.
%packages Not supported in ESXi 5.x.
Disk Device Names
The install, upgrade, and installorupgrade installation script commands require the use of disk device
names.
Table 7‑3. Disk Device Names
Format Examples Description
VML vml.00025261 The device name as reported by
the vmkernel
MPX mpx.vmhba0:C0:T0:L0 The device name
NOTE When you perform a scripted upgrade from ESX 4.x to ESXi 5.x, the MPX and VML disk names
change, which might cause the upgrade to fail. To avoid this problem, use Network Address Authority
Identifiers (NAA IDs) for the disk device instead of MPX and VML disk names.
After you obtain the NAA ID or VML number, typically from the BIOS of the storage adapter, you can
modify the kickstart file (ks.cfg) for each host to identify the disk device by the NAA ID or VML number.
Some devices do not provide an NAA ID. In these circumstances, an MPX Identifier is generated by ESXi to
represent the LUN or disk. The identifier takes a form similar to the canonical name of previous versions of
ESXi with the mpx. prefix. This identifier can be used exactly as the NAA ID. See Knowledge Base article
1014953.

vSphere 5.5 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
enables you to perform a scripted, unattended installation or upgrade when you boot the resulting installer
ISO image.

Prerequisites
n Linux machine.
n The ESXi ISO image VMware-VMvisor-Installer-5.x.x-XXXXXX.x86_64.iso,where 5.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 into a folder:
mount -o loop VMware-VMvisor-Installer-5.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
5 (Optional) Modify the boot.cfg file to specify the location of the installation or upgrade script using the
kernelopt option.
This step makes the installation or upgrade completely automatic, without the need to specify the
kickstart file during the installation or upgrade.
6 Recreate the ISO image:
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 /esxi_cdrom
The ISO image now includes your custom installation or upgrade script.