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 VMware 2V0-21.20 exam objectives 1.2, 1.5, 2.3, 5.6, 7.1, 7.2, 7.3, 7.6, 7.9, 7.11.4

This chapter provides details on vCenter Server features that have not been covered in previous chapters. It details for virtual machines, such as file structure, migrations, and cloning. Chapters 13 and 14 provides details for 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. Regardless, 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.”

1. You just installed a new vCenter Server. Using the vSphere Client, what is the first object that you can create in the inventory pane? (pick two)

a. A cluster

b. A host

c. A virtual machine

d. A data center

e. A datastore

f. A folder

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

a. A library backed by vSAN

b. A local library

c. A published library

d. 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?

a. Server01.vmdk

b. Server01-flat.vmdk

c. Server01.vmx

d. Server01-data.vmdk

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

a. Under the parent snapshot.

b. Under the child snapshot

c. Under the latest snapshot.

d. 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?

a. SIO Controller

b. SCSI Controller

c. Parallel Port

d. 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?

a. General Options

b. Encryption Options

c. Snapshot Options

d. vApp Options

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

a. If separate SSO domains are used, you must use the APIs to perform the migration.

b. If separate SSO domains are used, you can use the vSphere Client to perform the migration

c. If separate SSO domains are used, you cannot perform the migration.

d. The vSphere and vCenter Server Enterprise licenses are required.

8. You want to perform multiple, simultaneous virtual machine migrations for a 4 node DRS cluster with a 10 GigE vMotion network and multiple datastores. Which of the following operations are allowed without any queuing?

a. 9 simultaneous vMotion migrations

b. 9 simultaneous vMotion without Shared Storage migrations.

c. One Storage vMotion and 4 vMotion operations

d. 4 simultaneous vMotion and 5 provisioning operations involving the same host.

9. You are optimizing your vSphere environment. Which of the following is not helpful for improving vMotion performance?

a. Use NIOC to increase shares for vMotion traffic

b. Use traffic shaping to limit the bandwidth that is available to vMotion traffic.

c. Use Multi NIC vMotion

d. Use jumbo frames

10. You want to use Instant Clones in vSphere. Which of the following statements are true?

a. You can use the Host Client to perform an instant clone.

b. You can use the vSphere Client to perform an instant clone.

c. A sample, major use case for Instant Clones are large scale deployments in a VMware Horizon VDI

d. vSphere 6.5 supports Instant Clones

Foundation Topics

vCenter Server and vSphere

Previous chapters provide detail for the vSphere topology, storage infrastructure, network infrastructure and vSphere clusters. This section provides details for other features, such as the vSphere inventory, host profiles, and the content library.

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 the 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 set permissions, monitor tasks, monitor events, and set alarms. You can organize many of these objects by placing them into folders, making them easier to manage.

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.

Data Centers

A data center is a container object in the vSphere inventory that is an aggregation of all the different types of objects used to work in virtual infrastructure. The first object that you must create in a vSphere inventory is a data center (except for a folder to contain data centers). You cannot add any ESXi hosts, virtual machines, or other objects 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 may wish 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 objects in the appropriate data center.

Within each data center, there are four separate hierarchies.

•   Virtual machines (and templates)

•   Hosts (and clusters)

•   Networks

•   Datastores

The data center the is the 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 in two different data centers. Virtual machines, templates, and clusters need not to have unique names within the data center but must have unique names within their folder.

Folders

Folders are container objects in the vSphere inventory 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.

The only setting that is available for you to set on a folder is its name. Additionally, you can assign permissions and 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 because of CPU compatibility errors. If you enable vSphere DRS on a cluster, you can allow automatic resource balancing 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 using the cluster’s available host resource capacity.

Cluster features are covered in detail in Chapter 4.

Resource Pools

Resource pools are container objects in the vSphere inventory 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 much like a folder 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 for strictly 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 detail on resource pools.

Hosts

Hosts are objects in the vSphere inventory that represent your actual 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 that 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 will be removed.

If the SSL certificate used by vCenter Server is replaced or changed, the vCenter Server will be unable to decrypt the host passwords. You will need to reconnect and resupply the host credentials.

To remove a host from the vSphere inventory, you must first enter maintenance mode.

Networks

Networks are objects in the vSphere inventory 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 provides details on networks.

Datastores

Datastores are objects in the vSphere inventory 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 data stores can be backed by NAS. vSAN datastores can be built in VSAN clusters.

Chapter 2 provides details on datastores.

Virtual Machines

Virtual machines are represented in the vSphere inventory in a manner that reflects the current inventory view. For example, in the Hosts and Clusters view, each virtual machine is descendent of the ESXi host on which it runs. In the Networks view, each virtual machine is descendent of the network to which it connects.

Templates

Templates are objects in the vSphere inventory that effectively are 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. Templates can have a guest operating system and application software installed. They are often customized during deployment to ensure that each new virtual machine has a unique name and network settings.

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 this 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 template.

For more details on templates see the Virtual Machine Cloning section 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 graceful 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. It is especially helpful in environments administrators manage multiple hosts and clusters with vCenter Server. The following list 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 configure 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 the 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. Set up and configure a reference host.

1. Create a host profile from the reference host.

2. Attach hosts or clusters to the host profile.

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

4. If the hosts are not fully compliant, then you apply (remediate) the hosts with the host profile.

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 Library

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. The content library, which was introduced in vSphere 6.0, addresses 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 this 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 only download metadata whenever it receives notification of a change. In this 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 actual 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. It allows the administrator to allow, modify and delete content. 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 upon 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, 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 the libraries synchronized. Version numbers are assigned to each library 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 and published library

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

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

3. Using vCSP, the library service determines what data has changed and sends a request to the transfer serviced to copy the required files.

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

Beginning with vSphere 6.5, you can mount an ISO directly from the Content Library, apply a guest OS customization specification during VM deployment, and update existing templates. The Content Library performance is improved. The new 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 / restore.

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. So, templates in the content library can either be of 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 are 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 at a vCenter Server level cannot see the libraries unless they have a Read-Only role as a global permission.

vSphere with Kubernetes

By using vSphere with Kubernetes, 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 Kubernetes 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 Kubernetes, you must use the VMware vSphere 7 Enterprise Plus with Add-on for Kubernetes license 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.

Additional files may 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 creating 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 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.

displayName = “server1”
guestOS = “centos-64”
nvram = “server1.nvram”
scsi0:0.fileName = “server1.vmdk”

If that virtual machine is sized with two virtual CPUs and 1024 GB memory, then 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 its number of cylinders, heads, and sectors, as shown in the following sample content.

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 resulting files may be created.

•   server1-000001-sesparse.vmdk: A delta data disk that store 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

Snapshots capture 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, then 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 create another snapshot, you add branches to the snapshot tree, as shown is 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.

Use Cases

The following list contains 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 their experiments, 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 will delete the snapshot.

•   Troubleshooting and triage: You can take a snapshot of a troubled virtual machine to allow you an option 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 where 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. State of each virtual disks.

•   (Optional) Memory state. The contents of the virtual machine's memory

•   Power state. The virtual machine can be 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.

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 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) the virtual memory are 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. Its name contains the work flat. Only the names of the metadata files appear in the vSphere Client Datastore Browser. In normal circumstances, the virtual machines 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 the virtual machine 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 snapshots 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 corrupt, 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

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 datacenter level you can set the Default VM Compatibility setting. See Chapter 14 for more 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 virtual machine memory to its virtual machines 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 to allow you to add memory or CPU resources to a running virtual. 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.

Virtual Machine –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 in the Virtual Disk Type section 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 will not be available. VMware Tools enhances the guest OS performance by enabling the latest drivers for virtual devices, enabling memory functions (like ballooning), and more. It includes drivers, such as SVGA, Paravirtual SCSI, VMXNet NIC, mouse, audio, guest introspection, memory control, and more. Prior to upgrading the hardware for a virtual machine, you should upgrade VMware Tools.

VMware Tools includes the VMware user process named vmtoolsd that enables copy and paste, 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 your VM. With VMware Tools, you have more control over the virtual machine interface.

Virtual Machine Options

When you 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, datacenters, clusters, or resource pools on which the virtual machine resides. Table 5-4 describes the available virtual machine options.

Virtual Machine Advanced Settings

As mentioned in the previous table, you can use the vSphere Client to edit the Advanced Settings for a virtual machine in 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.

In the Advanced Settings, you can select Configuration Parameters, where you can directly manipulate the virtual machine low level settings, as illustrated in Figure 5.4.

Virtual Machine Migration

This chapter provides information such as concepts, prerequisites, and data flow details for each migration type. Chapter 14 provides information for performing the migrations.

Virtual Machine Migration

VM Migration Overview

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. For another example, if you want to perform maintenance (such as an upgrade), you could first 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 inventory folder or resource pools in the same data center is not considered a migration. Cloning and copying a virtual machine are also not forms of migration.

Each migration type involves a unique set of requirements, such as minimum privileges required to perform the operation.

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, then you can proceed with no concern. If the panel display 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 a 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 will use the storage policy and datastore 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.

•   Both 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 must be in the same vCenter Single Sign-On domain.

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, where each migration and provisioning operation is assigned a cost per resource. Any operation whose cost causes a resource to exceed its limit is queued until other operations complete.

Limits depend on the resource type, ESXi version, migration type, and other factors, like network type. ESXi versions 5.0 to 7.0 have consistent limits.

•   Network Limits: Network limits apply only to vMotion migrations. Each vMotion has a network resource cost of 1. The Network Limit is dependent on the network bandwidth for the VMkernel adapter enabled for vMotion. 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 cross host and cross data store (vMotion without shared storage) is considered to be a combination of vMotion and Storage vMotion and applies the associated network, host, and datastore costs. vMotion without shared storage is equivalent to a Storage vMotion with a network cost of 1.

Consider the following examples, for a 4 node DRS cluster with a 10 GigE vMotion network.

•   If you perform 9 simultaneous vMotion migrations, the 9^th migration is queued due to the network limit, even if different hosts are involved.

•   If you perform 9 simultaneous hot cross host and cross data store migrations involving the same datastore, the 9^th 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 4 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 vMotion. A hot migration across hosts and datastores is often called a vMotion without shared storage. A hot cross vCenter Server migration is often called a cross vCenter Server vMotion Although the term vMotion may be used to describe any hot cross host migration, this section provides details on just the traditional vMotion, where shard 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 Enhanced vMotion Compatibility (EVC) section 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 be meet the licensing, shared storage, and networking requirements for vMotion.

For standard vMotion, 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.

For vMotion, 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 the network connection is 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.

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

2. Connect two VMkernel adapters enabled for vMotion

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

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 that is 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.

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 it is resumed on the target ESXi host. The process involves the following steps.

•   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, repeat the pre-copy of just the dirty pages, while scanning 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.

•   isabled: 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, then do allow the migration.

Storage vMotion Details

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

Storage vMotion Overview

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

Storage vMotion Requirements and Limitations

•   Virtual disks in non-persistent 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 VMFS5 datastore to a VMFS3 datastore.

•   The source host 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 virtual machine home directory is copied to the destination datastore.

•   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 pre-existing worlds.

•   An initial copy of the source virtual disk is made to the destination datastore, while leveraging change block tracking (CBT) to track blocks that are changed after they are copied.

•   The previous step is repeated until the amount of changed blocks is small enough to support a fast switch over.

•   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 pre-existing worlds that were associated with the virtual machine are removed.

Virtual Machine Cloning

In vSphere, you have many cloning options as described in this section.

Clone

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 content 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 as well as the new virtual machine as inventory objects in vCenter Server.

Cold clone

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

Hot Clone

A hot clone occurs if when the source virtual machine is running during a clone operation. In this case, the vCenter Server must act not to disrupt 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 Clone

A linked clone is a virtual machine that was cloned in 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. In comparison to full clones, the linked clone operation is faster and conserves disk space. You cannot use the vSphere Client to directly create linked clones. You can use PowerCLI (using the -LinkedClone parameter in 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.

Template

Templates are objects in the vSphere inventory that effectively are 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. Templates typically have a guest operating system and application software installed. They are often customized during deployment to ensure that each new virtual machine has a unique name and network settings.

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 this 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 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 content 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 as well as the new virtual machine as inventory objects in vCenter Server.

Deploying a virtual machine from a template is much like cloning a virtual machine. In either case, a new virtual machine is created 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 Clone

Starting with vSphere 6.7, you can use the Instant Clone technology to hot clone a running virtual machine using technology that is much 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 matches the source virtual machine. To avoid network conflicts, you can customize the virtual NICs’ MAC addresses, but the guest customization feature is not supported for instant clones. You cannot use the vSphere Client to perform an instant clone operation.

The main use case for instant clone is just in time deployment in 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. In comparison to View Composer, which uses Linked clones, Instant Clone eliminates some steps (such as reconfigure and checkpoints) and replaces 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 U1 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 like regular virtual machines without any restrictions.

Exam Preparation Tasks

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 a reference of these key topics and the page numbers on which each is found.

Define Key Terms

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

Review Questions

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

a. Rollback guest OS changes.

b. Recover from the accidental deletion of a flat file.

c. Troubleshooting

d. Linked clone in a vRA blueprint

2. You are troubleshooting a virtual machine using the vSphere Client. Which if the following is not a valid debugging and statistics Advanced setting?

a. Record Trivial

b. Record Debugging

c. Run Normal

d. 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?

a. 6.0

b. 6.5

c. 6.7

d. 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 following statements are true?

a. This operation is not supported in vSphere 7.0

b. The virtual disk data is transferred over the management network.

c. The virtual disk data is transferred over the vMotion network.

d. 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 are associated with vmFork?

a. Instant Clone

b. Linked Clone

c. Snapshot

d. Cross-vCenter vMotion