Method and system for cloud management platform to switch virtual machine tenants

Abstract

The invention relates to the technical field of cloud computing, in particular to a virtual machine tenant switching method and system for a cloud management platform, and the method comprises the following steps: carrying out the overall calling of storage, network and scheduling components through a computing component Nova to complete the tenant switching function of a virtual machine; expanding a Nova interface of the computing component; a native transfer interface of the storage component Cinder is expanded, and transfer is carried out on the ins-use volume and the snapshot in a supporting mode; the method comprises the following steps of: expanding a Placement interface of a scheduling component, supporting obtaining of a controller, updating of the controller and deleting of a controller interface, and realizing full-life-cycle management of controller data of a virtual machine; the method has the beneficial effects that interfaces provided by Cinder, Glane, Neutron and Placement components in the cloud management platform are scheduled in a unified manner through the Nova component, virtual machine transfer is executed, created and received, a virtual machine tenant switching task is created and received, user and project information in virtual machine calculation, storage, mirroring, network and scheduling information is updated, and the integrity and consistency of functions are improved.

Description

Technical Field

[0001] The present invention relates to the technical field of cloud computing, and in particular to a method and system for switching virtual machine tenants on a cloud management platform. Background Art

[0002] With the development of information technology and cloud computing, cloud computing technology has been increasingly applied in education, science, culture, government and other fields. The demand for digital transformation and business model innovation has increased significantly. Empowering enterprises to develop innovation through digital transformation is the general trend of the economic market. Digital transformation through cloud computing is a key boost for enterprises to reduce costs and increase efficiency, and develop innovation needs. For private cloud usage scenarios, the cloud management platform deployed by enterprises or government departments will divide different projects according to their respective departmental structures, and there are different tenants under each project, which use and manage their respective virtualized resources in a unified manner. The resources created by tenants through the cloud platform belong only to the corresponding tenants, and other tenants in the project can be viewed and used by granting permissions.

[0003] However, as time goes by, the current personnel and project structure will become more and more bloated. At the same time, with the changes in the company's internal organizational structure and personnel changes, there is a need to change and switch tenants of the virtualized resources under the existing tenants. Summary of the invention

[0004] The purpose of the present invention is to provide a method and system for switching virtual machine tenants on a cloud management platform to solve the problems raised in the above background technology.

[0005] To achieve the above object, the present invention provides the following technical solution: a method for switching virtual machine tenants on a cloud management platform, the method comprising the following steps:

[0006] R1. The computing component Nova coordinates the calling of storage, network, and scheduling components to complete the virtual machine tenant switching function;

[0007] R2, Nova interface of extended computing component;

[0008] R3. Expand the native transfer interface of the storage component Cinder to support the transfer of ins-use volumes and snapshots;

[0009] R4. Expand the Placement interface of the scheduling component to support obtaining consumers, updating consumers, and deleting consumers, thus achieving full lifecycle management of virtual machine consumer data.

[0010] R5. Expand the network component Neutron to natively update the port interface, update the port project and user, and implement the network port switching tenant function.

[0011] Preferably, in step R1, the OpenStack components Nova, Cinder, Placement, and Neutron interfaces are extended, and Nova is used as the initiator to coordinate the calls to the interfaces provided by other components. The user uses the source tenant to log in to the cloud platform, directly calls the Nova component's newly added create transfer interface, passes in the virtual machine uuid, creates a virtual machine tenant switching task, and records the return result; then uses the target tenant to log in to the cloud platform, passes in transfer_id and transfer_id, calls the receive transfer interface, and completes the virtual machine switching project process.

[0012] Preferably, in step R2, the Nova interface is expanded to implement the creation, reception, query, and deletion interfaces of the virtual machine transfer task, thereby realizing the full life cycle management of the virtual machine tenant switching task.

[0013] Preferably, in step R3, the native Cinder component only supports the restriction of tenant switching for volumes and snapshots in the available state, and the Cinder volume transfer interface is expanded to support ins-use volume switching tenant information without recording user projects and user information on the volume backend, support recording user projects and user information on the volume backend, and provide a backend API to support real-time modification of projects and user in-use volume switching tenant information.

[0014] Preferably, in step R5, the native port update interface of the Neutron interface is expanded to update the port user and project attributes and realize the tenant metadata change; for the underlying network card device, in order to ensure the maximum availability of the business virtual machine, it is divided according to the network type. For the classic network type, the underlying physical network card device tenant is directly updated online. For the VPC type network, the virtual machine needs to be shut down and then the underlying physical network card device tenant is updated.

[0015] A cloud management platform switching virtual machine tenant system, the system is composed of a computing component, a storage component, a scheduling component, a network component and a mirror component;

[0016] The computing component Nova coordinates the calls to the storage, network, and scheduling components to complete the virtual machine tenant switching function;

[0017] Extended computing component Nova interface;

[0018] The native transfer interface of the storage component Cinder is extended to support the transfer of ins-use volumes and snapshots;

[0019] After the Placement interface of the scheduling component is expanded, it supports obtaining consumers, updating consumers, and deleting consumers, realizing the full life cycle management of virtual machine consumer data;

[0020] After the network component Neutron natively updates the port interface extension, it updates the port project and user to implement the network port switching tenant function;

[0021] The image component Glance natively supports the image configuration tenant function and directly calls the image update interface.

[0022] Preferably, the computing component extends the OpenStack components Nova, Cinder, Placement, and Neutron interfaces, and Nova is used as the initiator to coordinate the calls to the interfaces provided by other components. The user uses the source tenant to log in to the cloud platform, directly calls the Nova component's newly added create transfer interface, passes in the virtual machine uuid, creates a virtual machine tenant switching task, and records the return result; then uses the target tenant to log in to the cloud platform, passes in transfer_id and transfer_id, calls the receive transfer interface, and completes the virtual machine switching project process.

[0023] Preferably, the storage component expands the Nova interface to implement the creation, reception, query, and deletion interfaces of virtual machine transfer tasks, thereby achieving full life cycle management of virtual machine tenant switching tasks.

[0024] Preferably, the scheduling component, with respect to the native Cinder component, only supports the restriction of tenant switching for volumes and snapshots in the available state, expands the Cinder volume transfer interface, supports switching tenant information of in-use volumes that do not record user projects and user information on the volume backend, supports recording user projects and user information on the volume backend, and provides a backend API to support real-time modification of projects and user's in-use volume switching tenant information.

[0025] Preferably, the network component extends the native port update interface of the Neutron interface to update the port user and project attributes and change the tenant metadata; for the underlying network card device, in order to ensure the maximum availability of the business virtual machine, it is divided according to the network type. For the classic network type, the underlying physical network card device tenant is directly updated online. For the VPC type network, the virtual machine needs to be shut down and then the underlying physical network card device tenant is updated.

[0026] Compared with the prior art, the present invention has the following beneficial effects:

[0027] The method and system for switching virtual machine tenants on a cloud management platform proposed in the present invention, through the Nova component, uniformly dispatches the interfaces provided by the Cinder, Glance, Neutron, and Placement components in the cloud management platform, executes the creation and reception of virtual machine transfers, realizes the creation and reception of a virtual machine tenant switching task, completes the update of user and project information in the virtual machine computing, storage, mirroring, network, and scheduling information, and improves the integrity and consistency of the functions. There is no need to call computing, storage, network and other resources separately, which simplifies the user's operation process. At the same time, the same processing architecture as Cinder volume transfer is used to improve the platform's ease of use. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] Figure 1 This is the overall structure diagram of the virtual machine switching of the cloud management platform of the present invention;

[0029] Figure 2 It is a user operation flow chart of the present invention. DETAILED DESCRIPTION

[0030] In order to make the purpose and technical solution of the present invention clearly and completely described, and the advantages more clearly understood, the embodiments of the present invention are further described in detail with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are part of the embodiments of the present invention, rather than all of the embodiments, and are only used to explain the embodiments of the present invention, and are not used to limit the embodiments of the present invention. All other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0031] Embodiment 1

[0032] See also Figure 1 to Figure 2 The present invention provides a technical solution: a method for switching virtual machine tenants on a cloud management platform, the method comprising the following steps:

[0033] R1. The computing component Nova coordinates the calls to the storage, network, and scheduling components to complete the virtual machine tenant switching function; the OpenStack components Nova, Cinder, Placement, and Neutron interfaces are extended, and Nova is used as the initiator to coordinate the calls to the interfaces provided by other components. The user logs in to the cloud platform using the source tenant, directly calls the Nova component's newly added create transfer interface, passes in the virtual machine uuid, creates a virtual machine tenant switching task, and records the return result; then uses the target tenant to log in to the cloud platform, passes in transfer_id and transfer_id, calls the receive transfer interface, and completes the virtual machine switching project process.

[0034] R2. Expand the Nova interface of the computing component; expand the Nova interface to implement the creation, reception, query, and deletion interfaces of virtual machine transfer tasks, and realize the full life cycle management of virtual machine tenant switching tasks.

[0035] R3. Expand the native transfer interface of the storage component Cinder to support the transfer of ins-use volumes and snapshots. In view of the limitation that the native Cinder component only supports tenant switching for volumes and snapshots in the available state, expand the Cinder volume transfer interface to support switching tenant information for ins-use volumes that do not record user projects and user information on the volume backend, support recording user projects and user information on the volume backend, and provide a backend API to support real-time modification of projects and user in-use volume switching tenant information.

[0036] R4. Expand the Placement interface of the scheduling component to support obtaining consumers, updating consumers, and deleting consumers, thus achieving full lifecycle management of virtual machine consumer data.

[0037] R5. Expand the native update port interface of the network component Neutron, update the port project and user, and implement the network port switching tenant function; expand the native port update interface of the Neutron interface to update the port user and project attributes and change the tenant metadata; for the underlying network card equipment, in order to ensure the maximum availability of the business virtual machine, it is divided according to the network type. For the classic network type, the underlying physical network card device tenant is directly updated online. For the VPC type network, the virtual machine needs to be shut down and then the underlying physical network card device tenant is updated.

[0038] Embodiment 2

[0039] Based on the first embodiment, a system for switching virtual machine tenants according to a cloud management platform is proposed, which specifically includes:

[0040] 1. Computing components

[0041] The computing component Nova serves as the entry point and main scheduler for the virtual machine tenant switching function. It is responsible for receiving tenant requests and calling the image, block storage, network, and scheduling components to complete the switching of tenant information of each component.

[0042] Refer to the implementation of the transfer function of the Cinder component to extend the Nova component to implement the create transfer, receive transfer, get transfer, and delete transfer interfaces.

[0043] For users who need to change the tenant of a virtual machine, first log in through the original tenant page of the virtual machine and call Nova to create a transfer interface. Nova will perform the following processes in sequence:

[0044] 1) Check the virtual machine status (ACTIVE, SHUTOFF, SUSPENDED, PAUSED), and throw an exception if it is abnormal;

[0045] 2) Verify the virtual machine image properties;

[0046] 3) Generate salt, auth_key, and generate crypt_hash based on salt and auth_key;

[0047] 4) Traverse the virtual machine volume list, call the Cinder component to create a volume transfer interface, and create a transfer for the system volume and data volume of the virtual machine;

[0048] 5) Nova database inserts transfer and changes the virtual machine state to awaiting-transfer;

[0049] 6) Return data {

[0050] 'id':transfer['id'],

[0051] 'instance_id':transfer['instance_id'],

[0052] 'display_name':transfer['display_name'],

[0053] 'auth_key':auth_key,

[0054] 'created_at':transfer['created_at'],

[0055] 'no_images':transfer['no_images'],

[0056] 'source_project_id':transfer['source_project_id'],

[0057] 'accepted':transfer['accepted']

[0058] }, complete the task of creating a virtual machine to switch tenants.

[0059] Then, after the user records the return information of creating a transfer, he switches to the new tenant to call the transfer receiving interface, and passes in the transfer id and auth_key in the return information of creating a transfer. The following processes will be carried out in the Nova component in sequence:

[0060] 1) Get transfer according to the transfer_id in the input parameter, get the crypt_hash of the database record according to the auth_key in the input parameter and the salt in the transfer, and verify it with the crypt_hash in the transfer;

[0061] 2) Obtain virtual machine information according to vm_id in transfer, and verify virtual machine status, task status, etc.;

[0062] 3) Traverse the virtual machine volume list, call the Cinder component to receive the volume transfer interface, and receive the transfer of the system volume and data volume of the virtual machine;

[0063] 4) Call the Neutron component interface to update the ports interface and update the user and project related information in the network resources;

[0064] 5) If the virtual machine has a virtual machine image, call the Glance component interface to update the image interface and modify the project related information in the images table of the glance database;

[0065] 6) Call the Placement component to update the consumer interface and update the user and project related information in the consumers table of the placement database;

[0066] 7) Verify the quota and reserved resource information related to the virtual machine and virtual machine image;

[0067] 8) Start the virtual machine accept transfer and verify whether the current user has the target virtual machine ACCEPT_POLICY operation permission;

[0068] 9) Update user and project related information in nova and nova_api databases;

[0069] 10) Update deleted, deleted_at, updated_at, accepted, and destination_project_id in the tranfer record; commit the modification of the virtual machines and virtual machine image quotas of the new and old projects;

[0070] 11) Return data

[0071] {

[0072] 'id':transfer_id,

[0073] 'display_name':transfer['display_name'],

[0074] 'accepted':transfer['accepted']

[0075] 'source_project_id':transfer['source_project_id'],

[0076] 'destination_project_id':transfer['destination_project_id'],

[0077] 'vm_uuid':instance_ref['uuid']

[0078] }, complete the transfer receiving function and complete the virtual machine tenant switching process.

[0079] 2. Storage Components

[0080] The storage component Cinder natively supports the volume transfer function for switching the tenants of volumes and snapshot resources, but it only supports tenant switching for volumes in the available state, that is, it cannot perform tenant switching for volumes in the in-use state (already mounted to a virtual machine). Based on this problem, Cinder's transfer creation and transfer reception functions are optimized to support direct tenant switching for in-use volumes.

[0081] 1) For creating a transfer interface, modify the logic of throwing an exception when the volume status is not available in the create process of Cinder API volume_transfer, and change it to throwing an exception when the volume status is not available or in-use, so as to support in-use volume tenant switching in the API; and modify the Cinder component to check that the original volume status is available when updating the volume status in the database, so that the in-use status can also be used to update the database for the transfer_create operation.

[0082] 2) For the transfer receiving interface, modify the accept method in Cinder API volume_transfer to determine the original volume status after the transfer is accepted based on the volume attach_status attribute, and pass it to the db transfer_accept method as a function parameter; and modify the Cinder component to check that the original volume status is available when updating the volume status in the database, and support the in-use status to update the database for the transfer_accept operation. And modify the abnormal rollback of the volume status when the switch fails, from hard-coded available to rollback to the original volume status, to ensure that the volume is restored to the state before the transfer when the transfer fails. At the same time, considering that some storage backends will record user and project information to the backend after the volume is mounted to the virtual machine, this is also the reason why the native method directly prohibits tenant switching of mounted volumes (in-use). A backend judgment is added to the API, and tenant switching of mounted volumes (in-use) is prohibited only in scenarios where the backend records user and project information and does not provide dynamic modification interfaces for users and projects. For scenarios where the backend records user and project information and provides dynamic modification interfaces for users and projects, the backend interface is called to synchronously modify the user and project information recorded by the backend to achieve complete switching of tenant information; for scenarios where the backend does not record user and project information, the native logic is directly used to update the user and project information recorded in the Cinder database to achieve tenant switching.

[0083] 3. Scheduling Component

[0084] The scheduling component Placement records the user and project information of the virtual machine through consumers. Each consumer corresponds to a virtual machine, and the Placement component also maintains user and project data separately. By adding consumer-related API interfaces, it is possible to query and delete records in the consumers table of the placement database, and modify user and project information in the consumers table. If the user and project data in the Placement does not exist, the user and project records are created in the users table and projects table of the placement database synchronously.

[0085] 4. Network components

[0086] The network component Neutron supports the update interface of the port, but does not support the update of user and project information. It is necessary to expand the API interface to support the modification of the user and project of the port to achieve tenant information switching. It should be noted that since the modification of the port involves the change of the underlying network equipment, the operation method is different for different types of networks. For classic network types, tenant information can be modified without shutting down the virtual machine, but for VPC type networks, the virtual machine needs to be shut down to ensure that the tenant information switching is completed.

[0087] 5. Mirror Components

[0088] The image component Glance natively supports the image configuration tenant function and can directly call the image update interface.

[0089] Although embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions and variations may be made to the embodiments without departing from the principles and spirit of the present invention, and that the scope of the present invention is defined by the appended claims and their equivalents.

Claims

1. A method for switching virtual machine tenants on a cloud management platform, characterized in that: The method comprises the following steps: R1. The computing component Nova coordinates the calling of storage, network, and scheduling components to complete the virtual machine tenant switching function; R2, Nova interface of extended computing component; R3. Expand the native transfer interface of the storage component Cinder to support the transfer of ins-use volumes and snapshots; R4. Expand the Placement interface of the scheduling component to support obtaining consumers, updating consumers, and deleting consumers, thus achieving full lifecycle management of virtual machine consumer data. R5. Expand the network component Neutron to natively update the port interface, update the port project and user, and implement the network port switching tenant function.

2. A method for switching virtual machine tenants on a cloud management platform according to claim 1, characterized in that: In step R1, the interfaces of OpenStack components Nova, Cinder, Placement, and Neutron are extended, and Nova is used as the initiator to coordinate the calls to the interfaces provided by other components. The user logs in to the cloud platform using the source tenant, directly calls the newly added create transfer interface of the Nova component, passes in the virtual machine uuid, creates a task for switching the tenant of a virtual machine, and records the return result; then logs in to the cloud platform using the target tenant, passes in transfer_id and transfer_id, calls the receive transfer interface, and completes the virtual machine switching project process.

3. According to claim 1, a method for switching virtual machine tenants on a cloud management platform is characterized in that: In step R2, the Nova interface is expanded to implement the creation, reception, query, and deletion interfaces of virtual machine transfer tasks, and to achieve full life cycle management of virtual machine tenant switching tasks.

4. A method for switching virtual machine tenants on a cloud management platform according to claim 1, characterized in that: In step R3, the native Cinder component only supports the restriction of tenant switching for volumes and snapshots in the available state. The Cinder volume transfer interface is expanded to support the switching of tenant information of in-use volumes that do not record user projects and user information on the volume backend, support the recording of user projects and user information on the volume backend, and provide a backend API to support real-time modification of projects and user in-use volume switching tenant information.

5. According to claim 1, a method for switching virtual machine tenants on a cloud management platform is characterized in that: In step R5, the native port update interface of the Neutron interface is expanded to update the port user and project attributes and change the tenant metadata. For the underlying network card device, in order to ensure the maximum availability of the business virtual machine, it is divided according to the network type. For the classic network type, the underlying physical network card device tenant is directly updated online. For the VPC type network, the virtual machine needs to be shut down and then the underlying physical network card device tenant is updated.

6. A cloud management platform switching virtual machine tenant system according to the method for switching virtual machine tenants on a cloud management platform according to any one of claims 1 to 5, characterized in that: The system is composed of a computing component, a storage component, a scheduling component, a network component and a mirror component; The computing component Nova coordinates the calls to the storage, network, and scheduling components to complete the virtual machine tenant switching function; Extended computing component Nova interface; The native transfer interface of the storage component Cinder is extended to support the transfer of ins-use volumes and snapshots; After the Placement interface of the scheduling component is expanded, it supports obtaining consumers, updating consumers, and deleting consumers, realizing the full life cycle management of virtual machine consumer data; After the network component Neutron natively updates the port interface extension, it updates the port project and user to implement the network port switching tenant function; The image component Glance natively supports the image configuration tenant function and directly calls the image update interface.

7. A cloud management platform switching virtual machine tenant system according to claim 6, characterized in that: The computing component extends the OpenStack components Nova, Cinder, Placement, and Neutron interfaces, and Nova is used as the initiator to coordinate the calls to the interfaces provided by other components. The user uses the source tenant to log in to the cloud platform, directly calls the Nova component's newly added create transfer interface, passes in the virtual machine uuid, creates a virtual machine tenant switching task, and records the return result; then uses the target tenant to log in to the cloud platform, passes in transfer_id and transfer_id, calls the receive transfer interface, and completes the virtual machine switching project process.

8. A cloud management platform switching virtual machine tenant system according to claim 6, characterized in that: The storage component expands the Nova interface to implement the creation, reception, query, and deletion interfaces of virtual machine transfer tasks, thereby achieving full life cycle management of virtual machine tenant switching tasks.

9. A cloud management platform switching virtual machine tenant system according to claim 6, characterized in that: The scheduling component, in response to the restriction that the native Cinder component only supports tenant switching for volumes and snapshots in the available state, expands the Cinder volume transfer interface, supports switching tenant information of in-use volumes that do not record user projects and user information on the volume backend, supports recording user projects and user information on the volume backend, and provides a backend API to support real-time modification of projects and user in-use volume switching tenant information.

10. A cloud management platform switching virtual machine tenant system according to claim 6, characterized in that: The network component extends the native port update interface of the Neutron interface to update the port user and project attributes and change the tenant metadata. For the underlying network card device, in order to ensure the maximum availability of the business virtual machine, it is divided according to the network type. For the classic network type, the underlying physical network card device tenant is directly updated online. For the VPC type network, the virtual machine needs to be shut down and then the underlying physical network card device tenant is updated.

Images