The document outlines the management of virtual machines (VMs) using VMware technologies, focusing on VM migration techniques such as vSphere vMotion and vSphere Storage vMotion. It emphasizes the importance of skills in migrating VMs, taking snapshots, and managing resources, while detailing the requirements and processes for successful VM migrations. Additionally, it covers Enhanced vMotion Compatibility for ensuring CPU compatibility during migrations and provides guidelines for performing these operations effectively.
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0 ratings0% found this document useful (0 votes)
63 views98 pages
Module 8. Managing Virtual Machines
The document outlines the management of virtual machines (VMs) using VMware technologies, focusing on VM migration techniques such as vSphere vMotion and vSphere Storage vMotion. It emphasizes the importance of skills in migrating VMs, taking snapshots, and managing resources, while detailing the requirements and processes for successful VM migrations. Additionally, it covers Enhanced vMotion Compatibility for ensuring CPU compatibility during migrations and provides guidelines for performing these operations effectively.
Learner Objectives • Recognize the types of VM migrations that you can perform within a vCenter instance • Explain how vSphere vMotion works • Verify vSphere vMotion requirements • Migrate virtual machines using vSphere vMotion
About VM Migration Migration means moving a VM from one host, datastore, or vCenter instance to another host, datastore, or vCenter instance. Migration can be cold or hot: • A cold migration moves a powered-off or suspended VM. • A hot migration moves a powered-on VM. vCenter performs compatibility checks before migrating suspended or powered-on VMs to ensure that the VM is compatible with the target host.
Migration Types The type of migration that you perform depends on the power state of the VM that you select in the inventory and the migration type that you select in the Migrate wizard.
About vSphere vMotion A vSphere vMotion migration moves a powered-on VM from one host (compute resource) to another. vSphere vMotion provides the following capabilities: • Improvement in overall hardware use • Continuous VM operation while accommodating scheduled ESXi host downtime • vSphere DRS to balance VMs across hosts
vSphere vMotion Migration Workflow The source host (ESXi01) and the destination host (ESXi02) can access the shared datastore that holds the VM’s files.
VM Requirements for vSphere vMotion Migration For migration with vSphere vMotion, a VM must meet these requirements: • If it uses an RDM disk, the RDM file and the LUN to which it maps must be accessible by the destination host. • It must not have a connection to a virtual device, such as a CD/DVD or floppy drive, with a host-local image mounted. You can use vSphere vMotion to migrate a VM with a device that is attached through a remote console (such as a physical device or disk image).
Host Requirements for vSphere vMotion Migration (1) Source and destination hosts must have the following characteristics: • Accessibility to all the VM’s storage: – 128 concurrent migrations are possible per datastore. – If the swap file location on the destination host differs from the swap file location on the source host, the swap file is copied to the new location. • VMkernel port with vSphere vMotion activated • Matching management network IP address families (IPv4 or IPv6) between the source and destination hosts
Host Requirements for vSphere vMotion Migration (2) • The number of concurrent, active vSphere vMotion tasks is a function of the vSphere vMotion network speed: – Each active vSphere vMotion process requires a minimum throughput of 250 Mbit/second (Mbps) on the vSphere vMotion network. – Concurrent migrations are limited to four on a 1 Gbps network. – Concurrent migrations are limited to eight on a 10 Gbps (or faster) network. – For better performance, dedicate at least two VMkernel port groups to the vSphere vMotion traffic. • Compatible CPUs: – The CPU feature sets of both the source host and the destination host must be compatible. – Some features can be hidden by using Enhanced vMotion Compatibility or compatibility masks.
Checking Migration Errors When you select the host or cluster, validation checks are performed to verify that most vSphere vMotion requirements are met.
Migrating Encrypted VMs When powered-on, encrypted VMs are migrated, encrypted vSphere vMotion is automatically used.
For VMs that are not encrypted, select one of
the following encrypted vSphere vMotion menu items: • Disabled • Opportunistic (default): Encrypted vSphere vMotion is used if the source and destination hosts support it • Required: If the source or destination host does not support encrypted vSphere vMotion, the migration fails
Review of Learner Objectives • Recognize the types of VM migrations that you can perform within a vCenter instance • Explain how vSphere vMotion works • Verify vSphere vMotion requirements • Migrate virtual machines using vSphere vMotion
Learner Objectives • Describe the role of Enhanced vMotion Compatibility in migrations • Configure EVC CPU mode on a vSphere cluster • Explain how per-VM EVC CPU mode works with vSphere vMotion • Configure EVC Graphics mode on a vSphere cluster or a VM
EVC Cluster Requirements for CPU Mode All hosts in the cluster must meet several CPU-based requirements: • Use CPUs from a single vendor, either Intel or AMD. • Be activated for hardware virtualization: AMD-V or Intel VT. • Be activated for execution-disable technology: AMD No eXecute (NX) or Intel eXecute Disable (XD). • Be configured for vSphere vMotion migration. Applications in VMs must be CPU ID compatible.
Configuring EVC CPU Mode on an Existing Cluster You configure EVC CPU mode on an existing cluster to ensure vSphere vMotion CPU compatibility between the hosts in the cluster.
Changing the EVC Mode for a Cluster Several EVC mode approaches are available to ensure CPU compatibility: • If all the hosts in a cluster are compatible with a newer EVC mode, you can change the EVC mode of an existing Enhanced vMotion Compatibility cluster. • You can configure EVC mode for a cluster that does not have EVC mode configured. You can raise or lower the EVC mode, but the VMs must be in the correct power state to do so.
EVC Mode VM Power Action
Raise the EVC mode to a CPU • Running VMs can remain powered on. baseline with more features. • New EVC mode features are not available to the VMs until they are powered off and powered back on again (Suspending and resuming the VM is not sufficient.) Lower the EVC mode to a • Power off VMs if they are powered on and running CPU baseline with fewer at a higher EVC mode than the one you intend to features. configure.
Virtual Machine EVC CPU Mode EVC mode can be applied to some or all VMs in a cluster: • At the VM level, EVC mode facilitates the migration of VMs beyond the cluster and across vCenter systems and data centers. • You can apply more granular definitions of Enhanced vMotion Compatibility for specific VMs. • VM EVC mode is independent of the EVC mode defined at the cluster level.
EVC Cluster Requirements for Graphics Mode EVC for vSGA GPUs is configured at the ESXi cluster level: • All ESXi hosts must satisfy GPU requirements of the defined baseline. • Additional hosts cannot join the cluster if they cannot satisfy the baseline requirements. • A mixed cluster of ESXi 6.7 and ESXi 7.0 hosts is supported when using Enhanced vMotion Compatibility at a cluster level. EVC for vSGA GPUs is configured at a virtual machine level: • VM compatibility for ESXi 7.0 Update 1 is required (virtual machine hardware version 18). • VMs using GPU Enhanced vMotion Compatibility at a VM level must run on ESXi 7.0 Update 1.
Review of Learner Objectives • Describe the role of Enhanced vMotion Compatibility in migrations • Configure EVC CPU mode on a vSphere cluster • Explain how per-VM EVC CPU mode works with vSphere vMotion • Configure EVC Graphics mode on a vSphere cluster or a VM
Learner Objectives • Explain how vSphere Storage vMotion works • Recognize guidelines for using vSphere Storage vMotion • Migrate virtual machines using vSphere Storage vMotion • Migrate both the compute resource and storage of a virtual machine
About vSphere Storage vMotion With vSphere Storage vMotion, you can migrate a powered-on VM from one datastore to another datastore of any type.
Using vSphere Storage vMotion, you can
perform the following tasks: • Move VMs off arrays for maintenance or to upgrade. • Change the disk provisioning type. • Change VM files on the destination datastore to match the inventory name of the VM. • Migrate between datastores to balance traffic across storage paths and reduce latencies. • Redistribute VMs or virtual disks to different storage volumes to balance capacity or improve performance.
Identifying Storage Arrays That Support vSphere Storage APIs – Array Integration vSphere Storage vMotion offloads its operations to the storage array if: • The array supports VMware vSphere Storage APIs – Array Integration, also called hardware acceleration. • Both datastores are located within the same storage array. Use the vSphere Client to determine whether your storage array supports hardware acceleration.
vSphere Storage vMotion Guidelines and Limitations Guidelines: • Plan the migration and coordinate with administrators • Perform migrations during off-peak hours Limitation: • Independent virtual machine disks must be in persistent mode
Changing Both Compute Resource and Storage During Migration When you change both compute resource and storage during migration, a VM changes its host and datastore and optionally its network, either within or across vCenter instances. • This technique combines vSphere vMotion and vSphere Storage vMotion into a single operation. • You can migrate VMs across clusters, data centers, and vCenter instances.
Use Cases for Changing Both Compute Resource and Storage Compute resource and storage migration is useful in the following cases: • Migrating a VM located on a host's local storage to a host that uses shared storage • Migrating a VM to a new cluster, when the target cluster does not have access to the source cluster's storage • Migrating a VM to a different data center, whose storage is not shared with the source data center • Migrating a VM to a different vCenter instance, whose storage is not shared with the source vCenter instance
Lab 2: vSphere Storage vMotion Migrations Use vSphere Storage vMotion to migrate virtual machines: 1. Migrate Virtual Machine Files from One Datastore to Another 2. Migrate Both the Compute Resource and Storage of a Virtual Machine
Review of Learner Objectives • Explain how vSphere Storage vMotion works • Recognize guidelines for using vSphere Storage vMotion • Migrate virtual machines using vSphere Storage vMotion • Migrate both the compute resource and storage of a virtual machine
About Cross vCenter Migrations With vSphere vMotion, you can migrate VMs between vCenter instances, whether or not they are in the same Enhanced Linked Mode group. Cross vCenter migrations are helpful in the following cases: • Balancing workloads across clusters and vCenter instances that are in the same site or in another geographical area. • Moving VMs between environments that have different purposes, for example, from a development environment to production environment. • Moving VMs to meet different service level agreements (SLAs) for storage space, performance, and so on. • Moving VMs from an on-premises vSphere data center to a data center in the public cloud, such as VMware Cloud on AWS.
Cross vCenter Migration Requirements Cross vCenter migrations have the following requirements: • Hosts must be time-synchronized. • Both vCenter instances can be in the same or different vCenter Single Sign-On domain.
Performing a Cross vCenter vMotion in Different SSO Domain (1) From the Migrate wizard, select Cross vCenter Server export as the migration type. Optionally, you can clone the VM rather than migrate it.
Performing a Cross vCenter vMotion in Different SSO Domain (2) Then, you specify the FQDN or IP address of the target vCenter instance and the vCenter credentials.
Network Checks for Cross vCenter Migrations vCenter performs several network compatibility checks to prevent the following configuration problems: • MAC address incompatibility on the destination host • vSphere vMotion migration from a distributed switch to a standard switch • vSphere vMotion migration between distributed switches of different versions
VMkernel Networking Layer and TCP/IP Stacks The VMkernel networking layer provides connectivity to hosts and handles the standard system traffic of vSphere vMotion, IP storage, vSphere Fault Tolerance, vSAN, and others. TCP/IP stacks at the VMkernel level that are configured by default: • Default TCP/IP stack • vSphere vMotion TCP/IP stack • Provisioning TCP/IP stack You can also create a custom TCP/IP stack.
About Long-Distance vSphere vMotion Migration Long-distance vSphere vMotion migration is an extension of cross vCenter migration. vCenter instances are spread across large geographic distances and where the latency across sites is high. Use cases for long-distance vSphere vMotion migration: • Permanent migrations • Disaster avoidance • Site Recovery Manager and disaster avoidance testing • Multisite load balancing • Follow-the-sun scenario support
Networking Prerequisites for Long-Distance vSphere vMotion Long-distance vSphere vMotion migrations must connect over layer 3 connections: • Virtual machine network: — L2 connection — The same VM IP address is available at the destination • vSphere vMotion network: — L3 connection — 250 Mbps per vSphere vMotion operation — Round-trip time between hosts can take up to 150 milliseconds.
About VM Snapshots With snapshots, you can preserve the state of the VM so that you can repeatedly return to the same state. For example, if problems occur during the patching or upgrading process, you can revert to the previous state. VM snapshots are not recommended as a VM backup strategy.
Taking Snapshots You can take a snapshot while a VM is powered on, powered off, or suspended. A snapshot captures the following items: • VM configuration • VM memory state (optional) • Virtual disks A snapshot capture does not include Independent virtual disks (persistent and nonpersistent).
Types of Snapshots A delta or child disk is created when you create a snapshot: • On the datastore, the delta disk is a sparse disk. • Delta disks use different sparse formats depending on the type of datastore.
Snapshot Datastore Type Filename Block
Type Size VMFSsparse • VMFS5 with virtual disks smaller than 2 #-delta.vmdk 512 bytes TB SEsparse • VMFS6 #-sesparse.vmdk 4 KB • VMFS5 with virtual disks larger than 2 TB • Space efficient (thin provisioned) • Supports disk reclamation (unmap) vsanSparse • vSAN Delta object 4 MB
VM Snapshot Files A snapshot consists of a set of files: • -Snapshot#.vmsn: Configuration state • -Snapshot#.vmem: Memory state (optional) • -00000#.vmdk: Disk descriptor • -00000#-delta.vmdk: VMFS5 delta • -00000#-sesparse.vmdk: VMFS6 delta • .vmsd: Stores names, descriptions, and relationships for all the VM's snapshots
Deleting VM Snapshots (1) If you delete a snapshot one or more levels above the, You are here level, the snapshot state is deleted. In this example, the snap01 data is committed into the parent (base disk), and the foundation for snap02 is retained.
Deleting VM Snapshots (2) If you delete the latest snapshot, the changes are committed to its parent. The snap02 data is committed into snap01 data, and the snap02 -delta.vmdk file is deleted.
Deleting VM Snapshots (3) If you delete a snapshot one or more levels below the You are here level, subsequent snapshots are deleted, and you can no longer return to those states. The snap02 data is deleted.
Deleting All VM Snapshots The delete-all-snapshots mechanism uses storage space efficiently. The size of the base disk does not increase. Snap01 is committed to the base disk before snap02 is committed.
About Snapshot Consolidation Snapshot consolidation is a method for committing a chain of delta disks to the base disks when the Snapshot Manager shows that no snapshots exist, but the delta disk files remain on the datastore.
Snapshot consolidation resolves problems that might occur with snapshots:
• The snapshot descriptor file is committed correctly, and the Snapshot window shows that all the snapshots are deleted. • The snapshot files (-delta.vmdk or -sesparse.vmdk) still exist in the VM's folder on the datastore. • Snapshot files can continue to expand until they reach the size of the -flat.vmdk file or until the datastore runs out of space.
Consolidating Snapshots After the snapshot consolidation warning appears, you can use the vSphere Client to consolidate the snapshots. All snapshot delta disks are committed to the base disks.
Lab 3: Working with Snapshots Take VM snapshots, revert a VM to a different snapshot, and delete snapshots: 1. Take Snapshots of a Virtual Machine 2. Add Files and Take Another Snapshot of a Virtual Machine 3. Revert the Virtual Machine to a Snapshot 4. Delete a Snapshot 5. Delete All Snapshots
Review of Learner Objectives • Take a snapshot of a virtual machine • Manage multiple snapshots • Delete virtual machine snapshots • Consolidate snapshots
Learner Objectives • Describe CPU and memory concepts in relation to a virtualized environment • Recognize techniques for addressing memory resource overcommitment • Identify additional technologies that improve memory use • Describe how VMware Virtual SMP works • Explain how the VMkernel uses hyperthreading
Memory Virtualization Basics vSphere has the following layers of memory: • Guest OS virtual memory is presented to applications by the operating system • Guest OS physical memory is presented to the virtual machine by the VMkernel • Host machine memory that is managed by the VMkernel provides a contiguous, addressable memory space that is used by the VM
VM Memory Overcommitment Memory is overcommitted when the combined configured memory footprint of all powered-on VMs exceeds that of the host memory sizes. When memory is overcommitted: • VMs do not always use their full allocated memory • To improve memory use, an ESXi host reclaims memory from idle VMs to allocate to VMs that need more memory • VM memory can be swapped out to the .vswp file • VM memory overhead can be swapped out to the vmx-*.vswp file
Memory Overcommit Techniques An ESXi host uses memory overcommit techniques to allow the overcommitment of memory while possibly avoiding the need to page memory out to disk.
Methods Used by the ESXi Details
Host Transparent page sharing This method economizes the use of physical memory pages. In this method, pages with identical contents are stored only once. Ballooning This method uses the VMware Tools balloon driver to deallocate memory from virtual machines. The ballooning mechanism becomes active when memory is scarce, sometimes forcing VMs to use their own paging areas. Memory compression This method reduces a VM's memory footprint by storing memory in a compressed format. Host-level SSD swapping The ESXi host can swap out memory to locally-attached solid-state drives. VM memory paging to disk Using VMkernel swap space is the last resort because of poor performance.
Configuring Multicore VMs You can build VMs with multiple virtual CPUs (vCPUs). The number of vCPUs that you configure for a single VM depends on the physical architecture of the ESXi host.
About Hyperthreading With hyperthreading, a core can execute two threads or sets of instructions at the same time: • Hyperthreading provides more logical CPUs on which vCPUs can be scheduled • Hyperthreading is activated by default To activate hyperthreading: • Verify that the host system supports hyperthreading • Activate hyperthreading in the system BIOS • Ensure that hyperthreading for the ESXi host is turned on
Review of Learner Objectives • Describe CPU and memory concepts in relation to a virtualized environment • Recognize techniques for addressing memory resource overcommitment • Identify additional technologies that improve memory use • Describe how VMware Virtual SMP works • Explain how the VMkernel uses hyperthreading
Learner Objectives • Assign share values for CPU and memory resources • Describe how virtual machines compete for resources • Define CPU and memory reservations and limits
Reservations, Limits, and Shares Beyond the CPU and memory configured for a VM, you can apply resource allocation settings to a VM to control the amount of resources granted: • A reservation specifies the guaranteed minimum allocation for a VM • A limit specifies an upper bound for CPU or memory that can be allocated to a VM • A share is a value that specifies the relative priority or importance of a VM's access to a given resource
Resource Allocation Reservations: RAM RAM reservations: • Memory reserved to a VM is guaranteed never to swap or balloon. • If an ESXi host does not have enough unreserved RAM to support a VM with a reservation, the VM does not power on. • Reservations are measured in MB, GB, or TB. The default is 0 MB.
Resource Allocation Reservations: CPU CPU reservations: • CPU that is reserved for a VM is guaranteed to be immediately scheduled on physical cores. The VM is never placed in a CPU ready state. • If an ESXi host does not have enough unreserved CPU to support a VM with a reservation, the VM does not power on. • Reservations are measured in MHz or GHz. • The default is 0 MHz.
Resource Allocation Limits RAM limits: • VMs never consume more physical RAM than is specified by the memory allocation limit. • VMs use the VM swap mechanism (.vswp) if the guest OS attempts to consume more RAM than is specified by the limit. CPU limits: • VMs never consume more physical CPU than is specified by the CPU allocation limit. • CPU threads are placed in a ready state if the guest OS attempts to schedule threads faster than the limit allows. Usually, specifying a limit is not necessary.
Resource Allocation Shares Shares define the relative importance of a VM: • If a VM has twice as many shares of a resource as another VM, the VM is entitled to consume twice as much of that resource when these two VMs compete for resources. • Share values apply only if an ESXi host experiences contention for a resource. You can set shares to high, normal, or low. You can also select the custom setting to assign a specific number of shares to each VM.
Setting CPU Share Values Memory Share Values
High 2,000 shares per vCPU 20 shares per MB of configured VM memory Normal 1,000 shares per vCPU 10 shares per MB of configured VM memory Low 500 shares per vCPU 5 shares per MB of configured VM memory
Lab 4: Controlling VM Resources Observe the behavior of VMs with different CPU share values: 1. Create CPU Contention 2. Verify the CPU Share Functionality
Review of Learner Objectives • Assign share values for CPU and memory resources • Describe how virtual machines compete for resources • Define CPU and memory reservations and limits
Key Points • Hot migrations use vSphere vMotion, vSphere Storage vMotion, or both. • You can migrate VMs between vCenter instances, whether they are in the same SSO domain, different SSO domain, or geographically far apart. • Enhanced vMotion Compatibility prevents vSphere vMotion migrations from failing because of incompatible CPUs or incompatible vSGA GPUs. • You can use VM snapshots to preserve the state of the VM so that you can return repeatedly to the same state. • You can apply reservations, limits, and shares against a VM to control the amount of CPU and memory resources granted. Questions?