Chapter 5

vCenter Server Features and Virtual Machines

This chapter covers the following topics:

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 headings 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 inventory pane?

A cluster
A host
A virtual machine
A data center
A datastore
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?

A library backed by vSAN
A local library
A published library
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?

Server01.vmdk
Server01-flat.vmdk
Server01.vmx
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?

Under the parent snapshot
Under the child snapshot
Under the latest snapshot
Under the associate delta file

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

SIO controller
SCSI controller
Parallel port
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?

General Options
Encryption Options
Snapshot Options
vApp Options

7. You want to perform a cross-vCenter Server migration in vSphere 7.0. Which of the following statements is true?

If separate SSO domains are used, you must use the APIs to perform the migration.
If separate SSO domains are used, you can use the vSphere Client to perform the migration.
If separate SSO domains are used, you cannot perform the migration.
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?

Nine simultaneous vMotion migrations
Nine simultaneous vMotion migrations without Shared Storage
One Storage vMotion operation and four vMotion operations
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?

Using NIOC to increase shares for vMotion traffic
Using traffic shaping to limit the bandwidth that is available to vMotion traffic
Using multiple-NIC vMotion
Using jumbo frames

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

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

Foundation Topics

vCenter Server and vSphere

Previous chapters provide details about the vSphere topology, storage infrastructure, 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 information 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, monitoring 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 deployed 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 infrastructure. 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 corresponding 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 identical datastore names within the same data center, but you can use identical 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 configuring 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 monitor 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 limits. Otherwise, you can create resource pools directly on specific ESXi hosts.

You can configure resource settings for resource pools, such as reservations, 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 reconnect 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 multiple virtual network adapters. Each virtual network adapter may be connected to a port group (on a standard virtual switch) or a distributed port group (on a vSphere distributed switch). All virtual machines that connect to the same port group belong to the same network in the virtual environment, 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 machine that can be used to create and provision new virtual machines. A template can have a guest operating system and application software installed. 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 packaging and managing applications. Typically, a vApp is a set of virtual machines that runs a single application and allows you to manage the application 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 management 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 configuration 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 authentication, the reference host must be configured to use a directory service.

In previous releases, vSphere requires that the reference host be available 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 automatically synchronize with the published library. For example, you can create a local content library using the main office vCenter Server, publish 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 subscribing library reflects the most recent changes, but it is not burdened with supplying the storage space for every published file. Instead, the administrator 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 subscribed. A local content library is the simplest form. You can allow, modify, 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 numbers 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 published 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 between 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 performance 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 machine 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 enabled on a vSphere cluster, vSphere with Tanzu creates a Kubernetes control 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 explicit 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-flat.vmdk	Virtual disk data file (commonly called a flat file)
vmname.nvram or nvram	Virtual machine BIOS or UEFI configuration 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 number 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 template, 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 hardware. 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 memory, 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 included 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 machine named server1 that has only one virtual disk and no previous snapshots, 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 original 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 created in a linear fashion, as shown in Figure 5-1. The vSphere Client represents 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 revert 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 another snapshot, you add branches to the snapshot tree, as shown in Figure 5-3.

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

In the vSphere Client, you can perform several snapshot operations, including taking a snapshot, reverting to a snapshot, and deleting a snapshot. When taking a snapshot, you can choose whether to snap the memory and whether to quiesce the guest OS. In cases where no snapshot exists 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 access. 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 vRealize Automation and Horizon, may leverage virtual machine snapshots 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 includes 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 snapshot 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 virtual 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 relationships 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 independent 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 snapshot 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 machine 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 available 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 machines as physical hardware devices do for traditional servers. Each virtual 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 capacity 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 configurable. 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 systems may not be able to make use of the added memory without restarting. The ESXi license and other factors for the host where the virtual machine 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 logical 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-proprietary 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-ROM drive	One by default. You can configure the virtual DVD/CD-ROM device to connect to client devices, host devices, or datastore ISO files. You can add and remove virtual DVD/CD-ROM devices.
Hard disk	A virtual disk is backed by a set of files, as discussed earlier in this chapter.
IDE 0, IDE 1	Two virtual Integrated Drive Electronics (IDE) interfaces are present by default.
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 adapter	You can configure the number of virtual network adapters (NICs) and the adapter type used by each virtual machine.
Parallel port	You can add, remove, and configure virtual parallel ports.
PCI controller	One PCI controller, which is located on the virtual motherboard, is presented to the virtual machine. It cannot be removed or modified.
PCI device	If you configured devices to be reserved for PCI passthrough on the host, you can add up to 16 PCI vSphere DirectPath devices to a virtual machine.
Pointing device	The virtual pointing device is mapped to the user’s pointing device when you connect to the virtual machine console.
Serial port	You can configure a virtual machine with up to 32 virtual serial ports. You can add, remove, or configure virtual serial ports.
SATA controller	Provides access to virtual disks and DVD/CD-ROM devices. The SATA virtual controller appears to the guest OS as an AHCI SATA controller.
SCSI controller	Provides access to virtual disks. 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 controller	Provides serial and parallel ports and floppy devices and performs system management activities. One SIO controller is available to the virtual machine, but it cannot be configured or removed.
USB controller	The virtual USB controller is the software virtualization of the USB host controller function in the virtual machine.
USB device	You can add multiple virtual USB devices to a virtual 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 controller	NVM Express (NVMe) is a logical device interface specification for accessing non-volatile storage media attached through a PCI Express (PCIe) bus in real and virtual hardware.
NVDIMM controller	Provides access to the non-volatile memory resources of the host.
NVDIMM device	You can add up to 64 virtual non-volatile dual in-line memory module (NVDIMM) devices to a virtual machine.
TPM device	You can add a virtual Trusted Platform Module (TPM) 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 provisioned, 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 during 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 services that can communicate with the VMkernel. This communication allows 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 virtual 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 performance 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 settings 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 Options	Settings include virtual machine name, configuration file location, and the working directory location.
Encryption Options	Settings allow you to enable or disable virtual machine encryption or vMotion encryption.
Power Management	Settings allow you to choose how to respond when the guest OS is placed on standby. The choices are to suspend the virtual machine or put the guest OS into standby mode.
VMware Tools	Settings allow you to choose how to respond to specific 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 Based Security (VBS)	For virtual machines running the modern Windows OS versions, you can enable VBS to add an extra level of protection.
Boot Options	Settings include firmware, boot delay, and failed boot recovery parameters.
Advanced Options	Settings include logging, debugging, swap file location, and configuration parameters.
Fibre Channel NPIV	Settings allow the virtual machine to use N_Port ID 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 directly 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 advanced 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 statistics to Run Normally, Record Debugging Information, Record Statistics, or Record Statistics and Debugging. For applications that are highly sensitive 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 settings, as illustrated in Figure 5-4.

Virtual Machine Migration

This section provides information such as concepts, prerequisites, and data flow details for each migration type. Chapter 14 provides information 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 copying virtual machines are also not forms of migration.

Each migration type involves a unique set of requirements, such as minimum 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 virtual machine are not interrupted.

Cross-Host Migrations

Moving a virtual machine, whether hot or cold, to a new host is considered 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, resource pool, or vApp as the destination.

The cross-host migration wizards include a Compatibility panel to identify any compatibility issues or warnings. If the panel displays the message “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 considered 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 instances 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 migration and provisioning operations that occur per host, network, and datastore. 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 resource. 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 consistent 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 enabled 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 vMotion migrations. Each vMotion migration has a resource cost of 1 against the shared datastore. Each Storage vMotion migration has a resource 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 operations, including new deployments, and cloning. Provisioning and vMotion 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 considered 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 migration 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 migration 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 vMotion 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 vMotion. 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 migration 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 includes 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 requirements. Each host must meet the licensing, shared storage, and networking requirements for vMotion.

For standard vMotion migration, you must configure the source and destination hosts with shared storage to enable the migrated virtual machines 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 datastore to meet the shared storage requirement for vMotion migrations between cluster members.

Note

Hot migrations that are cross-host and cross-datastore migrations, 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 recommends that the network connection be made to a secured network. The vMotion network must provide at least 250 Mbps of dedicated bandwidth 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 implementing 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 network adapters that are configured to use separate paths. For example, you can apply the following steps to enable multi-NIC vMotion, as illustrated in Figure 5-5:

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 traffic 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 behavior, 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 virtual 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 resumed 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 trackers. 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 until 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 anywhere) 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 support 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 vMotion. 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 (redistribution of storage load), and transforming the virtual disk provisioning type. When you use Storage vMotion on a virtual machine, you can migrate all the virtual machine files to a single location, migrate individual 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 virtual disk, configuration, snapshot, and NVRAM files. If the new names exceed the maximum filename length, the migration 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 perform 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 vMotion 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 underlying 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 machine that is a copy of the original virtual machine. The virtual disk files, configuration file, and other files are copied from the original virtual machine 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 configuration file, are modified. At the end of the operation, you can manage both the original virtual machine and the new virtual machine as inventory 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 virtual 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 install 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 creates 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 configuration file, are modified. At the end of the operation, you can manage both the original template and the new virtual machine as inventory objects 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 operation is a new virtual machine (destination virtual machine) that is identical 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 enable 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 replace other steps to greatly reduce the provisioning time. Other use cases are large deployments of identical virtual servers in the cloud and situations 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, customizes 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 machine 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 applications 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 inventory objects. You can manage instant clone destination virtual machines 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 companion 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 Element	Description	Page 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 migrations	187
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:

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?

Rolling back guest OS changes
Recovering from the accidental deletion of a flat file
Troubleshooting
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?

Record Trivial
Record Debugging
Run Normal
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?

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 following statements is true?

This operation is not supported in vSphere 7.0.
The virtual disk data is transferred over the management network.
The virtual disk data is transferred over the vMotion network.
You must perform the operation in two separate steps: vMotion and Storage vMotion.

5. You are supporting thousands of virtual machines in a vSphere environment. Which of the following features is associated with vmFork?

Instant clone
Linked clone
Snapshot
Cross-vCenter vMotion