Virtual Machine migration technology, part 1

Preface

System migration refers to moving the operating system and applications on the source host to the target host and running properly on the target host. In the era when there is no virtual machine, the migration between physical machines relies on system backup and recovery technologies. Back up the operating system and application status on the source host in real time, connect the storage media to the target host, and restore the system on the target host. With the development of virtual machine technology, system migration is more flexible and diversified.

This series of articles fully introduces three methods of Virtual Machine migration: p2v, V2V, and v2p, and their implementation methods on Kernel Virtual Machine KVM, which are divided into five parts. The first part introduces various migration methods and corresponding migration tools for virtual machines, and focuses on the memory pre-Copy Technology in the Linux platform's open-source virtualization tools KVM and xen real-time migration;

The second part introduces V2V migration technology between KVM virtual machines, including offline migration and online migration. The third part describes how to migrate a VMware or xen-based virtual machine to a KVM-based virtual machine; part 4 describes how to migrate p2v from a physical machine to a virtual machine and v2p from a virtual machine to a physical machine on a KVM Virtual Machine. Part 5 describes the cloning, snapshot, and backup technologies of virtual machines that are closely related to virtual machine migration.

Back to Top

Introduction to virtual machine migration

Why migrate servers?

The migration server can save management, maintenance, and upgrade costs for users. In the past, x86 servers were relatively large, while the current servers are much smaller than before, the migration technology allows users to use one server to replace many previous servers at the same time, thus saving a lot of Data room space for users. In addition, servers in virtual machines have unified "virtual hardware resources". Unlike previous servers, they have many different hardware resources (such as different Motherboard chipset, different NICs, hard disks, raid cards, different video cards ). The migrated servers can be managed not only on a unified interface, but also through some virtual machine software, such as the high availability tools provided by Vmware, when these servers are shut down due to various faults, you can automatically switch to another virtual server in the network to avoid service interruption. In short, the advantage of migration is to simplify system maintenance and management,
Improve system load balancing, increase system error tolerance, and optimize system power management.

Performance indicators of Virtual Machine migration

An excellent migration tool aims to minimize the overall migration time and downtime and minimize the impact of migration on the performance of services running on the migrated host. Of course, these factors affect each other. The implementers need to measure the application requirements for migration and select appropriate tools and software. The performance indicators of Virtual Machine migration include the following:

1. Overall migration time: the time from the source host to the end of migration
2. Downtime: the time when the source host and target host are unavailable during migration
3. Impact on application performance: the impact of migration on the performance of services running on the migrated host.

Back to Top

Classification and principles of Virtual Machine migration

Physical-to-virtual)

P2v refers to the migration of the operating system on the physical server and its application software and data to the virtual server managed by vmm (Virtual Machine monitor. This migration method mainly uses various tools and software to "mirror" the system status and data on the physical server to the virtual machine provided by vmm, replace the storage hardware and NIC Driver of the physical server in the virtual machine. You only need to install the corresponding driver in the virtual server and set the same address (such as the TCP/IP address) as the original server. After restarting the virtual server, A virtual server can replace a physical server for work.

P2v migration method

• Manual migration: complete all Migration Operations manually. You must have a good understanding of the physical machine system and virtual machine environment.

1. Shut down services and operating systems on the original physical machine, and start a new system from other media. For example, start a new CD system from livecd. Most releases contain livecd.
2. Make the disk of the physical machine system into a virtual machine image file. If multiple disks exist, you need to create multiple images and copy the images to the virtual machine.
3. Create Virtual Devices for virtual machines and load image files
4. Start the VM, adjust system settings, and enable the service.

• Semi-automatic migration:Professional tools are used to assist p2v migration and automate some manual steps. For example, converting the disk data of a physical machine to a virtual machine format has always been a very time-consuming task. You can select a professional tool to complete this step. There are a lot of tools to use, such as RedHat Open Source Tool virt-p2v, Microsoft Virtual Server migration toolkit and so on.
• P2v hot migration:Avoid downtime during migration. Most p2v tools also have a large limit: physical machines are unavailable throughout the migration process. This tool is not optional in the environment where key tasks are run or where SLA (SLA) exists. Fortunately, with the development of p2v technology, VMWare vcenter converter and Microsoft hyper-V have been able to provide hot migration to avoid downtime. Currently, p2v hot migration is only available on Windows physical servers. Support for Linux will be added in the future.

Virtual-to-virtual)

V2V migration refers to moving the operating system and data between virtual machines, taking care of differences at the host level and processing different virtual hardware. The Virtual Machine is migrated from the vmm on one physical machine to the vmm on another physical machine. The two vmm types can be the same or different. For example, migrate from VMware to KVM and from KVM to KVM. You can move a VM from one VM host system to another VM host system in multiple ways.

V2V offline migration

Offline migration is also called regular migration and static migration. Pause the VM before migration. If shared storage is used, only the system status is copied to the target host, and the VM status is rebuilt on the target host to resume execution. If you use local storage, You need to copy the virtual machine image and status to the target host at the same time. In this migration process, the virtual machine must be stopped. From the user's perspective, there is a clear period of service downtime. This migration method is simple and suitable for scenarios where the service availability requirements are not strict.

V2V online migration

Online migration: Also known as live migration ). This means that, while ensuring the normal operation of services on virtual machines, virtual machines are migrated between different physical hosts. The logical steps are almost the same as offline migration. The difference is that to ensure the availability of Virtual Machine services during the migration process, the migration process has only a very short downtime. In the previous stage of migration, the service runs on the source host. When the migration is in a certain stage, the target host already has the necessary resources for running the system. After a very short switchover, the source host transfers control to the target host, and the service continues to run on the target host. For the service itself, because the switching time is very short, the user does not feel the service interruption, so the migration process is transparent to the user. Online migration is suitable for scenarios with high service availability requirements.

Currently, mainstream online migration tools, such as VMware vmotion and xen xenmotion, require the use of San (Storage Area Network) and NAS (Network-Attached Storage) between physical machines) for centralized shared external storage devices, you only need to consider migrating the operating system memory execution status during migration to achieve better migration performance.

In addition, in some scenarios where shared storage is not used, you can use the online migration technology of storage blocks to achieve online migration of V2V virtual machines. Compared with online migration based on shared storage, online migration of data blocks requires migration of Virtual Machine Disk Images and system memory status at the same time, resulting in discounts on migration performance. However, in a distributed local storage environment, he can still use the Migration Technology to transfer the computer environment and ensure the availability of operating system services during the migration, extends the application scope of online migration of virtual machines. V2V online migration technology eliminates software and hardware relevance and is a powerful tool for software and hardware system upgrades, maintenance, and other management operations.

V2V memory Migration Technology

For VM memory state migration, both xen and KVM adopt mainstream pre-copy policies. After the migration starts, the source host VM is still running and the target host VM is not started. The migration uses a loop to send the memory data of the source host VM to the target host VM. The first round of the cycle sends all the memory page data, and the next round of the cycle sends the dirty page memory dirty pages written by the VM during the previous round of pre-copy. When the time is ripe, the pre-copy cycle ends and the copy is stopped. The source host is suspended and no memory update is available. Dirty pages in the last cycle are transmitted to the target host VM. The pre-copy mechanism greatly reduces the amount of memory data that needs to be transferred during the stop copy phase, thus greatly reducing the downtime.

However, for memory parts with extremely fast update speeds, each cycle will become corrupted, and pre-copy needs to be repeated, resulting in a large number of cycles and a longer migration time. To address this problem, the KVM virtual machine has established three principles: the centralization principle, the dirty pages in a loop is smaller than or equal to 50; the non-diffusion principle, the dirty pages transmitted in a loop are less than the newly generated ones. In the finite loop principle, the number of loops must be less than 30. In terms of implementation, the following measures are taken:

• Limited Loop: the number of cycles and the effect are controlled. The effect of pre-copy in each round is calculated. If pre-copy does not significantly reduce the number of inconsistent memories, or if the number of cycles exceeds the upper limit, the cycle will be suspended and the copy is stopped.
• Set a memory access monitoring module in the kernel of the migrated VM. During the memory pre-copy process, a VM process is limited to a maximum of 40 memory write operations during a scheduled operation. This method directly limits the speed of dirty memory during the pre-copy process. The cost is to limit the running of processes on the VM.

KVM pre-copy online migration process details:

1. The system verifies that the storage and network settings of the target server are correct, and reserves the resources of the virtual machines on the target server.

   Figure 1. Source and target servers
   

2. When the VM is still running on the source server, all memory images are copied to the target server in the first cycle. In this process, KVM will still monitor any changes in memory.

   Figure 2. memory image copying
   

3. In subsequent cycles, check whether the memory in the previous cycle has changed. If a change occurs, vmm copies the changed Memory Page dirty pages to the target server and overwrites the previous Memory Page. At this stage, the vmm will continue to monitor memory changes.

   Figure 3. Memory replication with changes
   

4. Vmm will continue such a memory replication loop. As the number of cycles increases, the dirty pages to be copied will be significantly reduced, and the time consumed by replication will gradually become shorter. Therefore, the memory may not have enough time to change. Finally, when the difference between the source server and the target server reaches a certain standard, the memory replication operation ends and the source system is suspended.

   Figure 4. The data to be copied is decreasing
   

5. When both the source and target systems are down, copy the last cycle of dirty-pages and the source system device's working status to the target server.

   Figure 5. Copy status information
   

6. The storage is then unlocked from the source system and locked to the target system. Start the target server and connect it to storage and network resources.

   Figure 6. Stop the source server and start the target server
   

Migration from virtual-to-Physical Virtual Machine to Physical Machine

V2p refers to the p2v inverse operation that migrates an operating system, applications, and data from a virtual machine to the primary hard disk of the physical machine. It can simultaneously migrate virtual machine systems to one or more physical machines. Although the basic requirement of virtualization is to integrate physical machines into virtual machines, it is not the only application of virtualization. For example, sometimes problems with applications on virtual machines need to be verified on the physical machine to eliminate the impact of the virtual environment. In addition, configuring a new workstation is a headache for IT managers, but virtualization applications can help them solve this problem. First configure the virtual machine, and then use the hard disk clone tool to copy data to the workstation hardware, such as Symantec's Save & restore (ghost ). However, this cloning method has two limitations: an image can only be used on machines with the same hardware configuration; To save the configuration changes, you can only redo the new image.

V2p migration can be done manually by determining the target physical environment, such as attaching a specific hard disk to the virtual system, and then installing the operating system, applications, and data in the virtual environment, finally, manually modify the system configuration and driver. This is a tedious and uncertain process, especially when the new environment contains more hardware than the old one. To simplify the operation, we can use a dedicated migration tool to complete part or all of the migration work in an automatic manner. Currently, tools supporting v2p conversion include platespin migrate and EMC homebase. Using this tool makes v2p conversion easier and faster than using a third-party disk image tool.

V2p migration method

Due to the uncertainty of v2p, there are not many automated tools. Currently, there are mainly the following solutions:

• VMware officially recommends using ghost + sysprep for semi-automatic migration.
• A solution based on backup and recovery of the operating system. This solution utilizes a ready-made system backup and recovery tool, without reflecting the differences between virtual machines and physical machines, similar to P2P (physical-to-physical machine migration to physical machine ). Note that the backup tool can restore the system to a heterogeneous hardware platform.
• Open-source tool solution. It is suitable for Linux/Unix systems. It uses open-source tools and scripts to manually migrate the system. This solution is difficult and suitable for experienced administrators.

Back to Top

Technical difficulties of Linux System in Virtual Machine migration

We usually expect that the migration of virtual machines can be completed automatically or partially, but in fact, the Linux system may encounter some difficulties in p2v and V2V migration. This section lists precautions for Linux migration.

1. The disk partition name is hard-coded. When we perform disk virtualization, we may use different types of virtual disk devices, which will lead to changes in the disk name. For example, the semi-virtualization device in the xen virtual machine uses/dev/xvda and the standard Linux semi-virtualization device uses/dev/vda. In the Linux system to be migrated, the/dev/HD * And/dev/SD * partitions are separated, for example, in the/etc/fstab file, start the initialization file system ramfs and some boot script files that parse disk devices. The V2V migration tool needs to find and modify these associations on the entire disk. There is a simple way to avoid this situation:
   Mainstream file systems and swap partition types in Linux can use lables or UUID as the partition name. This information is protected during migration. The system should be careful when using this information. Do not use the device as the partition name. In addition, the LVM partition name is independent of the device and is not affected during migration.
2. Changes in network hardware. Network devices may change during system migration. For example, the conversion between virtual network devices and physical network devices or between different types of network devices. However, their MAC address remains unchanged. The MAC address is assigned to the physical device manufacturer by IEEE. The two physical devices do not have the same MAC address. However, this may happen to virtual network devices. Therefore, during Virtual Machine migration, you must record the MAC address of each network device to ensure the correspondence between the MAC address and the network device.
3. The kernel does not support certain Virtual Devices. Some Linux distributions do not have virtio Virtual Device Drivers, probably because the Linux release is earlier than the virtual device, or the driver of the virtual device is closed to the source, or is removed during system compilation. Therefore, sometimes we need a completely different kernel (such as the earlier version of xen ). In any case, installing a new kernel on the client and enabling it to start is a big risk. It is best to avoid this.
4. XWindow needs to be reconfigured. Like a disk or network device, the device changes after the system is migrated. Ideally, XWindow will automatically handle this change and detect all the display devices and use it to discover the first device. However, this does not mean that all Linux distributions work in this way.
5. Network environment changes. Static IP address and static DNS resolution are being migrated in the Virtual MachineYesA troublesome task. Although not required, it is recommended that the configuration system automatically obtain all network configuration information from the DHCP server.
6. The Extended Instruction Set of the CPU changes. In the migrated system, the new virtual CPU or motherboard may be different from the old one. CPU extended instruction sets such as SSE, vectors, and Nx may be added or removed. The CPU model and manufacturer information may be changed. Therefore, if you want to optimize the software on the virtual system, it may be a waste of time and cause the system to crash. It is best to use common software so that the program can check the runtime environment and whether optimization is required at each startup. In fact, real-time migration is more complex than this because the processor may be changed during the running of the program. So far, no solution can solve this problem well.

As you can see, the biggest problem with p2v and V2V is hardware changes. Linux releases should be able to handle all hardware changes: Check all hardware at system startup, the operating system kernel recognizes new devices and looks for new drivers to process them, do not bind all applications to hardware. Design a good model to deal with sudden environment changes.

Back to Top

Introduction to the migration features of popular Virtual Machine Software

P2v migration tool

The Virtual Hardware presented by the virtual machine is usually different from the physical hardware on the original server. P2v migration tool solves this problem as follows:

• VMware vcenter converter: supports conversion from sources such as physical machines, VMWare and Microsoft Virtual Machine formats, and some third-party disk image formats. He has replaced the old migration tools vmware workstation importer and VMWare p2v assistant. VMware vcenter converter supports and recognizes most server hardware types. VMware vcenter converter provides two cloning mechanisms: Hot cloning (Real-time migration) and cold cloning (using bootcd cloning ). When using hot cloning, VMWare
  Vcenter converter communicates directly with the operating system running on the Source Physical Machine, so there is no direct hardware-level dependency. When using cold cloning, VMware vcenter converter bootcd provides a Windows PE boot environment that supports the latest hardware, so you can identify most physical server system hardware. Currently, only Microsoft Windows-based physical machines can be migrated.
• Xenconvert: a migration tool from a physical server to a virtual machine. Not only can windows physical machines be migrated to the virtual machines managed by xenserver, but also the vmdk format and ovf package of VMWare virtual machines can be imported.
• Virtual Machine manager 2008: provides a task-based wizard that automatically executes most of the conversion processes to simplify p2v conversion. You can use scripts to complete p2v conversion. Therefore, you can use Windows powershell command lines to perform large-scale p2v conversion. Vmm2008 supports both online and offline conversion.
• Symantec Ghost: creates an image file and restores it to a virtual machine. It is used to make the hard disk of the server to be migrated into an image file through the network, and then restore the image file to the virtual machine through the network.
• Virt-p2v: Open Source migration tool for Redhat.

V2V migration tool

V2V migration is an important function of Virtual Machine Management tools. Therefore, various virtualization software provides modules or tools for V2V migration. Online V2V migration greatly reduces the downtime of Virtual Machine migration. This makes dynamic migration the first choice for users to migrate virtual machines when they need to work continuously. The common online migration solution is to use shared storage for virtual machines. during migration, only the memory of the virtual machines is copied. For the principle, see the previous section "V2V memory migration technology ".

VMware vmotion

VMware's online migration is implemented by the vmotion component. Vmotion's real-time solution features its own Cluster File System: vmfs and supports NFS. Vmotion encapsulates the entire virtual machine, including its complete state, in several files and stores them in shared storage such as San/NAs. The migration process is to copy the memory and running status from the source to the target through the high-speed network.

Citrix xenmotion

Xenmotion is a feature of xenserver that can migrate running virtual machines from one xenserver host to another without the risk of downtime. This means that the migrated virtual machines can be accessed at any time during the migration process. Xenmotion is primarily designed to prevent end users from experiencing extremely short-term interruptions to an application during scheduled repairs on a server, so that the entire service process is normal and smooth.

Microsoft hyper-V

Microsoft hyper-V has supported dynamic migration technology since 2.0. Using hyper-V dynamic migration, you can move a running Virtual Machine from one hyper-V physical host to another without interrupting any services or stopping services, the memory in the VM migrated through pre-replication is directed to the target host. When the administrator or script starts the dynamic migration, it controls the target computer for this migration. When the customer uses the migrated system, it does not feel that the migration is in progress.

QEMU-KVM/libvirt

Qumranet, the original company of kernel Virtual Machine KVM technology, was developed rapidly and comprehensively after it was acquired by RedHat in 2008. The Redhat Enterprise Linux 2009 released in 5.4 fully supports KVM virtual machines, including offline migration and online migration technologies. The graphic KVM Virtual Machine Management Tool virt-manager is integrated in Redhat Enterprise Linux 2010 and SuSE Linux Enterprise Server 11 Service Pack 1 released in 5.5, making migration of virtual machines more intuitive and informative. The next article in this series will detail how to migrate
KVM virtual machine.

Back to Top

Future of automated migration

At present, many enterprises have virtualized data center devices including CPU, memory, I/O, storage, and network. How can they better manage and utilize these virtual and physical resources, it has become an urgent problem in the heterogeneous virtualization period of data centers. P2v migration tool simplifies physical resource virtualization and data center migration; V2V migration tool optimizes virtual resources; and v2p migration tool can quickly deploy virtual machines to physical machines. In the near future, p2v, v2p, and V2V tools will lose their original meaning. All functions will be integrated into an intelligent, automated, and autonomous data center optimization system. The highly automated monitoring module scans the entire data center 24 hours a day to find overload and idle virtual machines. The planning module selects the best migration tool based on the monitoring report and collected information for resource optimization, the migration process is automatically executed when the application is running normally. At that time, the entire environment could flow freely like a liquid, and the load was constantly balanced across servers. The virtual environment and the physical environment would be no different for users.

Virtualization and cloud computing

Cloud computing provides computing resources in the form of services. One of the most important concepts behind cloud computing is scalability, and the key to achieving it is virtualization. Virtualization aggregates multiple operating systems and applications on a shared computer to make better use of the server. Virtualization also allows online migration. Therefore, when a server is overloaded, You can migrate one of the Operating Systems and Its Applications to a new and not busy server. In the cloud, virtual servers can be shared between multiple operating systems and applications to reduce the number of servers. Less servers mean less space (less space occupied by data centers) and less power for cooling (less carbon pollution ). IBM believes that virtualization is a key component module of the future cloud computing architecture.
The key to the "cloud" capability of IT enterprises is their virtualization implementation capability. Virtualization technology is becoming popular, and it may not take too long. We deal with virtual machines every day.

Back to Top

Summary

This article introduces various methods and tools for Virtual Machine migration, analyzes the principles of the memory pre-Copy technology, and lists the issues that should be paid attention to during Virtual Machine migration. It not only provides a reference for system administrators to fully understand the migration methods and policies, but also provides guidance for developers and testers of virtual machines. The articles later in this series will introduce how to operate and implement system migration on KVM virtual machines.

References

Learning

• Refer to the "Linux virtualization technology" column on developerworks to learn about Linux virtualization technology and software.

• Refer to the "vmare vmtion" Product homepage to learn about the features of vmtion.
• Refer to the "cirix xenmotion" Product homepage to learn about the features of xenmotion.
• Refer to the "KVM migration" Wiki page to learn about KVM migration.
• Find Linux developers (including
  For more information, see us.
  The most popular articles and tutorials.

• Refer to all
  Linux skills and
  Linux tutorial.

Source: http://www.ibm.com/developerworks/cn/linux/l-cn-mgrtvm1/