Citrix Server Virtualization-XenMotion of Xenserver Virtual Machine
XenMotion is a feature of XenServer that can migrate running virtual machines from one XenServer host to another without the risk of downtime. The main purpose of XenMotion is to make the end user unaware that the application program has been interrupted for a short time when a certain server is undergoing planned maintenance, so that the entire service process is normal and smooth. XenMotion does not just migrate when the server fails or fails to work properly. XenMotion combined with Xen Workload Balancing, when the server is overloaded, it will migrate the upper part of the virtual machine, including the running application, to the alternate server intact. Therefore, XenMotion can reasonably allocate the workload of XenServer in the resource pool, greatly improving resource utilization and work efficiency. XenMotion works with resource pools. The function of the resource pool is to collect multiple similar XenServerEnterprise servers connected to each other in a set of resources, so that the virtual machines connected to it can share remote storage and network resources.
For the same resource pool, it allows real-time migration of virtual machines in it. When the resource pool and shared storage work together, as long as the capacity of the XenServer host is large enough, then the virtual machine can be started on these hosts at will. This creates certain conditions for XenMotion. Although there is no clear regulation, each resource pool can generally support up to 16 XenServer hosts. In fact, XenMotion migration cannot achieve 100% zero downtime, and the exact downtime is generally 100 to 150 milliseconds. However, due to the short time interval, the virtual machine running on the server is not aware of it, and there will be no interruption. Most of this extremely short downtime is spent transferring the network switching equipment to a new port.
XenMotion system requirements:
1. The processors in XenServer must have the same type. Although XenMotion allows the memory, storage controller and network controller of each system to be different, the processors must be of the same type. In addition to the hard and fast rules of the type, it also allows some subtle differences (such as the operating speed of the CPU). For example, for servers in the same resource pool, the same series of processors must be used.
2. At least two XenServer Enterprise servers must be in operation in the resource pool.
3. The memory type of the virtual machine. The virtual machine must be stored in a remote shared memory. For example, it is connected to a storage based on the network file system NFS (Network File System) or iSCSI (starting software through iSCSI). In addition, if a XenServer host in the resource pool is removed, the virtual machine originally running on it is not deleted, but still exists in the database, which will not cause data loss, and for other XenServer hosts The members are visible. However, these virtual machines are in a disabled state, and only their virtual disks can be shared by other XenServers in the resource pool when they are connected to the shared server. Therefore, in order to improve resource utilization, it is best to add the local disk to the shared memory when the shared memory is created. (Migration without shared storage is not included here)
4. Network bandwidth requirements: Gigabit Ethernet is recommended.
How XenMotion works: (pre-copy migration)
1. The system verifies whether the storage and network settings of the target server are correct, and reserves the resources of the target server virtual machine.
2. When the virtual machine is still running on the source server, copy the memory image to the target server. During this process, XenServer will still monitor any changes in memory.
3. Check whether the memory has changed since the memory mirroring is copied to the target server during this stage.
4. If there is a change, XenServer will re-copy the changed memory to the target server and overwrite the previous memory. At this stage, Xen will continue to monitor changes in memory.
5. XenServer will continue such memory copy operations. As the number of copies increases, the data that needs to be copied will be significantly reduced, and the time spent in copying will gradually become shorter, so there may not be enough time for the memory to change. Finally, when the difference between the source server and the target server can be ignored without timing, the memory copy operation will end.
6. After the memory copy is completed, after copying the working status of the machine to the target server, the source server stops working. Then, unlock the storage from the source system and lock it on the target system. Start the target server, connect to storage resources and network resources, and clear the resources on the source server at the same time.