Chapter 5

vCenter Server Features and Virtual Machines

This chapter covers the following topics:

vCenter Server and vSphere

Virtual Machine File Structure
Virtual Machine Snapshots
Virtual Machine Settings
Virtual Machine Migration
Virtual Machine Cloning

This chapter contains information related to Professional VMware

vSphere 7.x (2V0-21.20) exam objectives 1.2, 1.5, 2.3, 5.6, 7.1, 7.2, 7.3, 7.6,
7.9, and 7.11.4.

This chapter provides details on vCenter Server features that have not
been covered in previous chapters. It covers virtual machine features
such as file structure, migrations, and cloning. Chapters 13, “Managing
vSphere and vCenter Server,” and 14, “Virtual Machine
Management/Provision, Migrate, and Replication,” provide details on
managing vCenter Server, vSphere, and virtual machines.

“Do I Know This Already?” Quiz

The “Do I Know This Already?” quiz allows you to assess whether you
should study this entire chapter or move quickly to the “Exam
Preparation Tasks” section. In any case, the authors recommend that you
read the entire chapter at least once. Table 5-1 outlines the major head-
ings in this chapter and the corresponding “Do I Know This Already?”
quiz questions. You can find the answers in Appendix A, “Answers to the
‘Do I Know This Already?’ Quizzes and Review Questions.”

Table 5-1 “Do I Know This Already?” Section-to-Question Mapping

 Foundation Topics Section Questions

vCenter Server and vSphere 1, 2

Virtual Machine File Structure 3

Virtual Machine Snapshots 4

Virtual Machine Settings 5, 6

Virtual Machine Migration 7– 9

Virtual Machine Cloning 10

1. You just installed a new vCenter Server. Using the vSphere Client, which
of the following objects can be the first object that you create in the in-
ventory pane?

1. A cluster
2. A host
3. A virtual machine
4. A data center
5. A datastore
6. A virtual machine folder

2. You want to create a content library for your vCenter Server. Which type
of content library cannot be modified directly?

1. A library backed by vSAN

2. A local library
3. A published library
4. A subscribed library

3. You are providing support for a virtual machine named Server01 in a

vSphere 7.0 environment. Which of the following is the virtual disk data
file?
 1. Server01.vmdk
2. Server01-flat.vmdk
3. Server01.vmx
4. Server01-data.vmdk

4. You have taken multiple snapshots for a virtual machine. In the vSphere
Client Snapshot Manager, where is the You Are Here icon located?

1. Under the parent snapshot

2. Under the child snapshot
3. Under the latest snapshot
4. Under the associate delta file

5. You are configuring a virtual machine in vSphere 7.0. Which of the fol-
lowing devices cannot be configured or removed?

1. SIO controller
2. SCSI controller
3. Parallel port
4. PCI device

6. You are using the vSphere Client to edit a virtual machine in vSphere 7.0.
Which of the following is not available on the VM Options tab?

1. General Options
2. Encryption Options
3. Snapshot Options
4. vApp Options

7. You want to perform a cross-vCenter Server migration in vSphere 7.0.

Which of the following statements is true?

1. If separate SSO domains are used, you must use the APIs to perform
the migration.
2. If separate SSO domains are used, you can use the vSphere Client to
perform the migration.
3. If separate SSO domains are used, you cannot perform the migration.
 4. The vSphere and vCenter Server Enterprise licenses are required.

8. You want to perform multiple simultaneous virtual machine migrations

for a four-node DRS cluster with a 10 GigE vMotion network and multiple
data-stores. Which of the following operations are allowed without any
queuing?

1. Nine simultaneous vMotion migrations

2. Nine simultaneous vMotion migrations without Shared Storage
3. One Storage vMotion operation and four vMotion operations
4. Four simultaneous vMotion and five provisioning operations involving
the same host

9. You are optimizing your vSphere environment. Which of the following is

not helpful for improving vMotion performance?

1. Using NIOC to increase shares for vMotion traffic

2. Using traffic shaping to limit the bandwidth that is available to vMo-
tion traffic
3. Using multiple-NIC vMotion
4. Using jumbo frames

10. You want to use instant clones in vSphere. Which of the following state-
ments is true?

1. You can use the vSphere Host Client to perform an instant clone.
2. You can use the vSphere Client to perform an instant clone.
3. A sample major use case for instant clones is a large-scale deployment
in a VMware Horizon VDI.
4. vSphere 6.5 supports instant clones.

Foundation Topics

vCenter Server and vSphere

Previous chapters provide details about the vSphere topology, storage in-
frastructure, network infrastructure, and vSphere clusters. This section
provides details about other features, such as the vSphere inventory, host
profiles, and content libraries.

vSphere Managed Inventory Objects

This section describes the vSphere inventory and object types, which
should be planned prior to implementing vSphere. It provides informa-
tion on creating and configuring inventory objects during vSphere
implementation.

In vSphere, the inventory is a collection of managed virtual and physical

objects. Depending on the object type, you can configure each object and
perform operations such as setting permissions, monitoring tasks, moni-
toring events, and setting alarms. You can organize many of these objects
by placing them into folders, which makes managing them easier.

All inventory objects except for hosts can be renamed to represent their
purposes. For example, they can be named after company departments,
locations, or functions.

Note

Many systems that rely on vCenter Server, such as VMware

Horizon, also refer to vCenter objects according to their
names. Take care when renaming vCenter inventory objects
such as data centers, folders, and datastores if you have de-
ployed any external systems that rely on vCenter Server.

Note

Inventory object names cannot exceed 214 bytes (UTF-8

encoded).

Data Centers
In the vSphere inventory, a data center is a container object that is an
aggregation of all the different types of objects used to work in virtual in-
frastructure. Other than an optional folder to contain data centers, you
cannot create any object in the inventory until you create a data center.

Data centers are often used to contain all the objects in a physical data
center. For example, if you use a single vCenter Server to manage
vSphere assets in San Francisco and Chicago, you might want to use cor-
responding virtual data centers to organize each city’s assets. You could
create data center objects named San Francisco and Chicago and place
each ESXi host, virtual machine, and other object in the appropriate data
center.

Within each data center, there are four separate hierarchies:

Virtual machines (and templates)

Hosts (and clusters)
Networks
Datastores

A data center is a namespace for networks and datastores. The names for
these objects must be unique within a data center. You cannot use identi-
cal datastore names within the same data center, but you can use identi-
cal datastore names within two different data centers. Virtual machines,
templates, and clusters do not need to have unique names within the data
center but must have unique names within their folder.

Folders

In the vSphere inventory, folders are container objects that allow you to
group objects of a single type. A folder can contain data centers, clusters,
datastores, networks, virtual machines, templates, or hosts. For example,
one folder can contain hosts and a folder containing hosts, but it cannot
contain hosts and a folder containing virtual machines.

You can create data center folders directly under the root vCenter Server
and use them to organize your data centers. Within each data center is
one hierarchy of folders for virtual machines and templates, one for hosts
and clusters, one for datastores, and one for networks.

When creating or modifying a folder, the only available setting is the

folder name. You can use folders when assigning permissions and config-
uring alarms.

Clusters

A cluster is a set of ESXi hosts that are intended to work together as a

unit. When you add a host to a cluster, the host’s resources become part
of the cluster’s resources. vCenter Server manages the resources of all
hosts in a cluster as one unit. In addition to creating a cluster, assigning a
name, and adding ESXi objects, you can enable and configure features on
a cluster, such as VMware EVC, vSphere DRS, and vSphere HA.

If you enable VMware EVC on a cluster, you can ensure that migrations
with vMotion do not fail due to CPU compatibility errors. If you enable
vSphere DRS on a cluster, you can allow automatic resource balancing by
using the pooled host resources in the cluster. If you enable vSphere HA
on a cluster, you can allow rapid virtual machine recovery from host
hardware failures by using the cluster’s available host resource capacity.

Cluster features are covered in detail in Chapter 4, “Clusters and High

Availability.”

Resource Pools

In the vSphere inventory, resource pools are container objects that are
used to compartmentalize the CPU and memory resources of a host or
cluster. Virtual machines run in resource pools, using resources provided
by the resource pools. You can create multiple resource pools as direct
children of a standalone host or cluster.

You can use resource pools to organize VMs. You can delegate control
over each resource pool to specific individuals and groups. You can moni-
tor resources and set alarms on resource pools. If you need a container
just for organization and permission purposes, consider using a folder. If
you also need resource management, then consider using a resource pool.

If DRS is enabled, you can use the vSphere Client to create resource pools
in the cluster and assign resource settings, such as reservations and lim-
its. Otherwise, you can create resource pools directly on specific ESXi
hosts.

You can configure resource settings for resource pools, such as reserva-
tions, limits, and shares. See Chapter 4 for more details on resource pools.

Hosts

In the vSphere inventory, hosts are objects that represent your ESXi
servers. After installing an ESXi host, you can choose to add it to the
vSphere inventory, which requires you to provide credentials for a user
who is assigned the administrator role directly on the host.

The vpxa agent in the ESXi server maintains communication with vCenter
Server. It is an interface between the vCenter Server and the ESXi hostd
service, which drives the main operations on the host, such as powering
on a virtual machine.

For maintenance and troubleshooting activities, you can disconnect a

host from the vCenter Server, which does not remove it from vCenter
Server but suspends related vCenter Server monitoring activities. You can
connect hosts that are disconnected. If you choose to remove a host from
inventory, the host and all its associated virtual machines are removed.

If the SSL certificate used by vCenter Server is replaced or changed, the

vCenter Server is unable to decrypt the host passwords. You need to re-
connect the certificate and resupply the host credentials.

To remove a host from the vSphere inventory, you must first enter
Maintenance Mode.

Networks
In the vSphere inventory, networks are objects that are used to connect a
set of virtual network adapters. Each ESXi host may have multiple
VMkernel virtual network adapters. Each virtual machine may have mul-
tiple virtual network adapters. Each virtual network adapter may be con-
nected to a port group (on a standard virtual switch) or a distributed port
group (on a vSphere distributed switch). All virtual machines that con-
nect to the same port group belong to the same network in the virtual en-
vironment, even if they are on different physical servers. You can manage
networks by monitoring, setting permissions, and setting alarms on port
groups and distributed port groups.

Chapter 3, “Network Infrastructure,” provides details on networks.

Datastores

In the vSphere inventory, datastores are objects that represent physical

storage resources in the data center. A datastore is the storage location
for virtual machine files. The physical storage resources can come from
local SCSI disks of the ESXi host, Fibre Channel SAN disk arrays, iSCSI SAN
disk arrays, or network attached storage (NAS) arrays. VMFS datastores
can be backed by local SCSI, Fibre Channel, or iSCSI. NFS datastores can
be backed by NAS. vSAN datastores can be built in VSAN clusters.

Chapter 2, “Storage Infrastructure,” provides details on datastores.

Virtual Machines

In the vSphere inventory, virtual machines are represented in a manner

that reflects the current inventory view. For example, in the Hosts and
Clusters view, each virtual machine is a descendant of the ESXi host on
which it runs. In the Networks view, each virtual machine is a descendant
of the network to which it connects.

Templates

In the vSphere inventory, templates are objects that are effectively non-
executable virtual machines. A template is a master copy of a virtual ma-
chine that can be used to create and provision new virtual machines. A
template can have a guest operating system and application software in-
stalled. Templates are often customized during deployment to ensure that
each new virtual machine has a unique name and network settings.

For more details on templates, see the “Virtual Machine Cloning” section,
later in this chapter.

vApps

A vApp is a container object in vSphere that provides a format for pack-

aging and managing applications. Typically, a vApp is a set of virtual ma-
chines that runs a single application and allows you to manage the appli-
cation as a single unit. You can specify a unique boot order for the virtual
machines in a vApp, which allows you to gracefully start an application
that spans multiple virtual machines. You can apply resource manage-
ment settings to a vApp in a similar manner as you would to a resource
pool.

Host Profiles

A host profile is a feature that enables you to encapsulate the configura-

tion of one host and apply it to other hosts. A host profile is especially
helpful in environments where administrators manage multiple hosts
and clusters with vCenter Server. The following are characteristics of host
profiles:

Host profiles are an automated and centrally managed mechanism.

Host profiles are used for host configuration and configuration
compliance.
Host profiles can improve efficiency by reducing the use of repetitive
manual tasks.
Host profiles capture the configuration of a reference host and store
the configuration as a managed object.
Host profiles provide parameters for configuring networking, storage,
security, and other host-level settings.
 Host profiles can be applied to individual hosts, a cluster, or a set of
hosts and clusters.
Host profiles make it easy to ensure that all hosts in a cluster have a
consistent configuration.

You can use the following workflow to leverage a host profile to apply a
consistent host configuration in your vSphere environment:

Step 1. Set up and configure a reference host.

Step 2. Create a host profile from the reference host.

Step 3. Attach hosts or clusters to the host profile.

Step 4. Check the compliance of the hosts with the host profile. If all hosts are
compliant with the reference host, you do not need to take additional
steps.

Step 5. If the hosts are not fully compliant, apply (remediate) the hosts with the
host profile.

Note

If you want a host profile to use directory services for au-

thentication, the reference host must be configured to use a
directory service.

In previous releases, vSphere requires that the reference host be avail-

able for certain tasks, such as editing, importing, and exporting the host
profile. Starting with vSphere 6.0, a dedicated reference host is no longer
required for these tasks.

Auto Deploy uses host profiles to configure ESXi.

Content Libraries

A content library is a repository that can be used to share files such as

virtual machine templates, vApps, and image files among a set of vCenter
Servers. Content libraries, which were introduced in vSphere 6.0, address
the fact that multiple vCenter Servers do not directly share associated
files such as Open Virtualization Format (OVF) and image (ISO) files. A
great use case is companies having multiple sites, each managed by a
dedicated vCenter Server, where the OVF files and ISO files that are used
at one site are not directly available for use at other sites. In such a case,
you can create a content library at one site and publish it to serve the
other sites. At the other sites, you can create subscribed libraries that au-
tomatically synchronize with the published library. For example, you can
create a local content library using the main office vCenter Server, pub-
lish it, and subscribe to it from branch office vCenter Servers.

A subscribed content library can be configured to download metadata

only whenever it receives notification of a change. In such a case, the sub-
scribing library reflects the most recent changes, but it is not burdened
with supplying the storage space for every published file. Instead, the ad-
ministrator can choose whether to download the data for the entire item
or per item.

Three types of content libraries can be used: local, published, and sub-
scribed. A local content library is the simplest form. You can allow, mod-
ify, and delete content in a content library. A published library is a local
library where content is published for subscription. A subscribed library
is a library whose content you cannot change or publish. It receives its
content from a published library.

Each content library is built on a single storage entity, which may be a

VMFS datastore, an NFS datastore, a CIFS share, a local disk, or a vSAN
datastore. In vSphere 7.0, the following maximum limitations apply:
 1000 libraries per vCenter Server
1000 items per library
16 concurrent synchronization operations per published library
9 virtual disk files per OVA/OVF template

After one library is set to subscribe to another library, synchronization

occurs. Automatic synchronization occurs every 24 hours by default and
can be modified using an API. The content library service, which is
named vmware-vdcs, is installed as part of the vCenter Server installation
and uses the same database as vCenter Server.

Simple versioning is used to keep libraries synchronized. Version num-

bers are assigned to the libraries and to each item in the library. These
numbers are incremented whenever content is added or modified. The
library does not store previous versions or provide rollback.

The following sequence occurs between a subscribed library and a pub-

lished library:

Step 1. The library service on the subscriber connects to the library services on
the publisher by using the VMware Content Subscription Protocol (VCSP)
and checks for updates.

Step 2. The subscriber pulls the lib.json file from the publisher, and each
library’s lib.json files are examined to determine if discrepancies exist be-
tween the publisher and the subscriber.

Step 3. The library service uses VCSP to determine what data has changed and
sends a request to the transfer serviced to copy the required files.

Step 4. The subscriber updates the versioning information in the database.

Beginning with vSphere 6.5, you can mount an ISO file directly from the
content library, apply a guest OS customization specification during VM
deployment, and update existing templates. The content library’s perfor-
mance is then improved. The Optimized HTTP Sync option stores content
in a compressed format, which reduces the synchronization time. The
content library leverages new features in vCenter Server 6.5, including
vCenter HA and backup/restoration.

In previous versions of vSphere, content libraries supported only OVF

templates. As a result, virtual machine templates and vApp templates
were converted to OVF files when you uploaded them to a content library.
Starting with vSphere 6.7 Update 1, content libraries support virtual ma-
chine templates. Therefore, templates in the content library can be either
the OVF template type or the VM template type. vApp templates are still
converted to OVF files when you upload them to a content library. The
distribution of VM templates requires that the respective vCenter Server
instances be in Enhanced Linked Mode or Hybrid Linked Mode and that
the respective hosts be connected through a network.

To allow a user to manage a content library and its items, you can assign
the Content Library administrator role, which is a sample role, to that
user as a global permission. Users who are assigned the administrator
role at a vCenter Server level cannot see the libraries unless they have a
read-only global permission.

vSphere with Tanzu

By using vSphere with Tanzu, you can use a vSphere cluster as a platform
for running Kubernetes workloads in dedicated resource pools. Once en-
abled on a vSphere cluster, vSphere with Tanzu creates a Kubernetes con-
trol plane directly in the hypervisor layer, enabling you to deploy
vSphere pods and run your applications inside these clusters.

A vSphere pod, which is the equivalent of a Kubernetes pod, is a small

virtual machine that runs one or more Linux containers. The storage and
compute for each vSphere pod is sized precisely for its workload, with ex-
plicit resource reservations.

To use vSphere with Tanzu, you must use the VMware vSphere 7
Enterprise Plus license with an add-on for Kubernetes for all ESXi hosts
that you want to use in a supervisor cluster. You must assign an NSX-T
Data Center Advanced or higher license to NSX Manager.
Virtual Machine File Structure

A virtual machine consists of several files that are stored in a datastore.

The key files are the configuration file, virtual disk file, NVRAM setting
file, and log file. Table 5-2 provides details for virtual machine files. You
can configure virtual machine settings through the vSphere Client, esxcli,
or the vSphere Web Services SDK.

Note

Do not directly change, move, or delete virtual machine files

without guidance from a VMware Technical Support
representative.

Table 5-2 Virtual Machine Files

File Description

vmname.vmx Virtual machine configuration file

vmname.vmxf Additional virtual machine configuration file

vmname.vmdk Virtual disk characteristics (metadata) file

vmname- Virtual disk data file (commonly called a flat

flat.vmdk file)

vmname.nvram Virtual machine BIOS or UEFI configuration

or nvram file

vmname.vmsd Virtual machine snapshot file

vmname.vmsn Virtual machine snapshot data file

vmname.vswp Virtual machine swap file

 vmname.vmss Virtual machine suspend file

vmware.log Current virtual machine log file

vmware-#.log Old virtual machine log file, where # is a num-

ber starting with 1

Additional files can be created when you perform specific operations,

such as creating snapshots. If you convert a virtual machine to a tem-
plate, the .vmtx file replaces the virtual machine configuration file (.vmx
file).

By default, when you create a virtual machine, the system creates a folder
in the datastore and assigns a folder name that is similar to the virtual
machine name. In cases where the default folder name is already in use,
the system appends a number to the new folder to make it unique.

Configuration File

A virtual machine’s configuration file is a text file that contains all of the
virtual machine’s settings, including a description of the virtual hard-
ware. For example, a portion of the contents of a VMX file for a CentOS
virtual machine named server1 could include the following text:

Click here to view code image

displayName = "server1"

guestOS = "centos-64"

nvram = "server1.nvram"

scsi0:0.fileName = "server1.vmdk"

If this virtual machine is sized with two virtual CPUs and 1024 GB mem-
ory, the contents of the VMX file may also include the following text:
 numvcpus = "2"

memSize = "1024"

Virtual Disk Files

The name of the VMDK file that contains metadata for a virtual disk is in-
cluded in the VMX file as shown in the previous example
(scsi0:0.fileName = " server1.vmdk " ) . The VMDK metadata file is
a text file that contains details about the virtual disk, such as the numbers
of cylinders, heads, and sectors, as shown in the following sample
content:

Click here to view code image

ddb.geometry.cylinders = "1305"

ddb.geometry.heads = "255"

ddb.geometry.sectors = "63"

The VMDK metadata file also contains the names of other files associated
with the virtual disk, such as data (extent) files, as shown in the following
sample content:

# Extent description
RW 20971520 VMFS "server1-flat.vmdk"

Snapshot Files

When you take a snapshot of a virtual machine, the system creates a few
files. For example, if you take a snapshot for a powered-off virtual ma-
chine named server1 that has only one virtual disk and no previous snap-
shots, the following files may be created:
 server1-000001-sesparse.vmdk: A delta data disk that stores changes
made since the creation of the snapshot
server1-000001.vmdk: A VMDK metadata file for the delta disk
server1-Snapshot1.vmsn: Snapshot data

The following section provides more details on virtual machine

snapshots.

Virtual Machine Snapshots

A virtual machine snapshot captures the state of a virtual machine and

the data in the virtual machine at a specific point in time. Snapshots are
useful when you want to return the state of a virtual machine to a point
that was previously captured. For example, you can create a snapshot of a
virtual machine just prior to installing and testing software in the virtual
machine. This enables you to revert the virtual machine back to its origi-
nal state when you finish testing.

You can take multiple snapshots of a virtual machine. If you take multiple
snapshots without reverting the virtual machine, the snapshots are cre-
ated in a linear fashion, as shown in Figure 5-1. The vSphere Client repre-
sents the snapshot hierarchy of a virtual machine as a tree with the root
node being the virtual machine and nodes being each snapshot. If you re-
vert the virtual machine to a snapshot, the state of your virtual machine
is associated with that snapshot, as shown in Figure 5-2. If you create an-
other snapshot, you add branches to the snapshot tree, as shown in
Figure 5-3.
FIGURE 5-1 Linear Snapshots

FIGURE 5-2 Post-Revert Snapshot Tree

FIGURE 5-3 New Branch in Snapshot Tree

Each branch in a snapshot tree can have up to 32 snapshots.

In the vSphere Client, you can perform several snapshot operations, in-
cluding taking a snapshot, reverting to a snapshot, and deleting a snap-
shot. When taking a snapshot, you can choose whether to snap the mem-
ory and whether to quiesce the guest OS. In cases where no snapshot ex-
ists but delta files exist, you can choose to consolidate the disks.

Snapshot Use Cases

The following are some common use cases for snapshots:

Rollback changes: Prior to upgrading or making a configuration

change to an application, you can take a virtual machine snapshot to
provide a rollback option.
Rollback guest OS upgrade: Prior to upgrading the guest OS, you can
take a virtual machine snapshot to provide a rollback option.
Training and development labs: You can take snapshots of a set of
virtual machines used in a lab environment prior to allowing user ac-
cess. When the user finishes experimenting, you can revert the state of
the environment back to the original state for the next user.
Backups: A backup utility may first trigger a virtual machine snapshot
and then copy the virtual machine files without needing to deal with
open files. Following the backup, the utility deletes the snapshot.
Troubleshooting and triage: Taking a snapshot of a troubled virtual
machine enables you to later choose to return the virtual machine to
the exact state when it experienced an issue.
Linked clones: Automation and virtual desktop software, such as vRe-
alize Automation and Horizon, may leverage virtual machine snap-
shots to allow you to use fast provisioning (linked clone) methods by
which new virtual machines share a base virtual disk. For example, to
use a linked clone in a vRealize Automation blueprint, you need to
identify a virtual machine snapshot.
What a Snapshot Preserves

A snapshot preserves the following information:

Virtual machine settings: The virtual machine directory, which in-

cludes the disks added or changed after you take the snapshot
Disk state: The state of each virtual disk
Memory state: (Optional) The contents of the virtual machine’s
memory
Power state: Whether the virtual machine is powered on, powered
off, or suspended when you take the snapshot (If you revert to a snap-
shot that includes the memory state, the virtual machine is returned to
its preserved power state.)

Parent Snapshots

The first virtual machine snapshot that you create is the base snapshot.
Taking a snapshot creates a delta disk file for each disk attached to the
virtual machine and, optionally, a memory file. The delta disk files and
memory file are stored with the base VMDK file. The parent (current)
snapshot is always the snapshot that appears immediately above the You
Are Here icon in the Snapshot Manager. If you revert to a snapshot, that
snapshot becomes the parent of the You Are Here current state. When
you have multiple snapshots, each child snapshot has a parent snapshot.

Note

The parent snapshot is not always the snapshot that you took
most recently.

Snapshot Behavior

Taking a snapshot preserves the disk state by creating a series of delta

disks for each attached virtual disk or virtual raw device mapping (RDM).
Taking a snapshot creates a snapshot object in the Snapshot Manager that
represents the virtual machine state and settings. Each snapshot creates a
delta disk for each virtual disk. When you take a snapshot, the system
prevents the virtual machine from writing to the current data (VMDK) file
and instead directs all writes to the delta disk. The delta disk represents
the difference between the current state of the virtual disk and the state
that existed at the time that you took the parent snapshot. Delta disk files
can expand quickly and can become as large as the configured size of the
virtual disk if the guest operating system writes to every block of the vir-
tual disk.

When you take a snapshot, the state of the virtual machine, virtual disks,
and (optionally) virtual memory is captured in a set of files, such as the
delta, database, and memory files. By default, the delta disks are stored
with the corresponding virtual disk files, and the memory and database
files are stored in the virtual machine directory.

Flat File

A virtual disk involves a metadata file and a data file, each with the
.vmdk extension. The metadata VMDK file contains information about the
virtual disk, such as geometry and child–parent relationship information.
The data VMDK file is called the flat file, and its name contains the word
flat. Only the names of the metadata files appear in the vSphere Client
Datastore Browser. In normal circumstances, the virtual machine’s guest
OS and applications write to the flat file.

Delta Disk Files

When you create a snapshot, you create a delta disk for each virtual disk.
The delta (child) disk represents the difference between the current state
of the virtual disk and the state that existed at the time that you took the
parent snapshot. A delta disk has two VMDK files. One is a small metadata
file, and the other is a data file. Delta disk data files are also called redo
logs.

Database File
The database file is a file with the .vmsd extension that contains snapshot
details required by the Snapshot Manager. It contains details on the rela-
tionships between snapshots and child disks.

Memory File

The memory file is a file with the .vmsn extension that includes the active
state of the virtual machine’s memory. Capturing the memory state of the
virtual machine lets you revert to a powered-on state. Memory snapshots
take longer to create than nonmemory snapshots. The size of the memory
impacts the amount of time required to create the snapshot.

Limitations

The use of snapshots can impact a virtual machine’s performance and

can be limited in some scenarios, as summarized in the following list:

Snapshots are not supported for RDM physical mode disks or for iSCSI
initiators in a guest OS.
Snapshots of powered-on or suspended virtual machines with inde-
pendent disks are not supported.
A quiesced snapshot requires a supported guest operating system and
active VMware Tools services.
Snapshots are not supported with PCI vSphere DirectPath I/O devices.
Snapshots are not supported for virtual machines configured for bus
sharing.
Although snapshots may be a useful step for a backup utility, a snap-
shot is not a backup by itself. A snapshot does not provide a redundant
copy of data. If the base flat file is lost or corrupted, you cannot restore
the virtual machine by reverting to a snapshot.
Snapshots can negatively affect the performance of a virtual machine.
The performance degradation is impacted by factors such as the age of
the snapshot, the depth of the snapshot tree, and the amount of data in
the delta files.
Snapshot operations can take much longer to finish when they involve
virtual disks larger than 2 TB.
 Deleting a large snapshot that is part of the current path (as indicated
by You Are Here in the Snapshot Manager) can negatively impact the
performance and the health of the virtual machine. To minimize risk,
you can shut down the virtual machine prior to deleting the snapshot.

Virtual Machine Settings

This section provides information on virtual machine settings in vSphere

7.0.

VM Hardware/Compatibility

You can configure a virtual machine’s compatibility setting to control

which ESXi host versions can be used to run the virtual machine. In the
vSphere Client, you can set the Compatible With option for a virtual ma-
chine to a compatible ESXi version, such as ESXi 7.0 and later or ESXi 6.7
Update 2 and later. The compatibility setting determines which ESXi host
versions the virtual machine can run on and the hardware features avail-
able to the virtual machine. At the host, cluster, or data center level, you
can set the Default VM Compatibility setting. (See Chapter 14 for details.)

Virtual hardware devices perform the same function for the virtual ma-
chines as physical hardware devices do for traditional servers. Each vir-
tual machine has CPU, memory, and disk resources. All modern operating
systems provide support for virtual memory, allowing software to use
more memory than is present in the server hardware. Similarly, ESXi can
provide to its virtual machines VM memory totaling more than the capac-
ity of the host’s physical memory.

You can add virtual hardware devices to a virtual machine by editing the
virtual machine’s settings in the vSphere Client. Not all devices are config-
urable. For example, the PCI and SIO virtual hardware devices are part of
the virtual motherboard but cannot be configured or removed. You can
enable the Memory Hotplug or CPU Hotplug settings in order to add
memory or CPU resources to a running virtual machine. Memory Hotplug
is supported on all 64-bit operating systems, but some guest operating sys-
tems may not be able to make use of the added memory without restart-
ing. The ESXi license and other factors for the host where the virtual ma-
chine runs may impact the available devices for the virtual machine. For
a list of hardware devices and their functions, see Table 5-3.

Table 5-3 Virtual Machine Hardware Devices

Device Description

CPU At least one vCPU but not more than the number of logi-
cal CPUs in the host.
You can set advanced CPU features, such as the CPU
identification mask and hyperthreaded core sharing.

Chipset The virtual motherboard consists of VMware-propri-

etary virtual devices, based on the following chips:

Intel 440BX AGPset 82443BX host bridge/controller

Intel 82371AB (PIIX4) PCI ISA IDE Xcelerator
National Semiconductor PC87338 ACPI 1.0 and
PC98/99 Compliant SuperI/O
Intel 82093AA I/O advanced programmable interrupt
controller

DVD/CD- One by default.

ROM You can configure the virtual DVD/CD-ROM device to
drive connect to client devices, host devices, or datastore ISO
files.
You can add and remove virtual DVD/CD-ROM devices.

Hard A virtual disk is backed by a set of files, as discussed

disk earlier in this chapter.

IDE 0, Two virtual Integrated Drive Electronics (IDE) interfaces

IDE 1 are present by default.
Device Description

Keyboard The virtual keyboard is mapped to the user keyboard

when you connect to the virtual machine console.

Memory The size of the virtual memory becomes the size of

memory that the guest OS perceives to be physical
memory.

Network You can configure the number of virtual network

adapter adapters (NICs) and the adapter type used by each vir-
tual machine.

Parallel You can add, remove, and configure virtual parallel

port ports.

PCI One PCI controller, which is located on the virtual moth-

controller erboard, is presented to the virtual machine. It cannot
be removed or modified.

PCI If you configured devices to be reserved for PCI

device passthrough on the host, you can add up to 16 PCI
vSphere DirectPath devices to a virtual machine.

Pointing The virtual pointing device is mapped to the user’s

device pointing device when you connect to the virtual ma-
chine console.

Serial You can configure a virtual machine with up to 32 vir-

port tual serial ports.
You can add, remove, or configure virtual serial ports.
Device Description

SATA Provides access to virtual disks and DVD/CD-ROM

controller devices.
The SATA virtual controller appears to the guest OS as
an AHCI SATA controller.

SCSI Provides access to virtual disks.

controller The SCSI virtual controller appears to the guest OS as
different types of controllers, including LSI Logic
Parallel, LSI Logic SAS, and VMware Paravirtual.

SIO Provides serial and parallel ports and floppy devices

controller and performs system management activities.
One SIO controller is available to the virtual machine,
but it cannot be configured or removed.

USB The virtual USB controller is the software virtualization

controller of the USB host controller function in the virtual
machine.

USB You can add multiple virtual USB devices to a virtual

device machine that you map to USB devices connected to an
ESXi host or a client computer.

VMCI The Virtual Machine Communication Interface (VMCI)

device provides a high-speed communication channel
between a virtual machine and the hypervisor.
You cannot add or remove VMCI devices.

NVMe NVM Express (NVMe) is a logical device interface speci-

controller fication for accessing non-volatile storage media at-
tached through a PCI Express (PCIe) bus in real and vir-
tual hardware.
 Device Description

NVDIMM Provides access to the non-volatile memory resources of

controller the host.

NVDIMM You can add up to 64 virtual non-volatile dual in-line

device memory module (NVDIMM) devices to a virtual
machine.

TPM You can add a virtual Trusted Platform Module (TPM)

device 2.0 device to a virtual machine to allow the guest OS to
store sensitive information, perform cryptographic
tasks, or attest the integrity of the guest platform.

Virtual Disk Provisioning

You can configure the provisioning type for a virtual disk to thin provi-
sioned, lazy zeroed thick provisioned, or eager zeroed thick provisioned,
as described in the section “Virtual Disk Type” in Chapter 2:

With thin provisioning, storage blocks are not allocated during disk
creation, which allows fast provisioning but requires allocation and
zeroing during runtime.
With thick eager zeroed, storage blocks are allocated and zeroed dur-
ing provisioning, which allows fast runtime.
With thick lazy zeroed provisioning, storage blocks are pre-allocated
but not pre-zeroed.

Your choice for the provisioning type depends on each virtual machine’s
use case. For example, if you want to minimize the virtual machine
startup time and minimize its risk, you may choose thick provision lazy
zeroed.

VMware Tools
VMware Tools is a set of software modules and services, including ser-
vices that can communicate with the VMkernel. This communication al-
lows integration with vSphere for activities such as customizing the guest
OS, running scripts in the guest OS, and synchronizing time. If you use
guest operating systems without VMware Tools, many VMware features
are not available. VMware Tools enhances the performance of the guest
OS by enabling the latest drivers for virtual devices, enabling memory
functions (such as ballooning), and more. It includes drivers such as
SVGA, Paravirtual SCSI, VMXNet NIC, mouse, audio, guest introspection,
and memory control drivers. Prior to upgrading the hardware for a vir-
tual machine, you should upgrade VMware Tools.

VMware Tools includes the VMware user process named vmtoolsd,

which enables copy and paste and mouse control and automatically sets
screen resolution for some non-Windows guests. It enhances the perfor-
mance of the virtual machine’s guest operating system and improves
management of the virtual machine. It includes device drivers and other
software that is essential for the VM. With VMware Tools, you have more
control over the virtual machine interface.

Virtual Machine Options

To edit a virtual machine setting, you can navigate to and manipulate set-
tings on the VM Options tab. Many of these options have dependencies
with the ESXi hosts, data centers, clusters, or resource pools on which the
virtual machine resides. Table 5-4 describes the available virtual machine
options.

Table 5-4 Virtual Machine Options

Category Description

General Settings include virtual machine name, configura-

Options tion file location, and the working directory
location.

Encryption Settings allow you to enable or disable virtual ma-

 Options chine encryption or vMotion encryption.

Power Settings allow you to choose how to respond when

Management the guest OS is placed on standby. The choices are to
suspend the virtual machine or put the guest OS
into standby mode.

VMware Settings allow you to choose how to respond to spe-

Tools cific power operations. For example, you can choose
whether to power off the virtual machine or shut
down the guest when the red power-off button is
clicked.

Virtualization For virtual machines running the modern Windows

Based OS versions, you can enable VBS to add an extra
Security (VBS) level of protection.

Boot Options Settings include firmware, boot delay, and failed

boot recovery parameters.

Advanced Settings include logging, debugging, swap file loca-

Options tion, and configuration parameters.

Fibre Settings allow the virtual machine to use N_Port ID

Channel NPIV Virtualization (NPIV), including whether to generate
new worldwide names (WWNs).

vApp Options Settings allow you to control vApp functionality for

the virtual machine, such as enable/disable and IP
allocation policy. vApp settings that are made di-
rectly to a virtual machine override settings made
on the vApp.

Virtual Machine Advanced Settings

As indicated in Table 5-4, you can use the vSphere Client to edit the ad-
vanced settings for a virtual machine on its VM Options tab. You can set a
virtual machine’s advanced settings to enable or disable logging. You can
enable or disable hardware acceleration. You can set debugging and sta-
tistics to Run Normally, Record Debugging Information, Record Statistics,
or Record Statistics and Debugging. For applications that are highly sensi-
tive to latency, you can set Latency Sensitivity to High.

Under Advanced Settings, you can select Configuration Parameters,

where you can directly manipulate the virtual machine’s low-level set-
tings, as illustrated in Figure 5-4.

FIGURE 5-4 Sample Virtual Machine Configuration Parameters

Virtual Machine Migration

This section provides information such as concepts, prerequisites, and

data flow details for each migration type. Chapter 14 provides informa-
tion on performing the migrations.

Virtual Machine Migration

You can migrate virtual machines from one compute resource or storage
location to another while the virtual machine is stopped (cold) or running
(hot). For example, if you want to balance the workload, you can migrate
some virtual machines from busy ESXi hosts or datastores (or both) to
other hosts and datastores. As another example, if you want to perform
maintenance (such as an upgrade), you can migrate all virtual machines
from an ESXi host or datastore, perform the maintenance, and optionally
migrate virtual machines back to the original location.

Moving a virtual machine between the inventory folder or resource pools

in the same data center is not considered a migration. Cloning and copy-
ing virtual machines are also not forms of migration.

Each migration type involves a unique set of requirements, such as mini-

mum privileges required to perform the operation.

Note

To migrate virtual machines with disks larger than 2 TB, the

source and destination ESXi hosts must be Version 6.0 and
later.

Cold Migrations

Moving a powered-off or suspended virtual machine to a new host, new

datastore, or both is considered a cold migration. The required privilege
is Resource.Migrate Powered Off Virtual Machine.

Hot Migrations

Moving a powered-on virtual machine to a new host, new datastore, or

both is considered a hot migration. During the migration, vCenter Server
must take steps to ensure that active connections and services of the vir-
tual machine are not interrupted.

Cross-Host Migrations
Moving a virtual machine, whether hot or cold, to a new host is consid-
ered a cross-host migration. In vSphere Client wizards that involve cross-
host migrations, you can choose a destination host. Alternatively, when
available and properly configured, you can choose a DRS cluster, re-
source pool, or vApp as the destination.

The cross-host migration wizards include a Compatibility panel to iden-

tify any compatibility issues or warnings. If the panel displays the mes-
sage “Compatibility Checks Succeeded,” you can proceed with no concern.
If the panel displays an error, the migration is disabled for the associated
hosts. If it displays a warning message, the migration is not disabled, and
you can proceed, bearing in mind the warning. For hot migrations, the
compatibility check accommodates vMotion CPU compatibility checking.

For a virtual machine using an NVDIMM device and PMem storage, the
destination host or cluster must have available PMem resources to pass
the compatibility check. For a cold migration involving a virtual machine
that does not have an NVDIMM device but uses PMem storage, you can
choose a target host or cluster without available PMem resources. The
hard disks use the storage policy and data-store selected for the virtual
machine’s configuration files.

Cross-Datastore Migrations

Moving a virtual machine, whether hot or cold, to a new datastore is con-

sidered a cross-datastore migration.

Cross-vCenter Server Migrations

Moving a virtual machine, whether hot or cold, to a new vCenter Server is

considered a cross-vCenter Server migration. To perform a cross-vCenter
Server migration, you must meet the following requirements:

The associated vCenter Servers and ESXi hosts must be 6.0 or later.
 The cross-vCenter Server and long-distance vMotion features require
an Enterprise Plus license.
The vCenter Server instances must be time-synchronized with each
other for correct vCenter Single Sign-On token verification.
For migration of compute resources only, both vCenter Server in-
stances must be connected to the shared virtual machine storage.
When using the vSphere Client, both vCenter Server instances must be
in Enhanced Linked Mode, and they must be in the same vCenter
Single Sign-On domain.

Note

If the vCenter Server instances exist in separate vCenter

Single Sign-On domains, you can use vSphere APIs/SDK to
migrate virtual machines.

Virtual Machine Migration Limitations

vCenter Server limits the number of simultaneous virtual machine migra-

tion and provisioning operations that occur per host, network, and datas-
tore. Each of the network, datastore, and host limits must be satisfied for
the operation to proceed. vCenter Server uses a costing method by which
each migration and provisioning operation is assigned a cost per re-
source. Operations whose costs cause resources to exceed their limits are
queued until other operations complete.

Limits depend on the resource type, ESXi version, migration type, and
other factors, such as network type. ESXi Versions 5.0 to 7.0 have consis-
tent limits:

Network limits: Network limits apply only to vMotion migrations.

Each vMotion migration has a network resource cost of 1. The network
limit depends on the network bandwidth for the VMkernel adapter en-
 abled for vMotion migration. For 1 GigE the limit is 4, and for 10 GigE
it is 8.
Datastore limits: Datastore limits apply to vMotion and Storage vMo-
tion migrations. Each vMotion migration has a resource cost of 1
against the shared datastore. Each Storage vMotion migration has a re-
source cost of 16 against both the source and destination datastores.
The datastore limit per datastore is 128.
Host limits: Host limits apply to vMotion, Storage vMotion, and cold
migrations. They also apply to virtual machine provisioning opera-
tions, including new deployments, and cloning. Provisioning and vMo-
tion operations have a host cost of 1. Storage vMotion operations have
a host cost of 4. The host limit per host is 8.

For costing purposes, a hot migration that is both a cross-host and cross-
datastore migration (vMotion migration without shared storage) is con-
sidered to be a combination of a vMotion and Storage vMotion migration
and applies the associated network, host, and datastore costs. vMotion
migration without shared storage is equivalent to Storage vMotion migra-
tion with a network cost of 1.

Consider the following examples for a four-node DRS cluster with a 10

GigE vMotion network:

If you perform nine simultaneous vMotion migrations, the ninth mi-

gration is queued due to the network limit, even if different hosts are
involved.
If you perform nine simultaneous hot cross-host and cross-datastore
migrations involving the same datastore, the ninth migration is
queued due to the datastore limit, even if the migrations are split as to
whether the datastore is the source or the target.
You can simultaneously perform one Storage vMotion and four vMo-
tion operations involving a specific host.

TCP/IP Stacks

You can use the vMotion TCP/IP stack to isolate vMotion traffic and assign
it to a dedicated default gateway, routing table, and DNS configuration. To
use the vMotion TCP/IP stack, select vMotion from the TCP/IP Stack drop-
down menu when configuring the associated VMkernel virtual network
adapter. When you assign a VMkernel virtual network adapter to the
vMotion stack, you cannot use the adapter for purposes other than vMo-
tion. Likewise, you can use the provisioning TCP/IP stack to isolate traffic
for cold migration, cloning, and snapshots. To use the provisioning TCP/IP
stack, select Provisioning from the TCP/IP Stack drop-down menu when
configuring the associated VMkernel virtual network adapter. When you
assign a VMkernel virtual network adapter to the provisioning stack, you
cannot use the adapter for purposes other than provisioning.

vMotion Details

This section provides details on the vMotion feature in vSphere.

vMotion Overview

A hot cross-host migration is called a vMotion migration. A hot migration

across hosts and datastores is often called a vMotion migration without
shared storage. A hot cross-vCenter Server migration is often called a
cross-vCenter Server vMotion migration. Although the term vMotion mi-
gration may be used to describe any hot cross-host migration, this section
provides details on just the traditional vMotion migration, in which
shared storage is used and cross-datastore migration does not occur.

During a vMotion migration, the entire state of the virtual machine is

moved to the new host. The state includes the current memory content
and all the information that defines and identifies the virtual machine.
The memory content includes the components of the operating system,
applications, and transaction data that are in the memory. The state in-
cludes all the data that maps to the virtual machine hardware elements,
such as BIOS, devices, CPU, MAC addresses for the Ethernet cards, chipset
states, and registers. The associated virtual disk remains in the original
location on storage that is shared between the source and destination
hosts. After the virtual machine state is migrated to the destination host,
the virtual machine continues execution on the destination host.
vMotion Requirements

As explained in the section “Enhanced vMotion Compatibility (EVC)” in

Chapter 4, vMotion requires that the destination host’s processors be
compatible with the source host’s processors to support live migration.
Specifically, the destination processors must come from the same family
and provide the same instruction set as the source processors. You can
enable EVC in the cluster to broaden the vMotion compatibility.

Before using vMotion, you must address its host configuration require-
ments. Each host must meet the licensing, shared storage, and networking
requirements for vMotion.

For standard vMotion migration, you must configure the source and des-
tination hosts with shared storage to enable the migrated virtual ma-
chines to remain in the same datastore throughout the migration. Shared
storage may be implemented with Fibre Channel, iSCSI, or NAS storage.
The datastore may be VMFS or NFS. You can also leverage a vSAN datas-
tore to meet the shared storage requirement for vMotion migrations be-
tween cluster members.

Note

Hot migrations that are cross-host and cross-datastore migra-

tions, which are often called vMotion migrations without
shared storage, do not required shared storage.

For vMotion migration, you must configure each host with a VMkernel
virtual network interface connected to a virtual switch with an uplink
that uses at least one physical network interface card (NIC). VMware rec-
ommends that the network connection be made to a secured network.
The vMotion network must provide at least 250 Mbps of dedicated band-
width per concurrent vMotion session. For long-distance migrations, the
 maximum supported network round-trip time for vMotion migrations is
150 milliseconds. For faster vMotion migrations, consider using 10 Gbps
NICs instead of 1 Gbps NICs.

To improve vMotion migration times even further, consider implement-

ing multi-NIC vMotion. With multi-NIC vMotion, multiple paths are used
simultaneously to carry the vMotion workload. To configure multi-NIC
vMotion, you can enable vMotion traffic for two VMkernel virtual net-
work adapters that are configured to use separate paths. For example,
you can apply the following steps to enable multi-NIC vMotion, as illus-
trated in Figure 5-5:

FIGURE 5-5 Multi-NIC vMotion

Step 1. On a virtual switch, attach two uplink adapters connected to the vMotion
network.

Step 2. Connect two VMkernel adapters enabled for vMotion.

Step 3. For the first VMkernel adapter, set the first uplink path to Active and the
second uplink path to Standby.

Step 4. For the second VMkernel adapter, set the first uplink path to Standby and
the second uplink path to Active.

For more vMotion performance improvements, you can use Network I/O
Control (NIOC) to guarantee network bandwidth to vMotion traffic. You
can also use jumbo frames. To avoid network saturation, you can use traf-
fic shaping to limit the average and peak bandwidth available to vMotion
traffic.

By default, you cannot use vMotion to migrate a virtual machine that is

attached to a standard switch with no physical uplinks. To change this be-
havior, you can set the
config.migrate.test.CompatibleNetworks.VMOnVirtualIntranet advanced
settings of vCenter Server to False.

Note

During a vMotion migration without shared storage, the vir-

tual disk data is transferred over the vMotion network.

vMotion Migration and Data Flow Details

During a vMotion migration, the state of the running virtual machines is

copied to the destination host over the designated vMotion network, the
virtual machine is stopped on the source ESXi host, and the VM is re-
sumed on the target ESXi host. The process involves the following phases:

Compatibility check: Intended to ensure that requirements are met

and that the destination host can run the virtual machine.
Pre-copy: Briefly stuns the source memory and starts memory track-
ers. Copies memory page from source to target. Tracks which source
pages are modified after the pre-copy so these pages (dirty pages) can
be re-sent later.
Iterations of Pre-copy: If dirty pages exist, repeats the pre-copy of just
the dirty pages and scans for new dirtied pages. Continue iteration un-
til no dirty pages exist or until vMotion determines that the final page
copy can be completed in less than 500 ms.
Switchover: Quiesces and suspends the virtual machine execution on
the source host, transfers checkpoint data, and starts the execution of
the virtual machine using the checkpoint data on the target host.
The stun time (the time at which the virtual machine is not running any-
where) is typically between 100 ms and 200 ms.

Encrypted vMotion

When migrating encrypted virtual machines, vSphere vMotion always

uses encryption. For non-encrypted virtual machines, you can select one
of the following encrypted vMotion options:

Disabled: Do not use encryption.

Opportunistic: Use encryption if the source and destination hosts sup-
port it.
Required: If the source or destination host does not support encrypted
vMotion, do not allow the migration.

Note

Only ESXi Versions 6.5 and later use encrypted vSphere vMo-
tion. To use vMotion to migrate encrypted virtual machines
across vCenter Server instances, you must use the vSphere
API.

Storage vMotion Details

This section provides details on the Storage vMotion feature in vSphere.

Storage vMotion Overview

Storage vMotion migration is a hot cross-datastore migration. Storage

vMotion enables you to migrate a virtual machine and its disk files from
one datastore to another while the virtual machine is running. Use cases
for Storage vMotion include preparing for datastore maintenance (such
as upgrading the underlying storage array), optimizing performance (re-
distribution of storage load), and transforming the virtual disk provision-
ing type. When you use Storage vMotion on a virtual machine, you can
migrate all the virtual machine files to a single location, migrate individ-
ual virtual disks, or separate virtual disks from other virtual machine
files.

Note

Migration with Storage vMotion changes virtual machine

files on the destination datastore to match the inventory
name of the virtual machine. The migration renames all vir-
tual disk, configuration, snapshot, and NVRAM files. If the
new names exceed the maximum filename length, the migra-
tion fails.

Storage vMotion Requirements and Limitations

The following are the major requirements and limitations for Storage
vMotion in vSphere 7.0:

Virtual disks in nonpersistent mode are not supported for Storage

vMotion. For virtual compatibility mode RDMs, you can migrate just
the mapping file or include the migration of the data to a virtual disk
file. For physical compatibility mode RDMs, you can only migrate the
mapping file.
Storage vMotion migration is not supported during VMware Tools
installation.
You cannot use Storage vMotion to migrate virtual disks larger than 2
TB from a VMFS Version 5 datastore to a VMFS Version 3 datastore.
The source host that is running must have a license that includes
Storage vMotion.
ESXi 4.0 and later hosts do not require vMotion configuration to per-
form Storage vMotion migrations.
The host on which the virtual machine is running must have access to
both the source and target datastores.

Storage vMotion Data Flow Details

 The following major steps are automatically performed by Storage vMo-
tion in vSphere 7.0:

Step 1. The virtual machine’s home directory is copied to the destination

datastore.

Step 2. A hidden (shadow) virtual machine starts using the copied files. The un-
derlying processes (worlds) are visible to the esxtop utility. The virtual
machine continues to run in preexisting worlds.

Step 3. An initial copy of the source virtual disk is made to the destination data-
store, and change block tracking (CBT) is leveraged to track blocks that
are changed after they are copied.

Step 4. Step 4 is repeated until the number of changed blocks is small enough to
support a fast switchover.

Step 5. The system invokes a fast suspend and resume operation that transfers
the running virtual machine to the idling hidden virtual machine. The
virtual machine now runs in the new worlds. The preexisting worlds that
were associated with the virtual machine are removed.

Virtual Machine Cloning

vSphere provides many cloning options, as described in this section.

Clones

When you clone a virtual machine, vCenter Server creates a virtual ma-
chine that is a copy of the original virtual machine. The virtual disk files,
configuration file, and other files are copied from the original virtual ma-
chine to the new virtual machine. The new virtual machine is commonly
referred to as a clone. The new virtual machine files are named and
stored based on parameters you provide during the deployment. You can
choose to make some configuration changes and customizations during
the cloning process. The contents of some of the files, such as the configu-
ration file, are modified. At the end of the operation, you can manage
both the original virtual machine and the new virtual machine as inven-
tory objects in vCenter Server.

Cold Clones

A cold clone occurs when the source virtual machine is powered down
prior to starting the clone operation. In this case, vCenter Server does not
have to worry about interrupting the execution of the source virtual
machine.

Hot Clones

A hot clone occurs when the source virtual machine is running during a
clone operation. In this case, the vCenter Server must avoid disrupting
the execution of the source virtual machine. To do so, it takes a virtual
machine snapshot prior to copying data and removes the snapshot at the
end of the operation.

Linked Clones

A linked clone is a virtual machine that is cloned in such a manner that it

shares its virtual disk files with the original virtual machine (parent). The
shared files are static. Much like a virtual machine that has a snapshot, a
linked clone writes its virtual disk changes to separate data files.
Compared to a full clone, a linked clone operation is faster and conserves
disk space. You cannot use the vSphere Client to directly create linked
clones. You can use PowerCLI (via the -LinkedClone parameter with the
New-VM command) or other VMware products to create linked clones.
For example, in VMware Horizon you can create desktop pools based on
linked clones, and in vCloud Director you can use fast provisioning.

Rapid Provisioning with Templates

As stated previously, templates are objects in the vSphere inventory that

are effectively non-executable virtual machines.
You can convert a virtual machine to a template and vice versa. But the
main use case for templates is for rapid deployment of new similar vir-
tual machines from a single template. In such a case, you are effectively
cloning the template again and again, allowing the template to remain
unchanged and ready for future use. To update a template, such as to in-
stall the most recent guest OS updates, you can temporarily convert the
template to a virtual machine, apply the updates, and convert back to a
template.

When you deploy a virtual machine from a template, vCenter Server cre-
ates a virtual machine that is a copy of the original template. The virtual
disk files, configuration file, and other files are copied from the template
to the new virtual machine. The new virtual machine files are named and
stored based on parameters you provide during the deployment. You can
choose to make some configuration changes and customizations during
the cloning process. The contents of some of the files, such as the configu-
ration file, are modified. At the end of the operation, you can manage
both the original template and the new virtual machine as inventory ob-
jects in vCenter Server.

Deploying a virtual machine from a template is a lot like cloning a virtual

machine. In either case, you create a new virtual machine by copying a
source object. For template deployments, the source object is a template.
For virtual machine cloning, the source object is a virtual machine.

Instant Clones

Starting with vSphere 6.7, you can use the instant clone technology to hot
clone a running virtual machine in a manner that is like a combination of
vMotion and linked clone technology. The result of an instant clone oper-
ation is a new virtual machine (destination virtual machine) that is iden-
tical to the source virtual machine. The processor state, virtual device
state, memory state, and disk state of the destination virtual machine
match those of the source virtual machine. To avoid network conflicts,
you can customize the MAC addresses of the virtual NICs, but the guest
customization feature is not supported for instant clones. You cannot use
the vSphere Client to perform an instant clone operation.

A common use case for instant clones is just-in-time deployment in a

VMware Horizon virtual desktop infrastructure (VDI). Instant clones en-
able you to perform large-scale deployments by creating virtual machines
from a controlled point in time. For example, VMware Horizon uses
Instant Clone to improve the provisioning process for virtual desktops.
Compared to View Composer, which uses linked clones, instant clones
eliminate some steps (such as reconfiguration and checkpoints) and re-
place other steps to greatly reduce the provisioning time. Other use cases
are large deployments of identical virtual servers in the cloud and situa-
tions where you want to reduce boot storms and provisioning times.

During an instant clone (vmFork) operation, the system quiesces and

stuns the source virtual machine, creates and transfers a checkpoint, cus-
tomizes the destination MAC address and UUID, and forks the memory
and disk. The destination virtual machine shares the parent virtual
machine’s disk and memory for reads. For writes, the destination ma-
chine uses copy on write (COW) to direct disk and memory changes to
delta files and private memory space.

The requirements for instant clones may depend on the software applica-
tions that use the API to perform the cloning operations. For example,
VMware Horizon 7.1 requires static port binding, ESXi 6.0 Update 1 or
later, and a distributed virtual switch.

Instant cloned virtual machines are fully independent vCenter Server in-
ventory objects. You can manage instant clone destination virtual ma-
chines as you would regular virtual machines, without any restrictions.

Exam Preparation Tasks

As mentioned in the section “How to Use This Book” in the Introduction,

you have some choices for exam preparation: the exercises here, Chapter
15, “Final Preparation,” and the exam simulation questions on the com-
panion website.

Review All Key Topics

Review the most important topics in this chapter, noted with the Key
Topics icon in the outer margin of the page. Table 5-5 lists these key topics
and the page number on which each is found.

Table 5-5 Key Topics for Chapter 5

Key Topic Description Page

Element Number

Procedure Host profile workflow 171

List Content library limitations 172

List Files in a virtual machine snapshot 175

List Use cases for snapshots 177

List Requirements for cross-vCenter Server 187

migrations

Section Virtual machine migration limitations 187

Section vMotion requirements 189

Section Instant clones 195

Complete Tables and Lists from Memory

Print a copy of Appendix B, “Memory Tables” (found on the companion
website), or at least the section for this chapter, and complete the tables
and lists from memory. Appendix C, “Memory Tables Answer Key” (also
on the companion website), includes completed tables and lists to check
your work.

Define Key Terms

Define the following key terms from this chapter and check your answers
in the glossary:

vSphere inventory

data center

cluster

resource pool

template

vApp

host profile

content library

virtual machine snapshot

VMware Tools

vMotion

Storage vMotion

Review Questions
1. Which of the following is not a valid use case for virtual machine
snapshots?

1. Rolling back guest OS changes

2. Recovering from the accidental deletion of a flat file
3. Troubleshooting
4. Linking a clone in a vRA blueprint

2. You are troubleshooting a virtual machine by using the vSphere Client.

Which of the following is not a valid debugging and statistics advanced
setting?

1. Record Trivial
2. Record Debugging
3. Run Normal
4. Record Statistics

3. You want to migrate a virtual machine with a 2.5 TB virtual disk. What is
the minimum ESXi version that supports this?

1. 6.0
2. 6.5
3. 6.7
4. 7.0

4. You want to hot migrate a virtual machine from one ESXi host and VMFS
datastore to another ESXi host and VMFS datastore. Which of the follow-
ing statements is true?

1. This operation is not supported in vSphere 7.0.

2. The virtual disk data is transferred over the management network.
3. The virtual disk data is transferred over the vMotion network.
4. You must perform the operation in two separate steps: vMotion and
Storage vMotion.

5. You are supporting thousands of virtual machines in a vSphere environ-

ment. Which of the following features is associated with vmFork?
1. Instant clone
2. Linked clone
3. Snapshot
4. Cross-vCenter vMotion

Support Sign Out

©2022 O'REILLY MEDIA, INC. TERMS OF SERVICE PRIVACY POLICY