Virtual Machine Management

Creating Templates and Clones

 Using a Template
• A template is a master copy of a virtual machine. It is used to create and provision
new virtual machines.
 Creating a Template
• Clone the virtual machine
to a template:
o The virtual machine can be powered
on or powered off.
• Convert the virtual
machine to a template:
o The virtual machine must be
powered off.
• Clone a template:
o Used to create a new template based
on one that existed previously.
Deploying a Virtual Machine from a Template
• To deploy a virtual machine, you must provide such information as the virtual
machine name, inventory location, host, datastore, and guest operating system
customization data.
 Updating a Template
• Update a template to
include new patches, make
system changes, and install
new applications:
o Convert the template to a virtual
machine.
o Place the virtual machine on an
isolated network to prevent user
access.
o Make appropriate changes to the
virtual machine.
o Convert the virtual machine to a
template.
 Cloning a Virtual Machine
• Cloning a virtual
machine creates a
virtual machine that is
an exact copy of the
original:
o Cloning is an alternative to
deploying a virtual machine.
o The virtual machine being
cloned can be powered on or
powered off.
 Customizing the Guest Operating System
• Use the Guest Operating System Customization wizard to make virtual machines
created from the same template or clone unique.
Customizing a guest operating system enables you to change:
o Computer name
o Network settings
o License settings
o Windows Security Identifier
• During cloning or deploying virtual machines from a template:
o You can create a specification to prepare the guest operating systems of virtual machines.
o Specifications can be stored in the database.
o You can edit specifications in the Customization Specifications Manager.
o Windows and Linux operating systems are supported.
Migrating Virtual Machines
 Migrating Virtual Machines
• Migration means moving a virtual machine from one host, datastore, or vCenter
Server system to another host, datastore, or vCenter Server system.
• Types of migrations:
o Cold: Migrate a virtual machine that is powered off.
o Suspended: Migrate a virtual machine that is suspended.
o vSphere vMotion: Migrate a virtual machine that is powered on.
o vSphere Storage vMotion: Migrate a virtual machine’s files, while the virtual machine is powered on, to another datastore.
• Concurrent migrations are possible:
o A maximum of 128 concurrent vSphere vMotion accesses to a single VMware vSphere® VMFS datastore.
o A maximum of 8 concurrent cloning, deployment, or vSphere Storage vMotion accesses to a single VMFS datastore.
 Comparison of Migration Types
Virtual Change Across Shared
Migration CPU
Machine Host or vCenter Storage
Type Compatibility
Power State Datastore? Servers? Required?

Host or
Different CPU
Cold Off datastore Yes No
families allowed
or both

Host or Must meet CPU

Suspended Suspended datastore Yes No compatibility
or both requirements

Must meet CPU

vSphere
On Host Yes Yes compatibility
vMotion
requirements

vSphere
Storage On Datastore Yes No N/A
vMotion

Cross-host Must meet CPU

vSphere On Both Yes No compatibility
vMotion requirements
 How vSphere vMotion Migration Works
• In the diagram, the source host is ESXi01 and the target host is ESXi02. The source
host and the target host have access to the shared datastore holding the virtual
machine’s files.

VM A VM A

Memory ESXi-01 ESXi-02

Bitmap

vSphere
Memory
vMotion
Network
Virtual Machine
Port Group
 vSphere vMotion Migration Requirements

• A virtual machine must meet the following requirements:

o It must not have a connection to an internal standard switch: virtual switch with zero uplink adapters.
o It must not have a connection to a virtual device, such as a CD/DVD or floppy drive, with a local image mounted.
o It must not have CPU affinity configured.
o If the virtual machine’s swap file is not accessible to the destination host, vSphere vMotion must be able to create a swap
file accessible to the destination host before migration can begin.
o If a virtual machine uses an RDM, the RDM and the physical disk to which it maps must be accessible by the destination
host.
Host Requirements for vSphere vMotion Migration

• Source and destination hosts must have these characteristics:

o Accessibility to all storage (Fibre Channel, iSCSI, or NAS) used by the virtual machine:
• 128 concurrent vSphere vMotion migrations per VMFS datastore
o At least a 1 Gigabit Ethernet (1GigE) network:
• Four concurrent vSphere vMotion migrations on a 1 Gbps network
• Eight concurrent vSphere vMotion migrations on a 10 Gbps network
o Compatible CPUs:
• CPU feature sets of both the source and destination host must be compatible.
• Some features can be hidden by using Enhanced vMotion Compatibility (EVC) or compatibility masks.
 Other Cluster Settings: EVC for vSphere DRS
• Enhanced vMotion Compatibility is a cluster feature that prevents vSphere vMotion
migrations from failing because of incompatible CPUs.
 CPU Baselines for an EVC Cluster
• EVC works at the cluster level, using CPU baselines to configure all processors
included in the cluster enabled for EVC.

A baseline is a set of CPU

features supported by
every host in the cluster.
CPU Baseline Feature Set

CPUI CPUI CPUI CPUI

D D D D

X… X… X… K…
Cluster Enabled for EVC
 EVC Cluster Requirements

• All hosts in the cluster must meet the following requirements:

o Use CPUs from a single vendor, either Intel or AMD:
• Use Intel CPUs with Core 2 micro architecture and newer.
• Use AMD first-generation Opteron CPUs and newer.
o Be enabled for hardware virtualization: AMD-V or Intel VT
o Be enabled for execution-disable technology: AMD No eXecute (NX) or Intel eXecute Disable (XD)
o Be configured for vSphere vMotion migration

• Applications in virtual machines must be CPU ID compatible.

 vSphere Storage vMotion in Action

• vSphere Storage vMotion

Read/write
uses an I/O mirroring I/O to virtual
architecture to copy disk disk.
VM VM
blocks between source Process Process

and destination: VMkernel

Mirror Driver
o Initiate storage migration.
o Use the VMkernel data mover or
Data Mover
VMware vSphere® Storage APIs -
Array Integration to copy data.
o Start a new virtual machine
process.
o Mirror I/O calls to file blocks that
are already copied to virtual disk Storage Array
on the destination datastore.
o Cut over to the destination virtual
machine process to begin
accessing the virtual disk copy. VAA
Source Datastore I Destination Datastore
vSphere Storage vMotion Guidelines and Limitations
• Guidelines:
o Plan the migration and coordinate with administrators.
o Perform migrations during off-peak hours.
o Ensure that the host has access to source datastores and target datastores.

• Limitations:
o Virtual machine disks must be in persistent mode or be RDMs.
 Cross-Host vSphere vMotion
• Cross-host vSphere vMotion migration enables a virtual machine to change its
datastore and host simultaneously, even if the two hosts do not have shared storage.
o This technique combines vSphere vMotion migration and vSphere Storage vMotion migration into a single operation
o You can migrate between hosts and clusters without shared storage.

Layer 2 Network

ESXi ESXi

vCenter
Server
 Cross-Host vSphere vMotion Migration
Considerations
In vSphere 6, multiple changes can occur simultaneously with cross-host vSphere vMotion migrations.
 Migration Between vCenter Server Instances
• In vSphere 6, vSphere vMotion can migrate virtual machines between linked vCenter
Server instances. This type of migration requires:
o ESXi hosts and vCenter Server systems must be upgraded to vSphere 6.
o vCenter Server instances must be in Enhanced Linked Mode.
o Hosts must be time-synchronized.

vSphere vMotion Network

Network A Network B

ESXi
ESXi

Enhanced Linked
Mode
vCenter vCenter
Server A Server B
 Long-Distance vSphere vMotion Migration

• Long-distance vSphere vMotion migrations span larger networks with higher latency.
• Use cases for long-distance
vSphere vMotion migration:
o Permanent migrations
o Disaster avoidance
o VMware vCenter™ Site
Recovery Manager™ and
disaster avoidance testing
o Multisite load balancing
o Follow-the-Sun scenario support
 Networking Requirements for Long-Distance
vSphere vMotion Migration
• vSphere vMotion migrations between vCenter Server instances must connect over
layer 3 connections:
o Virtual machine network:
• L2 connection
• Same virtual machine IP address available at destination
o vSphere vMotion network:
• L3 connection
• Secure (dedicated or encrypted)
• 250 Mbps per vSphere vMotion operation
Network Checks for Migrations Between vCenter
Server Instances
• vCenter Server performs several network compatibility checks to prevent the
following configuration problems:
o MAC address compatibility on the destination host
o vSphere vMotion migration from a distributed switch to a standard switch
o vSphere vMotion migration between distributed switches of different versions
o vSphere vMotion migration to an internal network, for example, a network without a physical NIC
Creating Virtual Machine Snapshots
 Virtual Machine Snapshots
• Snapshots enable you to preserve the state of the virtual machine so that you can
repeatedly return to the same state.
 Virtual Machine Snapshot Files

A snapshot consists of a set of files: the memory state file (.vmsn), the description file
(-00000#.vmdk), and the delta file (-00000#-delta.vmdk).
The snapshot list file (.vmsd) keeps track of the virtual machine’s snapshots.
 Taking a Snapshot
• You can take a snapshot while a virtual machine is powered on, powered off, or
suspended.
• A snapshot captures the state of the virtual machine: memory state, settings state, and
disk state.
• Snapshots are not backups.

committed to disk
transactions
Pending
.vmdk
 Managing Snapshots
• The Snapshot Manager
enables you to review all
snapshots for the active
virtual machine and act on
them directly.
• Actions you can perform:
o Revert to a snapshot.
o Delete one or all snapshots.
 Deleting a Virtual Machine Snapshot
• If you delete a snapshot one or more levels above You Are Here, the snapshot state is
deleted. The snap01 data is committed into the previous state (base disk) and the
foundation for snap02 is retained.

base disk (5GB) +

base disk (5GB)
snap01 data

snap01 delta (1GB)

snap02 delta (2GB)

You are here.

 Deleting a Virtual Machine Snapshot (2)
• If you delete the current snapshot, the changes are committed to its parent. The
snap02 data is committed into snap01 data, and the snap02 -delta.vmdk file is
deleted.

base disk (5GB)

snap01 delta (1GB) +

snap01 delta (1GB)
snap02 delta (2GB)

snap02 delta (2GB)

You are here.

 Deleting a Virtual Machine Snapshot (3)
• If you delete a snapshot one or more levels below You Are Here, subsequent
snapshots are deleted and you can no longer return to those states. The snap02 data is
deleted.

base disk (5GB)

snap01 delta (1GB)

You are here.

snap02 delta (2GB)

 Deleting All Virtual Machine Snapshots
• The delete-all-snapshots mechanism uses storage space efficiently. The size of the
base disk does not increase. Just like a single snapshot deletion, changed blocks in
the snapshot overwrite their counterparts in the base disk.

base disk (5GB) +

base disk (5GB)
snap01/02 data

snap01You are(1GB)
delta here.

snap02 delta (2GB)

You are here.

 About Snapshot Consolidation

• Snapshot consolidation is a method to commit a chain of snapshots to the base disks

when the Snapshot Manager shows that no snapshots exist, but the delta files still
remain on the datastore.
• Snapshot consolidation is intended to resolve problems that might occur with
snapshots:
o The snapshot descriptor file is committed correctly, but the Snapshot Manager incorrectly shows that all the snapshots are
deleted.
o The snapshot files (-delta.vmdk)are still part of the virtual machine.
o Snapshot files continue to expand until the virtual machine runs out of datastore space.
 Discovering When to Consolidate

•The Snapshot Manager displays no snapshots. However, a warning on the Monitor >
Issues tab of the virtual machine notifies the user that a consolidation is required.
 Performing Snapshot Consolidation

• After the snapshot consolidation warning appears, the user can use the vSphere Web
Client to consolidate the snapshots:
o Select Snapshots > Consolidate to reconcile snapshots.
o All snapshot delta disks are committed to the base disks.