Volume migration method and system based on OpenStack

Abstract

The invention relates to the technical field of cloud computing, in particular to a volume migration method and system based on OpenStack, and the method comprises the following steps: a user initiates a volume type switching request to a Cinder service through a console or a REST interface, and appoints a target volume type and selectable bandwidth upper limit parameters; the method has the beneficial effects that the virtual machine is supported to be migrated to other available areas online, the functions of displaying the volume migration progress, terminating volume migration, migrating the volume in the mounted state under the state that the virtual machine is turned off, supporting and limiting the bandwidth during volume migration and the like are provided, the flexibility of the OpenStack service is improved, and the availability of the virtual machine and the service running in the virtual machine is enhanced.

Description

Technical Field

[0001] This invention relates to the field of cloud computing technology, specifically to a method and system for volume migration based on OpenStack. Background Technology

[0002] Originating from cloud computing, OpenStack has experienced rapid and rapid development. IaaS (Infrastructure as a Service) is currently the most widely offered cloud service by cloud providers, and OpenStack is its most typical representative. As a large-scale cloud operating system, OpenStack controls computing, network, and storage resources, provides a web-based visual interface for easy administrator control, employs an authentication mechanism to grant users permissions and resources, and has its own standard infrastructure and service functions. However, it also includes other components to provide additional services, ensuring high availability of user applications.

[0003] Virtual machine volume migration is the operation of migrating a virtual machine from one physical server to another. Its main functions are as follows: (1) It can achieve balanced allocation of storage resource load, which helps to make reasonable use of storage resources and avoids affecting storage performance due to high storage pool utilization. (2) It allows administrators to maintain, upgrade, or replace storage hardware without interrupting service. (3) It meets customers' needs for changing storage specifications, allowing customers to choose high-performance storage according to the actual application situation.

[0004] However, while current open-source volume migration solutions in OpenStack enable online volume migration while the virtual machine is powered on, they have limited capabilities. These limitations include not supporting the display of volume migration progress, not supporting the termination of volume migration progress, not being able to migrate mounted volumes while the virtual machine is powered off, and not supporting bandwidth limits during volume migration. These drawbacks affect the flexibility and usability of the functionality. Summary of the Invention

[0005] The purpose of this invention is to provide a method and system for volume migration based on OpenStack, which supports the online migration of virtual machines to other availability zones, improves the flexibility of OpenStack services, and enhances the availability of virtual machines and the services running on them, thereby solving the problems mentioned in the background art.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a method for volume migration based on OpenStack, comprising the following steps:

[0007] Users can initiate a volume type switching request to the Cinder service via the console or REST interface, specifying the target volume type and optional bandwidth limit parameters;

[0008] The Cinder API service verifies the validity of the request body, including: verifying the validity of the target volume type name or UUID, prioritizing searching by UUID, and searching by name if the search fails; returning an error if neither is found; verifying that the bandwidth limit parameter is a positive integer and does not exceed 1 GiB, and verifying user permissions.

[0009] After authentication and parameter verification are successful, the Cinder API forwards the request to the corresponding Cinder-Volume backend service via RPC.

[0010] The Cinder-Volume backend service checks whether the current backend belongs to the target volume type: if it does, it directly updates the volume type attribute and returns success; if it does not, it calls the Cinder-Scheduler service via RPC to select a new Cinder-Volume backend that matches the target volume type and specifications, and creates a new volume synchronously.

[0011] Preferably, after the new volume is created, the process further includes: the original Cinder-Volume service sending a migration request to the Nova-API via the RESTful interface of the Nova callback, the request body encapsulating the virtual machine UUID, the original volume UUID, the new volume UUID, and bandwidth limit parameters; the Nova-API performing the following verifications: authenticating the caller's token permissions; querying the virtual machine status, returning failure if it is not Active or the task status is not empty; verifying the mount relationship between the original volume and the virtual machine, returning failure if it is not mounted; checking the validity of the bandwidth limit parameters, returning failure if it exceeds the configured maximum value; after the verification passes, the Nova-API updates the virtual machine task status to "volume migration in progress" and performs subsequent migration operations by calling the Nova-Compute service via RPC.

[0012] Preferably, the Nova-Compute service performs the migration operation by including the following steps: Mounting the target volume to the compute node where the virtual machine resides: Obtaining the compute node IP, HBA card WWPN, and hostname information; Notifying the Cinder-Volume service to complete the mounting via the Cinder-API and obtaining the mounting information; Querying the operating system mapping of the virtual disk device on the local compute node; Checking the virtual machine's running status, and if it is in a shutdown state, starting it via the virtualization driver and pausing it to the Paused state; Calling the block device copy interface of the virtualization driver layer to start the volume copy, passing in the user-specified bandwidth limit; Periodically querying the copy progress and rate, and updating the volume metadata via the Cinder-API, with the storage format being JSON.

[0013] Preferably, it also includes volume migration progress query and interruption functions, with the following specific steps: Progress query: The user passes the new volume UUID through the interface provided by Cinder-API; Cinder-API queries the volume copy progress field from the database, and returns 0 if it does not exist;

[0014] Interrupted migration: The user initiates an interruption request by passing the original volume UUID through the Cinder-API; the Cinder-API verifies the user's permissions and volume status, and returns an error if the volume is not in migration or has been completed; if interruption is allowed, the Cinder-API sends a termination command to the Nova-Compute service through the Nova-API; Nova-Compute calls the driver layer interface to stop the volume copy, deletes the new volume mount information, and the Cinder-Volume service cleans up the new volume.

[0015] Preferably, when the virtual machine task status is "volume migration in progress", other operations are restricted in the following way: add a decorator to the API entry response function of Nova-API for virtual machine shutdown, restart, hot migration, operating system reset and configuration modification operations; the decorator intercepts the request and checks the virtual machine task status, and if it is "volume migration in progress", the operation is rejected and an error message is returned.

[0016] A system for a volume migration method based on OpenStack, comprising:

[0017] User Request Module: Initiates a volume type switching request to the Cinder service via the console or REST interface. The request body includes the target volume type identifier and optional bandwidth limit parameters.

[0018] Cinder API service module: Verifies the validity of the request body, including the validity of the target volume type identifier and the validity of the bandwidth parameters; after successful authentication, it forwards the request to the corresponding Cinder-Volume backend service via RPC.

[0019] The Cinder-Volume backend service module checks whether the current backend belongs to the target volume type. If it does, it directly updates the volume type attributes and returns the result. If it does not, it calls the Cinder-Scheduler service via RPC to request a new volume, receives the appropriate backend information returned by Cinder-Scheduler, and synchronously creates a new volume. After the new volume is created, it sends a migration request to the Nova service through the RESTful interface of the Nova callback. The request body encapsulates the virtual machine UUID, the original volume UUID, the new volume UUID, and bandwidth limit parameters.

[0020] Preferably, the Nova service module includes the following sub-modules:

[0021] The Nova-API service submodule receives the migration request from Cinder-Volume, authenticates the caller's token, queries the virtual machine status (if not Active or the task status is not empty, it returns failure and identifies the status and task information), checks the mount relationship between the original volume and the virtual machine (if not mounted, it returns failure), verifies the validity of the bandwidth parameters (if exceeding the configured maximum value, it returns failure), and updates the virtual machine task status to "volume migration in progress" and performs the migration operation by calling the Nova-Compute service via RPC.

[0022] Status Interception Submodule: Adds decorators to the API entry response functions for virtual machine shutdown, restart, hot migration, operating system reset, and configuration modification operations; intercepts requests and checks the virtual machine task status; if it is "volume migration in progress", the operation is rejected and an error message is returned.

[0023] Preferably, the Nova-Compute service module includes the following functional units:

[0024] Target Volume Mounting Unit: Obtains the compute node IP, HBA card WWPN and hostname information, and notifies the Cinder-Volume service to mount the target volume to the compute node via Cinder-API; receives the mount information returned by Cinder-Volume, and queries the operating system mapping of the virtual disk device on the local compute node;

[0025] Virtual machine status processing unit: Checks the virtual machine running status. If it is in a shutdown state, it starts the virtualization driver and pauses it to the Paused state.

[0026] Volume copy execution unit: Initiates volume copy by calling the block device copy interface of the virtualization driver layer, passing in the user-specified bandwidth limit; periodically queries the copy progress and rate, and updates volume metadata through Cinder-API.

[0027] Preferably, it also includes a progress query and interruption management module, the specific functions of which include:

[0028] Progress query submodule: Provides a query interface, with the new volume UUID as the input parameter; the Cinder-API service queries the volume copy progress field in the database based on the UUID, and returns 0 if the progress does not exist;

[0029] Interruption handling submodule: Provides an interrupt interface with the original volume UUID as input; verifies user permissions and volume status; returns an error if the volume is not in migration or has been completed; if interruption is allowed, sends a termination command to the Nova-Compute service via Nova-API; Nova-Compute calls the driver layer interface to stop volume copying, deletes the new volume mount information, and the Cinder-Volume service cleans up the new volume.

[0030] Preferably, the Cinder-Scheduler service module includes the following resource scheduling logic: receiving new volume application requests from the Cinder-Volume service, parsing the volume specifications and target volume type requirements; filtering qualified Cinder-Volume backends based on the remaining capacity, IOPS performance, and volume type compatibility of the backend storage resources; and returning the selected backend information to the original Cinder-Volume service via RPC to ensure that the new volume creation is consistent with the original volume specifications and target type.

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

[0032] The method and system for volume migration based on OpenStack proposed in this invention support the online migration of virtual machines to other availability zones. It provides functions such as displaying the progress of volume migration, terminating volume migration, migrating mounted volumes while the virtual machine is powered off, and supporting bandwidth limitation during volume migration, thereby improving the flexibility of OpenStack services and enhancing the availability of virtual machines and the services running on them. Attached Figure Description

[0033] Figure 1 This is a flowchart of the method of the present invention. Detailed Implementation

[0034] 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.

[0035] Example 1: This invention provides a technical solution: a method for volume migration based on OpenStack, comprising the following steps:

[0036] Users can request the Cinder service via the console or through the REST interface to perform a volume type switch operation on a specified volume. The request body must specify the current volume type to be switched to. Optional administrator users can specify the upper limit of bandwidth for volume migration. The default bandwidth limit is -1, which means that when the migrated volume is in-use, the default bandwidth limit of the migrated volume provided by the Nova service is used.

[0037] Upon receiving a volume migration request, Cinder's API service first checks if the request body meets the requirements. For example, the user must specify a valid volume type name or UUID; that is, the user-provided volume type UUID or name must exist. The verification process involves first checking if the given volume type is a valid UUID. If it is, the UUID is used for lookup. If it is not a valid UUID or cannot be found by UUID, the name is searched. If no result is found, an error is returned, prompting the user to select an available volume type. If the user specifies a bandwidth limit for the volume migration, the input parameter must first be checked for validity. For example, the input parameter must be a positive integer and should not exceed 1 GiB, and the user must have permission to set the bandwidth limit. If these requirements are not met, failure is returned.

[0038] After authentication and input parameter validity checks are completed, the Cinder API service forwards the user's request to the corresponding Cinder-Volume backend via RPC. Upon receiving the volume type change request, the Cinder-Volume backend service first verifies whether the current Cinder-Volume service backend belongs to the volume type the user requested to change. If the current Cinder-Volume backend already belongs to the given volume type, it directly updates the volume's type attribute and returns the result. If the current Cinder-Volume backend does not belong to the user-specified volume type, the Cinder-Volume service remotely calls the Cinder-Scheduler service via RPC to request a new volume with the same specifications as the current volume and using the user-specified volume type. After the Cinder-Scheduler selects a suitable Cinder-Volume backend, it returns the backend information to the original Cinder-Volume service via RPC. The original Cinder-Volume service then synchronously requests the new Cinder-Volume service selected by the Cinder-Scheduler to create a new volume via RPC. After the new volume is created, the original Cinder-Volume service notifies the Nova service to perform the remaining volume migration processing through the Nova callback RESTful interface. The callback request body encapsulates the virtual machine's UUID, the original volume's UUID for switching types, the new volume's UUID, and the bandwidth limit during the switching process (which is optional).

[0039] When the Nova-API service receives a volume switch request, it first authenticates the caller's token to confirm that the API caller has sufficient permissions to use the API. After authentication, Nova-API queries the virtual machine's status using its UUID. If the virtual machine's status is not Active or its task status attribute is not empty, it returns a request failure result to the caller, indicating the virtual machine's status and the currently executing task in the returned structure. If the virtual machine's status is normal, the next step is to check the binding relationship between the virtual machine and the original volume. If the original volume is not mounted on the specified virtual machine, it returns a request failure result to the caller. Finally, it checks whether the bandwidth limit field in the request body is a valid number and whether the specified bandwidth does not exceed the configured maximum bandwidth limit (generally set to 1 GiB). If the requested bandwidth is incorrect, it also returns a request failure result to the caller.

[0040] After verification, the Nova-API service needs to update the virtual machine's task status field to indicate that the virtual machine is undergoing a volume migration operation. After updating the status in the database, the Nova-Compute service on the compute node where the virtual machine is located is remotely called via RPC, and the Nova-Compute service performs the next migration operation.

[0041] Once the virtual machine's task state is set to "volume migration in progress," the Nova-API code needs to be adjusted to prevent operations such as virtual machine shutdown, restart, hot migration, operating system reset, and configuration modification from being executed, thus avoiding interference with the completion of the volume migration. A simple method is to intercept requests using decorators in the response functions of the relevant API entry points, achieving state interception with minimal code modification.

[0042] After receiving a volume migration request from Nova-API, the Nova-Compute service first needs to mount the target volume to the compute node where the virtual machine resides. Specifically, it first obtains information such as the compute node's IP address, HBA card's WWPN, and hostname, and then passes this information to the Cinder-API service through the update mount information interface. Cinder-API then notifies the Cinder-Volume service via RPC to mount the specified volume to the given compute node. After Cinder-Volume completes the mounting, it returns the mount information and responds to the Nova-Compute service through Cinder-API. The Nova-Compute service then uses the mount information provided by Cinder-Volume to find the mapping of the virtual disk device on the operating system on the local compute node through the interface.

[0043] After retrieving the virtual disk information, the Nova-Compute service checks the running status of the virtual machine. If the virtual machine is currently shut down, it starts the shut-down virtual machine through the suspend operation interface implemented by the virtualization driver and keeps the virtual machine in a paused state.

[0044] After completing the operations described in the previous step, the volume copy process is initiated through the block device copy interface (blockcopy) implemented by the virtualization driver layer. When initiating the volume copy process, the user-specified upper limit of the volume copy bandwidth is passed in to ensure that the volume copy process does not affect the use of other virtual machines on the compute node. During the copy process, the volume copy progress and copy rate are periodically queried at fixed intervals. This data is then updated in the volume's metadata via the Cinder-API metadata interface. The storage format is not limited; JSON format can be considered for easy formatting.

[0045] The Cinder-API provides an interface for querying the progress of type switching. The input parameter is the UUID of the new volume, and the return information such as the progress and speed of volume copying. The Cinder-API service queries the database for the corresponding data field of the volume based on the UUID of the volume input parameter, and obtains the volume copying progress stored in the database. If the field does not exist in the database, the copying progress is 0.

[0046] The Cinder-API provides an interface for interrupting volume switching. The input parameter of this interface is the original volume's UUID. First, it checks the user's API access permissions; if permissions are insufficient, it returns an exception. Then, it checks the current volume status. If the volume is not in the process of migration or the migration is already complete, it returns an exception with the reason for the error. If the volume is currently being migrated, the Cinder-API finds the information of the virtual machine currently mounted on the volume and sends the command to terminate volume copy, the volume UUID, and the virtual machine UUID as the request body through the interface provided by the Nova-API. After verifying that the request is valid, the Nova-API sends the command to terminate volume copy to the Nova-Compute service via RPC. Upon receiving the request, Nova-Compute stops the volume copy process using the command to terminate online volume copy provided by the driver layer. After the volume copy process is stopped, Nova-Compute calls back to the Cinder-API service and deletes the mount information of the new volume. The Cinder-Volume service then cleans up the new volume, thus terminating the backend volume switch.

[0047] Example 2, based on Example 1, proposes a system for volume migration based on OpenStack, including:

[0048] User Request Module: Initiates a volume type switching request to the Cinder service via the console or REST interface. The request body includes the target volume type identifier and optional bandwidth limit parameters.

[0049] Cinder API service module: Verifies the validity of the request body, including the validity of the target volume type identifier and the validity of the bandwidth parameters; after successful authentication, it forwards the request to the corresponding Cinder-Volume backend service via RPC.

[0050] The Cinder-Volume backend service module checks whether the current backend belongs to the target volume type. If it does, it directly updates the volume type attributes and returns the result. If it does not, it calls the Cinder-Scheduler service via RPC to request a new volume, receives the appropriate backend information returned by Cinder-Scheduler, and synchronously creates a new volume. After the new volume is created, it sends a migration request to the Nova service through the RESTful interface of the Nova callback. The request body encapsulates the virtual machine UUID, the original volume UUID, the new volume UUID, and bandwidth limit parameters.

[0051] The Nova service module includes the following sub-modules: The Nova-API service sub-module: After receiving a migration request from Cinder-Volume, it authenticates the caller's token; queries the virtual machine status, returning failure if it is not Active or the task status is not empty, and identifies the status and task information; checks the mount relationship between the original volume and the virtual machine, returning failure if it is not mounted; verifies the validity of the bandwidth parameters, returning failure if it exceeds the configured maximum value; after successful verification, updates the virtual machine task status to "Volume Migrating in Progress" and performs the migration operation via RPC call to the Nova-Compute service; The status interception sub-module: adds decorators to the API entry response functions for virtual machine shutdown, restart, hot migration, operating system reset, and configuration modification operations; intercepts requests and checks the virtual machine task status, rejecting the operation and returning an error message if it is "Volume Migrating in Progress".

[0052] The Nova-Compute service module includes the following functional units: Target Volume Mounting Unit: Obtains the compute node IP, HBA card WWPN, and hostname information, and notifies the Cinder-Volume service to mount the target volume to the compute node via Cinder-API; receives the mount information returned by Cinder-Volume and queries the operating system mapping of the virtual disk device on the local compute node; Virtual Machine Status Processing Unit: Checks the virtual machine's running status, and if it is in a shutdown state, starts it through the virtualization driver and pauses it to the Paused state; Volume Copy Execution Unit: Calls the block device copy interface of the virtualization driver layer to start volume copying, passing in the user-specified bandwidth limit; periodically queries the copy progress and rate, and updates the volume metadata via Cinder-API.

[0053] It also includes a progress query and interruption management module, with specific functions including: Progress query submodule: provides a query interface with the new volume UUID as input parameter; the Cinder-API service queries the volume copy progress field in the database based on the UUID, and returns a progress of 0 if it does not exist; Interruption handling submodule: provides an interruption interface with the original volume UUID as input parameter; verifies user permissions and volume status, and returns an error if the volume is not in migration or has been completed; if interruption is allowed, it sends a termination command to the Nova-Compute service through the Nova-API; Nova-Compute calls the driver layer interface to stop the volume copy, deletes the new volume mount information, and the Cinder-Volume service cleans up the new volume.

[0054] The Cinder-Scheduler service module includes the following resource scheduling logic: receiving new volume request requests from the Cinder-Volume service, parsing the volume specifications and target volume type requirements; filtering eligible Cinder-Volume backends based on the remaining capacity of backend storage resources, IOPS performance, and volume type compatibility; and returning the selected backend information to the original Cinder-Volume service via RPC to ensure that the new volume creation is consistent with the original volume specifications and target type.

[0055] 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 volume migration based on OpenStack, characterized in that: Includes the following steps: Users can initiate a volume type switching request to the Cinder service via the console or REST interface, specifying the target volume type and optional bandwidth limit parameters; The Cinder API service verifies the validity of the request body, including: verifying the validity of the target volume type name or UUID, prioritizing the search by UUID, and searching by name if the search fails; if neither is found, an error is returned. Verify that the bandwidth limit parameter is a positive integer and does not exceed 1 GiB, and verify user permissions; After authentication and parameter verification are successful, the Cinder API forwards the request to the corresponding Cinder-Volume backend service via RPC. The Cinder-Volume backend service checks whether the current backend belongs to the target volume type: if it does, it directly updates the volume type attribute and returns success; if it does not, it calls the Cinder-Scheduler service via RPC to select a new Cinder-Volume backend that matches the target volume type and specifications, and creates a new volume synchronously.

2. The method for volume migration based on OpenStack according to claim 1, characterized in that: After the new volume is created, the following steps are taken: The original Cinder-Volume service sends a migration request to the Nova-API via the RESTful interface of the Nova callback. The request body encapsulates the virtual machine UUID, the original volume UUID, the new volume UUID, and bandwidth limit parameters. The Nova-API performs the following verifications: authenticates the caller's token permissions; queries the virtual machine status, and returns failure if it is not Active or the task status is not empty; verifies the mount relationship between the original volume and the virtual machine, and returns failure if it is not mounted; checks the validity of the bandwidth limit parameters, and returns failure if it exceeds the configured maximum value; after the verification passes, the Nova-API updates the virtual machine task status to "volume migration in progress" and performs subsequent migration operations by calling the Nova-Compute service via RPC.

3. The method for volume migration based on OpenStack according to claim 2, characterized in that: The Nova-Compute service performs migration operations including the following steps: Mounting the target volume to the compute node where the virtual machine resides: Obtaining the compute node IP, HBA card WWPN, and hostname information; Notifying the Cinder-Volume service to complete the mounting via the Cinder-API and obtaining mounting information; Querying the operating system mapping of the virtual disk device on the local compute node; Checking the virtual machine's running status; If it is in a shutdown state, starting it via the virtualization driver and pausing it to the Paused state; Calling the block device copy interface of the virtualization driver layer to start the volume copy, passing in the user-specified bandwidth limit; Periodically querying the copy progress and rate, updating the volume metadata via the Cinder-API, and storing it in JSON format.

4. The method for volume migration based on OpenStack according to claim 3, characterized in that: It also includes volume migration progress query and interruption functions. The specific steps are as follows: Progress query: The user passes the new volume UUID through the interface provided by Cinder-API; Cinder-API queries the volume copy progress field from the database. If it does not exist, it returns a progress of 0. Interrupted migration: The user initiates an interruption request by passing the original volume UUID through the Cinder-API; the Cinder-API verifies the user's permissions and volume status, and returns an error if the volume is not in migration or has been completed; if interruption is allowed, the Cinder-API sends a termination command to the Nova-Compute service through the Nova-API; Nova-Compute calls the driver layer interface to stop the volume copy, deletes the new volume mount information, and the Cinder-Volume service cleans up the new volume.

5. The method for volume migration based on OpenStack according to claim 4, characterized in that: When the virtual machine task status is "volume migration in progress", other operations are restricted in the following way: Add a decorator to the API entry response function of Nova-API for virtual machine shutdown, restart, hot migration, operating system reset and configuration modification operations; the decorator intercepts the request and checks the virtual machine task status. If it is "volume migration in progress", the operation is rejected and an error message is returned.

6. A system for a volume migration method based on OpenStack as described in claim 5, characterized in that: include: User Request Module: Initiates a volume type switching request to the Cinder service via the console or REST interface. The request body includes the target volume type identifier and optional bandwidth limit parameters. Cinder API service module: Verifies the validity of the request body, including the validity of the target volume type identifier and the validity of the bandwidth parameters; after successful authentication, it forwards the request to the corresponding Cinder-Volume backend service via RPC. The Cinder-Volume backend service module checks whether the current backend belongs to the target volume type. If it does, it directly updates the volume type attributes and returns the result. If it does not, it calls the Cinder-Scheduler service via RPC to request a new volume, receives the appropriate backend information returned by Cinder-Scheduler, and synchronously creates a new volume. After the new volume is created, it sends a migration request to the Nova service through the RESTful interface of the Nova callback. The request body encapsulates the virtual machine UUID, the original volume UUID, the new volume UUID, and bandwidth limit parameters.

7. The system according to claim 6, characterized in that: The Nova service module includes the following sub-modules: The Nova-API service submodule receives the Cinder-Volume migration request, authenticates the caller's token, queries the virtual machine status, and returns failure if it is not Active or the task status is not empty, and identifies the status and task information. Check the mount relationship between the original volume and the virtual machine; if not mounted, return failure. Verify the validity of the bandwidth parameter; if it exceeds the configured maximum value, return failure. After successful verification, the virtual machine task status is updated to "volume migration in progress", and the migration operation is performed by calling the Nova-Compute service via RPC. The State Interception Submodule adds decorators to the API entry response functions for virtual machine shutdown, restart, hot migration, operating system reset, and configuration modification operations. Intercept the request and check the virtual machine task status. If it is "volume migration in progress", reject the operation and return an error message.

8. The system according to claim 7, characterized in that: The Nova-Compute service module includes the following functional units: Target Volume Mounting Unit: Obtains the compute node IP, HBA card WWPN and hostname information, and notifies the Cinder-Volume service to mount the target volume to the compute node via Cinder-API; receives the mount information returned by Cinder-Volume, and queries the operating system mapping of the virtual disk device on the local compute node; Virtual machine status processing unit: Checks the virtual machine running status. If it is in a shutdown state, it starts the virtualization driver and pauses it to the Paused state. Volume copy execution unit: Initiates volume copy by calling the block device copy interface of the virtualization driver layer, passing in the user-specified bandwidth limit; periodically queries the copy progress and rate, and updates volume metadata through Cinder-API.

9. A system according to claim 8, characterized in that: It also includes a progress query and interruption management module, with specific functions including: Progress query submodule: Provides a query interface, with the new volume UUID as the input parameter; the Cinder-API service queries the volume copy progress field in the database based on the UUID, and returns 0 if the progress does not exist; Interruption handling submodule: Provides an interrupt interface with the original volume UUID as input; verifies user permissions and volume status; returns an error if the volume is not in migration or has been completed; if interruption is allowed, sends a termination command to the Nova-Compute service via Nova-API; Nova-Compute calls the driver layer interface to stop volume copying, deletes the new volume mount information, and the Cinder-Volume service cleans up the new volume.

10. A system according to claim 9, characterized in that: The Cinder-Scheduler service module includes the following resource scheduling logic: receiving new volume request requests from the Cinder-Volume service, parsing the volume specifications and target volume type requirements; filtering eligible Cinder-Volume backends based on the remaining capacity of backend storage resources, IOPS performance, and volume type compatibility; and returning the selected backend information to the original Cinder-Volume service via RPC to ensure that the new volume creation is consistent with the original volume specifications and target type.

Images