Shulou(Shulou.com)06/02 Report--

Blog outline:

1. Ways to migrate KVM virtual machines

Second, realize the static migration of KVM virtual machine

Third, realize the dynamic migration of KVM virtual machine.

1. Ways to migrate KVM virtual machines

There are two types of KVM virtual machine migrations in KVM platforms:

(1) Cold migration (static migration)

The directory where we store the virtual machine disk is the disk of a nfs file system. During the cold migration, as long as the nfs file system is mounted on the target host, you can see the disk file of the virtual machine to be migrated, usually ending in .qcow2 or .raw. Then, you just need to send the .xml configuration file of the virtual machine to the target server, and then redefine the migrated virtual machine!

(2) Hot migration (dynamic migration)

If the source host and the destination host share the storage system, you only need to send the client's vCPU execution status, the contents in memory, and the status of the virtual device to the destination host over the network. Otherwise, you also need to send the client's disk storage to the destination host. A shared storage system means that the mirror file directories of the source and destination virtual machines are on a shared storage.

Based on the shared storage system, the specific process of dynamic migration:

(1) at the beginning of the migration, the client is still running on the host, while the client's memory page is transferred to the destination host.

(2) QEMU/KVM will monitor and record any modifications to all memory pages that have been transferred during the migration, and begin to transfer changes to memory pages in the previous process as soon as all memory pages have been transferred.

(3) QEMU/KVM estimates the transfer speed during the migration. When the remaining amount of memory data can be transferred within a set time period (default is 30 milliseconds), QEMU/KVM will shut down the client on the source host, then transfer the remaining amount of data to the destination host, and the final transferred memory content will restore the running state of the client on the destination host.

(4) at this point, the dynamic migration operation of KVM is complete! The migrated client is as consistent as it was before the migration, unless some configuration, such as a bridge, is missing on the destination host. Note that when the memory usage in the client is very large and frequently modified, and the data in memory is constantly modified faster than the memory speed that KVM can transfer, the process of dynamic migration cannot be completed, and it can only be moved statically.

(3) points for attention

(1) the CPU brand of the migrated server should be consistent.

(2) 64-bit can only be migrated between 64-bit hosts, while 32-bit can migrate 32-bit and 64-bit hosts.

(3) the names of virtual machines in the host cannot conflict.

(4) the software configurations of the destination host and the source host are the same as possible.

(4) Summary

Static migration:

(1) copy image files and virtual machine configuration files

(2) just redefine the virtual machine!

Dynamic migration:

(1) create shared storage

(2) two KVM hosts mount shared storage

(3) start dynamic migration

(4) create a migrated virtual configuration file

(5) redefine the virtual machine

2. Realize the static migration of KVM virtual machines (1) the environment requires a KVM service to obtain the A:IP address: 192.168.1.7, of which one is a KVM virtual machine of web01; the B:IP address of a KVM server is 192.168.1.8; (2) implementation steps

Operation of KVM Server A:

Due to the experimental environment, for the sake of simplicity, we will skip it here. If you are interested, you can create your own files or directories for testing!

[root@localhost ~] # systemctl stop firewalld [root@localhost ~] # setenforce 0 lsmod / experimental environment, simply disable the firewall and SElinux [root@localhost ~] # lsmod | grep kvm / confirm that the virtual machine supports the kvm environment kvm_intel 174841 0 kvm 578518 1 kvm_intelirqbypass 13503 1 kvm [root@localhost ~] # virsh list-- all / / confirm the existence of the virtual machine And it is the shutdown status Id name status-web01 shutdown

Operation of KVM Server B:

[root@localhost ~] # systemctl stop firewalld [root@localhost ~] # setenforce 0ram / Experimental Environment For simplicity, turn off the firewall and SElinux [root@localhost ~] # lsmod | grep kvm / confirm that the virtual machine supports the kvm environment kvm_intel 174841 0 kvm 578518 1 kvm_intelirqbypass 13503 1 kvm [root@localhost ~] # virsh list-- all / / verify that there is no kvm virtual machine Id name State-[root@localhost ~] # scp 192.168.1.7:/etc/libvirt/qemu/web01.xml / etc/libvirt/qemu/web01.xml// copy the virtual machine configuration file of KVM host A [root@localhost ~] # scp 192.168.1. 7:/kvm/disk/web01.raw / kvm/disk/web01.raw// copy the virtual machine disk file of the KVM host [root@localhost] # cd / etc/libvirt/qemu/ [root@localhost qemu] # virsh define web01.xml definition domain web01 (from web01.xml) / / generate a virtual machine according to the configuration file [root@localhost qemu] # virsh start web01 / / start the virtual machine for testing domain web01 has started [root@localhost qemu] # Virsh list-- all Id name status-1 web01 running// can be booted normally means there is no problem Just do the test yourself!

Static migration completed!

Static migration actually has nothing to say, to put it bluntly, it is almost the same as cloning!

3. To realize the dynamic migration of KVM virtual machines (1) the environment requires a NFS server: IP address: 192.168.1.6; a KVM server A:IP address: 192.168.1.7; a KVM server B:IP address: 192.168.1.8

Note: the KVM host does not require a KVM virtual machine!

(2) implementation steps

Operations of the NFS server:

[root@localhost ~] # systemctl stop firewalld [root@localhost ~] # setenforce 0Compact / experimental environment, simply turn off the firewall and SElinux [root@localhost ~] # yum-y install nfs-utils rpcbind// install the software required by NFS [root@localhost ~] # mkdir / kvmshare / / create a shared directory [root@localhost ~] # echo "/ kvmshare * (rw,sync,no_root_squash)" > > / etc/exports// configure permissions for the shared directory Shared user / / no_root_squash: enable it to obtain the root permission of the NFS server [root@localhost ~] # systemctl start rpcbind / / start the remote transmission control service [root@localhost ~] # systemctl start nfs / / start the NFS sharing service

Two KVM to verify:

[root@localhost] # showmount-e 192.168.1.6Export list for 192.168.1.6:/kvmshare *

Operation of KVM Server A:

[root@localhost ~] # systemctl stop firewalld [root@localhost ~] # setenforce 0ram / Experimental Environment For simplicity, turn off the firewall and SElinux [root@localhost ~] # lsmod | grep kvm / confirm that the virtual machine supports the kvm environment kvm_intel 174841 0 kvm 578518 1 kvm_intelirqbypass 13503 1 kvm [root@localhost ~] # virsh list-- all / / verify that there is no kvm virtual machine Id name State-[root@localhost ~] # virt-manager / / Open the graphical interface to manage KVM

Preferred to create a storage pool, as shown in the figure:

Next, create a storage volume based on the storage pool, as shown in the figure:

Next, create a virtual machine, as shown in the figure:

Next, create a suitable virtual machine according to your actual situation!

After the virtual machine is restarted, shut it down and configure it as a bridging network as follows:

[root@localhost] # virsh destroy centos7.0 / / Experimental environment, forced shutdown is adopted. However, it is not recommended to use domain centos7.0 to be deleted [root@localhost ~] # systemctl stop NetworkManager / / to close the network management tool [root@localhost ~] # virsh iface-bridge ens33 br0 / / to generate br0 using ens33 to generate bridging ens33 using additional device br0 failed / / prompt failure does not matter. Bridge interface br0 [root@localhost ~] # virsh edit centos7.0 / / use "edit" Command to edit the configuration file of the virtual machine and navigate to interface Modify the content: change it to bridge and change it to bridge='br0' [root@localhost ~] # virsh start centos7.0 / / start the centos7 virtual machine

Operation of KVM Server B:

[root@localhost ~] # systemctl stop firewalld [root@localhost ~] # setenforce 0ram / Experimental Environment For simplicity, turn off the firewall and SElinux [root@localhost ~] # lsmod | grep kvm / confirm that the virtual machine supports the kvm environment kvm_intel 174841 0 kvm 578518 1 kvm_intelirqbypass 13503 1 kvm [root@localhost ~] # virsh list-- all / / verify that there is no kvm virtual machine Id name State-[root@localhost ~] # virt-manager / / Open the graphical interface to manage KVM

Create a storage pool in exactly the same way as KVM server A, as shown below:

Generate a bridge Nic br0 to facilitate hot migration later, as follows:

[root@localhost ~] # systemctl stop NetworkManager [root@localhost ~] # virsh iface-bridge ens33 br0 using additional device br0 to generate bridging ens33 failed to start bridging interface br0// because there is no virtual machine locally, so you just need to generate a bridging network card! [root@localhost ~] # hostname kvmB [root@localhost ~] # su-Last login: December 4 20:05:59 CST 2019 modify the hostname from the 192.168.1.253pts/1 [root@kvmB ~] # / / otherwise an error may occur later

KVM server A does the following:

If the following error occurs, as shown in the figure:

That's because the password-asking software package required to connect using the SSH protocol is not installed!

The next operation needs to be performed on both KVM:

[root@localhost ~] # yum-y install openssh-askpass [root@kvmB ~] # yum-y install openssh-askpass / / install the dependent package that asks for a password. Note that both KVM servers need to be installed.

After the installation is complete, connect again on KVM server A:

Open the KVM virtual machine to access Baidu all the time, as shown in the figure:

Next, perform a hot migration operation, as shown in the figure:

Check whether there is a terminal phenomenon in the access of the KVM virtual machine, as shown in the figure:

According to the display results, it is found that the access is not interrupted, so the dynamic migration is successful!

-this is the end of this article. Thank you for reading-

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.