Method and system for switching virtual machine tenants of a cloud management platform

Abstract

The application relates to the technical field of cloud computing, in particular to a method and system for switching virtual machine tenants of a cloud management platform, which comprises the following steps: through a computing component Nova, storage, network and scheduling components are called to complete the function of switching tenants of virtual machines; the interface of the computing component Nova is extended; the original transfer interface of the storage component Cinder is extended to support transfer of ins-use volumes and snapshots; the interface of the scheduling component Placement is extended to support the consumer, update consumer and delete consumer interfaces, and the full life cycle management of virtual machine consumer data is realized; the beneficial effects are as follows: through the Nova component, the interfaces provided by the Cinder, Glance, Neutron and Placement components in the cloud management platform are uniformly scheduled, the creation and reception of virtual machine transfer are executed, the creation and reception of a virtual machine tenant switching task are realized, the update of user and project information in the virtual machine computing, storage, image, network and scheduling information is completed, and the completeness and consistency of the function are improved.

Description

Technical Field

[0001] This invention relates to the field of cloud computing technology, specifically to a method and system for switching virtual machine tenants on a cloud management platform. Background Technology

[0002] With the development of information technology and cloud computing, cloud computing technology is increasingly being applied in various fields such as education, science, culture, and government. Enterprises across industries are experiencing a significant increase in demand for digital transformation and business model innovation. Empowering enterprise development and innovation through digital transformation is a general trend in the economic market. Digital transformation through cloud computing is a key driver for enterprises to reduce costs, increase efficiency, and meet their innovation needs. In private cloud scenarios, cloud management platforms deployed by enterprises or government departments are divided into different projects based on their departmental architecture. Each project has different tenants, who uniformly use and manage their respective virtualization resources. Resources created by a tenant through the cloud platform belong only to that tenant; other tenants within the project can view and use them through authorization.

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

[0004] The purpose of this invention is to provide a method and system for switching virtual machine tenants on a cloud management platform, so as to solve the problems mentioned in the background art.

[0005] To achieve the above objectives, 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 uses the computing component Nova to coordinate and call storage, network, and scheduling components to complete the virtual machine tenant switching function;

[0007] R2, extended computing component Nova interface;

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

[0009] R4 extends the Placement interface of the scheduling component to support the interfaces for obtaining, updating, and deleting consumers, thereby enabling full lifecycle management of virtual machine consumer data.

[0010] R5 extends the Neutron native update port interface of the network component to update port items and users, and implements the function of switching tenants for network ports.

[0011] Preferably, step R1 extends the interfaces of the OpenStack components Nova, Cinder, Placement, and Neutron. Nova acts as the initiator, coordinating the calls to the interfaces provided by other components. The user logs into 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 virtual machine tenant switching task, and records the return result. Then, the user logs into 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.

[0012] Preferably, in step R2, the Nova interface is extended to implement interfaces for creating, receiving, querying, and deleting virtual machine transfer tasks, thereby enabling full lifecycle management of virtual machine tenant switching tasks.

[0013] Preferably, in step R3, in response to the limitation that the native Cinder component only supports tenant switching for volumes and snapshots in the available state, the Cinder volume transfer interface is extended to support tenant switching for in-use volumes where the volume backend does not record user projects and user information, and supports tenant switching for in-use volumes where the volume backend records user projects and user information. Furthermore, a backend API is provided to support real-time modification of project and user in-use volume tenant switching information.

[0014] Preferably, in step R5, the native port update interface of the Neutron interface is extended to update the port user and project attributes, thereby realizing the change of tenant metadata. For the underlying network interface 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 tenant of the underlying physical network interface device is updated directly online. For the VPC type network, the virtual machine needs to be shut down and then the tenant of the underlying physical network interface device is updated.

[0015] A cloud management platform system for switching virtual machine tenants, the system comprising computing components, storage components, scheduling components, network components, and image components;

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

[0017] Extend the Nova interface of the computing component;

[0018] After the Cinder storage component's native transfer interface is extended, it supports the transfer of in-use volumes and snapshots;

[0019] After the Placement interface of the scheduling component is extended, it supports the interfaces for obtaining, updating, and deleting consumers, realizing full lifecycle management of virtual machine consumer data;

[0020] After the Neutron network component natively updates the port interface, it updates the port project and user, and realizes the function of switching tenants for network ports.

[0021] The Glance mirror component natively supports the function of configuring tenants for images, which can be achieved by directly calling the image update interface.

[0022] Preferably, the computing component extends the interfaces of the OpenStack components Nova, Cinder, Placement, and Neutron. Nova acts as the initiator, coordinating the calls to the interfaces provided by other components. Users log in to the cloud platform using the source tenant, directly call the newly added create transfer interface of the Nova component, pass in the virtual machine UUID, create a virtual machine tenant switching task, and record the return result. Then, users log in to the cloud platform using the target tenant, pass in transfer_id and transfer_id, call the receive transfer interface, and complete the virtual machine switching project process.

[0023] Preferably, the storage component extends the Nova interface to implement interfaces for creating, receiving, querying, and deleting virtual machine transfer tasks, thereby enabling full lifecycle management of virtual machine tenant switching tasks.

[0024] Preferably, the scheduling component, in response to the limitation of the native Cinder component that only supports tenant switching for volumes and snapshots in the available state, extends the Cinder volume transfer interface to support tenant information switching for in-use volumes where the volume backend does not record user projects and user information, and supports tenant information switching for in-use volumes where the volume backend records user projects and user information. It also provides a backend API to support real-time modification of project and user in-use volume tenant information switching.

[0025] Preferably, the network component extends the native port update interface of the Neutron interface to update port user and project attributes and realize tenant metadata changes. For the underlying network interface device, in order to ensure the maximum availability of business virtual machines, it is divided according to the network type. For classic network types, the tenants of the underlying physical network interface device are updated directly online. For VPC type networks, the virtual machines need to be shut down and then the tenants of the underlying physical network interface device are updated.

[0026] Compared with the prior art, the beneficial effects of the present invention are:

[0027] The method and system for switching virtual machine tenants on a cloud management platform proposed in this invention utilizes the Nova component to uniformly schedule the interfaces provided by the Cinder, Glance, Neutron, and Placement components in the cloud management platform. This enables the creation and reception of virtual machine transfers, achieving the creation and reception of a virtual machine tenant switching task. It also updates user and project information in the virtual machine's compute, storage, image, network, and scheduling information, improving functional completeness and consistency. It eliminates the need for separate calls to compute, storage, and network resources, simplifying the user's workflow. Furthermore, the use of the same processing architecture as Cinder volume transfers enhances the platform's usability. Attached Figure Description

[0028] Fig. 1 This is a diagram showing the overall structure of virtual machine switching on the cloud management platform of the present invention.

[0029] Fig. 2 This is a user operation flowchart for the present invention. Detailed Implementation

[0030] To make the objectives, technical solutions, and advantages of the present invention clear and complete, the embodiments of the present invention will be further described in detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are only some, not all, embodiments of the present invention, and are merely illustrative of the embodiments of the present invention. They are not intended to limit the embodiments of the present invention. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0031] Example 1

[0032] Please see Figs. 1-2 This 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 utilizes the Nova compute component to coordinate and call storage, network, and scheduling components to complete the virtual machine tenant switching function. It extends the interfaces of the OpenStack components Nova, Cinder, Placement, and Neutron, with Nova acting as the initiator to coordinate and call the interfaces provided by other components. Users log in to the cloud platform as the source tenant, directly call the newly added create transfer interface of the Nova component, pass in the virtual machine UUID, create a virtual machine tenant switching task, and record the return result; then, users log in to the cloud platform as the target tenant, pass in transfer_id and transfer_id, call the receive transfer interface, and complete the virtual machine switching project process.

[0034] R2, Extend the Nova interface of the computing component; extend the Nova interface to implement the creation, reception, query and deletion of virtual machine transfer tasks, and realize the full lifecycle management of virtual machine tenant switching tasks.

[0035] R3 extends the native transfer interface of the Cinder storage component to support the transfer of in-use volumes and snapshots; addressing the limitation that the native Cinder component only supports tenant switching for volumes and snapshots in the available state, the Cinder volume transfer interface is extended to support switching tenant information for in-use volumes where the volume backend does not record user projects and user information, and supports switching tenant information for in-use volumes where the volume backend records user projects and user information. Furthermore, a backend API is provided to support real-time modification of project and user in-use volume tenant information switching.

[0036] R4 extends the Placement interface of the scheduling component to support the interfaces for obtaining, updating, and deleting consumers, thereby enabling full lifecycle management of virtual machine consumer data.

[0037] R5 extends the Neutron native update port interface of the network component to update port items and users, enabling the function of switching tenants on network ports; it also extends the native port update interface of Neutron to update port user and item attributes, enabling tenant metadata changes; for the underlying network interface device, in order to ensure the maximum availability of business virtual machines, it is divided according to network type. For classic network types, the tenants of the underlying physical network interface device are updated directly online. For VPC type networks, the virtual machine needs to be shut down before updating the tenants of the underlying physical network interface device.

[0038] Example 2

[0039] Based on Example 1, a method for switching virtual machine tenant systems according to a cloud management platform is proposed, specifically including:

[0040] 1. Computing Components

[0041] The compute 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 for each component.

[0042] Referring to the implementation of the transfer function in the Cinder component, the Nova component is extended to implement interfaces for creating, receiving, obtaining, and deleting transfers.

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

[0044] 1) Virtual machine status check (ACTIVE, SHUTOFF, SUSPENDED, PAUSED), throw an exception if the status is abnormal;

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

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

[0047] 4) Iterate through the virtual machine volume list and call the Cinder component to create the volume transfer interface for each virtual machine's system volume and data volume;

[0048] 5) Insert the `transfer` statement into the Nova database and change the virtual machine status 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 and switching tenants.

[0059] Then, after the user records the return information of creating the transfer, they switch to the new tenant and call the transfer receiving interface, passing in the transfer id and auth_key from the return information of creating the transfer. The Nova component will then perform the following process in sequence:

[0060] 1) Obtain the transfer based on the transfer_id in the input parameter, and verify the crypt_hash of the database record with the crypt_hash in transfer based on the auth_key in the input parameter and the salt in transfer;

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

[0062] 3) Traverse the virtual machine volume list and call the Cinder component to receive the volume transfer interface for the virtual machine's system volume and data volume respectively;

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

[0064] 5) If a virtual machine image exists, call the Glance component interface to update the image and modify the relevant project 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 information in the consumers table of the Placement database;

[0066] 7) Verify the quotas and reserved resource information related to virtual machines and virtual machine images;

[0067] 8) Begin virtual machine accept transfer, verifying whether the current user has the permission to operate on the target virtual machine ACCEPT_POLICY;

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

[0069] 10) Update the deleted, deleted_at, updated_at, accepted, and destination_project_id in the transfer record; commit the changes to virtual machines and virtual machine image quotas for both 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 receive transfer function, and complete the virtual machine tenant switching process.

[0079] 2. Storage components

[0080] The Cinder storage component natively supports volume transfer functionality for switching tenants of volumes and snapshot resources. However, it only supports tenant switching for volumes in an available state; it cannot perform tenant switching for volumes in an in-use state (already mounted to a virtual machine). To address this issue, Cinder's transfer creation and reception functions have been optimized to support direct tenant switching for in-use volumes.

[0081] 1) For the create transfer interface, modify the logic in the Cinder API volume_transfer create process that throws an exception when the volume status is not available, and change it to throw an exception when the volume status is not available or in-use, so as to support tenant switching of in-use volumes in the API; and modify the Cinder component's check that the original volume status is expected to be available when performing database update of volume status, so as to support database update of transfer_create operation even when the volume status is in-use.

[0082] 2) For the receive transfer interface, modify the `accept` method in the Cinder API's `volume_transfer` function to determine the original volume's status after transfer acceptance based on the volume's `attach_status` attribute, and pass this as a function parameter to the `db transfer_accept` method. Also, modify the Cinder component's check for the original volume's expected status as `available` when updating the volume status in the database, allowing database updates even in-use states. Furthermore, modify the abnormal rollback of the volume status when the switch fails, changing from hardcoding `available` to rolling back to the original volume status, ensuring that the volume recovers to its pre-transfer state when transfer acceptance fails. Meanwhile, considering that some storage backends record user and project information after a volume is mounted to a virtual machine, which is why natively, tenant switching is directly prohibited for mounted volumes (in-use), a backend check is added to the API. Tenant switching for mounted volumes (in-use) is only prohibited for scenarios where the backend records user and project information but does not provide an interface for dynamically modifying user and project information. For scenarios where the backend records user and project information and provides an interface for dynamically modifying user and project information, the backend interface is called to synchronously modify the user and project information recorded by the backend to achieve a complete tenant information switch. For scenarios where the backend does not record user and project information, the native logic is used directly to update the user and project information recorded in the Cinder database to achieve tenant switching.

[0083] 3. Scheduling Component

[0084] The Placement scheduling component records user and project information for virtual machines through consumers. Each consumer corresponds to a virtual machine, and the Placement component also maintains user and project data independently. By adding new 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 user or project data does not exist in the Placement, records for the user and project are created synchronously in the users and projects tables of the Placement database.

[0085] 4. Network components

[0086] The Neutron network component supports port updates, but not user and project information updates. An extended API is needed to allow modification of ports for users and projects to switch tenant information. It's important to note that port modifications involve changes to the underlying network devices, and the operation differs depending on the network type. For classic networks, tenant information can be modified without shutting down the virtual machine. However, for VPC networks, the virtual machine must be shut down to ensure successful tenant information switching.

[0087] 5. Mirror component

[0088] The image component Glance natively supports the function of configuring tenants for images, and the image update interface can be called directly.

[0089] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which 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 includes the following steps: R1 uses the computing component Nova to coordinate and call storage, network, and scheduling components to complete the virtual machine tenant switching function; R2, Nova interface for extended computing components; R3 extends the native transfer interface of the storage component Cinder to support the transfer of in-use volumes and snapshots; R4 extends the Placement interface of the scheduling component to support the interfaces for obtaining, updating, and deleting consumers, thereby enabling full lifecycle management of virtual machine consumer data. R5 extends the Neutron native update port interface of the network component to update port items and users, and implements the function of switching tenants for network ports.

2. The method for switching virtual machine tenants on a cloud management platform according to claim 1, characterized in that: Step R1 extends the interfaces of the OpenStack components Nova, Cinder, Placement, and Neutron. Nova acts as the initiator, coordinating the calls to the interfaces provided by other components. Users log in to the cloud platform using the source tenant, directly call the newly added create transfer interface of the Nova component, pass in the virtual machine UUID, create a virtual machine tenant switching task, and record the return result. Then, users log in to the cloud platform using the target tenant, pass in transfer_id and transfer_id, call the receive transfer interface, and complete the virtual machine switching project process.

3. The method for switching virtual machine tenants on a cloud management platform according to claim 1, characterized in that: In step R2, the Nova interface is extended to implement interfaces for creating, receiving, querying, and deleting virtual machine transfer tasks, thereby enabling full lifecycle management of virtual machine tenant switching tasks.

4. The method for switching virtual machine tenants on a cloud management platform according to claim 1, characterized in that: In step R3, to address the limitation that the native Cinder component only supports tenant switching for volumes and snapshots in the available state, the Cinder volume transfer interface is extended to support tenant switching for in-use volumes where the volume backend does not record user project or user information, and also supports switching tenant information for in-use volumes where the volume backend records user project or user information. Furthermore, a backend API is provided to support real-time modification of project and user in-use volume tenant switching information.

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

6. A cloud management platform virtual machine tenant switching system according to any one of claims 1-5, characterized in that: The system consists of computing components, storage components, scheduling components, network components, and mirroring components; The compute component Nova coordinates and calls upon storage, network, and scheduling components to complete the virtual machine tenant switching function; Extend the Nova interface of the computing component; After the Cinder storage component's native transfer interface is extended, it supports the transfer of in-use volumes and snapshots; After the Placement interface of the scheduling component is extended, it supports the interfaces for obtaining, updating, and deleting consumers, realizing full lifecycle management of virtual machine consumer data; After the Neutron network component natively updates the port interface, it updates the port project and user, and realizes the function of switching tenants for network ports. The Glance mirror component natively supports the function of configuring tenants for images, which can be achieved by directly calling the image update interface.

7. A cloud management platform system for switching virtual machine tenants according to claim 6, characterized in that: The computing component extends the interfaces of the OpenStack components Nova, Cinder, Placement, and Neutron. Nova acts as the initiator, coordinating the calls to the interfaces provided by other components. Users log in to the cloud platform as the source tenant, directly call the newly added create transfer interface of the Nova component, pass in the virtual machine UUID, create a virtual machine tenant switching task, and record the return result. Then, users log in to the cloud platform as the target tenant, pass in transfer_id and transfer_id, call the receive transfer interface, and complete the virtual machine switching project process.

8. A cloud management platform system for switching virtual machine tenants according to claim 6, characterized in that: The storage component extends the Nova interface to implement interfaces for creating, receiving, querying, and deleting virtual machine transfer tasks, thereby enabling full lifecycle management of virtual machine tenant switching tasks.

9. A cloud management platform system for switching virtual machine tenants according to claim 6, characterized in that: The scheduling component addresses the limitation of the native Cinder component, which only supports tenant switching for volumes and snapshots in the available state. It extends the Cinder volume transfer interface to support tenant switching for in-use volumes where the volume backend does not record user project or user information, and supports switching for in-use volumes where the volume backend records user project or user information. It also provides a backend API to support real-time modification of project and user in-use volume tenant switching information.

10. A cloud management platform system for switching virtual machine tenants according to claim 6, characterized in that: The network component extends the Neutron interface's native port update interface to update port user and project attributes, enabling tenant metadata changes. For the underlying network interface device, to ensure maximum availability of business virtual machines, it is divided according to network type. For classic network types, the underlying physical network interface device tenant is updated directly online. For VPC type networks, the virtual machine needs to be shut down before updating the underlying physical network interface device tenant.

Images