Shulou(Shulou.com)05/31 Report--

This article mainly explains "how to realize virtual machine migration technology". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Next let the editor to take you to learn "how to achieve virtual machine migration technology"!

How to migrate systems between virtual machines and physical machines and between virtual machines and virtual machines

Virtual machine migration technology provides a convenient method for server virtualization. Popular virtualization tools such as VMware,Xen,HyperV,KVM provide their own migration components. Although the function of commercial virtual software is relatively powerful, open source virtual machines such as Linux kernel virtual machines KVM and XEN are developing rapidly, and the migration technology is becoming more and more perfect. This series of articles introduces three ways of virtual machine migration: P2V, V2V and V2P, and their implementation on kernel virtual machine KVM, which is divided into five parts. This paper is the first part, which comprehensively introduces various methods and corresponding migration tools of virtual machine migration, and focuses on the memory pre-copy technology of KVM and XEN real-time migration, which are open source virtualization tools on Linux platform.

Preface

The migration of the system means that the operating system and applications on the source host are moved to the destination host and can run normally on the destination host. In the era without virtual machines, the migration between physical machines depends on system backup and recovery technology. Back up the status of the operating system and applications in real time on the source host, then connect the storage media to the target host, and finally restore the system on the target host. With the development of virtual machine technology, the migration of the system is more flexible and diversified.

This series of articles comprehensively introduces the three ways of virtual machine migration: P2V, V2V and V2P, and their implementation on kernel virtual machine KVM, which is divided into five parts. The first part introduces various methods and corresponding migration tools of virtual machine migration, and focuses on the analysis of memory pre-copy technology in KVM and XEN real-time migration, which are open source virtualization tools on Linux platform.

The second part introduces the V2V migration technology between KVM virtual machines, including offline migration and online migration; the third part introduces how to migrate VMware or XEN-based virtual machines to KVM-based virtual machines; the fourth part introduces the implementation of physical machine-to-virtual machine migration P2V and virtual machine-to-physical machine migration V2P on KVM virtual machines; the fifth part introduces virtual machine cloning, snapshot and backup technologies which are closely related to virtual machine migration.

Introduction to Virtual Machine Migration Why migrate servers

Migrating the server can save users administrative funds, maintenance costs and upgrade costs. In the past, the x86 server was relatively "large", but now the server is much smaller than before, and the migration technology enables users to replace many previous servers with one server at the same time. This saves users a lot of computer room space. In addition, the servers in the virtual machine have unified "virtual hardware resources", unlike previous servers with many different hardware resources (such as different motherboard chipsets, different network% Aq, different "% 1" disks, different RAID cards, different graphics cards). The migrated server can not only be managed in a unified interface of "% Bx", but also access to some virtual machine software of% B, such as the high availability tools provided by VMware, when these services "% Ax" are down due to the failure of "% 7" of eBA, they can automatically switch to the same virtual server in the network, so as to achieve the purpose of not interrupting business. In a word, the advantage of migration lies in simplifying system maintenance management, improving system load balancing, enhancing system error tolerance and optimizing system power management.

Performance metrics for virtual machine migration

An excellent migration tool that aims to minimize 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 influence each other, and the implementers need to measure them according to the needs of the applications targeted by the migration and choose the appropriate tools and software. The performance metrics of virtual machine migration include the following three aspects:

Overall migration time: the time from the source host to the end of the migration

Downtime: the time during which the source host and destination host are unavailable at the same time in "eA8"

The "E80" of the application can affect the extent to which the migration affects the performance of the services running on the migrated host.

Classification and principle of virtual machine migration physical machine to virtual machine migration (Physical-to-Virtual)

P2V refers to the migration of the operating system and its application software and data on the physical server to a virtual server managed by VMM (Virtual Machine Monitor). This kind of migration mainly uses various tools and software to "mirror" the system state and data on the physical server to the virtual machine provided by VMM, and "replace" the storage hardware and network card driver of the physical server in the virtual machine. As long as the corresponding driver is installed in the virtual server and set the same address as the original server (such as TCP/IP address, etc.), after restarting the virtual machine server, the virtual server can replace the physical server to work.

P2V migration method

Manual migration: all migration operations are done manually, and a good understanding of the physical machine system and virtual machine environment is required.

Shut down the services and operating systems on the existing physical machine, and start a new system from other media. For example, boot a new CD-ROM system from LiveCD. Most distributions come with LiveCD.

Make the disk of the physical machine system into a virtual machine image file, if there are multiple disks, you need to do multiple mirrors, and copy them to the virtual host.

Create virtual devices for virtual machines and load image files

Start the virtual machine, adjust the system settings, and turn on the service.

Semi-automatic migration: use professional tools to assist P2V migration and automate some manual links. For example, converting disk data from a physical machine to a virtual machine format has always been a time-consuming task, and you can choose professional tools to complete this step. There are a large number of tools available, such as RedHat's open source tool virt-p2v,Microsoft Virtual Server Migration Toolkit.

P2V hot migration: avoid downtime in the migration. Most P2V tools also have a big limitation: physical machines are not available throughout the migration process. This tool is not optional in an environment where mission-critical operations are running or where there is a SLA (service level agreement). Fortunately, with the development of P2V technology, VMware vCenter Converter and Microsoft Hyper-V have been able to provide hot migration capabilities to avoid downtime. Currently, P2V hot migration is only available on Windows physical servers, and support for Linux will be added in the future.

Virtual machine to virtual machine migration (Virtual-to-Virtual)

V2V migration is about moving operating systems and data between virtual machines, taking into account differences at the host level and dealing with different virtual hardware. Virtual machines migrate from VMM on one physical machine to VMM on another physical machine, and the two VMM types can be the same or different. Such as VMware migrates to KVM, KVM migrates to KVM. You can move virtual machines from one VM Host system to another VM Host system in a number of ways.

V2V offline migration

Offline migration (offline migration): also known as regular migration, static migration. The virtual machine is paused before the migration, and if the storage is shared, only the system state is copied to the destination host, and finally the virtual machine state is rebuilt on the destination host to resume execution. "if you use local storage, you need to copy both the virtual machine image and state to the destination host." The migration process to this way needs to be shown to stop the running of the virtual machine. From the user's point of view, there is a clear period of time when the service is unavailable. This migration method is simple and easy, and is suitable for situations where service availability requirements are not strict.

V2V online migration

Online migration (online migration): also known as live migration (live migration). It means that while ensuring the normal operation of services on the virtual machine, the virtual machine is migrated between different physical hosts, and its logical steps are almost exactly the same as offline migration. The difference is that in order 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 the migration, the service runs on the source host. When the migration reaches a certain stage, the destination host already has the necessary resources to run the system. After a very short switch, the source host transfers control to the destination host, and the service continues to run on the destination host. For the service itself, because the switching time is very short and the user does not feel the interruption of the service, the migration process is transparent to the user. Online migration is suitable for scenarios that require high service availability.

At present, the mainstream online migration tools, such as VMotion,XEN xenMotion of VMware, require centralized sharing of external memory devices such as SAN (storage area network) and NAS (network-attached storage) between physical machines, so the migration of operating system memory execution state only needs to be considered in the migration, so as to obtain better migration performance.

In addition, in some situations where shared storage is not used, the online migration technology of storage blocks can be used to realize the online migration of V2V virtual machines. Compared with the online migration based on shared storage, the online migration of data blocks needs to migrate the virtual machine disk image and the system memory state at the same time, and the migration performance is reduced. However, in the environment of decentralized local storage, he can still use migration technology to transfer the computer environment, and ensure the availability of operating system services in the migration process, and expand the application scope of virtual machine online migration. V2V online migration technology eliminates the correlation between software and hardware, and is a powerful tool for software and hardware system upgrade, maintenance and other management operations.

V2V memory Migration Technology

For the migration of VM memory state, both XEN and KVM adopt the mainstream pre-copy (pre-copy) strategy. "after the migration begins, the source host VM is still running and the destination host VM has not been started." The migration sends the in-memory data from the source host VM to the destination host VM through a loop. The first round of the loop sends all the memory page data, and each subsequent round sends the dirty page memory dirty pages written by VM during the previous round of pre-copy. Until the time is ripe, the pre-copy cycle ends and enters the downtime copy phase, the source host is suspended and there are no more memory updates. The dirty pages in the last loop are transferred to the destination host VM. The pre-copy mechanism greatly reduces the amount of memory data that needs to be transferred in the downtime copy phase, thus greatly reducing the downtime.

However, for memory parts that are updated very fast, each cycle gets dirty, requiring repetition of pre-copy, which also results in a very large number of cycles and longer migration time. In view of this situation, the KVM virtual machine has established three principles: the centralization principle, the dirty pages in a cycle is less than or equal to 50; the non-proliferation principle, the transmission of dirty pages in a loop is less than the newly generated dirty pages; and the limited cycle principle, the number of cycles must be less than 30. In terms of implementation, the following measures have been taken:

Limited cycle: the number and effect of cycles are controlled, and the effect of each round of pre-copy is calculated. If the effect of pre-copy on reducing inconsistent memory is not significant, or if the number of cycles exceeds the upper limit, the cycle will be terminated and enter the downtime copy phase.

Set up a memory access monitoring module in the kernel of the migrated VM. During the in-memory pre-copy process, a process in VM is restricted to perform up to 40 memory writes during a scheduled run period. This measure directly limits the speed of memory dirty in the pre-copy process, at the cost of a certain limit on the running of the process on the VM.

The process of pre-copy online migration of KVM is described in detail:

The system verifies that the storage and network settings of the target server are correct, and pre-reserves the resources of the target server virtual machine.

Figure 1. Source and target server diagrams

While the virtual machine is still running on the source server, all memory images are copied to the target server in the first cycle. During this process, KVM still monitors for any changes in memory.

Figure 2. Memory mirror copy diagram

In a later loop, check to see if the memory has changed in the previous loop. If a change occurs, VMM will re-copy the changed memory page, the dirty pages, to the target server and overwrite the previous memory page. At this stage, VMM continues to monitor memory changes.

Figure 3. Perform memory replication with changes

VMM will continue this memory replication cycle. As the number of cycles increases, there is a significant reduction in the amount of dirty pages that needs to be replicated, and the time taken to copy becomes shorter, so there may not be enough time to change the memory. 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 paused.

Figure 4. The data that needs to be replicated is decreasing.

Copy the dirty-pages of the last cycle and the working status of the source system device to the destination server when both the source system and the destination system are down.

Figure 5. Replication of status information

The storage is then unlocked from the source system and locked on the target system. Start the target server and connect 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 migration of an operating system, applications and data from a virtual machine to the main hard disk of the physical machine, which is the reverse operation of P2V. It can migrate virtual machines to one or more physical machines at the same time. Although the basic requirement of virtualization is to integrate physical machines into virtual machines, this is not the only application of virtualization. For example, sometimes problems with applications on a virtual machine need to be verified on the physical machine to eliminate the impact of the virtual environment. In addition, configuring new workstations is a headache for IT managers, but virtualized applications can help him solve this problem. Configure the virtual machine, and then use hard disk cloning tools to copy data to workstation hardware, such as Symantec's Save & Restore (Ghost). However, this cloning method has two limitations: an image can only be used on a machine with the same hardware configuration, and if you want to save configuration changes, you can only redo a new image.

The migration of V2P can be done manually by determining the target physical environment, such as loading a specific hard disk into the virtual system, then installing the operating system, applications, and data in the virtual environment, and finally manually modifying the system configuration and drivers. This is a tedious and uncertain process, especially if the new environment contains a lot more different hardware than the old one. In order to simplify the operation, we can use special migration tools to complete some or all of the migration work automatically. Currently, PlateSpin Migrate and EMC HomeBase are supported for V2P conversion. Using such a tool makes the V2P conversion process easier and faster than using a third-party disk mirroring tool.

V2P migration method

The uncertainty of V2P leads to a shortage of automation tools, and there are mainly the following solutions:

VMware officially recommends the use of Ghost+sysprep for semi-automated migration.

Solution based on backup and recovery of the operating system. This scheme uses ready-made system backup and recovery tools, does not reflect the difference between virtual machines and physical machines, similar to P2P (Physical-to-Physical physical machine to physical machine migration). Note that the backup tool can restore the system to heterogeneous hardware platforms.

Solutions for open source tools. Suitable for Linux/Unix systems, use open source tools and scripts to migrate the system manually. This scheme is difficult and suitable for experienced administrators.

Go back to the top of the page

Technical difficulties of Linux system in Virtual Machine Migration

Usually we expect the migration of virtual machines to be fully or partially automated, but in fact, Linux systems may encounter some difficulties in the migration of P2V and V2V. This section lists what you need to pay attention to in Linux migration.

The disk partition name is hard-coded. When we do disk virtualization, we may use different types of virtual disk devices, which will lead to a change in disk names. For example, paravirtualized devices in Xen virtual machines use / dev/xvda while standard Linux paravirtualized devices use / dev/vda. There are scattered associations for / dev/hd* and / dev/sd* disk partition names in the Linux system to be migrated, such as in the / etc/fstab file, the boot initialization file system ramfs, and some boot startup script files that parse disk devices. The V2V migration tool needs to find and modify these associations across the disk. There is a simple way to avoid this: the mainstream file systems and swap partition types on Linux systems can use Lables or UUID as the partition name. This information is highly protected during migration, and the system should use this information carefully and never use the device as the partition name. In addition, the LVM partition name is device-independent and is not affected during the migration.

The change of network hardware equipment. When the system migrates, the network equipment is likely to change. For example, the transformation of virtual network devices and physical network devices or the transformation between different types of network devices. But their MAC address hasn't changed. The MAC address is assigned by IEEE to the physical device manufacturer, and the two physical devices will not have the same MAC address; however, this may happen to virtual network devices. So when doing virtual machine migration, you must record the MAC address of each network device to ensure the corresponding relationship between the MAC address and the network device.

The kernel does not support some virtual devices. Some Linux distributions do not have drivers for virtio virtual devices, either because the Linux distribution was released earlier than the virtual device; or because the driver for the virtual device is closed-source; or it is removed at system compilation time. As a result, sometimes we need a completely different kernel (as was the case in earlier versions of Xen). In any case, installing a new kernel on the client and making it bootable is a big risk, and it's best to avoid doing so.

Xwindow needs to be reconfigured. Like disks and network devices, the display devices will change after the system migration. Ideally, Xwindow will automatically handle this change, detect all display devices and use the first device it discovers. But that doesn't mean that all Linux distributions work this way.

Changes in the network environment. Static IP address and static DNS resolution is a hassle in virtual machine migration. Although not required, it is best to configure the system to automatically obtain all network configuration information from the DHCP server.

At this point, I believe you have a deeper understanding of "how to achieve virtual machine migration technology". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.