How to implement online hot migration of KVM virtual machines (picture and text)

1. KVM virtual machine migration method and issues that need attention

There are two ways to migrate KVM virtual machines:
1. Static migration (cold migration): For cold migration, when the virtual machine is turned off, copy the virtual machine's disk file and .xml configuration file (these two files constitute a virtual machine) to the target host to be migrated, and then use the "virsh define *.xml" command on the target host to redefine the virtual machine.
2. Dynamic migration (hot migration): Hot migration is more commonly used. Usually, some services are running on this server, and these services are not allowed to be interrupted, so hot migration is needed. This blog post will describe the steps of hot migration in detail.

1. Cold Migration

Usually the directory where we store virtual machine disks is mounted on a disk with an nfs file system, and this disk is usually an LVM file system. Therefore, when cold migration is required, just mount the nfs file system on the target host, and you can see the disk file of the virtual machine to be migrated, which usually ends with .qcow2 or .raw. Then, just send the .xml configuration file of the virtual machine to the target server, and then redefine it. You can view the migrated virtual machine through the "virsh list --all" command.

2. Hot migration

If the source host and the destination host share a storage system, it is only necessary to send the client's vCPU execution state, memory contents, and virtual machine device states to the destination host via the network. Otherwise, the client's disk storage needs to be sent to the destination host. A shared storage system means that the image file directories of the source and destination virtual machines are on a shared storage.

When based on a shared storage system, the specific process of KVM dynamic migration is as follows:

1. When the migration starts, the client is still running on the host, and at the same time, the client's memory pages are transferred to the destination host.
2. QEMU/KVM will monitor and record any modifications to all transferred internal pages during the migration process, and will start transferring the changes to the memory pages in the previous process after all memory pages have been transferred.
3. QEMU/KVM will estimate the transfer speed during the migration process. When the remaining memory data can be transferred within a settable time period (30 milliseconds by default), QEMU/KVM will shut down the client on the source host and transfer the remaining data to the destination host. Finally, the transferred memory content will restore the client's running status on the destination host.
4. At this point, the dynamic migration operation of KVM is completed. The migrated client is as consistent as possible with the client before migration, unless some configurations are missing on the destination host, such as a bridge. Note that when the memory usage in the client is very high and is frequently modified, and the speed at which the data in the memory is constantly modified is faster than the memory speed that KVM can transmit, the dynamic migration process cannot be completed and only static migration can be performed.

3. Migration considerations

Whether it is cold migration or hot migration, the precautions are mostly similar.

The requirements for the target server before migration are as follows:

• It is best to migrate servers with the same CPU brand;
• 64-bit can only be migrated between 64-bit hosts, and 32-bit can migrate between 32-bit and 64-bit hosts;
• The names of the virtual machines in the host machine cannot conflict;
• The destination host and the source host have the same software configuration as much as possible, such as the same bridge network card, resource pool, etc.
• The settings of cat /proc/cpuinfo |grep nx on the two migrated hosts are the same. NX, the full name of which is "No eXecute", means "no eXecute". It is a technology applied to the CPU to separate the memory area into areas for storing processor instruction sets only or for data only. Any memory using NX technology is represented as data-only, so the processor's instruction set cannot be stored in these areas. This technology can prevent most buffer overflows, that is, some malicious programs place their own malicious instruction sets in the data storage area of ​​other programs and run them, thereby controlling the entire computer.

summary:

1. Static migration

• Copy the image file and virtual machine configuration file;
• Redefine this virtual machine.

2. Dynamic Migration

• Create shared storage;
• Mount the shared storage on both machines (manually; use resource pool);
• Start dynamic migration;
• Create a configuration file for the migrated virtual machine;
• Redefine the virtual machine.

2. KVM virtual machine hot migration configuration example

1. Environmental preparation:

My environment here is as follows:

Three Linux servers, two of which are KVM servers, with IP addresses 192.168.20.2 and 192.168.20.3. One is an NFS server with an IP address of 192.168.20.4, used for shared storage (the three servers must be able to ping each other).
Both KVM virtual machines must have a KVM environment.

I have a ready-made KVM environment, so I won’t show it here. If you don’t have a KVM environment, you can refer to the blog post: Basic management of KVM virtualization to set it up (it’s very simple, just install some packages with yum and start the “libvirtd” service, you may need to restart the server).

2. Configure NFS shared storage

The nfs server 192.168.20.4 is configured as follows:

[root@nfs ~]# yum -y install nfs-utils rpcbind #Install the required software packages[root@localhost ~]# systemctl enable nfs #Set NFS to start automatically[root@localhost ~]# systemctl enable rpcbind #Set rpcbind to start automatically[root@nfs ~]# mkdir -p /nfsshare #Create a directory to be shared[root@nfs ~]# vim /etc/exports #Edit the NFS configuration file, the default is empty/nfsshare *(rw,sync,no_root_squash)
#The first column represents the shared directory. #The asterisk in the second column means that all network access is allowed;
#rw represents read and write permissions; sync represents synchronous writing to disk;
#no_root_squash means that the current client is granted local root permissions when accessing as root # (the default is root_squash, which will be treated as nfsnobody user). If no_root_squash is added,
#It may result in downgrading your privileges and making it impossible to read and write (wr).
[root@nfs ~]# systemctl restart rpcbind #Start the service[root@nfs ~]# systemctl restart nfs #Start the service[root@nfs ~]# netstat -anpt | grep rpc #Confirm that the service has been started[root@nfs ~]# showmount -e #View the shared directory of this machineExport list for nfs:
/nfsshare *
[root@nfs ~]# firewall-cmd --add-service=rpc-bind --permanent 
[root@nfs ~]# firewall-cmd --add-service=nfs --permanent 
[root@nfs ~]# firewall-cmd --add-service=mountd --permanent 
[root@nfs ~]# systemctl restart firewalld #Restart the firewall to make the configuration take effect

The NFS server configuration is now complete! ! !

The migration operation here relies on the desktop graphical environment. If you need to use command migration, you can download this document for reference. I have not studied the use of command migration.

The two KVM servers are configured as follows (both KVM hosts need to be configured as follows):

1. Install the rpcbind software package and start the rpcbind service. In order to use the showmount query tool, install nfs-utils as well:

[root@localhost ~]# yum -y install nfs-utils rpcbind 
[root@localhost ~]# systemctl enable rpcbind
[root@localhost ~]# systemctl start rpcbind
[root@kvm ~]# showmount -e 192.168.20.4 #Query the directory shared by the nfs server Export list for 192.168.20.4:
/nfsshare *
[root@kvm ~]# mount -t nfs 192.168.20.4:/nfsshare /kvm/disk/ #Mount [root@kvm ~]# df -hT /kvm/disk/
File system type Capacity Used Available Used% Mount point 192.168.20.4:/nfsshare nfs4 50G 33M 50G 1% /kvm/disk
#Write a test file on one of the servers to see if it can be seen on other servers [root@kvm1 ~]# touch /kvm/disk/test #Create a test file on one of the kvm servers [root@kvm2 ~]# ls /kvm/disk #Ensure that test can also be seen in the directory of the second kvm server

At this point, it is ensured that the directories used by the two kvm servers are stored on the same disk (Note: the directory paths for mounting the nfs file system of the two kvm virtual machines must be consistent. Here, both kvm virtual machines are mounted to the /kvm/disk/ directory, otherwise errors will occur in subsequent operations).

3. Create storage volumes on two kvm servers:

[root@kvm1 ~]# virt-manager #Open the virtual machine console 

In the following dialog box, the target path is "/kvm/disk" of the KVM machine, the host name is the IP address of the nfs server, and the source path is the directory shared by the nfs server.

The above operations also need to be performed on the second KVM. It is best to define the same storage pool name. In order to avoid unnecessary trouble.

3. Create a new virtual machine on kvm1 for migration testing

:

Upload a centos iso system file by yourself. Here you need to specify the iso file to be installed:

At this point, you can install the virtual machine normally.

4. Configure the newly created virtual machine network to Bridge mode, and you can ping the external network

The following operations are mainly to simulate hot migration of virtual machines in providing services to public network users.

1) The operations of kvm1 are as follows:

[root@kvm ~]# systemctl stop NetworkManager #Stop this service[root@kvm ~]# virsh iface-bridge ens33 br0 #When executing this command, if the following message is prompted, don't worry, because it already exists. Use the additional device br0 to generate bridge ens33. Failed to start the bridge interface br0
[root@kvm ~]# ls /etc/sysconfig/network-scripts/ | grep br0  
ifcfg-br0 #Make sure this file exists[root@kvm ~]# virsh destroy centos7.0 #Close the newly created virtual machine domain centos7.0 is deleted[root@kvm ~]# virsh edit centos7.0 #Edit the virtual machine configuration file and locate the interface
<interface type='bridge'> #Change this to bridge
 <mac address='52:54:00:a9:cc:5f'/> #Delete the Mac address line <source bridge='br0'/> #Change this to this #Save and exit [root@kvm1 ~]# virsh start centos7.0 
Domain centos7.0 has started

After starting the virtual machine, configure the virtual machine's network card configuration file. The default network card file is ifcfg-eth0:

Restart the network service and confirm the IP address:

Now you can execute the "ping www.baidu.com" command on the virtual machine to enable it to continuously ping the public network.

2) The kvm2 operation is as follows:

[root@kvm ~]# systemctl stop NetworkManager #Stop this service[root@kvm ~]# virsh iface-bridge ens33 br0 #When executing this command, if the following message is prompted, don't worry, because it already exists. Use the additional device br0 to generate bridge ens33. Failed to start the bridge interface br0
[root@kvm ~]# ls /etc/sysconfig/network-scripts/ | grep br0  
ifcfg-br0 #Make sure this file exists. #Since kvm2 does not have a virtual machine, you only need to change the network to bridge mode.
#The above configuration is to prevent the virtual machine from being unable to communicate with the public network after being migrated to this server.

5. Start preparing for hot migration of the newly built centos 7

1) Perform the following operations on the kvm1 server:

[root@kvm1 ~]# virt-manager #Open the virtual machine console 

Fill in the form as follows, and click "Connect" after completing:

You will be prompted to install the following software packages:

To install:

[root@kvm1 ~]# yum -y install openssh-askpass 

According to the dialog box that pops up, enter "yes":

Enter the target host's root password:

6. Start hot migration

Wait for the migration to complete, which is a quick process:

Migration Complete:

Now go to the target kvm server and open the newly migrated virtual machine (you will find that the ping command is still continuing and has never been interrupted):

You can use "virsh list --all" on the two kvm servers to confirm whether the virtual machine has been migrated to the second kvm server.

The above is the full content of this article. I hope it will be helpful for everyone’s study. I also hope that everyone will support 123WORDPRESS.COM.