OpenStack Virtual machine cold migration and thermal migration

One, virtual machine Migration Analysis

OPENSTACVK Virtual machine migration is divided into two ways: cold migration and thermal migration.

1.1 Cold Migration :

Cold Migration (Cold migration) , also called static migration. power off the virtual machine for migration. With cold migration, you can choose to move the associated disk from one data store to another.

benefit: The virtual machine does not need to be on shared storage and the data loss rate is small.

Disadvantage: Need to power off, business interruption.

1.2 Thermal Migration:

Thermal Migration ( Live migration), also known as dynamic migration, live migration, virtual machine save / restore, is usually the entire virtual machine running state intact, and can be quickly restored to the original hardware platform or even on different hardware platforms. After recovery, the virtual machine still runs smoothly and the user does not perceive any differences.

Benefits: Maintenance upgrades of software and hardware systems that do not affect users ' critical services, improve service availability and satisfaction of the user.

Cons: The process is non-disruptive and complex to operate.

1.3 The virtual machine migration scenario:

Scenario 1: Maintenance of the physical machine hardware system, fault repair and upgrade (upgrade), but the virtual machine running on this physical machine cannot be shut down because the user's important service is running on it.

Scenario 2: Physical machine software system upgrade, patching (patch), in order to not affect the running of the virtual machine, before upgrading and patching, the need to move the virtual machine to another physical machine.

Scenario 3: The load on a physical machine is too heavy and some virtual machines need to be reduced to free up resources.

Scenario 4: in a cross-domain environment, there are too many virtual machines on the physical machines in some domains, and there are too few virtual machines on the physical machines in some domains to balance the resources.

1.4 Data processing in virtual machine migrations

The migration of virtual machines is the transfer of data, and if there is no shared storage between compute nodes, the data to be transferred consists of two parts:

1. static data: The image file of the virtual machine stored locally, including the back-end mirror (Libvirt Base) and the virtual machine separate incremental image file (libvirt instance disks) .

2, Dynamic Data: In-memory virtual machine runtime data, in-memory data is dynamically changing data, the size of the load running in the virtual machine directly affect the length of time of migration.

1.5 Storage in virtual machine migrations

Shared storage and non-shared storage

the virtual machine's data exists on the shared disk (Shared storage-based Live Migration) , migration only needs to complete the migration of memory data.

virtual machine data exists on local disk (Block migration) , you need to migrate both the mirrored file and the memory data.

Note: The system used in this article is Ubuntu18.04,openstack version is pike. Other systems have a slight discrepancy

Second, Cold Migration

There are several ways to implement cold migration, such as having snapshots to migrate instances and instance file migrations. Take file migration as an example to complete a cold migration.

2.1 Virtual machine file Cold migration steps:

1. shut down the virtual machine

2. Locate the virtual camera under/var/lib/nova/instances file

3. Copy all the files of the virtual machine to the same location of the target host

4. Modify user Groups

5, the Host,node field in the update database is the name of the target host

6, restart the target host nova-compute service

2.2 Operation Record

Display the running virtual machine

Turn off the virtual machine

Copy the file to the destination host in the corresponding location

Modify Permissions

Modify a field in a database

Update instances set host= ' Compute15 ', node= ' compute15 ' where uuid= ' 3483d9f1-4015-48d9-9837-b67ca82dd54d ';

Querying the host on which the virtual machine resides

Start a virtual machine

Third, Thermal Migration

Thermal migration is done in a non-stop scenario, and the steps are more complex than cold migration.

3.1 Thermal Migration steps:

1, pre-migration conditions check

2, pre-migration pre-treatment

3. Migration Process

4. Post-migration processing

3.1.1 Pre-migration condition checks

For a dynamic migration to execute successfully, some conditions must be met, so some condition checks must be made before the migration is performed.

1. Permission checks to see if the user performing the migration has sufficient privileges to perform a dynamic migration.

2, parameter check, the parameters passed to the API is sufficient and correct, such as whether the block-migrate parameter is specified.

3, check whether the target physical host exists.

4. Check if the migrated virtual machine is a running state.

5. Check whether the Nova-compute service on the source and destination physical host is working properly.

6, check the purpose of the physical host and the source physical host is the same machine.

7. Check if the destination physical host has enough memory .

8, Check the purpose and source physical master machine hypervisor and hypervisor version is the same.

3.1.2 Pre-migration pre-treatment

Do some preparatory work before you actually perform the migration

1. obtain and prepare the virtual machine mounted Block device (volume) on the destination physical host.

2. set the virtual machine's network (networks) on the destination physical host .

3, The purpose of the physical host set up the virtual machine firewall (fireware).

3.1.3 Migration Process

After the conditions are met and the preprocessing is done, you can perform a dynamic migration. The main steps are as follows:

1, call libvirt python interface Migratetouri, to migrate the source host to the destination host.

2. Call the wait_for_live_migration method at a certain time interval (0.5) to detect the state of the virtual machine migration until the virtual machine is successfully migrated.

3.1.4 post-migration processing

After the virtual machine migration is complete, do some cleanup work.

1, detach volume on the source physical host .

2. Release security group Ingress rule on the source physical host .

3. Update the state of the virtual machine in the database on the destination physical host.

4. Delete the virtual machine on the source physical host.

When the above four steps are completed properly, the virtual machine successfully migrated from the source physical host to the destination physical host.

3.2 Thermal Migration configuration:

hot migration requires libvirt telnet and transmission, so libvirt TCP connection is turned on

Virsh-c Qemu+tcp://172.171.8.14/system

For example:qemu+tcp://172.16.0.15/system, the server only needs to be configured .

Modify /etc/libvirt/libvirtd.conf:

01"16509" "0.0.0.0  　　　　　　　　　 "None  "

　　

Modify The configuration file for LIBVIRTD/ETC/DEFAULT/LIBVIRTD:

# Start LIBVIRTD to handle qemu/kvm:start_libvirtd="Yes"  -L" to listen on tcplibvirtd_opts="-d-l--config/etc/libvirt/libvirtd.conf "

After the above modification, the execution

Service libvirt--ANPT | grep libvirt

can be See LIBVIRTD listening on the TCP 16509 Port.

Configure nova.conf

The/etc/nova/nova.conf file of the compute node adds the following to enable the compute service to support hot migration.

Live_migration_flag=vir_migrate_undefine_source,vir_migrate_peer2peer,vir_migrate_live

Restart Nova-compute

Service Nova-compute Restart

Modify a user group

View user group information for the target host

ID Nova

Modify all compute nodes to the same user group ID.

Usermod-u ** * ** ** * libvirt--G * * * KVM

 

OpenStack Migration Command

View all instances

Nova List

To view the virtual machine instances that need to be migrated

Nova Show [instance ID]

To view available compute nodes

Nova-manage Service List

View Target Node Resources

Nova-manage Service Describe_resource Computer1

Start migration, normal without any echo

Nova Live-migration  [instance ID]  [compute node]

3.3 Operation Record

View virtual machines

View the compute node where the virtual machine resides

Migration

View the node where the migrated virtual machine resides

During migration,the task that is being migrated appears in Dashboard

3.4 large mirror test

OpenLab Platform Mirroring Migration

Create virtual machine, image is ubuntu,1.8G

the host for Ubuntu before migration is compute14

in Migration

Ubuntu Host is compute15 after migration

Run Tests

Create a virtual machine ubuntu_two, where the host is compute14

Pre-migration interface

Migration process

The host on which the migrated virtual machine resides is COMPUTE15

migration process is fast, around 2min, after the migration interface is still the previous interface