Openstack Resize and cold migration code parsing and Improvement

Original article: http://www.hengtianyun.com/download-show-id-79.html

The resize (upgrade) function of openstack allows us to change the number of CPU cores, memory, and disk size of the Virtual Machine. Of course, the virtual machine can only be upgraded up and cannot be downgraded down. By analyzing the source code, we found that the resize process is actually a cold migration process, and the resize multi-transmits a flavor parameter. The following describes how to upgrade the Virtual Machine and cold migration of openstack.

I. Front-end entry

(1) resize

/Usr/share/openstack-dashboard/openstack_dashboard/dashboards/project/instances/workflows/resize_instance.py

From the code above, we can see that two related parameters are passed in. The first is the virtual machine ID (instance_id), and the second is the upgraded flavor. Go to API. Nova. server_resize

/Usr/share/openstack-dashboard/openstack_dashboard/API/NOVA. py

According to the Code, the novaclient client is used to send an upgrade request to the backend.

(2) Cold migration

/Usr/share/openstack-dashboard/openstack_dashboard/dashboards/admin/instances/Tables. py

The previous section used API. Nova. server_migrate to initiate a migration request. The parameter obj_id is the ID of the virtual machine.

/Usr/share/openstack-dashboard/openstack_dashboard/API/NOVA. py

The Code shows that the novaclient client is used to send a migration request to the backend.

Ii. backend response

When novaclient sends a request, the Nova-API component generally responds. We will analyze how the NOVA-API responds to the resize and cold migration respectively.

(1) resize

The function that responds to the resize request is located in the file

/Usr/lib/python2.7/dist-packages/NOVA/API/openstack/compute/servers. py

Continue to go deep into the self. _ resize () function

The code above shows that compute_api.resize is called at last, and the instance and flavor_id parameters are passed in.

(2) Cold migration

/Usr/lib/python2.7/dist-packages/NOVA/API/openstack/compute/contrib/admin_actions.py

According to the Code, the cold migration also calls compute_api.resize (). Compared with the resize function, it only transmits one instance Parameter

(3) the common process of Resize and cold migration

The following code is analyzed from compute_api.resize ().

/Usr/lib/python2.7/dist-packages/NOVA/compute/API. py

/Usr/lib/python2.7/dist-packages/NOVA/conductor/API. py

Response Request from the Nova-conductor component

/Usr/lib/python2.7/dist-packages/NOVA/conductor/manager. py

Function _ cold_migrate ()

Through the above Code, we found that the optimal node is scheduled by calling the NOVA-Scheduler component through rpc. The scheduling algorithm is divided into two stages: Filter and weight. First, filter, find the host that meets the instance running conditions from all hosts, and then find the most suitable host from the filtered hosts.

The default filters used in the filtering stage include retryfilter, availabilityzonefilter, ramfilter, computefilter, computecapabilitiesfilter, and imagepropertiesfilter. The most important filters include availabilityzonefilter and ramfilter, availabilityzonefiter ensures that scheduling occurs in the same zone, and ramfilter ensures that the memory is sufficient. By default, the RAM expansion coefficient is 1.5, that is, if the physical memory is 100 GB, the memory is virtualized to 150 GB, through the Nova. in the conf configuration file, we can change the expansion factor. In addition, through the configuration file, we can also change the called filter. In addition to the above filter, we can also use corefilter, diskfilter, ioopsfilter, and so on. These are the built-in filters of the system. We can also construct the filters as needed.

In the weight stage, from the perspective of its work, it is to select the "most suitable" host from the qualified hosts. This selection process is achieved by "rating. At this stage, weight is very simple. It is mainly weighed by ramweigher. The larger the remaining memory, the larger the weight.

After the above work is completed, if the appropriate node is not selected and the resize process ends, the system reports an error. If the appropriate node is selected, the resize process starts. First, RPC calls the NOVA-compute of the target node, that is, self. compute_rpcapi.prep_resize.

The target node Nova-compute starts to respond.

/Usr/lib/python2.7/dist-packages/NOVA/compute/manager. py (2885) _ prep_resize ()

In the prep_resize stage, the status before and after the Virtual Machine Resize is saved. Finally, the source node's Nova-compute is called through RPC, that is, self. compute_rpcapi.resize_instance.

/Usr/lib/python2.7/dist-packages/NOVA/compute/manager. py (3020) resize_instance ()

 

The above code, a more important process is to migrate disk files. This function is implemented through the self. Driver. migrate_disk_and_power_off function. Let's take a look at this function.

/Usr/lib/python2.7/dist-packages/NOVA/virt/libvirt/driver. py (4487) migrate_disk_and_power_off ()

By performing the preceding steps, the virtual machine's disk file is successfully copied to the target node and the last step of migration is started. The virtual machine creation step is implemented by calling the target node's Nova-compute through RPC, that is, self. compute_rpcapi.finish_resize. The Code is as follows.

/Usr/share/pyshared/NOVA/compute/manager. py: 3153

/Usr/lib/python2.7/dist-packages/NOVA/compute/manager. py (3073) _ finish_resize ()

/Usr/lib/python2.7/dist-packages/NOVA/virt/libvirt/driver. py

The Virtual Machine is successfully created through self. _ create_domain_and_network.

I. Deficiencies and Improvements

Through the analysis of resize, we found the following defects:

1) availabilityzonefilter

During the migration, the cross-origin resize occurs. availabilityzonefilter does not seem to have a filtering error. This is because when we create a virtual machine, the virtual machine's domain is set to ramdom, therefore, the availabilityzonefilter filters allow the hosts in all domains, causing the VM to be upgraded to another domain.

2) image copy process

During the migration process, the Incremental Images and base images are first merged at the source node, and then copied to the target node. The merging process is time-consuming. We can directly copy the incremental images to the target node, download the base image and rebase the last time.

Openstack Resize and cold migration code parsing and Improvement