Storage offloading for VM migration across virtualization platforms

Abstract

This invention provides a method and system for migrating virtual machines (VMs) and their associated virtual machine disks hosted on a datastore to a native-compatible volume format on the same storage platform, without requiring additional capacity and without impacting existing business operations. [Solution] The method is based on a process that includes sending a command to a virtual machine management system requesting the source identifier of the source volume to be migrated, obtaining the source identifier of the source volume, obtaining the destination identifier of the destination volume, selecting a copy configuration based on the parameters of the source volume identified by the source identifier and the destination volume identified by the destination identifier, and performing a copy operation on the source volume according to the copy configuration.

Description

Technical Field

[0001] The present disclosure generally relates to storage systems, and more particularly to the migration of virtual machines and / or volumes across virtualization platforms.

Background Art

[0002] When a virtual machine (VM) platform vendor is acquired by a new entity, the license costs that may arise from the new entity become unpredictable, and the costs may suddenly increase. In such a situation, the sharp increase in license costs accelerates the migration from such VM platforms. Such customers may increase their use of Kubernetes to run more productive IT services in a cloud-native environment and may use applications that can run existing VMs on Kubernetes without changing the applications.

Summary of the Invention

Problems to be Solved by the Invention

[0003] Regarding the ability to apply migrations from one virtualization platform to another, there are problems in the related art. Existing VM migration tools transfer VM data from a source logical device (LDEV) to a target LDEV by server-based data copy technology. Server-based copy technology consumes network and server resources and can be inefficient. In the related art, since existing migration technologies do not know the source LDEV and storage array, storage-based copy technology cannot be used either.

[0004] It is necessary to reduce the consumption of CPU and network resources by offloading data copying to a storage array.

Means for Solving the Problems

[0005] The exemplary embodiments described herein relate to methods and systems for migrating virtual machines (VMs) and their associated virtual machine disks hosted on a datastore to a natively compatible volume format on the same storage platform without additional capacity requirements and without impacting existing business operations. The exemplary embodiments further provide a Kubernetes-native method for creating thin clone images of these disks and importing them directly into Kubernetes as static persistent volumes attached to VM pods, enabling the virtual machines to operate unchanged in the target Kubernetes cluster.

[0006] Exemplary embodiments further include methods for reducing VM migration time and CPU / network consumption during migration across virtualization platforms.

[0007] An exemplary embodiment further includes a method and system for migrating virtual machines (VMs) and their associated datastores between a source server and a destination server in a networked computing environment. Such exemplary embodiments involve efficiently transferring VM data while ensuring compatibility and minimal downtime during the migration process by utilizing a storage offload engine in the destination server, storage subsystem, and their copy technology.

[0008] In an exemplary embodiment, a storage offload engine is used to offload data transfer operations from the CPU to the storage subsystem, thereby improving migration efficiency and reducing the load on the main processor. The storage offload engine retrieves the volume identifiers associated with the source and destination datastores and requests the storage subsystem to copy data between these volumes.

[0009] In an exemplary embodiment, the storage offload engine also selects a copy technology based on the conditions provided in the copy technology list, ensuring that the appropriate method is used for data replication. This helps optimize the migration process by selecting the copy technology best suited to a given storage environment.

[0010] The exemplary embodiments described herein can be utilized by industries that have legacy server virtualization platforms and wish to modernize to newer virtualization platforms. Such exemplary embodiments can be implemented on private clouds, operating systems, and storage systems, including hybrid cloud environments, and can function as storage management plugins for VM migration and operate in Kubernetes-based container orchestration environments.

[0011] In the exemplary embodiments described herein, the storage offload engine also determines the data formats of the source and destination datastores to ensure compatibility during the migration process. If the data formats are different, a data format conversion process is triggered to ensure seamless VM migration.

[0012] Exemplary embodiments also involve creating a migration plan that specifies the source and destination VMs, datastores, migration type (warm or cold), and storage offload settings. These plans are used to orchestrate the migration process and ensure that the VMs and their associated data are transferred accurately and efficiently.

[0013] Aspects of the present disclosure may include a method that, based on the execution of a process including sending a command to a virtual machine management system requesting the source identifier of the source volume to be migrated, obtains the source identifier of the source volume, obtains the destination identifier of the destination volume, selects a configuration based on the parameters of the source volume identified by the source identifier and the destination volume identified by the destination identifier, and performs an operation on the source volume according to the configuration.

[0014] Aspects of the present disclosure may include a computer program that, based on the execution of a process including sending an instruction to a virtual machine management system requesting the source identifier of a source volume to be migrated, obtains the source identifier of a source volume, obtains the destination identifier of a destination volume, selects a configuration based on the parameters of the source volume identified by the source identifier and the destination volume identified by the destination identifier, and performs an operation on the source volume according to the configuration. The computer program and instructions are maintained on a non-temporary computer-readable medium and can be executed by one or more processors.

[0015] Aspects of the present disclosure may include a system that includes means for obtaining a source identifier for a source volume, means for obtaining a destination identifier for a destination volume, means for selecting a configuration based on parameters of the source volume identified by the source identifier and the destination volume identified by the destination identifier, and means for performing an operation on the source volume according to the configuration.

[0016] Aspects of the present disclosure may include a device comprising a CPU configured to execute methods and instructions that include obtaining a source identifier for a source volume, obtaining a destination identifier for a destination volume, selecting a configuration based on parameters of the source volume identified by the source identifier and the destination volume identified by the destination identifier, and performing operations on the source volume according to the configuration. [Brief explanation of the drawing]

[0017] [Figure 1] This figure shows a networked computing environment with multiple servers and storage subsystems, according to an exemplary embodiment. [Figure 2] This diagram illustrates an exemplary embodiment of a networked computing environment focusing on virtual machines (VMs) and data storage across source and destination servers, along with the underlying storage subsystem. [Figure 3]This diagram shows a detailed view of the components and their roles in a virtualized environment, including source and destination servers, along with a storage subsystem, according to an exemplary embodiment. [Figure 4] This figure shows an overview of the data tables and lists used according to the first exemplary embodiment. [Figure 5] This figure shows a mapping between virtual machine (VM) IDs and their corresponding datastores, according to an exemplary embodiment. [Figure 6] This figure shows detailed information about a datastore, including capacity, data format, associated storage identifier, and volume identifier, according to an exemplary embodiment. [Figure 7] This diagram details a migration plan for virtual machines (VMs) and their associated datastores between a source server and a destination server, according to an exemplary embodiment. [Figure 8] This figure shows a mapping between virtual machine (VM) IDs and their corresponding datastores, according to an exemplary embodiment. [Figure 9] This figure shows detailed information about a datastore, including capacity, data format, associated storage identifier, and volume identifier, according to an exemplary embodiment. [Figure 10] This figure shows information about various copying techniques and their associated conditions, based on exemplary embodiments. [Figure 11] This flowchart details the process of a migration controller for migrating virtual machines (VMs) according to an exemplary embodiment. [Figure 12] This flowchart details the process of a storage offload engine according to an exemplary embodiment. [Figure 13] This figure shows a flowchart of a modified process of the storage offload engine according to a second exemplary embodiment. [Figure 14]Figure showing details of components and their roles in a virtualized environment with a source server and a destination server, along with a storage subsystem, according to an exemplary embodiment. [Figure 15] Figure showing in detail a migration plan for virtual machines (VMs) and their associated data stores between a source server and a destination server, according to a third exemplary embodiment. [Figure 16] Flowchart showing in detail the process of a migration controller, according to a third exemplary embodiment. [Figure 17] Represents a flowchart of a data in-place migration engine showing in detail the process for validating virtual machine (VM) volumes during migration, converting data formats if necessary, and managing them, according to an exemplary embodiment. **DETAILED DESCRIPTION OF THE INVENTION**

[0018] The following detailed description provides details of the figures and examples of the present application. Reference numerals and descriptions of overlapping elements between figures are omitted for clarity. The terms used throughout the description are provided as examples and are not intended to be limiting. For example, the use of the term "automatically" can include fully automatic or semi-automatic implementations, including user or administrator control over specific embodiments of the implementation, depending on the desired implementation of those skilled in the art practicing the implementation of the present application. The selection can be performed by the user via a user interface or other input means, or can be implemented via a desired algorithm. Exemplary embodiments as described herein can be used either alone or in combination, and the functions of those exemplary embodiments can be implemented via any means according to the desired embodiment.

[0019] Figure 1 shows a networked computing environment with multiple servers and storage subsystems according to an exemplary embodiment. The source server (200) and destination server (300) are connected via a network indicated by a network symbol. The storage subsystem (100) is connected to the source server (200) and destination server (300) via a network interface (NET I / F 110). The management server (400) is connected to the destination server (300) and other servers or network devices. The source server (200) and destination server (300) each include a central processing unit (CPU) (120, 330), memory (130, 340), front-end interfaces (FE I / F) (210, 310), and back-end interfaces (BE I / F) (220, 320), respectively. The storage subsystem (100) includes the CPU (120), memory (130), drives (140), and network interface (NET I / F) (110). The management server (400) may include similar components to the source server (200) and destination server (300), but these are omitted in this diagram for clarity. The front-end interface (FE I / F) is typically used for client or network-facing connections, while the back-end interface (BE I / F) is used for internal connections such as storage or other servers.

[0020] As shown in Figure 1, the source server (200) may include a CPU (120), which is a central processing unit that performs computational tasks. The memory (130) may be in the form of random access memory (RAM) used for temporary data storage and high-speed access. The FE I / F (210) is a front-end interface for connecting to a network or other servers. The BE I / F (220) is a back-end interface for connecting to storage or other back-end systems.

[0021] As shown in Figure 1, the destination server (300) may be accompanied by a CPU (330), which is a central processing unit that performs computing tasks. The memory (340) may be in the form of RAM used for temporary data storage and high-speed access. The FE I / F (310) is a front-end interface for connecting to a network or other servers. The BE I / F (320) is a back-end interface for connecting to storage or other back-end systems.

[0022] As shown in Figure 1, the storage subsystem (100) may include a CPU (120), which is a central processing unit for managing storage operations. Memory (130) may be in the form of RAM used for storage management and high-speed access. Drives (140) include physical storage drives for persistent data storage, such as hard disk drives (HDDs) or solid-state drives (SSDs). The NET I / F (110) is a network interface for connecting to other servers or network devices.

[0023] As shown in Figure 1, the management server (400) is responsible for supervising and managing the destination server (300). The management server (400) can connect to other servers or network devices.

[0024] The source server (200) and the destination server (300) are connected via a network, as indicated by the network symbol. Furthermore, the storage subsystem (100) is connected to the source server (200) via a network interface (NET I / F110).

[0025] The management server (400) oversees the entire system, although some of the direct connections to other elements in Figure 1 are omitted for clarity. The front-end interface (FE I / F) is typically used for client or network-facing connections. The back-end interface (BE I / F) is used for internal connections such as storage or other servers.

[0026] This configuration represents a VM migration system, where VMs and data are migrated from the source server to the destination server, the storage subsystem provides the necessary persistent storage, and the management server handles management tasks.

[0027] Figure 2 shows an exemplary embodiment of a networked computing environment focusing on virtual machines (VMs) and data storage across source and destination servers, along with the underlying storage subsystem.

[0028] A source server (S server) 200 may include S-VMs (201), which are virtual machines running on the source server. An S datastore (202) is a datastore associated with the source server and is used to store data required by virtual machines or other applications. A single S datastore may store data for multiple VMs.

[0029] The destination server (S server) 300 may include a D-VM (301), which is a virtual machine running on the destination server. The D datastore (302) is a datastore associated with the destination server and is used to store data required by the virtual machine or other applications.

[0030] The storage subsystem 100 includes an S volume (101-a), which is a storage volume allocated to the source server. The D volume (101-b) is a storage volume allocated to the destination server. The pool (102) is a storage pool to which the volumes (S volume and D volume) are allocated. This pool represents a collective storage resource to which servers can dynamically allocate space as needed.

[0031] Source server (S server) 200 has a virtual machine (S-VM201) and a datastore (S datastore 202), indicating that the VM uses the datastore for its operations. Destination server (D server) 300 has a virtual machine (D-VM 301) and a datastore (D datastore 302), indicating that this VM uses its associated datastore.

[0032] The storage subsystem 100 manages the underlying physical storage and provides storage volumes to both the source and destination servers. The S volumes (101-a) and D volumes (101-b) are specific allocations from a dedicated storage pool (102) for the source and destination servers, respectively. These volumes are used to store data associated with their respective datastores (S datastore 202 and D datastore 302). This configuration can represent a virtualized environment where the data from the source server's VMs and datastores is migrated to the destination server's VMs and datastores by the storage subsystem that allocates the volumes.

[0033] Figure 3 is a diagram illustrating the components and their roles in a virtualization environment with source and destination servers, along with a storage subsystem, according to an exemplary embodiment. The source server (200) includes a VM manager (2001) and a storage control driver (2004), while the destination server (300) includes a migration controller (3001), a storage offload engine (3002), an external VM in the S-server control driver (3003), and a storage control driver (3004). The storage subsystem (100) may include a storage volume manager (1001) and a storage copy engine (1002).

[0034] The source server (S server) (200) may include the following elements: The VM manager (2001) manages virtual machines on the source server and handles VM lifecycle tasks such as creation, deletion, and migration. The VM manager (2001) also manages VM configurations such as CPU, memory, and storage. The storage control driver for the S server (2004) manages the interaction between the source server and the storage subsystem and handles tasks such as I / O operations, volume mapping, and storage commands.

[0035] The destination server (D server) (300) may include the following elements: A migration controller (3001) oversees the migration of VMs and their data from the source server to the destination server. A storage offload engine (3002) offloads data transfer from the CPU to the storage subsystem to improve efficiency. External VMs (3003) in the S server control driver allow the destination server to manage and interact with VMs running on the source server for migration purposes. A storage control driver for the D server (3004) manages the storage interactions of the destination server.

[0036] The storage subsystem (100) may include the following elements: A storage volume manager (1001) manages the storage volumes within the storage subsystem. A storage copy engine (1002) handles the copying and replication of data between storage volumes, ensuring data consistency and enabling functions such as backup, snapshots, and data migration.

[0037] The VM manager (2001) on the source server (200) manages virtual machines and coordinates VM migration with the migration controller (3001) on the destination server (300) using an external VM (3003) in the S server control driver. Storage control drivers (2004 and 3004) on both servers handle communication between their respective servers and the storage subsystem (100). The storage offload engine (3002) on the destination server (300) improves the efficiency of VM migration by handling storage operations. The external VM (3003) in the S server control driver on the destination server (300) interacts with the VM on the source server (200) regarding migration tasks. Within the storage subsystem (100), the storage volume manager (1001) and storage copy engine (1002) manage and replicate storage volumes, ensuring efficient storage management across the environment.

[0038] The architecture shown in Figure 3 represents an advanced virtualization environment with VM migration capabilities, improving the efficiency of VM migration through storage offloading.

[0039] Figure 4 shows an overview of the data tables and lists used according to the first exemplary embodiment.

[0040] The source server (S server) 200 may include the following: The source VM table (241) contains information about virtual machines running on the source server. The source datastore table (242) contains information about datastores associated with the source server.

[0041] The destination server (D server) 300 may include the following: The VM migration plan table (341) contains a plan for migrating VMs from the source server to the destination server. The destination VM table (342) contains information about virtual machines that are migrated to or have been migrated to the destination server. The destination datastore table (343) contains information about datastores associated with the destination server. The copy technology list (344) contains information about the technologies used to copy data and the conditions under which each technology is applicable in the storage subsystem. The data format support table (345) contains information about data formats supported by the destination server.

[0042] The source VM table (241) and source datastore table (242) on the source server (200) track all relevant information about the VMs and datastores on the source server. The VM migration plan table (341) on the destination server (300) outlines the strategy and sequence for migrating VMs from the source server. The destination VM table (342) and destination datastore table (343) on the destination server (300) track information about the VMs and datastores after migration. The copy techniques list (344) provides an overview of the tools and methods used to facilitate the migration process. The data format support table (345) ensures that the destination server can properly handle and store incoming data formats from the source server.

[0043] Figure 5 shows a mapping between virtual machine (VM) IDs and their corresponding datastores in an exemplary embodiment.

[0044] The VM ID (2410) lists the unique identifiers of virtual machines. Each VM ID is a unique number assigned to a specific virtual machine within the system. This table shows three VM IDs: 0000, 0001, and 0002. The Datastore (2411) lists the unique identifiers of datastores. Each datastore ID is associated with a specific VM and represents the storage location where the data for that VM is stored. This table shows three datastore IDs: 0100, 0101, and 0102.

[0045] In the example in Figure 5, VM ID 0000 is associated with datastore 0100, indicating that the virtual machine with ID 0000 uses datastore ID 0100. VM ID 0001 is associated with datastore 0101, indicating that the virtual machine with ID 0001 uses datastore ID 0101. VM ID 0002 is associated with datastore 0102, indicating that the virtual machine with ID 0002 uses datastore ID 0102.

[0046] This table (which has columns for VM ID 2410 and datastore 2411) is a mapping that helps identify which datastore is associated with which virtual machine. This can be useful for managing storage resources and ensuring that data for each VM is correctly allocated and accessible.

[0047] Figure 6 shows detailed information about a datastore, including capacity, data format, associated storage identifier, and volume identifier, in an exemplary embodiment. Datastore ID (2420) lists the unique identifiers of the datastores. Each datastore ID is a unique number assigned to a particular datastore. The table in Figure 6 shows three datastore IDs: 0100, 0101, and 0102. Capacity (2421) lists the capacity of each datastore, indicating the amount of data that the datastore can hold. The capacities shown in Figure 6 are 200GB for datastore 0100, 400GB for datastore 0101, and 1TB for datastore 0102. Data format (2422) lists the format of the data stored in each datastore. The data formats shown in Figure 6 are format A for datastore 0100, format B for datastore 0101, and format C for datastore 0102. The Storage ID (2423) lists the unique identifiers of the storage subsystem that contains the datastore. In Figure 6, the Storage IDs are 5000 for datastores 0100 and 0101, and 5001 for datastore 0102. The Pool ID (2424) lists the unique identifiers of the storage pool to which the datastore is assigned. In Figure 6, the Pool IDs are 3000 for datastores 0100 and 0101, and 3001 for datastore 0102. The Volume ID (2425) lists the unique identifiers of the storage volumes associated with each datastore. In Figure 6, the Volume IDs are 1000 for datastore 0100, and 1001 for datastore 0101. Datastore 0102 is 1002.

[0048] Figure 7 details a migration plan for virtual machines (VMs) and their associated datastores between a source server and a destination server, according to an exemplary embodiment. Plan IDs (3410) list the unique identifiers of the migration plan. Each plan ID represents a specific migration plan. The table in Figure 7 shows one plan ID, 0000. S-VM (3411) lists the identifiers of the source virtual machines that are part of the migration plan. The source VM ID listed in Figure 7 is 0001. D-VM (3412) lists the identifiers of the destination virtual machines that host the migrated VMs. The destination VM ID listed in Figure 7 is 0001. S-Datastore (3413) lists the identifiers of the source datastores associated with the VMs that are part of the migration plan. The source datastore ID listed in Figure 7 is 0100. D-Datastore (3414) lists the identifiers of the destination datastores to which data from the source datastores is migrated. The destination datastore ID listed in Figure 7 is 0200. Migration (Warm / Cold) (3415) specifies the type of migration to be used. A "warm" migration indicates that the migration process takes place while the VM is still running, but with minimal downtime, while a "cold" migration means that the VM is completely powered off during the migration. The listed migration type is warm. Storage Offload (3416) indicates whether the storage offload feature is enabled or disabled. Storage offload helps improve efficiency by offloading storage-related tasks from the main CPU. The listed status for storage offload is enabled.

[0049] Figure 8 shows a mapping between virtual machine (VM) IDs and their corresponding datastores in an exemplary embodiment. VM ID(3420) lists unique identifiers for virtual machines. Each VM ID is a unique number assigned to a specific virtual machine in the system. This table shows two VM IDs, 0000 and 0001.

[0050] The datastore (3421) enumerates the unique identifiers of datastores. Each datastore ID is associated with a specific VM and represents the storage location where the data for that VM is stored. This table shows two datastore IDs, 0200 and 0201.

[0051] VM ID0000 is associated with datastore 0200, indicating that the virtual machine with ID0000 will use datastore ID0200. VM ID0001 is associated with datastore 0201, indicating that the virtual machine with ID0001 will use datastore ID0201.

[0052] Figure 9 shows detailed information about a datastore, including capacity, data format, associated storage identifier, and volume identifier, in an exemplary embodiment. Datastore ID (3430) lists the unique identifiers of the datastores. Each datastore ID is a unique number assigned to a particular datastore. This table shows two datastore IDs, 0200 and 0201. Capacity (3431) lists the capacity of each datastore, indicating the amount of data that the datastore can hold. The capacity is 200GB for datastore 0200 and 500GB for datastore 0201. Data format (3432) lists the format of the data stored in each datastore. The data format for both datastores is format A. Storage ID (3433) lists the unique identifiers of the storage units that house the datastores. The storage ID is 5000 for datastore 0200 and 5001 for datastore 0201. The Pool ID (3434) lists the unique identifiers of the storage pool to which the datastore is assigned. The Pool ID for datastore 0200 is 3000, and for datastore 0201 it is 3001. The Volume ID (3435) lists the unique identifiers of the storage volumes associated with each datastore. The Volume ID for datastore 0200 is 1010, and for datastore 0201 it is 1020.

[0053] This table provides a detailed plan for migrating virtual machines and their datastores from the source server to the destination server, including the type of migration and whether storage offloading is used. This table is created by the administrator or migration tool to plan and execute the migration process.

[0054] Figure 10 shows information about various copy technologies and their associated conditions in an exemplary embodiment. Copy technology (3440) lists various technologies used to copy data. Each technology represents a specific method of data copying. This table shows three types of copy technologies: virtual replication, local replication, and remote replication. Conditions (3441) list the conditions under which each copy technology is used. Each condition describes the environment and configuration required for the corresponding replication technology. This table shows the conditions of same pool, same storage subsystem, and different storage subsystems.

[0055] In the example in Figure 10, there are three types of replication. Virtual replication is used when data is replicated within the same storage pool, indicating that the source and destination are in the same storage pool. Local replication is used when data is replicated within the same storage subsystem, indicating that the source and destination are not in the same pool but are part of the same storage subsystem. Remote replication is used when data is replicated to a different storage subsystem, indicating that the source and destination are located in separate physical storage infrastructures and, in some cases, geographically different locations.

[0056] This table provides a comprehensive overview of various replication technologies and the specific conditions under which each technology is applicable, facilitating the appropriate selection of data replication based on your storage environment and requirements. Copy technologies and conditions may vary depending on your storage infrastructure.

[0057] Figure 11 shows a flowchart detailing the process of a migration controller (3001) migrating a virtual machine (VM) according to an exemplary embodiment. This process begins when the migration controller receives a request to migrate a VM from a source server to a destination server.

[0058] First, the VM specifications are obtained and verified (3001-1). This step involves obtaining the virtual machine specifications as S-VMs in the VM migration plan table (341), verifying the detailed specifications, and confirming that migration is possible. Then, a determination is made as to whether to perform a warm migration (3001-2). This determination point is made by checking the migration type in the migration plan table (341) to determine whether the migration will be a warm migration (the VM will continue to run with minimal downtime). If it is not a warm migration (No), the VM is requested to be turned off (3001-3). If the migration is not a warm migration, this step requests the source server (200) to power off the source VM in order to prepare for the migration.

[0059] If it is a warm migration (Yes), or afterwards (3001-3), proceed to create the D datastore (3001-4). This step involves creating a datastore on the destination server to migrate the data from the destination VM.

[0060] After creating the datastore, the step of creating and attaching the D volume (3001-5) requests the creation of a storage volume on the storage subsystem (100) and attaches it to the datastore. The storage offload determination point (3001-6) determines from the migration plan table (341) whether storage offload is enabled. If it is enabled (Yes), the storage offload engine is invoked (3001-7), which involves starting the storage offload engine and handling the data transfer. The waiting for completion (3001-8) step involves waiting for the data transfer to complete. This is relevant if storage offload is being used.

[0061] If storage offload is not enabled, the no-offload data transfer (3001-9) step involves transferring data without the assistance of the offload engine. After the data transfer is complete, the new virtual machine creation (3001-10) step involves creating a new virtual machine on the destination server using the migrated data.

[0062] The warm migration determination point (3001-11) re-evaluates whether the migration process is a warm migration before proceeding with the VM cutover. If the VM is still running (Yes), the VM off request (3001-12) step involves requesting the source VM to be turned off. The transfer of remaining data (3001-13) step involves transferring the remaining data from the source VM so that the destination VM's data is up-to-date with the data from the source VM.

[0063] The final VM-on step (3001-14) involves turning on the destination VM on the destination server.

[0064] As shown in Figure 11, the process begins by extracting and verifying the VM specifications. Depending on whether it is a warm migration, it may be necessary to turn off the VM. Then, the destination datastore and volume are created and attached. Storage offload is checked, and if enabled, the offload engine is invoked to transfer the data. Otherwise, the data transfer is performed without offloading. After the data transfer, a new VM is created on the destination server. The process re-evaluates the migration type and, if necessary, turns off the VM to transfer the remaining data. Finally, the VM is turned on at the destination.

[0065] Figure 12 shows a flowchart detailing the process of the Storage Offload Engine (3002) in an exemplary embodiment. Each step in the process is numbered and involves a specific action or decision. The S-Datastore Format Support Determination Point (3002-1) checks whether the data format of the source datastore (S-Datastore) is supported by the destination server. Some formats allow the datastore to store data for multiple VMs. In this case, a format conversion is necessary because the destination server does not know which segment of the volume the S-VM data is stored in. If the source datastore format is not supported (No), the Format Conversion Request Step (3002-2) involves requesting a format conversion to a supported format. One of the conversion tools is VMware Storage vMotion. The Wait Step (3002-3) involves waiting for the format conversion to complete.

[0066] The S-Volume Identifier Acquisition step (3002-4) involves retrieving the identifier of the source volume (S-Volume) that needs to be migrated. The D-Volume Identifier Acquisition step (3002-5) involves retrieving the identifier of the destination volume (D-Volume) to which the data will be migrated. The Copy Technology Selection step (3002-6) involves selecting the appropriate copy technology for data transfer based on requirements and conditions (local, remote, virtual replication, etc.). The Copy Request Step from S-Volume to D-Volume (3002-7) involves requesting the storage subsystem to perform the data copy process from the source volume to the destination volume. The Waiting step (3002-8) involves waiting to ensure that the data copy process is complete and that the S-Volume and D-Volume are synchronized. This copy process can be performed in the background or virtually instead of an immediate full data copy. The Warm Migration Determination Point (3002-9) checks whether the migration is a warm migration, meaning that the VM will continue to operate with minimal downtime during this process.

[0067] If the migration is not a warm migration (No), the VM off request step (3002-10) involves requesting that the virtual machine be turned off in order to complete the migration. The copy relationship split request step (3002-11) involves requesting the splitting of the copy relationship between the source volume and the destination volume, confirming the migration, and ensuring that the destination volume operates independently.

[0068] As shown in Figure 12, the process begins by checking whether the source datastore format is supported. If it is not supported, a format conversion is requested, and the process waits for its completion. The identifiers of the source and destination volumes are retrieved. The appropriate copy technology is selected, and the copy process begins. The process waits until the data copy is complete. Depending on whether it is a warm migration, the VM may be turned off. The copy relationship is split, and the migration process is complete.

[0069] The exemplary embodiment also allows for directly assigning the S volume to the D volume instead of copying the data from the S volume to the D volume. In this case, a backup of the data on the S volume can be maintained on a separate volume.

[0070] Figure 13 shows a flowchart of a modified process of the storage offload engine (3002) according to a second exemplary embodiment. This modification involves creating a backup by using the copy function of the S server and the storage array function.

[0071] The D volume identifier acquisition step (3002b-l) involves obtaining the identifier of the destination volume (D volume) created by the migration controller (3001). The request to attach the D volume to the S server (3002b-2) involves requesting that the D volume be mounted on the source server (S server) to facilitate data transfer. The request to the S server to convert data from the S datastore to the D volume (3002b-3) involves requesting the source server to convert data from the source datastore (S datastore) to the datastore mounted by the destination volume (D volume). The waiting step (3002b-4) involves waiting for the data conversion process to complete. The D volume snapshot request step (3002b-5) involves requesting a snapshot of the destination volume to back up data during VM migration. The waiting step (3002b-6) involves waiting for the snapshot process to complete.

[0072] The warm migration determination point (3002b-7) checks whether the migration is a warm migration, meaning that the VMs continue to operate with minimal downtime during this process.

[0073] If the migration is not a warm migration (No), the VM off request step (3002b-8) involves requesting that the virtual machine be turned off in order to complete the migration. The copy relationship split request step (3002b-9) involves requesting the splitting of the copy relationship between the source volume and the destination volume, confirming the migration, and ensuring that the destination volume operates independently.

[0074] As shown in Figure 13, this process is a variation of the Storage Offload Engine (3002) process, where the destination volume is mounted on the source server for data transfer. The process begins by retrieving the identifier of the destination volume. The destination volume is mounted on the source server. Data conversion from the source datastore to the destination volume is requested. The process waits until the conversion is complete. A snapshot of the destination volume is requested, and the process waits for its completion. Depending on whether it is a warm migration, the VM may be turned off. Finally, the copy relationship is split, and the migration process ends.

[0075] This flowchart ensures that all necessary steps and checks follow to manage volumes during virtual machine migration, whether it involves data conversion and minimal downtime (warm migration) or with the VMs turned off.

[0076] Figure 14 shows a detailed diagram of the components and their roles in a virtualized environment with source and destination servers, along with the storage subsystem, in an exemplary embodiment. The flow in Figure 14 is similar to that in Figure 3. The difference is that a data in-place migration engine (3005) has been added to the D server (300).

[0077] The destination server (D server) 300 may include a data-in-place migration engine (3005) that attaches S volumes to D datastores within the D server instead of actual data copies. The data-in-place migration engine (3005) on the destination server (300) improves the efficiency of VM migration by attaching S volumes to D datastores when data-in-place mode is requested.

[0078] Figure 15 details a migration plan for virtual machines (VMs) and their associated datastores between a source server and a destination server, according to a third exemplary embodiment. Figure 15 is similar to Figure 7. The only addition is Data In Place (3417), which indicates whether the Data In Place migration feature is enabled or disabled. Data In Place migration helps migrate VMs by directly attaching the S datastore to which the data is associated to the D datastore. In the example in Figure 15, the status of the listed Data In Place is "Enabled".

[0079] Figure 16 shows a flowchart detailing process 3001c of the migration controller according to a third exemplary embodiment. Each numbered object is described in detail below. The steps for obtaining and verifying the VM specification (3001c-l), the warm migration determination point (3001c-2), and the VM off request step (3001c-3) are the same as in Figure 11.

[0080] The data-in-place decision point (3001c-4) determines from the migration plan table (341c) whether data-in-place is enabled. If data-in-place is enabled (Yes), the full data-in-place migration engine step (3001c-5) involves calling the data-in-place migration engine to properly manage the data transfer. The migration controller (3001c) then waits for the data transfer to complete (3001c-6) before proceeding to the step of finally turning on the VM (3001-14).

[0081] If data in place is not enabled (No), the process proceeds to the steps starting from the D data store creation step (3001-4) in Figure 11.

[0082] As shown in Figure 16, the process is almost identical to that in Figure 11. The decision point checks whether data-in-place is enabled. If data-in-place is enabled, the data-in-place migration engine is invoked to handle the data transfer. If data-in-place is not enabled, the process proceeds to the steps beginning with "Create D Datastore (3001-4)" as detailed in the flowchart in Figure 11. This flowchart provides an alternative approach to the migration process by introducing data-in-place migration, which can be more efficient in certain scenarios where it is not necessary to physically move the data to the destination volume.

[0083] Figure 17 shows a flowchart of the data-in-place migration engine (3005) in an exemplary embodiment, detailing the process for verifying virtual machine (VM) volumes during migration, converting data formats if necessary, and managing them. The S datastore format compatibility determination point (3005-1), format conversion request step (3005-2), waiting step (3005-3), and S volume identifier acquisition step (3005-4) are the same flow as 3002-1 to 3002-4. The D datastore creation step (3005-5) involves creating a datastore on the destination server (D datastore) where the VM data will be migrated. After the destination datastore is created, the step of attaching the S volume to the D datastore (3005-6) involves attaching the source volume to the destination datastore. If a format conversion has been performed, the S volume refers to the volume containing the converted data. The S-volume snapshot request step (3005-7) involves requesting a snapshot of the source volume (S-volume) to preserve data during the migration. The warm migration determination point (3005-8) checks whether the migration is a warm migration, meaning that the VM continues to run with minimal downtime during this process.

[0084] If the migration is not a warm migration (No), the VM off request step (3005-9) involves requesting that the virtual machine be turned off in order to complete the migration. The copy relationship split request step (3005-10) involves requesting the splitting of the copy relationship between the source volume and its snapshot, confirming the migration, and ensuring that the volumes operate independently.

[0085] The step (3005-11) of requesting the unmount of the S volume from the S datastore involves requesting the source volume to be unmounted from the source datastore after the migration is complete.

[0086] As shown in Figure 17, the process begins by checking whether the source datastore format is supported. If not, a format conversion is requested, and the process waits for its completion. The source volume identifier is retrieved. A destination datastore is created, and the source volume is directly attached to it. A snapshot of the source volume is requested, and the process waits for its completion. Depending on whether it is a warm migration, the VM may be turned off. The copy relationship is split. Finally, after the migration is complete, the source volume is unmounted from the source datastore.

[0087] Through the exemplary embodiments described herein, efficient data migration can be facilitated. These exemplary embodiments provide a structured approach for migrating virtual machines and their associated datastores, ensuring efficient and reliable data transfer between servers by utilizing a storage offload engine and copy technology.

[0088] Through the exemplary embodiments described herein, storage optimization can be facilitated. By utilizing a storage offload engine and copy technology, the exemplary embodiments optimize the data transfer process, reduce the load on the main CPU, and improve overall system performance.

[0089] Through the exemplary embodiments described herein, data format compatibility can be facilitated. These exemplary embodiments address the issue of data format compatibility, ensuring that data can be migrated even when the source server and destination server have different data formats.

[0090] Downtime can be reduced through the exemplary embodiments described herein. In warm migration, the exemplary embodiments facilitate the reduction of VM downtime during the migration process by using a storage-based relational partitioning process instead of transferring the remaining data processes between the source and destination servers.

[0091] Through the exemplary embodiments described herein, automated migration can be facilitated. The flowchart provides a clear and automated process for migrating virtual machines and their datastores, reducing manual intervention and potential errors in the migration process.

[0092] Through the exemplary embodiments described herein, redundancy can be easily achieved. In the exemplary embodiments, data is reliably synchronized between the source and destination volumes, and the source data is retained until the administrator confirms that it is safe to delete the data. If the migration fails, a failback process can be performed.

[0093] Furthermore, the exemplary embodiment can be extended to support multiple source and destination servers, enabling complex migration scenarios involving multiple servers and datastores. This exemplary embodiment also allows for directly assigning an S volume to a D volume instead of copying data from the S volume to the D volume. In this case, a backup of the data on the S volume can be maintained on a separate volume.

[0094] Some parts of the detailed description are presented by algorithms and symbolic representations of computer operations. The descriptions and symbolic representations of these algorithms are means used by those skilled in the field of data processing to convey the essence of their innovations to others skilled in the art. An algorithm is a set of defined steps leading to a desired final state or result. In exemplary embodiments, the steps performed require the physical manipulation of tangible quantities to achieve a tangible result.

[0095] Unless otherwise noted, as will be apparent from the description, any description throughout this specification using words such as “process,” “calculate,” “calculate,” “determine,” “display,” or similar means may include actions and processes of a computer system or other information processing device that manipulate data represented as physical (electronic) quantities in the registers and memory of a computer system to convert it into other data similarly represented as physical quantities in the memory or registers or other information storage devices, transmission devices or display devices of a computer system.

[0096] Exemplary embodiments may further relate to apparatus for performing operations as described herein. This apparatus may include one or more general-purpose computers, which may be specifically constructed for a desired purpose or selectively activated or reconfigured by one or more computer programs. Such computer programs may be stored on computer-readable media, such as computer-readable storage media or computer-readable signaling media. Computer-readable storage media may include, but are not limited to, tangible media such as optical disks, magnetic disks, read-only memory, random-access memory, solid-state devices and drives, or any other type of tangible or non-temporary media suitable for storing electronic information. Computer-readable signaling media may include media such as carrier waves. The algorithms and representations presented herein are not inherently related to any particular computer or other apparatus. Computer programs may include pure software implementation containing instructions for performing the operations of a desired embodiment.

[0097] Various general-purpose systems may be used with the programs and modules illustrated herein, or it may be convenient as a result to construct specialized devices by performing the steps of a desired method. Furthermore, the exemplary embodiments are not described with reference to any particular programming language. It will be understood that various programming languages ​​may be used to carry out the techniques of the embodiments described herein. Instructions in the programming language may be executed by one or more processing devices, such as a central processing unit (CPU), processor, or controller.

[0098] As is known in the art to which this invention belongs, the operations described above can be performed by hardware, software, or any combination of software and hardware. Various aspects of the exemplary embodiments may be performed using circuits and logic devices (hardware), while other aspects may be performed using instructions stored on a machine-readable medium (software), which, when performed by a processor, cause the processor to perform the method for performing the implementation of the present invention. Furthermore, some exemplary embodiments of the present invention may be performed by hardware alone, while other exemplary embodiments may be performed by software alone. Furthermore, the various functions described can be performed by a single unit or distributed across a number of components in any number of ways. When performed by software, the method may be performed by a processor, such as a general-purpose computer, based on instructions stored on a computer-readable medium. If necessary, the instructions may be stored on the medium in compressed and / or encrypted form.

[0099] Furthermore, other embodiments of the present application will be apparent to those skilled in the art from the considerations herein and the practice of the present art. Various aspects and / or components of the exemplary embodiments described may be used individually or in any combination. This specification and the exemplary embodiments are intended to be considered as examples only, and the true scope and spirit of the present application are set forth by the following claims. [Explanation of symbols]

[0100] 100 Storage Subsystems 101a S volume 101b D volume 102 Pool 130 memory 140 Drive 1001 Storage Volume Manager 1002 Storage Copy Engine 200 Source Servers (S Servers) 202 S Datastore 241 Source VM Table 242 Source Datastore Tables 2001 VM Manager 2004 S Server Storage Control Driver 300 Destination Servers (D Servers) 341 VM Migration Planning Table 342 Destination VM Tables 343 Destination Datastore Table 344 Copying Techniques List 345 Data Format Support Tables 3001 Migration Controller 3002 Storage Off-Road Engine External VM in 3003 S Server Control Driver 3004 Storage control driver for D server

Claims

1. Obtaining the source identifier of the source volume based on the execution of a process that includes sending a command to the virtual machine management system requesting the source identifier of the source volume to be migrated, Obtaining the destination identifier of the destination volume, Selecting a configuration based on the parameters of the source volume identified by the source identifier and the destination volume identified by the destination identifier, A method comprising performing an operation on the source volume according to the above configuration.

2. The method according to claim 1, wherein the instruction includes one of an application programming interface (API) call to the virtual machine management system or an instruction sent via the Secure Shell Protocol (SSH).

3. The method according to claim 1, further comprising receiving the source identifier of the source volume in response to the instruction.

4. The method according to claim 3, wherein the configuration includes assigning the destination volume, identified by the destination identifier, as a primary volume after a snapshot of the source volume identified by the source identifier has been provided to the destination volume, and the operation is a copy operation.

5. The method according to claim 3, wherein the configuration includes assigning the source volume identified by the source identifier as the destination volume, and the operation includes maintaining the assignment.

6. The aforementioned process, Extracting the data from the source virtual machine to a new volume as the source volume, If the data storage type of the source virtual machine data is not supported by the destination volume, perform a data conversion of the source virtual machine data to a supported format. The method according to claim 1, comprising extracting the source identifier based on the data storage type of the source volume.

7. The method according to claim 6, wherein the copy configuration includes assigning the destination volume, identified by the destination identifier, as the primary volume after a snapshot of the source volume, identified by the source identifier, has been provided to the destination volume.

8. The method according to claim 6, wherein the copy configuration includes assigning the source volume identified by the source identifier as the primary volume after a snapshot of the source volume identified by the source identifier has been provided to the destination volume.

9. The method according to claim 1, wherein obtaining the destination identifier of the destination volume is performed from a path dynamically assigned from the forklift process.

Images