Xen Virtual Machine Migration Technology

I. Preparations for Migration Before migration, you have some preparation work to do, mainly for the target host and source host and their network. The following sections describe them respectively. First, both the source and target hosts must run the xen and xend daemon processes. Make sure that the target host has sufficient disk space, memory capacity, and resources for running the migrated domain. In addition, the source and destination hosts must have the same architecture and virtualization extensions, for example, if the source host uses a x86-64 architecture with virtualization extensions, this is also required for the target host. This is done to prevent domain migration from working properly due to the mismatch between the kernel and the instruction set used by the user library. In terms of network, the source host and the target host must also be located in the same subnet. During domain migration, if the destination node is located on different subnets, the migration will fail because the Mac and IP addresses of the domain will also be migrated. If you run the firewall, you may need to create the corresponding iptables rules to allow inbound connections. In addition, during the migration, the xend daemon will stop the running of the domain on the source host, copy it to the target host, and then restart the domain. By default, the xend daemon receives migration requests from the local machine. To make the migration target accept a migration request from a remote host, you must modify the xen-relocation-hosts-allow parameter in the/etc/xend-config.sxp file for the target host. Because authentication is not provided, you must restrict the hosts that can be migrated for security reasons. Next, we will introduce the first method for domain migration: storage reduction. Ii. Storage restoration migration method The storage reduction process is as follows: first, save the current running status of a domain to a file on the hard disk. Then, xend uses the file to restore the original status of the domain. In fact, this is very similar to the sleep function of a portable computer: When sleep, the portable computer will save the hard disk state image, and then automatically shut down. When you exit sleep, it uses the saved disk image to restore the system to its previous running state. This section describes how to save a running domain as a file, and then use it to restore the domain to the previous working state, it can be on the same server or an external xen server. However, before saving the domain as an image file, you must make sufficient disk space to store the file. Procedure Now, we will introduce the specific steps for migrating domain on the xen server. Specifically, create a Debian domain and save its status to a file. The file will be used to restore the Debian domain. 1. Create Debian guest domain: # XM create debian_etch_domu.cfg-C 2. Check whether the domain is running normally. Because we provide the-C parameter to the XM command above, this will start the client domain in the current console. However, to check whether the domain has been started, you must use another console session. 3. We will save the current status of this domain to the/xen-saved-images directory. Of course, we can also save it to another directory you selected: #XM save 1/xen-saved-images/etch. Save source VM is disabled 4. The saved domain will be deleted from the list of currently running domains. We can use the XM command to list the currently running domain to see if it has been deleted. 5. Restore the saved domain from a file: #XM restore/xen-saved-images/etch. Save 6. Run the XM command again. We can see that the restored domain is back to the current domain list. Description When saving the running status of the domain in work to a disk file, the file is not encrypted in any form. Therefore, malicious users only need to be able to access the directory of the saved image file, these images can be manipulated. Therefore, it is especially important to ensure the security of access to the folders that store these images. The running status of a domain is the snapshot or image of the domain at the time of storage. The information and status of all running processes are stored in this file. When you view this file, you will find that this is a huge binary file, and its size is equal to the amount of memory used when the domain is saved. Because xen domain usually runs some enterprise applicationsProgramTherefore, this file is usually about several GB. Therefore, you must ensure that you have enough storage space to store this file. Although this example keeps the status above a hard disk file, you can also store this file on a large enough network folder or even a USB flash disk. It is good to save domain to the USB flash drive so that it can be carried with you and restored on different servers when necessary. We can use the XM command and the restore option to restore the stored domain. This will start the domain again and restore it to the Saved state. When using the storage reduction method, you must note that the restored domain ID is different from the domain ID at the storage time. Therefore, when you use XM to view the restored domain, be sure to pay attention to the ID changes. Although the domain is restored to the original State (the State at the time of storage), it cannot be automatically connected to the console of the domain. On the contrary, we must explicitly run the XM command to connect to the console. Although this method is easy to migrate domains, you must note that the domain has been deleted from the active domain when it is saved, therefore, services running on the domain cannot be used or accessed. If you cannot accept this type of service interruption, consider using the dynamic Migration Feature of xen described in the next section. Iii. dynamic migration The storage reduction method for domain migration on the xen server is described above. Although this method is simple, you still cannot use this migration method if your server has key services that are not interrupted or you want to minimize the service interruption time. At this time, xen also provides us with a powerful function that will come in handy. It is the dynamic migration method. It allows the domain to be migrated to another xen server at the minimum service interruption during running. Xen dynamic migration has many advantages. The main advantages are listed as follows: · The dynamic migration of xen along with high availability solutions such as heartbeat can bring us a system that never breaks down. The latest enterprise SuSE Linux server and Red Hat Enterprise Linux also use xen to provide various high availability solutions. You can easily meet the demanding requirements of various services and ensure that all key business services are not interrupted. · It enables us to maintain the physical servers that are hosted on virtual machines in the "cure before disease" mode. You can monitor the server and immediately resolve potential and suspicious problems by transferring the system. · It makes it possible to achieve load balancing among multiple servers, so that we can make better use of all the computing resources in the enterprise and make the best use of them. Note that the open-source xen version does not support Automatic Dynamic migration when a fault is detected on dom0. · It makes it easier to add computing capabilities to system configurations as needed. · You can change the hardware as needed without interrupting the services running on the hardware. It is not enough to know the benefits of dynamic migration. Now we will introduce the specific usage methods. Requirements: 1. Both of them must run the xen and xend daemon processes. 2. Make sure that the target host has sufficient disk space, memory capacity, and resources. 3. The source host and target host must also be on the same subnet 4. The source host and target host must also have the same architecture and virtualization extension configuration file: [Root @ host1 ~] # VI /Etc/xen/xend-config.sxp (Xend-relocation-server yes) (Xend-relocation-port 8002) (Xend-relocation-address '') (Xend-relocation-hosts-Allow '') Run:/etc/init. d/xend restart. Operations First, we will introduce the servers involved in dynamic migration. They are: · Hosta: a Linux NFS server that provides storage space for xendomain through the network. · Hostb: An xen host server that uses the NFS Exported Directory to run a client domain: Ubuntu Fuwa. · Hostc: An xen host server, which is the migration destination of the client domain from the hostb server, that is, UBUNTU Fuwa. Shows us the specific configuration   Swap dynamic migration requires shared storage. In reality, except for the requirements in section 1, the minimum requirement for network speed is 100 MB. To share memory, we will create an NFS server on the top xen host. The domain to be migrated uses the shared storage space on the NFS server. ⒉ Edit the/etc/exports file and add the following line to export the storage directory: #/Xen-storage * (R, sync, no_root_squash) Supervisor saves the file and restarts the NFS server. Add the NFS server to the server's service and set it to run when the system is restarted: # Service NFS startchkconfig NFS on ⒋ We will create two xen servers and let them use the storage provided by the NFS server. To mount the export directory, you need to add the installation points for both xen servers: # Mount hostb:/xen-storage #-Mount hostc:/xen-storage ⒌ Modify the xend configuration file to allow dynamic migration. Edit the/etc/xen/xend-config.sxp file and make sure the following two lines are not commented out: (Xend-relocation-port 8002) (Xend-relocation-address '') It starts the xen daemon to listen for and respond to various requests for dynamic migration. Supervisor creates an xen domain running on the NFS server memory and starts the client domain on hostb. And make the client domain use the following Configuration: Cat>/home/pchaganti/xen-images/ubuntu_fuwa_nfs_domu.cfg <"EOF" Kernel = "/boot/vmlinuz-2.6.16.38-xenU" Memory = 256 Name = "ubuntu_fuwa_nfs_domu" VIF = ['IP = 192.168.1.111'] Nfs_server = '192. 168.1.67' Nfs_root = '/xen-store' Root = '/dev/nfs' EOF Now, we have a client domain running on hostb, which uses the NFS Exported Directory for storage. We can run the following command on hostb to check whether the domain runs normally: Then, we will dynamically migrate the client domain to the hostc server, which may take several minutes. If the migration fails, a message indicating a failure is displayed on the console. #XM migrate -- live ubuntu_fuwa_nfs_domu hostc The running domain is dynamically migrated to another xen server! Now, run the XM command to display the domain currently running on the hostb and hostc servers. You will find that the migrated domain can only be found on the hostc server, the shadow of the migrated domain cannot be found in the running domain on the hostb server. Description Dynamic migration is the process of moving a virtual machine from one physical host to another when it is "electrified. This process does not significantly affect the end user, so that the administrator can perform offline repair or upgrade on the physical server without affecting the normal use of the user. You must modify the default xend configuration file to change the running location of the domain. In addition, to make the modification take effect on the host, you must restart the host where the xen server is located. Modify the following configurations: · Xend-relocation-server: this flag is used to enable/cancel server migration. By default, this flag is set to no, that is, the server location cannot be changed. During the migration, the domain virtual memory will become the original form without any encryption. Therefore, be careful when enabling this option on untrusted networks. · Xend-relocation-Port: The xend daemon migrates data through this port. The default value of this port is 8002. In addition, there are two parameters that do not need to be modified. when migrating data in an enterprise deployment environment, pay attention to the following: · Xend-relocation-Address: this flag limits domain migration to a specific interface. The specified address is the interface address for listening to the local connection used for domain migration. This flag is used only when the xend-relocation-server parameter is enabled. · Xend-relocation-hosts-Allow: indicates the host that allows communication with the migration port. The value is a sequence of Regular Expressions separated by spaces. If this value is blank, all connections are allowed. Otherwise, the value must match either an IP address or a full domain name. In fact, the migration process from hostb to hostc is divided into multiple stages, as shown below: Phase 1: before migration. Fuwa domain runs on hostb and is an active domain. Phase 2: Reservation. Issue a migration request on hostb and check and confirm the resources available on hostc. Then, xend prepares a VM container on the hostc according to the required size. If xend cannot obtain the required resources on hostc, it will end. The domain still runs on hostb, just as nothing happened. This migration attempt gave up. Stage 3: duplicate pre-copy. First, all the memory pages are transmitted from hostb to hostc, and then the pages that have changed during the previous transfer continue. In the end, all pages are copied to hostc. Until the third stage, the Fuwa domain still runs normally on hostc. Stage 4: Stop and copy. The domain running on hostb is suspended, and all its network traffic is redirected to hostc. After the end of this phase, in addition to a suspended domain on hostb, hostb also has a copy of the suspended domain. In this case, the domain suspended on hostb can also be used as the original copy. In case of this failure, it can resume running on hostb. Stage 5: delivery. If no error or failure occurs in this step, hostc will send an indication to hostb that it already has a domain image that is exactly the same as that of hostb. Now, hostb will delete the domain from its xen server. From then on, hostc will become the first host in this domain. During the period from stage 4 to Phase 5, the Fuwa domain is in the stopped state. Stage 6: activation. Activate the migrated domain on hostc. All device drivers in the domain are now associated with the new machine. So far, Fuwa domain has been revived on hostc. These steps are all performed behind the scenes. It is this series of obscure operations that make the migration so stable and seamless! Iv. Conclusion This chapter describes two methods for migrating xen client domain: storage restoration and dynamic migration. The previous method is similar to the deep sleep of a portable computer. It first stores the captured domain running status as an image on the disk, and then restores the domain with the image. The latter method dynamically changes the running position of the domain in the running state with the least interruption and downtime. By using these two migration methods together, the efficiency of virtualization technology can be improved.