Not a single application could afford downtime. However, some downtime becomes completely avoidable. Sometimes, you get to know prior about the system downtime, when it is eminent, like for moves, maintenance, natural disasters, or so.
In such cases, users can perform a VMware Motion of that workload from a server that is going to suffer downtime to the one which isn’t.
VMware vMotion featuring zero downtime is the live migration of workloads from one server to another one. This competence is possible throughout Clusters, vSwitches, and also Clouds based on the vSphere version you own.
Throughout the workload transfer, the program keeps on running, and people continue to enjoy access to the systems they require. Thus, productivity always remains high with VMware vMotion!
Though Storage vMotion and vMotion serve different purposes, these tools feature a wide range of overlapping technology. That’s the reason we are going to talk about both of these two vSphere functions in this article.
So, vMotion is basically used for migrating virtual machines among running ESX-hosts, whereas Storage vMotion moves the data files between wholly functional data stores on those virtual machines.
If the destination or the source is offline, both of these vSphere features would not be of any use.
Part 1: Introduction to VMware vMotion
However, as opposed to well-known speculation, Storage VMotion and VMware vMotion are not programs designed for increasing high availability.
Most people have heard of VMware vMotion for sure, which is a live migration feature within VMware vSphere. So, the introduction will be quite brief. vMotion is a tool using which active virtual systems could be migrated from an ESX-host to the other one without interruption.
Also, it could be moved to the virtual systems themselves and even to the provided services. Using vSphere 5.x, previous restrictions on the virtual machines’ simultaneous migrations on datastore-basis and ESXi-host-basis have been eliminated.
This process was only possible previously as cold migration procedures using offline VMs. Therefore, VMware vMotion and VMware Storage vMotion have made it possible to move active VMs on a hosted basis and also on a datastore basis.
The vMotion procedure has become advanced as even in experiments at trade shows comprising hundreds of virtual machines, VMware vMotion does not ever lose VMs or disrupt the services of a VM. To be honest, not all virtual machines are well-suited for vMotion.
Key Features of VMware vMotion:
1. Carry Out Live Migrations
VMware vMotion enables users to transfer a complete running VM from one physical server to another, featuring no downtime.
The VM retains all the network connections and identities, thus ensuring a continuous migration procedure. One can transfer the active memory of a VM over a high-speed network, enabling the VM to switch from functioning on the source host to the target host.
Over a gigabit Ethernet connection, the entire process just takes two seconds or less. Now, live migration enables users to:
- Optimize VMs within a resource pool automatically.
- Accomplish hardware maintenance lacking disrupting business or scheduling downtime.
- Migrate VMs away from underperforming or failing servers.
2. Schedule and Automate Migrations
With the help of VMware vMotion, users could schedule migrations at a predefined time with no intervention from the administrator. This program organizes VM performance across clusters. VMware vMotion enables you to:
- Move numerous VMs running on any operating system across all hardware types.
- Recognize the optimum placement for a VM within seconds.
Other Technical Details Linked to VMware vMotion
VMFS (Virtual Machine File System)
The whole state of a VM is encapsulated through a set of shared storage files, like Internet Small Computer System Interface (iSCSI), Fibre Channel, Network-Attached Storage (NAS), or SAN. VMware VMFS enables multiple VMware ESX installations to access the same VM files concurrently.
vMotion Over Long Distances and Across Boundaries
vMotion has revolutionized the entire concept of live migration. Using vSphere 6.0, the company continues to live workload to offer new vMotion abilities, which span all the limits of distributed vCenter Servers and Switches.
Moreover, it is possible to carry out long-distance vMotion, up to 100 meters RTT. This technique allows VMware vMotion to migrate live workloads from data centers in London and New York.
VMware vSphere running on version 5.1 or later combines typical vMotion with VMware Storage vMotion within one migration. Users can migrate a complete VM between clusters, hosts, or data centers without disruption. In addition, one can even share storage among the involved hosts.
Conserving Network State
The primary host of vSphere virtualizes the networks employed by the VM. It ensures that after the transfer, the VM’s network connections and identity are preserved.
With vMotion migration, one preserves the exact execution state, active network connections, and network identity. Thus, users experience no disruption and downtime.
VMware vMotion could transfer the accurate executive state and active memory over high-speed networks. Thus, it allows switching from operating on the primary host to the target host. VMware vMotion also tracks all memory transactions going on with a bitmap. Thus, it keeps the migration period indiscernible to users.
After copying the complete system state and memory, it suspends the primary VM and copies that bitmap to the destination host. Then, it resumes the VM on the destination host. Therefore, VMware vMotion ensures transaction integrity.
Part 2: How Does VMware vMotion Work
Now, let’s dive deeper into VMware vMotion. When it comes to functionality, everyone will agree that its functionality is ingenious and very simple.
It guarantees system reliability throughout a conventionally problematic period, which is the maintenance of the host.
In addition, VMware vMotion is very significant, as anyone can notice, for separating the hardware from the applications and the operating system.
Now, it is time for you to know about the working of VMware vMotion. Below are certain simple steps that will help you understand how vMotion actually works.
So, Let’s See How It Functions Without Further Ado!
- First, users need to ensure that the VM source can be operated on the selected destination server.
- After this, a second M process will start on the target system, where the resources are also reserved.
- Now, the system memory checkpoint will be created. It means that all modifications to the VM source are written to an additional memory space.
- The system memory’s contents recorded at a checkpoint will be transferred to the target VM.
- The checkpoint-restore procedure or checkpoint will be repeated until there remain the smallest changes in the memory of the target VM.
- Next, the source VM’s source will stop working.
- The recent modifications on the main memory get transferred to the target VM within a few milliseconds.
- Now, the VMware vMotion procedure will end, and the reverse ARP packet will be sent to the physical switch. Please note that one should activate Notify Switches under the virtual switch’s properties. The access to hard disks will be taken over by the target ESX.
- Lastly, the source VM will be shut down. It means that the VM procedure present on the source ESX will be deleted.
Now, you should know what all the vMotion checkpoints record. The things that the checkpoints keep track of are as follows:
- All devices and their respective status
- Contents of the main memory
- CPU registers
- A serialization of the transmission status over the network
As one can examine, VMware vMotion is mostly concerned with the transmission of the contents of the main memory from an ESX server to the other one. It features a final warning notifying the physical network regarding the new interface over which the VM reaches out.
One receives the notification only after the procedure is over. Here, the course’s guest system does not observe anything.
The Following Table Displays an Example of How Memory Transfer Can Be Computed.
|Pre-Copy Iteration||Main Memory to be Transferred||Time Required for the Transfer||Change in Memory Throughout the Transfer|
|1||2.048 MB||16 seconds||512 MB|
|2||512 MB||4 seconds||128 MB|
|3||128 MB||1 second||32 MB|
|4||32 MB||0.25 second||8 MB|
|5||8 MB||vMotion Cutoff, as the residual transmission takes just ~0.06 second||_|
As one can see in the tab, the main memory transfer is achieved consecutively in various steps if disrupted only when a CPU stop is there, which leads to a system crash.
VMware vMotion comprises various components. These units are responsible for organizing diverse parts of the procedure. vCenter carries out the first configuration check and also begins the procedure over the hostd- and vpxa- components, where a pseudo-VM starts off as a container on the target host. Here, the vMotion module begins the actual procedure and manages the data transfer.
On the other hand, vCenter begins and validates the procedure. However, it is a part of the actual transfer of the data. Thus, an active VMware vMotion procedure should always be enabled to run for completion, even if vCenter crashes in some cases.
In the event of a crash, it is possible that vCenter has the source VM in the database and does not have any idea regarding the target VM in the new setting. If this occurs, it assists in restarting the management agent or in performing a reconnect/disconnect of the ESX host within vCenter.
The user interface of vMotion should be configured through an administrator and downloaded on the VMkernel port. It signifies that the data transfer through vMotion must be enabled from the VMkernel port’s settings.
So, users who like to migrate data from one server to another in a non-disruptive manner should go with this incredible program. Try out VMware vMotion now and enjoy its advanced features.