We’re worked on another topic today which is one of the base technologies which made VMware so famous. It’s vMotion and storage vMotion. As you know, those two technologies allow you to move workloads from one host to another, from one datastore type to another, without downtime.
Both need to be properly licensed and configured. The configuration can vary depending on many parameters (networks, hardware).
Our Study Guide for students willing to become VCP-DCV 2019 certified is taking shape at this page – VCP6.7-DCV Study Guide – VCP-DCV 2019 certification. Check it out, we’re actively working on it. It’s not perfect, but from our past experience, we received quite a lot of good feedback.
In order to become VCP-DCV 2019 certified, you can still pass the VCP6.5-DCV exam and earn the VCP-DCV 2019 badge. And, there are fewer chapters. Did you know?
To become VCP-DCV 2019 certified you have 3 different choices of exam:
- Professional vSphere 6.7 Exam 2019
- VCP6.5-DCV: VMware Certified Professional 6.5 – Data Center Virtualization exam (our VCP6.5-DCV Study Guide Page which is complete)
- VCP6.5-DCV DELTA: VMware Certified Professional 6.5 – Data Center Virtualization Delta exam
Note: You must be VCP5, or VCP6. If, not, you must attend a class and you have no “Delta” exam option.
With that said, let’s get started.
VCP6.7-DCV Objective 1.11 – Describe vMotion and Storage vMotion technology
Migration of VMs powered ON is called vMotion. (hot migration). Depending on the power state of the virtual machine that you migrate, migration can be cold or hot.
You should make sure that VMware vSphere vMotion traffic does not travel over networks where virtual machines are located. It should be either separated by VLANs or on a dedicated network. vSphere infrastructure networks are used for features such as vSphere vMotion, VMware vSphere Fault Tolerance, and storage. Isolate these networks for their specific functions.
Example of activation of vMotion traffic on a vmkernel port.
VMware vMotion – with vSphere vMotion you can move powered on virtual machines away from a host to perform maintenance, to balance loads, to collocate virtual machines that communicate with each other, to move virtual machines apart to minimize fault domain, to migrate to new server hardware, and so on.
When you migrate a virtual machine with vMotion, the new host for the virtual machine must meet compatibility requirements so that the migration can proceed.
We often talk about Hot migration, but there is also cold migration allowing to simply move VM which is powered OFF.
vMotion has 3 Phases:
- Phase 1 – vMotion is requested. vCenter server checks whether the existing VM is in a stable state with its current host.
- Phase 2 – VM state info (memory, registers and network connections) are copied to the target host.
- Phase 3 – VM resumes its activities on the new host.
- The host must be licensed for vMotion.
- The host must meet shared storage requirements.
- The Host must meet networking requirements for vMotion.
vMotion Migration Types
vMotion (traditional) – you change computer resource only. When you migrate virtual machines with vMotion and choose to change only the host, the entire state of the virtual machine is moved to the new host. The associated virtual disk remains in the same location on storage that must be shared between the two hosts.
Long-distance vMotion – sites that are separated by high network roundtrip latency times. vMotion across long distances is enabled when the appropriate license is installed. No
user configuration is necessary. Round trip < 150 ms, License for vMotion Long distance.
Migrate to another datacenter – by using cold or hot migration. For destination networking, you can select a dedicated port group on a distributed switch.
Migrate to another vCenter server – via vCenter Enhanced Linked Mode (ELM). Across a long distance too.
Storage vMotion – You move your VM from one storage to another. Without downtime. Change datastore. The virtual machine state, it’s VMDKs and associated files, are moved to another datastore. A proper license is required. The host on which the virtual machine is running must have access to both the source and target datastores.
Note: Storage vMotion limitations. Virtual machine disks must be in persistent mode or be raw device mappings (RDMs). For virtual compatibility mode RDMs, you can migrate the mapping file or convert to thick-provisioned or thin-provisioned disks during migration if the destination is not an NFS datastore. If you convert the mapping file, a new virtual disk is created and the contents of the mapped LUN are copied to this disk. For physical compatibility mode RDMs, you can migrate the mapping file only.
vMotion without shared storage – you can vMotion VMs to a different host and storage. This is useful for performing cross-cluster migrations when the target cluster machines might not have access to the source cluster’s storage
Transferred State Information – Includes current memory content and the info about the VM. Memory content has transaction data and the parts of OS and applications which are currently running in the memory. The defining and identification information stored in the state includes all the data that maps to the virtual machine hardware elements. This information includes BIOS, devices, CPU, MAC addresses for the Ethernet cards, chipset states, registers etc.
Limits on simultaneous migrations
vCenter places limits on the number of simultaneous VM migrations. Those limits apply on a host, network and datastore.
- Network limit – On 1GbE it is 4 and on 10GbE it is 8. Network limits depend on the version of ESXi and the network type.
- Datastore limit – 128 per datastore. Apply to migrations with vMotion and with Storage vMotion.
- Host Limit – apply to migrations with vMotion, Storage vMotion, and other provisioning operations such as cloning, deployment, and cold migration. All hosts have a maximum cost per host of 8.
Migrations of suspended virtual machines are possible. However, the VM has to be able to resume execution on the target host using equivalent instructions.
When you initiate a migration with vMotion or migration of a suspended virtual machine, the Migrate Virtual Machine wizard checks the destination host for compatibility. If compatibility problems prevent migration, the wizard displays an error message.
vMotion might need Enhanced vMotion Capability (EVC) configured at the cluster level when your cluster has different hardware (and CPU). Every new processor, for example, Intel, releases a new set of instructions that are not, as you can imagine, backward compatible with previous generations of CPUs. So this is why we need to “mask” these new capabilities within our cluster to retain our vMotion capability. We hide the newer instructions within vCenter Server.
As a result, EVC presents a homogeneous processor front to all the virtual machines (VMs) in a cluster. So it allows us to vMotion from, for example, Intel’s Sandy Bridge-based host into a Haswell-based host.
However, note that CPUs must be from a single vendor, for example, only from Intel or only from AMD. You cannot mix and match both and still expect to configure EVC for vMotion to work. No, it does not.
Do not rely only on our Study guide only. Use the official documentation as well as your home lab for the study. Follow the progress of the VCP6.7-DCV Study Guide page for further updates.
More from ESX Virtualization
- What is VMware Platform Service Controller (PSC)?
- What is vCenter Embedded Linked Mode in vSphere 6.7?
- VMware vExpert 2019 – This is vExpert x11
- How To Reset ESXi Root Password via Microsoft AD
- How to Patch VMware vCenter Server Appliance (VCSA) 6.7 Offline