Virtual machine memory data migration method, device, computer program product, and storage medium

Abstract

Embodiments of the present application provide a virtual machine memory data migration method, a device, a computer program product, and a storage medium. The method comprises: when performing a first migration for each virtual memory page in a virtual machine, detecting a page fault state of the virtual memory page; for the virtual memory page in the page fault state, a virtual machine manager in a source host acquiring corresponding memory data when no page fault recovery operation is triggered; and then migrating the acquired memory data to a destination host.

Description

[0001]A Virtual Machine Memory Data Migration Method, Device, Computer Program Product, and Storage Medium Cross-Reference This disclosure claims priority to a Chinese patent application filed with the China Patent Office on March 27, 2024, with application number 202410362467.4, entitled "A Virtual Machine Memory Data Migration Method, Device, Computer Program Product, and Storage Medium," the entire contents of which are incorporated herein by reference. Technical Field This disclosure relates to the field of cloud computing technology, and more particularly to a virtual machine memory data migration method, device, computer program product, and storage medium. Background: Virtual machine live migration refers to the process of migrating a running virtual machine from a source host to a destination host. The migration process does not interrupt the virtual machine's workload and is unaware to users. Memory data migration is a key step in the live migration process. Currently, memory data migration can cause significant fluctuations in physical memory usage on the source host, potentially leading to severe memory runs and impacting the source host's memory performance. SUMMARY OF THE INVENTION Various aspects of the present disclosure provide a virtual machine memory data migration method, apparatus, computer program product, and storage medium for reducing the amount of physical memory occupied by a source host due to memory data migration. Embodiments of the present disclosure provide a virtual machine memory data migration method, applicable to a virtual machine manager on a source host. The method comprises: when performing a first migration on a target virtual memory page, detecting a page fault status of the target virtual memory page; in response to the target virtual memory page being in a page fault status, obtaining memory data corresponding to the target virtual memory page without triggering a page fault recovery operation; and migrating the obtained memory data to a destination host. An embodiment of the present disclosure also provides a method for migrating memory data of a virtual machine, which is applicable to a kernel interface in a source host for supporting memory data migration. The method comprises: receiving a page fault status query instruction initiated by a virtual machine manager in the source host when performing a first migration of a target virtual memory page; generating page fault status description information for the target virtual memory page according to the page fault status query instruction, wherein the page fault status description information is used to indicate the page fault status of the target virtual memory page; providing the page fault status description information to the virtual machine manager, so that the virtual machine manager, after detecting that the target virtual memory page is in a page fault state, obtains memory data corresponding to the target virtual memory page without triggering a page fault recovery operation, and migrates the obtained memory data to the destination host.Embodiments of the present disclosure also provide a computing device comprising a memory, a processor, and a communication component; the memory is configured to store one or more computer instructions; the processor is coupled to the memory and the communication component and configured to execute the aforementioned virtual machine memory data migration method. Embodiments of the present disclosure also provide a computer-readable storage medium storing a computer program. When the computer program is executed by one or more processors, the one or more processors execute the aforementioned virtual machine memory data migration method. Embodiments of the present disclosure also provide a computer program product comprising a computer program. When the computer program is executed by one or more processors, the one or more processors execute the aforementioned virtual machine memory data migration method. Embodiments of the present disclosure also provide a computer program product comprising a non-volatile computer-readable storage medium storing the computer program. When the computer program is executed by the processor, the computer program implements the aforementioned virtual machine memory data migration method. Embodiments of the present disclosure also provide a computer program. When the computer program is executed by the processor, the computer program implements the aforementioned virtual machine memory data migration method. In embodiments of the present disclosure, improvements are made to the memory data migration scheme during virtual machine migration, proposing to detect the page fault status of each virtual memory page in the virtual machine during the first migration. For virtual memory pages in a page-fault state, the virtual machine manager on the source host will retrieve the corresponding memory data for these virtual memory pages without triggering a page-fault recovery operation. This prevents page-fault recovery operations from consuming the source host's physical memory, thus reducing the amount of physical memory used by the source host due to memory data migration. Consequently, memory data migration will no longer cause significant fluctuations in physical memory usage on the source host, thereby preventing exacerbations of memory runs on the source host. BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings described herein are provided to provide a further understanding of the present disclosure and constitute a part thereof. The illustrative embodiments of the present disclosure and their description are provided to explain the present disclosure and are not intended to unduly limit the present disclosure.In the accompanying drawings: Figure 1 is a flowchart of a virtual machine memory data migration method provided by an exemplary embodiment of the present disclosure; Figure 2 is a logical diagram of a virtual machine memory data migration method provided by an exemplary embodiment of the present disclosure; Figure 3 is a logical diagram of an optional implementation of a virtual machine memory data migration method provided by an exemplary embodiment of the present disclosure; Figure 4 is a structural diagram of page fault status description information provided by an exemplary embodiment of the present disclosure; Figure 5 is a flowchart of a virtual machine memory data migration method provided by another exemplary embodiment of the present disclosure; and Figure 6 is a structural diagram of a computing device provided by yet another exemplary embodiment of the present disclosure. DETAILED DESCRIPTION To further clarify the objectives, technical solutions, and advantages of the present disclosure, the technical solutions of the present disclosure will be described clearly and completely below in conjunction with the specific embodiments of the present disclosure and the corresponding drawings. Obviously, the described embodiments are only some of the embodiments of the present disclosure, and are not exhaustive. All other embodiments derived by persons of ordinary skill in the art based on the embodiments of the present disclosure without inventive effort are within the scope of protection of the present disclosure. Before describing in detail the technical solutions provided by the various embodiments of the present disclosure, several technical concepts involved in the present disclosure are explained below. A memory run is a phenomenon in which insufficient physical memory occurs on a host. The physical memory on a host is often over-provisioned to each virtual machine running on it. This is primarily because each virtual machine typically does not use all of its memory at the same time. Therefore, the goal is to ensure the memory usage requirements of each virtual machine through time-sharing multiplexing, thereby improving physical memory utilization. However, in some cases, the memory usage of each virtual machine may increase significantly, and the total memory required by each virtual machine may exceed the total physical memory on the host, resulting in a memory squeeze. This memory squeeze can cause some virtual machines to be unable to use memory properly, which is a serious performance issue on the host. Virtual machine migration refers to the technology of migrating a virtual machine from a source host to a destination host. Virtual machine migration is divided into hot migration and cold migration. Hot migration involves migrating a running virtual machine from a source host to a destination host. The downtime required for the virtual machine during hot migration is usually short enough that it is almost imperceptible to users. Cold migration involves migrating a virtual machine from a source host to a destination host after it has been decommissioned. Cold migration requires a relatively long downtime for the virtual machine. Memory data migration involves migrating the virtual machine's memory data from the source host to the destination host. Generally, cold migration does not involve memory data migration because cold migration requires shutting down the virtual machine and memory is volatile.Live migration does not require virtual machine downtime. Therefore, the virtual machine's memory data must be fully and correctly migrated to the destination host to ensure the virtual machine can run correctly on the destination host after the migration is complete. Memory virtualization is a virtualization technology that allows physical memory to be expanded into a larger logical memory space, allowing programs to access more memory resources. This technology divides the virtual address space into fixed-size pages (called virtual memory pages) and maps these virtual memory pages to physical memory, allowing each process or resource (such as a virtual machine) to have its own virtual memory space. A page fault, also known as a page fault, is a memory anomaly arising from memory virtualization technology. A page fault typically occurs when a virtual memory page is not mapped to a physical memory page, resulting in an inability to access the corresponding memory data. However, this memory anomaly is recoverable, and the operation to recover from the page fault is called page fault recovery. Page fault recovery reallocates physical memory pages for the faulted virtual memory page and restores the memory data to the reallocated physical memory pages. During their research, the inventors discovered that, during virtual machine migration, the virtual machine manager on the source host traverses the virtual memory pages occupied by the virtual machine while migrating memory data, and indiscriminately initiates memory access requests to these virtual memory pages. Memory access requests initiated for faulted virtual memory pages trigger page fault recovery operations in the source host's operating system, which require the use of physical memory on the source host. Therefore, as described in the background, memory data migration can cause significant fluctuations in physical memory usage on the source host. The inventors also discovered that virtual machine migration is often caused by insufficient physical memory on the source host, and migrating some virtual machines is intended to alleviate this problem. However, in this current situation, memory data migration requires a significant amount of physical memory on the source host, exacerbating the physical memory shortage on the source host and further exacerbating the memory run problem on the source host. Therefore, this embodiment proposes a method for virtual machine memory data migration. By modifying the memory data migration process, the physical memory usage caused by memory data migration can be effectively reduced. The following describes in detail the technical solutions provided by various embodiments of the present disclosure in conjunction with the accompanying drawings. FIG1 is a flowchart of a method for migrating virtual machine memory data provided by an exemplary embodiment of the present disclosure. FIG2 is a logic diagram of a method for migrating virtual machine memory data provided by an exemplary embodiment of the present disclosure.This method can be executed by a virtual machine manager (VMM) in the source host. The VMM can be implemented as software, hardware, or a combination of software and hardware, and can be integrated into the source host. Referring to Figure 1 , the method may include: Step 100: Detecting a page fault status of a target virtual memory page during a first migration; Step 101: Responding to the target virtual memory page being in a page fault state, without triggering a page fault recovery operation, obtaining memory data corresponding to the target virtual memory page; and Step 102: Migrating the obtained memory data to the destination host. In this embodiment, the Virtual Machine Manager (VMM) can be a hypervisor, Quick Emulator (QEMU), Kernel-based Virtual Machine (KVM), or the like. Furthermore, a virtual machine manager typically includes components in kernel mode and components in user mode. In this embodiment, user-mode components of the virtual machine manager are described as user-mode components, such as the aforementioned QEMU components; kernel-mode components of the virtual machine manager are described as kernel-mode components, such as the aforementioned KVM components. The virtual machine memory data migration method provided in this embodiment can be primarily executed by the user-mode components of the virtual machine manager. The virtual machine memory data migration method provided in this embodiment is applicable to the aforementioned virtual machine hot migration scenario. Of course, if memory data migration is also required in virtual machine cold migration scenarios, the virtual machine memory data migration method provided in this embodiment is also applicable to these scenarios. In other words, this embodiment does not limit the application scenario. During research, the inventors discovered that memory data migration generally includes two migration phases: a full first migration phase and a dirty page migration phase. The full first migration phase can be understood as the process of traversing the virtual machine's full memory data and migrating it from the source host to the destination host after the migration begins. The dirty page migration phase can be understood as after a virtual memory page completes its first migration. Since the virtual machine is still running normally in the source host, related operations occurring in the virtual machine may cause the memory data corresponding to some virtual memory pages to change. In this case, the virtual memory pages with changed memory data are dirty pages and need to be migrated to the destination host.Furthermore, the dirty page migration phase may require multiple rounds of migration until the latest round of dirty page migration is detected to have taken less than a specified time threshold. Upon completion of the latest round of dirty page migration, the dirty page migration phase can be terminated. Based on this, this embodiment proposes improvements to the aforementioned full first migration phase to reduce the physical memory usage caused by this phase. It is worth noting that during the full first migration phase, the first migration must be performed on the virtual memory pages occupied by the virtual machine. For ease of description, this embodiment will use the target virtual memory page as an example to describe the first migration process in detail. It should be understood that the virtual machine memory data migration method provided in this embodiment is applicable to any virtual memory page occupied by the virtual machine to be migrated. Referring to Figure 1 , step 100 proposes that when performing the first migration on the target virtual memory page, the page fault status of the target virtual memory page may be detected. It is understood that in this embodiment, when performing the first migration on the target virtual memory page, a memory access request for the target virtual memory page is not directly initiated. Instead, the page fault status of the target virtual memory page is first detected. In this embodiment, multiple implementations can be used to detect the page fault status of the target virtual memory page in step 100. FIG3 is a logical diagram of an optional implementation of a virtual machine memory data migration method provided by an exemplary embodiment of the present disclosure. Referring to FIG3 , an exemplary implementation of step 100 may include: the virtual machine manager may initiate a page fault status query instruction for the target virtual memory page to a kernel interface on the source host that supports memory data migration. The page fault status query instruction triggers the kernel interface to return page fault status description information corresponding to the target virtual memory page; in response to the page fault status description information indicating that the target virtual memory page is in a page fault state, the virtual machine manager determines that the target virtual memory page is in a page fault state. It should be understood that the source host's physical memory is managed in kernel mode. Therefore, memory data migration requires support from certain interfaces in the source host's kernel mode. In this embodiment, these interfaces are described as kernel interfaces on the source host that support memory data migration. The virtual machine manager and these kernel interfaces cooperate to complete memory data migration. The kernel interface in the source host for supporting memory data migration may be a kernel interface provided by the operating system of the source host, for example, a memory manager (MM for short).Of course, the kernel interface used for memory data migration in the source host can also be an interface provided by a kernel-mode component of the virtual machine manager, such as a memory access interface provided by a KVM component. The provider of the kernel interface used to support memory data migration in the source host is not limited herein. Accordingly, the virtual machine manager has call access to relevant interfaces provided by the kernel mode of the source host. For example, the QEMU component has call access to various interfaces provided by the KVM component; it also has call access to some kernel interfaces provided by the source host operating system. In this exemplary implementation, the communication protocol between the virtual machine manager and the kernel interface can be modified to ensure that both parties reach a consistent understanding of page fault status query instructions. In actual applications, the virtual machine manager can initiate a page fault status query instruction according to the instruction format specified by the kernel interface, and the kernel interface can determine whether the received instruction is a page fault status instruction based on the instruction format. The specified format here can include, for example, a special identifier or field in the instruction, which is not limited herein. During their research, the inventors discovered that a virtual machine manager manages virtual machines on a source host. Therefore, the virtual machine manager can determine which virtual memory pages are occupied by the virtual machine to be migrated within the virtual memory space provided by the source host. The address of a virtual memory page is the host virtual address (HVA). Based on this, in this exemplary implementation, a page fault query instruction can include the identifier of the target virtual memory page, such as the aforementioned HVA, so that the page fault query instruction points to the target virtual memory page. Furthermore, in this exemplary implementation, processing logic for querying page fault status can be incorporated into the kernel interface. Upon receiving the page fault status query instruction, the kernel interface will execute this processing logic. The processing logic for page fault status query in the above-mentioned kernel interface may include: generating page fault status description information for the target virtual memory page in response to a page fault status query instruction initiated by the virtual machine manager when performing the first migration of the target virtual memory page; and providing the page fault status description information to the virtual machine manager as a response result to the page fault status query instruction.During their research, the inventors discovered that the kernel interface described above is responsible for address translation between host virtual memory addresses (HVAs) and host physical memory addresses (HPAs) during memory data migration. This address translation relies on page tables. For example, the memory manager (MM) maintains a memory map (MMap), which is a type of page table. Within the page tables maintained by the kernel interface, the page table entries for virtual memory pages include a presence flag (represented by the "Present" flag). When the "Present" flag is 1, it indicates that a valid translation from the HVA to the HPA is possible, or that the HPA mapped by the HVA exists. Therefore, it can be determined that the corresponding virtual memory page is not in a page fault state. When the "Present" flag is 0, it indicates that a valid translation from the HVA to the HPA is not possible, or that the HPA mapped by the HVA does not exist. Therefore, it can be determined that the corresponding virtual memory page is not in a page fault state. On this basis, the kernel interface can query the page table and determine the page fault status of the target virtual memory page based on the value of the presence flag bit associated with the target virtual memory page. Accordingly, the page fault status description information generated by the kernel interface for the target virtual memory page can indicate the page fault status of the target virtual memory page. In this exemplary implementation, the virtual machine manager can parse the page fault status description information returned by the kernel interface and, in response to the indication in the page fault status description information that the target virtual memory page is in the page fault state, determine that the target virtual memory page is in the page fault state. It will be understood that in this exemplary implementation, the virtual machine manager can trigger the kernel interface to query the page fault status of the target virtual memory page by calling a kernel interface on the source host that supports memory data migration. The virtual machine manager can then obtain the page fault status of the target virtual memory page from the kernel interface, ensuring accuracy. In this embodiment, in addition to the exemplary implementation described above, the virtual machine manager can also use other implementations to detect the page fault status of the target virtual memory page in step 100. For example, the virtual machine manager may read the page table entry corresponding to the target virtual memory page from the kernel interface. Based on this, the virtual machine manager may detect the page fault state of the target virtual memory page based on the value of the presence flag bit in the page table entry.For another example, the source host's kernel state typically includes other interfaces that can provide mappings between virtual memory pages and physical memory pages. The virtual machine manager can also communicate with these interfaces in the source host's kernel state that are not used to support memory data migration to obtain the required information from these interfaces, thereby detecting the page fault status of the target virtual memory page. This will not be described in detail here, nor will further examples be provided. Continuing with FIG1 , step 101 proposes that, in response to the target virtual memory page being in a page fault state, memory data corresponding to the target virtual memory page is obtained without triggering a page fault recovery operation. The inventors discovered during research that a page fault recovery operation is caused by a memory access request being initiated for a virtual memory page in a page fault state. Therefore, in step 101, after determining that the target virtual memory page is in a page fault state, the virtual machine manager no longer initiates a memory access request for the target virtual memory page, thereby preventing the triggering of a page fault recovery operation. Accordingly, in this embodiment, memory access is no longer used to obtain swapped-out memory data, thereby avoiding the triggering of a page fault recovery operation. In addition to memory access, other data acquisition methods capable of acquiring swapped-out memory data are applicable to this embodiment for acquiring swapped-out memory data. It should be understood that this embodiment does not limit the data acquisition methods that can be used in step 101; exemplary data acquisition methods will be provided in subsequent embodiments. Furthermore, as mentioned above, the source host performs memory management in kernel mode. Therefore, the actual storage location of the memory data corresponding to the faulted virtual memory page is managed in kernel mode in the source host's kernel mode. Based on this, in step 101, based on the virtual machine manager's existing communication capabilities with the source host's kernel mode, the virtual machine manager can seamlessly determine the actual storage location of the memory data corresponding to the target virtual memory page, and then implement access logic capable of reaching this actual storage location to acquire the memory data corresponding to the target virtual memory page. It can be seen that in this embodiment, in step 101, in response to the existence of corresponding memory data for the target virtual memory page, the virtual machine manager can acquire the data from the actual storage location of the memory data, rather than through a memory access request. This not only ensures that the virtual machine manager can retrieve the memory data corresponding to the missing virtual memory page, but also ensures that page fault recovery operations are not triggered. Therefore, when the virtual machine manager retrieves the memory data corresponding to the missing virtual memory page, it does not cause incremental occupation of physical memory pages on the source host. Continuing with Figure 1, in step 102, the retrieved memory data can be migrated to the destination host.In this embodiment, during the entire first full migration phase, the virtual machine manager can traverse and detect the page fault status of each virtual memory page occupied by the to-be-migrated virtual machine. For virtual memory pages that are not in the page fault state, the virtual machine manager can initiate memory access requests for these virtual memory pages according to traditional migration methods to obtain the corresponding memory data from the physical memory pages mapped to these virtual memory pages. It is understandable that memory access requests initiated for these virtual memory pages do not inherently cause incremental occupation of physical memory pages on the source host. For virtual memory pages in the page fault state, the virtual machine manager no longer initiates memory access requests according to traditional methods, but instead retrieves the data from the actual storage location of the memory data. This change in data retrieval method not only ensures that the virtual machine manager can obtain the memory data corresponding to the missing virtual memory page, but also ensures that page fault recovery operations are not triggered, thereby preventing incremental occupation of physical memory pages on the source host. As a result, during the entire first full migration phase, the virtual machine manager no longer triggers page fault recovery operations, and pages no longer cause incremental occupation of physical memory pages on the source host. Echoing the aforementioned memory data migration phase, another phase included in the dirty page migration phase, in this embodiment, after completing the first migration of the target virtual memory page, in response to detecting that the target virtual memory page has become dirty, the virtual machine manager may obtain the dirty page data corresponding to the target virtual memory page from the physical memory page mapped to the target virtual memory page, and then migrate the obtained dirty page data for the target virtual memory page to the destination host. The technical concept "dirty page" referred to herein refers to a modified memory page. It should be understood that, while managing a virtual machine, the virtual machine manager may monitor memory access requests initiated by the virtual machine to a virtual memory page. As mentioned above, in response to the target virtual memory page being in a page fault state, the memory access request may trigger a page fault recovery operation to allocate a physical memory page for the target virtual memory page, and the corresponding memory data may be stored in the physical memory page. It is worth emphasizing that the page fault recovery operation in this case is caused by a memory access request initiated by the virtual machine. This memory access request is required during the normal operation of the virtual machine. The resulting occupation of physical memory pages in the source host is reasonable and this embodiment will not interfere.In this way, in response to the virtual machine manager detecting that the target virtual memory page has become dirty, the target virtual memory page must no longer be in a page fault state. The virtual machine manager can then normally initiate a memory access request for the target virtual memory page to obtain the dirty page data corresponding to the target virtual memory page and migrate it to the destination host. As can be seen, in this embodiment, during the dirty page migration phase, the virtual machine manager does not cause incremental occupation of physical memory pages on the source host when performing dirty page data migration. In summary, this embodiment improves the memory data migration solution during virtual machine migration by detecting the page fault state of each virtual memory page in the virtual machine during the first migration. For virtual memory pages in the page fault state, the virtual machine manager on the source host retrieves the corresponding memory data for these virtual memory pages without triggering a page fault recovery operation. In this way, during the virtual machine migration process, even if some virtual memory pages are in a page fault state, a page fault recovery operation will not be triggered. This avoids the physical memory usage of the source host caused by the page fault recovery operation and reduces the physical memory usage of the source host caused by memory data migration. Consequently, memory data migration will no longer cause significant fluctuations in physical memory usage on the source host, thereby avoiding exacerbating the memory run problem on the source host. In the above or following embodiments, various data acquisition schemes can be used in step 101 to acquire the memory data corresponding to the target virtual memory page without triggering a page fault recovery operation. During research, the inventors discovered that there are many reasons why a virtual memory page may be in a page fault state. Depending on the reason, the actual storage location of the memory data corresponding to the virtual memory page may vary. Therefore, in an exemplary data acquisition scheme, appropriate access logic can be used to access the actual storage location of the memory data in response to different page faults to retrieve the memory data. The reasons for the page fault state may include, but are not limited to, memory swapping and memory delay allocation. To this end, this data retrieval solution proposes: If a page fault recovery operation is not triggered, and the memory data corresponding to the target virtual memory page has been swapped out to the corresponding swap space on the source host, the memory data corresponding to the target virtual memory page is retrieved from the swap space. If the target virtual memory page has not yet been allocated to a physical memory page on the source host, an empty file is used as the memory data corresponding to the target virtual memory page. This data retrieval solution provides several possible actual storage locations for different causes of page faults: swapped out to swap space, and no actual storage location allocated (i.e., no memory data exists under the virtual memory page).Several technical concepts are involved here, which we will explain below. Memory swapping (swap) refers to memory exchange technology. When the host's physical memory is insufficient, some memory data is saved to swap space to free up physical memory on the host. Swap space, also known as swap space, is a virtual memory technology used in computer systems, allowing the operating system to use disk space as temporary memory. When the host's physical memory is insufficient, swap space can store temporarily inactive memory pages, freeing up physical memory for other programs. Swap space is typically located on the hard disk. Delayed memory allocation is a memory allocation mechanism. Before memory allocation, virtual machines on the host only receive a commitment to use memory space, rather than actually allocating physical memory to the virtual machine. When the virtual machine needs memory, one or more physical memory pages are allocated to the virtual machine in the host kernel state. In other words, some virtual memory pages occupied by the virtual machine may not have been accessed by the virtual machine yet, and therefore these virtual memory pages will not be allocated to physical memory pages. Only when the virtual machine initiates an access to these virtual memory pages will the host kernel state trigger the allocation of physical memory pages. It is understandable that the fact that a virtual memory page has not yet been allocated to physical memory indicates that the virtual machine has no memory data associated with that virtual memory page. This data acquisition solution also provides access logic for acquiring memory data for different actual storage locations. If the memory data corresponding to the target virtual memory page is located in swap space, the virtual machine manager can acquire the memory data corresponding to the target virtual memory page from the swap space. If the target virtual memory page has not yet been allocated to a physical memory page on the source host, indicating that no memory data exists under the target virtual memory page, the virtual machine manager can directly use an empty file as the memory data corresponding to the target virtual memory page. Furthermore, this embodiment provides a preferred implementation for acquiring the memory data corresponding to the target virtual memory page from swap space. This preferred implementation proposes that the virtual machine manager initiate a data acquisition request for the target virtual memory page to a kernel interface on the source host that supports memory data migration. The data acquisition request triggers the kernel interface to read the memory data corresponding to the target virtual memory page from the swap space, thereby acquiring the memory data corresponding to the target virtual memory page provided by the kernel interface. That is, in this preferred implementation, the virtual machine manager does not need to directly access the swap space, but can use the above-mentioned kernel interface in the source host to read the required memory data from the swap space. In this way, the virtual machine manager can obtain the memory data corresponding to the target virtual memory page from the above-mentioned kernel interface.Referring to Figure 3 , to facilitate the virtual machine manager obtaining the required memory data from the kernel interface, this preferred implementation further proposes that: To support data transfer between the virtual machine manager and the kernel interface, a cache space may be preset. Based on this, the virtual machine manager may allocate a cache address for the target virtual memory page within the preset cache space. The target virtual memory page identifier and cache address are included in a data retrieval request, triggering the kernel interface to read the memory data corresponding to the target virtual memory page from the swap space and store it at the cache address within the preset cache space. The kernel interface can then use the target virtual memory page identifier carried in the data retrieval request to locate the memory data corresponding to the target virtual memory page in the swap space, thereby accurately reading the memory data corresponding to the target virtual memory page. Based on this, the virtual machine manager can read the memory data corresponding to the target virtual memory page from the cache address. This effectively improves the efficiency of the virtual machine manager in obtaining the memory data corresponding to the target virtual memory page from the swap space, reduces the logic complexity within the virtual machine manager, and fully utilizes the kernel interface of the originating host. It should be understood that the above-mentioned actual storage locations that may correspond to the various types of memory data are merely exemplary and are not intended to limit this embodiment. Furthermore, the access logic provided for the above-mentioned actual storage locations that may correspond to the various types of memory data is also exemplary and is not intended to limit this embodiment. It is sufficient to ensure that the virtual machine manager can use appropriate access logic to reach the actual storage location of the memory data corresponding to the virtual memory page fault. Furthermore, to enable the virtual machine manager to more conveniently and efficiently determine the cause of the target virtual memory page in the page fault state, this embodiment also proposes a preferred solution. This preferred solution inherits the aforementioned basic concept of initiating a page fault status query instruction to the kernel interface supporting memory data migration in the source host. Based on this, this preferred solution proposes that the page fault type be indicated in the page fault status description information returned by the kernel interface. Here, the page fault type corresponds to the aforementioned cause of the page fault state. For example, if the cause of the page fault state is memory swapping, the corresponding page fault type is memory swapping; if the cause of the page fault state is delayed memory allocation, the corresponding page fault type is delayed allocation.Based on this, in this preferred solution: the virtual machine manager can parse the page fault status description information returned by the kernel interface for the target virtual memory page to obtain the page fault type corresponding to the target virtual memory page; in response to the page fault status description information indicating that the page fault type corresponding to the target virtual memory page is a memory swap type, determine that the memory data corresponding to the target virtual memory page has been swapped out to the swap space; and in response to the page fault status description information indicating that the page fault type corresponding to the target virtual memory page is a delayed allocation type, determine that the target virtual memory page has not yet been allocated to a physical memory page. Figure 4 is a schematic diagram of the structure of page fault status description information provided in an exemplary embodiment of the present disclosure. Referring to Figure 4, the page fault status description information may include a page fault status identification field and a page fault type field. Based on this, in response to the page fault status identification field taking a first value, it indicates that the target virtual memory page is in a page fault state; in response to the page fault status identification field taking a second value, it indicates that the target virtual memory page is not in a page fault state. In practical applications, the first value may be 1, the second value may be 00, and, in response to the page fault type field taking the third value, it indicates that the target virtual memory page's page fault type is memory swap; in response to the page fault type field taking the fourth value, it indicates that the target virtual memory page's page fault type is delayed allocation. FIG4 also illustrates other fields in the page fault status description information, such as the information type field, which indicates that the current information is page fault status description information for identification by the virtual machine manager. Further examples of other fields that may be included in the page fault status description information are not provided herein. It should be understood that, in addition to the above preferred solution, other implementation solutions may be adopted in this embodiment to support the virtual machine manager in determining the cause of the target virtual memory page's page fault state. For example, the virtual machine manager may apply for page table monitoring permissions from the kernel state of the source host to monitor modification events in the page table. Based on the modification events, the virtual machine manager can determine which virtual memory pages have experienced which event that caused the page fault, thereby determining the cause of the page fault state for the faulted virtual memory page. Further implementation examples are not provided here. In summary, in this embodiment, the virtual machine manager can fully interact with the kernel interface of the source host that supports memory data migration. This kernel interface provides the virtual machine manager with a reference for detecting page faults and uses this kernel interface to read memory data for the faulted virtual memory page. This enables the virtual machine manager to more efficiently detect virtual memory page faults and, without triggering a page fault recovery operation, more efficiently obtain the memory data corresponding to the faulted virtual memory page.FIG5 is a flowchart of a virtual machine memory data migration method provided by another exemplary embodiment of the present disclosure. This method may be applied to a kernel interface in a source host for supporting memory data migration. Referring to FIG5 , the method may include: Step 500: receiving a page fault status query instruction initiated by a virtual machine manager in the source host when performing the first migration of a target virtual memory page; Step 501: generating page fault status description information for the target virtual memory page based on the page fault status query instruction, wherein the page fault status description information indicates the page fault status of the target virtual memory page; Step 502: providing the page fault status description information to the virtual machine manager so that upon detecting that the target virtual memory page is in a page fault state, the virtual machine manager, without triggering a page fault recovery operation, retrieves the memory data corresponding to the target virtual memory page and migrates the retrieved memory data to the destination host. It should be understood that in this embodiment, the kernel interface still maintains its original memory data migration-related functions, such as responding to memory access requests for virtual memory pages. The memory data migration-related functions originally performed by the kernel interface will not be described in detail herein. In this embodiment, the processing logic shown in FIG. 5 is added to the kernel interface to enable the kernel interface to cooperate with the virtual machine manager to support the virtual machine manager in avoiding triggering page fault recovery operations during memory data migration. The following only clarifies some technical details of the kernel interface: In an optional embodiment, generating page fault status description information for a target virtual memory page may include: querying a page table; determining the page fault status of the target virtual memory page based on the value of the presence flag bit associated with the target virtual memory page, and generating the page fault status description information for the target virtual memory page. In an optional embodiment, the page fault status description information further indicates the page fault type. The page fault status description information may indicate that the page fault type corresponding to the target virtual memory page is a memory swap type, allowing the virtual machine manager to determine that the memory data corresponding to the target virtual memory page has been swapped out to the swap space; and the page fault status description information may indicate that the page fault type corresponding to the target virtual memory page is a delayed allocation type, allowing the virtual machine manager to determine that the target virtual memory page has not yet been allocated to a physical memory page.In an optional embodiment, the page fault status description information includes a page fault status identification field and a page fault type field. In response to the page fault status identification field taking a first value, it indicates that the target virtual memory page is in a page fault state. In response to the page fault status identification field taking a second value, it indicates that the target virtual memory page is not in a page fault state. In response to the page fault type field taking a third value, it indicates that the page fault type of the target virtual memory page is a memory swap fault. In response to the page fault type field taking a fourth value, it indicates that the page fault type of the target virtual memory page is a delayed allocation fault. In an optional embodiment, in response to a data acquisition request initiated by the virtual machine manager for the target virtual memory page, memory data corresponding to the target virtual memory page may be read from the swap space and provided to the virtual machine manager. In an optional embodiment, in response to the data acquisition request initiated by the virtual machine manager carrying the target virtual memory page identification and cache address, the memory data corresponding to the target virtual memory page read from the swap space is stored in the cache address, so that the virtual machine manager can read the memory data corresponding to the target virtual memory page from the cache address. It is worth noting that for more specific technical details regarding the kernel interface, please refer to the previous description and will not be elaborated upon here. However, this should not diminish the scope of protection of the present disclosure. Furthermore, while some processes described in the above embodiments and accompanying figures include multiple operations that appear in a specific order, it should be understood that these operations may be executed in a different order than those presented herein or in parallel. Operation sequence numbers, such as 801 and 802, are merely used to distinguish between different operations and do not represent any specific execution order. Furthermore, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel. It should be noted that terms such as "first" and "second" are used herein to distinguish between different values ​​and do not represent a sequential order, nor do they limit "first" and "second" to different types. FIG6 is a schematic diagram of the structure of a computing device provided by another exemplary embodiment of the present disclosure. As shown in FIG6 , the computing device may be the source host for the virtual machine to be migrated. The computing device may include a memory 60, a processor 61, and a communication component 62. The processor 61 is coupled to the memory 60 and the communication component 62, and is configured to execute the computer program in the memory 60. In some designs, the processor 61 may execute the computer program in the memory 60 to be implemented as a virtual machine manager in the source host.Under this request, the processor 61 may be configured to: detect a page fault status of the target virtual memory page when performing the first migration for the target virtual memory page; in response to the target virtual memory page being in the page fault status, obtain memory data corresponding to the target virtual memory page without triggering a page fault recovery operation; and migrate the obtained memory data to the destination host. In an optional embodiment, when obtaining the memory data corresponding to the target virtual memory page without triggering a page fault recovery operation, the processor 61 may be configured to: obtain the memory data corresponding to the target virtual memory page from the swap space of the source host without triggering a page fault recovery operation, in response to the memory data corresponding to the target virtual memory page being swapped out to the swap space of the source host; and in response to the target virtual memory page not being allocated to a physical memory page on the source host, use an empty file as the memory data corresponding to the target virtual memory page. In an optional embodiment, when detecting the page fault status of the target virtual memory page, the processor 61 may be configured to: initiate a page fault status query instruction for the target virtual memory page to a kernel interface supporting memory data migration in the source host, wherein the page fault status query instruction is configured to trigger the kernel interface to return page fault status description information corresponding to the target virtual memory page; and, in response to the page fault status description information indicating that the target virtual memory page is in the page fault status, determine that the target virtual memory page is in the page fault status. In an optional embodiment, the page fault status description information further indicates a page fault type corresponding to the target virtual memory page. The processor 61 may be further configured to: in response to the page fault type being a memory swap type, determine that memory data corresponding to the target virtual memory page has been swapped out to the swap space; and in response to the page fault type being a delayed allocation type, determine that the target virtual memory page has not yet been allocated to a physical memory page. In an optional embodiment, the page fault status description information includes a page fault status identification field and a page fault type field. In response to the page fault status identification field taking a first value, it indicates that the target virtual memory page is in a page fault state. In response to the page fault status identification field taking a second value, it indicates that the target virtual memory page is not in a page fault state. In response to the page fault type field taking a third value, it indicates that the page fault type of the target virtual memory page is a memory swap fault. In response to the page fault type field taking a fourth value, it indicates that the page fault type of the target virtual memory page is a delayed allocation fault. In an optional embodiment, when obtaining memory data corresponding to the target virtual memory page from the swap space, the processor 61 may be configured to: initiate a data acquisition request for the target virtual memory page to a kernel interface, wherein the data acquisition request is configured to trigger the kernel interface to read the memory data corresponding to the target virtual memory page from the swap space; and obtain the memory data corresponding to the target virtual memory page provided by the kernel interface.In an optional embodiment, when initiating a data acquisition request for a target virtual memory page to the kernel interface, the processor 61 may be configured to: allocate a cache address for the target virtual memory page in a preset cache space; include an identifier and cache address of the target virtual memory page in the data acquisition request to trigger the kernel interface to read memory data corresponding to the target virtual memory page from the swap space and store the read memory data at the cache address within the preset cache space; and acquire the memory data corresponding to the target virtual memory page provided by the kernel interface, including: reading the memory data corresponding to the target virtual memory page from the cache address. In an optional embodiment, the processor 61 may be further configured to: in response to the target virtual memory page not being in a page fault state, acquire the memory data corresponding to the target virtual memory page from the physical memory page mapped to the target virtual memory page. In an optional embodiment, the processor 61 may be further configured to: after completing the first migration for the target virtual memory page, in response to detecting that the target virtual memory page has become a dirty page, obtain dirty page data corresponding to the target virtual memory page from the physical memory page mapped to the target virtual memory page; and migrate the obtained dirty page data for the target virtual memory page to the destination host. In other designs, the processor 61 may execute a computer program in the memory 60 to implement a kernel interface in the source host for supporting memory data migration. In this case, processor 61 may be configured to: receive a page fault status query instruction initiated by the virtual machine manager in the source host when performing the first migration of the target virtual memory page; generate page fault status description information for the target virtual memory page based on the page fault status query instruction, wherein the page fault status description information indicates the page fault status of the target virtual memory page; and provide the page fault status description information to the virtual machine manager so that upon detecting that the target virtual memory page is in a page fault state, the virtual machine manager, without triggering a page fault recovery operation, retrieves memory data corresponding to the target virtual memory page and migrates the retrieved memory data to the destination host. Furthermore, as shown in FIG6 , the computing device also includes other components, such as a power supply component 63. FIG6 only schematically illustrates some components and does not mean that the computing device only includes the components shown in FIG6 . It is worth noting that the technical details of the above-mentioned computing device embodiments can be found in the description of the virtual machine manager and the kernel interface for supporting memory data migration in the aforementioned method embodiments. To save space, these details will not be repeated here, but this should not compromise the scope of protection of the present disclosure.Accordingly, embodiments of the present disclosure further provide a computer-readable storage medium storing a computer program. When executed, the computer program can implement each step of the above-described method embodiment. Accordingly, embodiments of the present disclosure further provide a computer program product, including the computer program. When executed by one or more processors, the computer program causes the one or more processors to: detect a page fault status of a target virtual memory page during a first migration of the target virtual memory page; in response to the target virtual memory page being in a page fault state, retrieve memory data corresponding to the target virtual memory page without triggering a page fault recovery operation; and migrate the retrieved memory data for the target virtual memory page to a destination host. The computer program product provided in this embodiment can detect the page fault status of each virtual memory page in a virtual machine during a first migration. For virtual memory pages in a page fault state, the virtual machine manager on the source host retrieves the corresponding memory data for such virtual memory pages without triggering a page fault recovery operation. In this way, even if some virtual memory pages are in a page fault state during virtual machine migration, page fault recovery operations will no longer be triggered. This prevents page fault recovery operations from occupying the source host's physical memory and reduces the amount of physical memory occupied by the source host due to memory data migration. Consequently, memory data migration no longer causes significant fluctuations in physical memory usage on the source host, thereby avoiding exacerbating memory run issues on the source host. The memory in Figure 6 is used to store computer programs and can be configured to store various other data to support operations on the computing platform. Examples of such data include instructions for any application or method operating on the computing platform, contact data, phone book data, messages, images, videos, etc.The memory can be implemented by any type of volatile or non-volatile memory device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), electrically erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk. The communication component in FIG6 is configured to facilitate wired or wireless communication between the device where the communication component is located and other devices. The device where the communication component is located can access a wireless network based on a communication standard, such as WiFi, 2G, 3G, 4G / Long-Term Evolution (LTE), 5G and other mobile communication networks, or a combination thereof. In one exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, the communication component also includes a near-field communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology, and other technologies. The power supply assembly in Figure 6 provides power to various components of the device in which the power supply assembly is located. The power supply assembly may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device in which the power supply assembly is located. Those skilled in the art will appreciate that the embodiments of the present disclosure may be provided as methods, systems, or computer program products.Therefore, the present disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present disclosure may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, compact disc read-only memory (CD-ROM), optical storage, etc.) containing computer-usable program code. The present disclosure is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present disclosure. It should be understood that each process and / or block in the flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, such that the instructions, executed by the processor of the computer or other programmable data processing device, generate means for implementing the functions specified in one or more processes in the flowcharts and / or one or more blocks in the block diagrams. These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means that implement the functions specified in one or more flow charts and / or one or more blocks in a block diagram. These computer program instructions may also be loaded onto a computer or other programmable data processing device, causing the computer or other programmable device to execute a series of operational steps to produce a computer-implemented process, whereby the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more flow charts and / or one or more blocks in a block diagram. It should also be noted that the terms "comprise," "include," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, product, or device comprising a list of elements may include not only those elements but also other elements not expressly listed, or elements inherent to such process, method, product, or device. In the absence of further restrictions, an element defined by the phrase "comprising a ..." does not exclude the existence of other identical elements in the process, method, product or equipment that includes the element.It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, storage, and display) involved in this disclosure are all authorized by the user or fully authorized by all parties. The collection, use, and processing of the relevant data must comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or reject. The above description is merely an embodiment of this disclosure and is not intended to limit this disclosure. Those skilled in the art will appreciate that various modifications and variations of this disclosure are possible. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of this disclosure are intended to be included within the scope of protection of this disclosure. Industrial Applicability The solution provided in the embodiments of this disclosure proposes detecting the page fault status of each virtual memory page in a virtual machine during the first migration. For virtual memory pages in the page fault state, the virtual machine manager on the source host will retrieve the corresponding memory data for such virtual memory pages without triggering a page fault recovery operation. This way, even if some virtual memory pages are faulted during virtual machine migration, page fault recovery operations will not be triggered. This prevents the source host's physical memory usage from being occupied by page fault recovery operations, reducing the amount of physical memory occupied by the source host due to memory data migration. Consequently, memory data migration no longer causes significant fluctuations in physical memory usage on the source host, thus resolving the technical issue of memory overflow on the source host.

Claims

Claims 1. A method for migrating virtual machine memory data, applicable to a virtual machine manager in a source host, the method comprising: when performing a first migration on a target virtual memory page, detecting a page fault state of the target virtual memory page; in response to the target virtual memory page being in the page fault state, obtaining memory data corresponding to the target virtual memory page without triggering a page fault recovery operation; and migrating the obtained memory data to a destination host.

2. The method according to claim 1, wherein obtaining memory data corresponding to the target virtual memory page without triggering a page fault recovery operation comprises: In a case where a page fault recovery operation is not triggered, in response to the memory data corresponding to the target virtual memory page being swapped out to the swap space corresponding to the source host, the memory data corresponding to the target virtual memory page is obtained from the swap space; in response to the target virtual memory page not yet being allocated to a physical memory page in the source host, an empty file is used as the memory data corresponding to the target virtual memory page.

3. The method according to claim 2, wherein detecting a page fault state of the target virtual memory page comprises: Initiate a page fault status query instruction for the target virtual memory page to a kernel interface in the source host for supporting memory data migration, wherein the page fault status query instruction is used to trigger the kernel interface to return page fault status description information corresponding to the target virtual memory page; in response to the page fault status description information indicating that the target virtual memory page is in the page fault state, determine that the target virtual memory page is detected to be in the page fault state.

4. The method according to claim 3, wherein the page fault status description information is further used to indicate a page fault type corresponding to the target virtual memory page, and the method further comprises: In response to the page fault type being a memory swap type, determining that memory data corresponding to the target virtual memory page has been swapped out to the swap space; In response to the page fault type being a delayed allocation class, it is determined that the target virtual memory page has not yet been allocated to the physical memory page.

5. The method according to claim 4, wherein the page fault status description information includes a page fault status identification field and a page fault type field; in response to the value of the page fault status identification field being a first value, it indicates that the target virtual memory page is in the page fault state; in response to the value of the page fault status identification field being a second value, it indicates that the target virtual memory page is not in the page fault state; in response to the value of the page fault type field being a third value, it indicates the page fault type of the target virtual memory page is the memory swap class; and in response to the value of the page fault type field being a fourth value, indicating that the page fault type of the target virtual memory page is the delayed allocation class.

6. The method according to claim 2, wherein obtaining memory data corresponding to the target virtual memory page from the swap space comprises: Initiate a data acquisition request for the target virtual memory page to a kernel interface in the source host that supports memory data migration, wherein the data acquisition request is used to trigger the kernel interface to read memory data corresponding to the target virtual memory page from the swap space; and obtain the memory data corresponding to the target virtual memory page provided by the kernel interface.

7. The method according to claim 6, wherein the step of initiating a data acquisition request for the target virtual memory page to the kernel interface comprises: Allocating a cache address for the target virtual memory page in a preset cache space; Carrying the identifier of the target virtual memory page and the cache address in the data acquisition request to trigger the kernel interface to read the memory data corresponding to the target virtual memory page from the swap space and store the read memory data in the cache address in the preset cache space; Acquiring memory data corresponding to the target virtual memory page provided by the kernel interface includes: reading the memory data corresponding to the target virtual memory page from the cache address.

8. The method according to claim 3, further comprising: In response to the target virtual memory page not being in the page fault state, memory data corresponding to the target virtual memory page is acquired from a physical memory page mapped to the target virtual memory page.

9. The method according to claim 1, further comprising: After completing the first migration for the target virtual memory page, in response to monitoring that the target virtual memory page becomes a dirty page, obtaining dirty page data corresponding to the target virtual memory page from a physical memory page mapped to the target virtual memory page; and migrating the obtained dirty page data for the target virtual memory page to the destination host.

10. A method for migrating memory data of a virtual machine, applicable to a kernel interface in a source host for supporting memory data migration, the method comprising: receiving a page fault status query instruction initiated by the virtual machine manager in the source host when performing a first migration on the target virtual memory page; Generate page fault status description information for the target virtual memory page according to the page fault status query instruction, wherein the page fault status description information is used to indicate the page fault status of the target virtual memory page; provide the page fault status description information to the virtual machine manager, so that after detecting that the target virtual memory page is in the page fault status, the virtual machine manager obtains memory data corresponding to the target virtual memory page without triggering a page fault recovery operation, and migrates the obtained memory data to a destination host.

11. The method according to claim 10, wherein the page fault status description information is further used to indicate the page fault type. The page fault type includes a memory interaction type or a delayed allocation type. The memory swap type is used to trigger the virtual machine manager to obtain memory data for the target virtual memory page from the swap space corresponding to the source host. The delayed allocation type is used to trigger the virtual machine manager to use an empty file as the memory data corresponding to the target virtual memory page.

12. A computing device comprising a memory, a processor, and a communication component; the memory being configured to store one or more computer instructions; and the processor being coupled to the memory and the communication component, configured to execute the one or more computer instructions to perform the virtual machine memory data migration method according to any one of claims 1 to 11.

13. A computer-readable storage medium storing a computer program, which, when executed by one or more processors, causes the one or more processors to execute the virtual machine memory data migration method according to any one of claims 1 to 11.

14. A computer program product, comprising a computer program, which, when executed by one or more processors, causes the one or more processors to execute the virtual machine memory data migration method according to any one of claims 1 to 11.

15. A computer program product, comprising a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, the method for migrating virtual machine memory data according to any one of claims 1 to 11 is implemented.

16. A computer program, wherein: When the computer program is executed by a processor, the method for migrating virtual machine memory data according to any one of claims 1 to 11 is implemented. 19

Images