Sandbox processing method, apparatus, device, and program product

Abstract

This application provides a sandbox processing method, apparatus, device, and program product. The sandbox processing method includes: in response to a cloning request for a source sandbox, generating a clone sandbox on a target virtual machine with a physical memory page to be allocated, wherein the target virtual machine's running state is the same as that of the virtual machine containing the source sandbox; when a memory access request exists in the clone sandbox, retrieving the target physical memory page corresponding to the memory access request from the memory of the source sandbox; and updating the memory page table of the clone sandbox based on the target physical memory page to fulfill the memory access request. This method can improve the real-time performance and efficiency of sandbox cloning.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and in particular to a sandbox processing method, apparatus, equipment and program product. Background Technology

[0002] With the rapid development of Artificial Intelligence Agent (AI Agent) technology, sandbox environments, as the core infrastructure for AI Agent applications, undertake key functions such as code execution, visualization, and task interaction. Because AI Agents frequently need to execute dynamically generated code (such as automated programming and algorithm verification), there is a need for sandboxes to quickly create and destroy environments. However, traditional sandbox cloning (Fork) solutions suffer from long cloning times due to issues such as memory copying, disk I / O bottlenecks, and data redundancy, resulting in low real-time performance and low cloning efficiency.

[0003] Therefore, improving the real-time performance and efficiency of sandbox cloning is an urgent problem to be solved. Summary of the Invention

[0004] This application provides a sandbox processing method, apparatus, equipment, and program product, which can improve the real-time performance and efficiency of sandbox cloning.

[0005] In a first aspect, this application provides a sandbox processing method, the method comprising:

[0006] In response to a cloning request for the source sandbox, a clone sandbox with physical memory pages to be allocated is generated on the target virtual machine, the target virtual machine having the same running state as the virtual machine containing the source sandbox.

[0007] When a memory access request exists in the clone sandbox, the target physical memory page corresponding to the memory access request is obtained from the memory of the source sandbox;

[0008] The memory page table of the clone sandbox is updated based on the target physical memory page to complete the memory access request.

[0009] Secondly, this application provides a map page display device, the device comprising:

[0010] The processing module is used to generate a clone sandbox with physical memory pages to be allocated on the target virtual machine in response to a cloning request for the source sandbox, wherein the running state of the target virtual machine is the same as the running state of the virtual machine where the source sandbox is located.

[0011] The acquisition module is used to acquire the target physical memory page corresponding to the memory access request from the memory of the source sandbox when there is a memory access request in the clone sandbox;

[0012] The control module is used to update the memory page table of the clone sandbox based on the target physical memory page in order to complete the memory access request.

[0013] Thirdly, this application provides an electronic device, including: a processor and a memory; the processor and the memory are communicatively connected.

[0014] The memory stores computer-executed instructions;

[0015] The processor executes computer execution instructions stored in the memory to implement the method as described in any of the first aspects.

[0016] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any of the first aspects.

[0017] Fifthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the method described in any of the first aspects.

[0018] The sandbox processing method, apparatus, device, and program products provided in this application generate a clone sandbox containing physical memory pages to be allocated on a target virtual machine in response to a cloning request for a source sandbox. The running state of the target virtual machine is the same as that of the virtual machine containing the source sandbox. When a memory access request exists in the clone sandbox, the target physical memory page corresponding to the memory access request is retrieved from the memory of the source sandbox, and the memory page table of the clone sandbox is updated based on the target physical memory page to complete the memory access request. This method avoids completely copying the memory data of the source sandbox by using a memory sharing mechanism and an on-demand loading mechanism between the source sandbox and the clone sandbox during runtime. The process of copying memory data is transferred to after the clone sandbox starts, and the clone sandbox loads the corresponding memory data according to the actual memory access request. This reduces the amount of data processing when generating the clone sandbox, thereby improving the efficiency and real-time performance of generating the clone sandbox. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 A schematic flowchart illustrating a sandbox processing method provided in an embodiment of this application;

[0021] Figure 2 A schematic flowchart of another sandbox processing method provided in an embodiment of this application;

[0022] Figure 3 A schematic flowchart illustrating another sandbox processing method provided in this application embodiment;

[0023] Figure 4 A schematic flowchart illustrating another sandbox processing method provided in an embodiment of this application;

[0024] Figure 5 A schematic flowchart illustrating another sandbox processing method provided in an embodiment of this application;

[0025] Figure 6 A schematic flowchart illustrating another sandbox processing method provided in an embodiment of this application;

[0026] Figure 7 A schematic flowchart illustrating another sandbox processing method provided in an embodiment of this application;

[0027] Figure 8 This is a schematic diagram of the structure of a sandbox management system provided in an embodiment of this application;

[0028] Figure 9A A flowchart illustrating a method for cloning a sandbox within a node, as provided in an embodiment of this application;

[0029] Figure 9B A flowchart illustrating a method for cloning a sandbox within a node, as provided in an embodiment of this application;

[0030] Figure 10A A flowchart illustrating a cross-node sandbox cloning method provided in this application embodiment;

[0031] Figure 10B A flowchart illustrating a cross-node sandbox cloning method provided in this application embodiment;

[0032] Figure 11 This is a schematic diagram of the structure of a sandbox treatment device provided in an embodiment of this application;

[0033] Figure 12 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0034] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0035] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0036] Currently, existing sandbox cloning solutions are based on a full snapshot mechanism, which persists all runtime data of the source sandbox as snapshot files and creates a full or incremental copy of the source sandbox's root file system. By reading these snapshot files and file system copies, a new virtual machine instance is initialized, thus completing the creation of the cloned sandbox.

[0037] However, since snapshot files need to completely record all memory data of the source sandbox, when the source sandbox memory is large, even with incremental snapshot technology, the copying and reading / writing of memory data still takes a long time, resulting in high clone startup latency and failing to meet the requirement of fast clone sandbox startup.

[0038] Secondly, since the root file system image of the source sandbox typically contains a large amount of underlying environment data, each time a sandbox is cloned, the root file system image must be copied or a difference file must be created. In multi-concurrent cloning scenarios, a large number of concurrent file read and write operations will consume a significant amount of storage I / O bandwidth, forming an I / O bottleneck and further extending the clone startup time. Furthermore, when multiple clone sandboxes are derived from the same underlying environment, existing sandbox cloning solutions require storing independent environment data for each clone sandbox, resulting in a large amount of duplicate data occupying storage space. This not only wastes storage resources but also further exacerbates I / O pressure.

[0039] Furthermore, because creating snapshot files requires pausing the source sandbox to ensure state consistency, and sandbox cloning currently takes a considerable amount of time, services running in the source sandbox may experience prolonged interruptions, impacting business continuity. Existing technologies, to mitigate this issue, require reserving a large amount of redundant sandbox resources as a buffer, further wasting computing resources.

[0040] In view of this, embodiments of this application provide a sandbox processing method. In response to a cloning request for a source sandbox, a clone sandbox with physical memory pages to be allocated is generated on the target virtual machine. The running state of the target virtual machine is the same as that of the virtual machine containing the source sandbox. When a memory access request exists in the clone sandbox, the target physical memory page corresponding to the memory access request is retrieved from the memory of the source sandbox, and the memory page table of the clone sandbox is updated based on the target physical memory page to complete the memory access request. This method avoids completely copying the memory data of the source sandbox by utilizing the memory sharing mechanism and on-demand loading mechanism between the source and clone sandboxes during their running states. The process of copying memory data is transferred to after the clone sandbox starts, and the clone sandbox loads the corresponding memory data according to the actual memory access request. This reduces the amount of data processing during clone sandbox generation, thereby improving the efficiency and real-time performance of clone sandbox generation.

[0041] The technical solutions of this application will now be described in detail with reference to specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0042] Figure 1 This is a flowchart illustrating a sandbox processing method provided in an embodiment of this application. Figure 1 As shown, the method may include the following steps:

[0043] S101. In response to a cloning request for the source sandbox, generate a clone sandbox on the target virtual machine for which physical memory pages are to be allocated.

[0044] The target virtual machine is running in the same state as the virtual machine in the source sandbox.

[0045] A source sandbox refers to a sandbox environment that serves as the source of a cloning operation. It runs specific applications or services and has independent resources such as memory space and file systems.

[0046] A clone request is triggered by a user or the system based on actual needs, and is used to instruct the creation of a clone sandbox with the same initial state as the source sandbox.

[0047] A virtual machine is a virtualized environment for deploying a sandbox. It provides the sandbox with the virtual hardware resources required for operation, such as a virtual central processing unit (vCPU), virtual memory, virtual disk, and virtual network interface. It should be understood that the virtual machines involved in the embodiments of this application may include microvirtual machines, lightweight virtual machines, containerized virtual machines, etc., and the embodiments of this application do not impose any limitations on them.

[0048] A cloned sandbox is a new sandbox obtained by cloning a source sandbox. The cloned sandbox needs to maintain consistency with the source sandbox in its initial state to be able to run applications or services from the source sandbox independently. The target virtual machine is the virtualization environment in which the cloned sandbox is deployed. The target virtual machine can be a pre-configured virtual machine with the same running state as the virtual machine containing the source sandbox, or it can be a virtual machine configured and generated in response to a cloning request based on the running state information of the virtual machine containing the source sandbox, ensuring that the cloned sandbox can start and run normally.

[0049] Pending physical memory pages refer to the physical memory space allocated when the target virtual machine is created, but not yet actually used by the cloning sandbox. This physical memory space will be allocated and used gradually based on memory access requests during the cloning sandbox's operation. For example, the cloning sandbox's memory page table at this time can be shown in Table 1 below:

[0050] Table 1

[0051]

[0052] In this case, the host physical address is NULL, which means that the virtual page number of the clone sandbox has not yet been assigned a corresponding physical address.

[0053] For example, taking a target virtual machine that is configured and generated in response to a cloning request based on the runtime status information of the virtual machine containing the source sandbox, when responding to a cloning request for the source sandbox, the virtualization management software can access the internal state of the virtual machine containing the source sandbox through its provided interface. Therefore, the runtime status information of the virtual machine containing the source sandbox can be obtained through the interface provided by the virtualization management software. Runtime status information refers to the running parameters and status data of the virtual machine containing the source sandbox at a specific moment. This runtime status information reflects the current running status of the virtual machine containing the source sandbox and provides a basis for configuring the target virtual machine for cloning the sandbox.

[0054] For example, runtime status information may include one or more of the following: vCPU status (such as the status of vCPU general-purpose registers, system registers, etc.), memory state metadata (such as memory layout, region description, page table base address, dirty page bitmap, etc.), block device status (such as I / O queue status, current read / write pointer, etc.), network device status (such as Media Access Control Address (MAC), packet queue, virtual queue, etc.), and other virtual machine status (such as interrupt controller status, system clock, etc.).

[0055] After obtaining the running status information of the virtual machine hosting the source sandbox, the target virtual machine can be configured based on this information. Specifically, configuring the target virtual machine may include, for example: allocating the target virtual machine to the same number of vCPUs as the source sandbox virtual machine, and setting the vCPU model, frequency, and other parameters to be consistent with the source sandbox virtual machine; allocating the target virtual machine to the same amount of memory space as the source sandbox virtual machine; configuring the target virtual machine's virtual devices, such as generating a new unique MAC address for the virtual network adapter, but network configuration parameters (such as IP address, subnet mask, gateway, etc.) can be the same as the source sandbox virtual machine or adjusted according to the network environment; and maintaining consistency with the source sandbox virtual machine in terms of virtual disk size, type, file system, and other parameters. Other parameters of the target virtual machine can also be configured, such as virtualization technology type (e.g., KVM, VMware), virtual BIOS settings, etc. It should be understood that these other parameters also need to be consistent with the source sandbox virtual machine.

[0056] This configuration process ensures that the target virtual machine maintains consistency with the virtual machine containing the source sandbox in terms of hardware resources and operating environment, thereby guaranteeing the normal operation of the clone sandbox.

[0057] S102. When a memory access request exists in the clone sandbox, retrieve the target physical memory page corresponding to the memory access request from the memory of the source sandbox.

[0058] In this embodiment, a memory access request refers to a request made by the clone sandbox to read or write memory during its operation. When an application in the clone sandbox executes instructions or accesses data, it generates a memory access request for a specific virtual address.

[0059] The memory of the source sandbox refers to the virtual memory used by the source sandbox during runtime. The memory page table of the source sandbox can be shown in Table 2 below:

[0060] Table 2

[0061]

[0062] The virtual memory of the source sandbox is mapped to the actual physical address of the host machine, and the application code, data, stack and other information of the source sandbox are stored in the corresponding physical address, so as to read data from the corresponding physical address or write data to the corresponding physical address through virtual memory.

[0063] Since a cloned sandbox is a clone of the source sandbox, the indexes in the memory page table of the cloned sandbox (such as the virtual page number mentioned above) can be the same as the indexes in the memory page table of the source sandbox, or there can be a fixed mapping relationship between the indexes in the memory page table of the cloned sandbox and the indexes in the memory page table of the source sandbox, so as to facilitate virtual address translation between sandboxes.

[0064] Since the clone sandbox initially does not load physical memory pages, a page fault will be triggered when a memory access request from the clone sandbox encounters an unloaded virtual address. This page fault can be caught, and the virtual address (e.g., virtual page number) that the clone sandbox needs to access can be determined. Then, based on this virtual address, the mapping relationship between the clone sandbox's virtual addresses and the source sandbox's virtual addresses, the virtual address in the source sandbox corresponding to the virtual address to be accessed in the clone sandbox can be determined. Finally, based on this virtual address determined in the source sandbox and the source sandbox's memory page table, the corresponding physical address, which is the target physical memory page, can be obtained.

[0065] For example, taking Tables 1 and 2 above as examples, when there is a memory access request in the clone sandbox, the range of virtual addresses that need to be accessed in the clone sandbox can be determined based on the memory access request. Suppose that the memory page page1 in the clone sandbox needs to be accessed, the physical address corresponding to the memory page page1 in the source sandbox can be determined from the memory page table of the source sandbox as 0x0004. This physical address is the target physical memory page.

[0066] Optionally, the cloning request mentioned in this application embodiment may include an intra-node cloning request or a cross-node cloning request. When the cloning request is an intra-node cloning request, the target physical memory page corresponding to the memory access request can be obtained from the memory of the source sandbox based on an inter-process memory read system call; when the cloning request is a cross-node cloning request, the target physical memory page corresponding to the memory access request can be obtained from the memory of the source sandbox based on Remote Direct Memory Access (RDMA).

[0067] S103. Update the memory page table of the clone sandbox based on the target physical memory page to complete the memory access request.

[0068] In this embodiment, the memory page table of the cloning sandbox is a key data structure used by the cloning sandbox to translate virtual addresses into physical addresses. It records the mapping relationship between virtual addresses and physical addresses. The memory page table consists of multiple page table entries, each corresponding to a virtual memory page, which stores information such as the physical memory address mapped to the virtual memory page and access permissions.

[0069] Updating the memory page table refers to modifying the page table entry of the virtual memory page corresponding to the current memory access request in the clone sandbox's memory page table, making it point to the physical address of the target physical memory page obtained from the source sandbox. Fulfilling the memory access request means that after updating the memory page table, the clone sandbox can find the correct physical memory address through the memory page table, thereby successfully reading or writing data and satisfying the application's memory access request.

[0070] After acquiring the target physical memory page, it's necessary to determine the page table entry in the clone sandbox's memory page table corresponding to the current memory access request for the virtual memory page. The clone sandbox's virtual address space is divided into multiple virtual memory pages, each with a corresponding page table entry. Based on the virtual address involved in the clone sandbox's memory access request, the page table entry index of the virtual memory page containing that virtual address can be calculated, thus finding the corresponding page table entry. Once the corresponding page table entry is found, the physical address stored in that page table entry can be updated to the physical address of the target physical memory page.

[0071] After the page table entries are updated, the memory management unit of the clone sandbox will use the updated page table entries when performing virtual address to physical address translation, thereby accessing the target physical memory page. At this point, the application in the clone sandbox can continue to execute, complete memory access operations, and satisfy memory access requests.

[0072] The method provided in this application, in response to a cloning request for a source sandbox, generates a clone sandbox on a target virtual machine with physical memory pages to be allocated. The running state of the target virtual machine is the same as that of the virtual machine containing the source sandbox. When a memory access request exists in the clone sandbox, the target physical memory page corresponding to the memory access request is retrieved from the memory of the source sandbox, and the memory page table of the clone sandbox is updated based on the target physical memory page to complete the memory access request. This method avoids completely copying the memory data of the source sandbox by using a memory sharing mechanism and an on-demand loading mechanism between the source sandbox and the clone sandbox during their running states. The process of copying memory data is transferred to after the clone sandbox starts, and the clone sandbox loads the corresponding memory data according to the actual memory access request. This reduces the amount of data processing during clone sandbox generation, thereby improving the efficiency and real-time performance of clone sandbox generation.

[0073] Optionally, the clone sandbox mentioned in this application embodiment may be located on a computing node that is different from the computing node where the source sandbox is located, or it may be located on the computing node where the source sandbox is located.

[0074] In other words, when the cloning request is an intra-node cloning request, the sandbox cloning needs to be performed on the compute node where the source sandbox is located, and both the generated clone sandbox and the source sandbox are deployed within that compute node; when the cloning request is a cross-node cloning request, the sandbox cloning needs to be performed on another compute node different from the compute node where the source sandbox is located, and both the generated clone sandbox and the source sandbox are deployed within different compute nodes.

[0075] When the cloning request is an intra-node cloning request, the target physical memory page corresponding to the memory access request can be obtained from the source sandbox memory based on the inter-process memory read system call.

[0076] The inter-process memory read system call is an interface provided by the operating system kernel of a compute node, used to read memory data between different processes within the same compute node. In intra-node cloning scenarios, the source sandbox and the clone sandbox typically run as different processes within the same operating system kernel, thus allowing direct reading of memory data through this system call.

[0077] Specifically, a cloned sandbox process can specify parameters such as the identifier of the source sandbox process, the address and size of the physical memory pages to be read, etc., through system calls. After verifying permissions, the operating system kernel directly copies the corresponding memory pages from the source sandbox process address space to the cloned sandbox process address space.

[0078] When the cloning request is a cross-node cloning request, the target physical memory page corresponding to the memory access request can be obtained from the memory of the source sandbox based on RDMA.

[0079] RDMA is a network transmission technology that allows a computer to bypass the operating system kernel and directly access the memory of a remote computer, thereby reducing data transmission latency. In cross-node cloning scenarios, where the source sandbox and the clone sandbox reside on different physical nodes, RDMA technology enables direct transfer of memory data between the two physical nodes.

[0080] Specifically, an RDMA connection can first be established between the source and target nodes, configuring relevant parameters of the RDMA network interface card (NIC), such as IP address, port number, and queue pairs. Then, the target node hosting the clone sandbox can send a memory read request via RDMA, specifying the memory address and data length of the source sandbox's memory node. Upon receiving the request, the source node's RDMA NIC directly reads the data from the source sandbox's physical memory and transmits the data to the memory of the compute node deploying the clone sandbox via the RDMA network.

[0081] The method provided in this application distinguishes between intra-node and cross-node cloning scenarios, and respectively uses inter-process memory read system calls and RDMA technology to enable the clone sandbox to read the source sandbox memory data on demand. Combining the runtime memory sharing mechanism and the on-demand loading mechanism, it eliminates the need to pause the source sandbox or completely copy the source sandbox's memory data and root file system copy. The memory data copying process is transferred to after the clone sandbox starts, and the corresponding target physical memory page is loaded only when the clone sandbox generates an actual memory access request. This reduces the amount of data processing and IO operations when the clone sandbox is generated, avoids the memory copying time, disk IO bottlenecks and data redundancy problems caused by the full snapshot scheme, and ensures the continuous operation of the source sandbox without interruption. This improves the efficiency and real-time performance of sandbox cloning and reduces the consumption of storage and computing resources.

[0082] The following section provides a detailed description of how the target physical memory page corresponding to the memory access request is obtained from the source sandbox memory in the aforementioned embodiments. Figure 2 This is a schematic flowchart illustrating another sandbox processing method provided in an embodiment of this application. Figure 2 As shown, the method may specifically include the following steps:

[0083] S201. Based on the memory access request and the page source mapping table between the pre-configured source sandbox and the clone sandbox, determine the virtual memory page in the source sandbox corresponding to the memory access request.

[0084] In this embodiment, the memory access request includes the virtual address information that the clone sandbox needs to access during operation. This virtual address information can be a specific virtual address value or a virtual address range, such as the memory page corresponding to the aforementioned virtual page number.

[0085] The page source map is a pre-configured data structure used to record the mapping relationship between virtual memory pages between source sandboxes and clone sandboxes. The page source map can exist in the form of mapping pairs, where each row contains the virtual memory page identifier of the clone sandbox and the corresponding virtual memory page identifier of the source sandbox. For example, the virtual memory page identifier can be a virtual page number, which is a number obtained by dividing the virtual address according to the page size of the virtual memory page. For instance, if the page size of the virtual memory page is 4KB, then the virtual page number corresponding to virtual addresses 0x00000000-0x00000FFF is 0, the virtual page number corresponding to 0x00001000-0x00001FFF is 1, and so on.

[0086] In this step, the virtual address that the clone sandbox needs to access is first extracted from the memory access request. Then, this virtual address is converted into a virtual page number for the clone sandbox based on the page size. Next, the page source mapping table is queried to find the source sandbox virtual page number corresponding to the clone sandbox virtual page number, thereby determining the virtual memory page in the source sandbox corresponding to the memory access request.

[0087] S202. Based on the mapping relationship between virtual memory pages, source sandbox virtual memory pages and physical memory, obtain the target physical memory page corresponding to the memory access request.

[0088] The mapping relationship between virtual memory pages and physical memory in the source sandbox can be, for example, the source sandbox's memory page table, or a pre-established mapping array, mapping hash table, or hardware-accelerated address translation entries. Taking the memory page table as an example, the source sandbox's memory page table is used to convert virtual page numbers to physical page numbers. A physical page number is an identifier for a physical memory page, and each physical page number corresponds to a physical memory page.

[0089] In this step, the virtual memory page of the source sandbox corresponding to the virtual memory page of the clone sandbox determined in step S201 can be determined first. For example, if the index of the virtual memory page of the clone sandbox determined in step S201 is page1, then the index of the virtual memory page corresponding to the source sandbox can be determined as page1. Next, by querying the memory page table of the source sandbox, the physical address corresponding to the virtual memory page (i.e., the virtual memory page with index page1) is determined from the memory page table of the source sandbox, and this physical address is used as the target physical memory page corresponding to the memory access request.

[0090] The method provided in this application pre-configures a page source mapping table between the source sandbox and the clone sandbox, determines the corresponding virtual memory page in the source sandbox based on the memory access request, and then obtains the target physical memory page based on the mapping relationship between the virtual memory page and physical memory in the source sandbox. This enables the clone sandbox to accurately and on-demand read the memory data of the source sandbox without having to completely copy the memory data of the source sandbox when the clone sandbox starts, without pausing the source sandbox, and without creating a complete snapshot file and a copy of the root file system. This reduces the amount of data processing and I / O operations during the sandbox cloning process, and reduces the problems of long memory copying time, disk I / O bottlenecks, data redundancy, and source sandbox service interruption that exist in traditional full snapshot solutions. As a result, the efficiency and real-time performance of sandbox cloning are improved, and the consumption of storage and computing resources is reduced.

[0091] The following section will take memory access requests, including memory read requests and memory write requests, as examples to explain in detail how the memory page table of the clone sandbox is updated from the target physical memory page in the aforementioned step S103 to complete the memory access request.

[0092] When a memory read request is needed within the cloning sandbox, the physical address of the first memory page in the cloning sandbox's memory page table can be updated to the physical address of the target physical memory page. Here, the first memory page is the virtual memory page corresponding to the memory read request.

[0093] Specifically, a memory read request refers to a request from the cloning sandbox to read data from memory. In this case, the cloning sandbox only needs to acquire the data and does not need to modify it. The first memory page is the virtual memory page in the cloning sandbox's virtual address space that corresponds to this memory read request. Its virtual page number can be calculated from the virtual address in the memory access request. The process of updating the cloning sandbox's memory page table includes: determining the page table entry corresponding to the first memory page in the cloning sandbox's memory page table, and modifying the physical address field in that page table entry to the physical address of the target physical memory page. In this way, when the cloning sandbox accesses the virtual address corresponding to the first memory page again, it can find the physical address of the target physical memory page through the cloning sandbox's memory page table, thereby reading the required data and fulfilling the memory read request.

[0094] Optionally, when the clone sandbox has a memory read requirement, the data in the target physical memory page can be copied to a new physical address, and the physical address corresponding to the first memory page in the clone sandbox's memory page table can be updated according to the new physical address. This way, when the clone sandbox subsequently has a memory read requirement for the first memory page, it will not need to access the source sandbox memory or perform cross-address space data acquisition operations through inter-process memory read system calls or RDMA, thereby further improving the efficiency of the clone sandbox in handling memory read requirements.

[0095] When a memory write request is required within the cloning sandbox, the target physical memory page can be copied to a new physical address, and the physical address of the second memory page in the cloning sandbox's memory page table can be updated to the new physical address. The second memory page is the virtual memory page corresponding to the memory write request.

[0096] Specifically, a memory write request refers to a request from the clone sandbox to write data into memory. Directly modifying the target physical memory page would affect the data consistency of the source sandbox. Therefore, a copy-on-write (CoW) mechanism can be used to implement the memory write request. The second memory page is the virtual memory page in the clone sandbox's virtual address space corresponding to this memory write request. Its virtual page number can also be calculated from the virtual address in the memory access request. First, a new physical memory page, i.e., a new physical address, can be allocated to the clone sandbox. Then, the data in the target physical memory page is completely copied to the new physical memory page. Next, the page table entry corresponding to the second memory page in the clone sandbox's page table is determined, the physical address field in that page table entry is modified to the new physical address, and the access permission bit is set to read / write, indicating that the clone sandbox has read and write permissions for this new physical memory page.

[0097] Subsequently, the clone sandbox's write operations on the second memory page will be applied to the new physical memory page, while the target physical memory page of the source sandbox remains unchanged, thus ensuring the independence of the data between the source sandbox and the clone sandbox.

[0098] The method provided in this application distinguishes between two different access needs of the cloned sandbox: memory read and memory write. It employs different memory page table update strategies accordingly. For memory read needs, the physical address of the page table entry for the corresponding virtual memory page in the cloned sandbox is directly updated to the physical address of the target physical memory page in the source sandbox. Alternatively, the target memory data is copied to a new physical address before updating the page table, achieving efficient memory data reading. For memory write needs, based on a copy-on-write mechanism, the target physical memory page is copied to a new physical address and the page table is updated, ensuring data independence between the source and cloned sandboxes. Combined with the aforementioned on-demand memory loading mechanism, it eliminates the need to completely copy the source sandbox memory data, pause the source sandbox, or create a complete snapshot. This effectively avoids the problems of long memory copying times, disk I / O bottlenecks, data redundancy, and source sandbox service interruptions inherent in traditional complete snapshot schemes, thereby significantly improving the real-time performance and efficiency of sandbox cloning.

[0099] Figure 3 This is a flowchart illustrating another sandbox processing method provided in an embodiment of this application. Figure 3 As shown, when the cloning request is a cross-node cloning request, the method may further include the following steps:

[0100] S301. Based on the historical memory access records of the source sandbox, predict the virtual memory pages required for the first startup of the clone sandbox.

[0101] In this embodiment, the historical memory access record of the source sandbox refers to the record of the source sandbox's access to memory pages during its past operation. This record may include, for example, the timestamp of the access, the virtual page number accessed, and the access type (read or write). The historical memory access record of the source sandbox can be stored in the node where the source sandbox resides as a log file, or it can be stored in a dedicated storage system.

[0102] The virtual memory page required for the initial startup of the clone sandbox refers to the virtual memory page that the clone sandbox must access during the initial startup process (for ease of description, this virtual memory page will be referred to as the startup memory page). The startup memory page contains the key code and data required for startup, such as the initialization code of the operating system kernel, the entry code of the application, and necessary configuration data.

[0103] In this step, predicting the startup memory page can be achieved using algorithms such as frequency-based prediction or sequence pattern-based prediction. For example, using a frequency-based prediction algorithm, the access frequency of each virtual page number in the source sandbox's historical memory access records can be statistically analyzed, and the memory pages corresponding to virtual page numbers with higher access frequencies can be predicted as startup memory pages. Using a sequence pattern-based prediction algorithm, the sequence patterns in the memory access records can be analyzed to identify virtual page number sequences that are frequently accessed in a specific order during the startup phase, and the memory pages corresponding to these sequences can be predicted as startup memory pages.

[0104] S302. Before the cloned sandbox starts, the startup physical memory page corresponding to the virtual memory page required for the first startup is obtained from the memory of the source sandbox based on RDMA.

[0105] In this embodiment, "before the clone sandbox starts" refers to the stage where the target virtual machine of the clone sandbox has been created, but the application in the clone sandbox has not yet started executing. The startup physical memory page refers to the physical memory page in the source sandbox memory corresponding to the startup memory page predicted in step S301.

[0106] In this step, an RDMA connection can first be established between the source node where the source sandbox is located and the target node where the clone sandbox is located. Then, based on the predicted virtual page number of the boot memory page, the target node determines the physical address and size of the corresponding boot physical memory page in the source sandbox using the methods described in steps S201 and S202, and constructs an RDMA read request accordingly. This RDMA read request may include the RDMA network card address of the source node, the physical address of the boot physical memory page, the data length, and the address of the buffer in the target node's local memory used to store the read data.

[0107] The target node's RDMA network card sends an RDMA read request to the source node's RDMA network card. Upon receiving the request, the source node's RDMA network card directly reads the data for the boot physical memory page from the source sandbox's memory and transmits the data to the target node's local memory buffer via the RDMA network. During this data transmission, no intervention from the source or target node's CPU is required, thus improving data transmission efficiency.

[0108] S303: Load the startup physical memory pages into the memory of the clone sandbox.

[0109] In this embodiment, loading the startup physical memory page into the clone sandbox memory means writing the data of the startup physical memory page obtained through RDMA into the unallocated physical memory page allocated to the target virtual machine of the clone sandbox, and updating the memory page table of the clone sandbox so that the startup memory page in the virtual address space of the clone sandbox is mapped to these physical memory pages.

[0110] Specifically, the target node can first copy the boot physical memory page data received via RDMA from its local memory buffer to the physical memory page to be allocated in the target virtual machine. Then, for the clone sandbox virtual page number corresponding to each boot memory page, it determines the corresponding page table entry in the clone sandbox memory page table and updates the physical address in the page table entry to the physical address of the physical memory page to be allocated that stores the boot physical memory page data.

[0111] In this way, when the cloning sandbox starts, these pre-loaded physical memory pages can be directly accessed through the page table, thereby speeding up the startup of the cloning sandbox and reducing page errors and data transfer latency during the startup process.

[0112] The method provided in this application predicts the startup memory pages required by the clone sandbox based on the historical memory access records of the source sandbox. Before the clone sandbox starts, it uses RDMA technology to prefetch the corresponding startup physical memory pages to the target node and load them into the clone sandbox memory, updating the memory page table of the clone sandbox. This achieves preloading and address mapping of key memory data in cross-node scenarios, reducing page faults and real-time data transmission latency during the clone sandbox startup process, further accelerating the startup speed of the clone sandbox, thereby further reducing sandbox startup latency in cross-node cloning scenarios and improving the real-time performance and response speed of cross-node deployment.

[0113] The following section provides a detailed explanation of how, in step S101, the target virtual machine with the clone sandbox containing the physical memory pages to be allocated is configured based on the running status information of the virtual machine where the source sandbox is located. Figure 4 This is a flowchart illustrating another sandbox processing method provided in an embodiment of this application. Figure 4 As shown, step S101 may specifically include the following steps:

[0114] S401. In response to the cloning request, suspend the vCPU of the virtual machine where the source sandbox resides.

[0115] In this embodiment, pausing the vCPU of the virtual machine where the source sandbox resides means temporarily stopping the instruction execution process of the vCPU, so that the running state of the virtual machine where the source sandbox resides remains at the current moment, so as to accurately obtain the running state information of the virtual machine where the source sandbox resides.

[0116] Upon receiving a cloning request, a pause command can be sent to the vCPU of the virtual machine hosting the source sandbox. After executing the current instruction or completing the current basic operation, the vCPU enters a paused state. In the paused state, the vCPU no longer executes new instructions, and its register values, program counter position, and other state information remain unchanged, thus ensuring the accuracy of subsequently acquired runtime state information.

[0117] S402. Obtain the running status information of the virtual machine where the source sandbox is located.

[0118] In this embodiment, after the vCPU of the virtual machine containing the source sandbox is suspended, the runtime status information of the virtual machine can be obtained through the interface or tools provided by the virtualization management software. The interface or tools provided by the virtualization management software can access the internal data structure of the virtual machine containing the source sandbox and extract the required runtime status information. The obtained runtime status information can be stored in a data structure for subsequent use when configuring the target virtual machine.

[0119] S403. Restore the vCPU of the virtual machine where the source sandbox is located, and configure the target virtual machine according to the running status information.

[0120] In this embodiment, after obtaining the running status information of the virtual machine where the source sandbox is located, it is necessary to restore the operation of the vCPU of the virtual machine where the source sandbox is located in order to avoid affecting the normal operation of the source sandbox.

[0121] Specifically, a recovery command can be sent to the vCPU of the virtual machine hosting the source sandbox. The vCPU resumes from its suspended state and continues executing instructions that were not completed before the suspension. After the vCPU of the virtual machine hosting the source sandbox resumes operation, the target virtual machine can be configured based on the obtained runtime status information. This ensures that the target virtual machine has a similar runtime environment to the virtual machine hosting the source sandbox, providing a foundation for the deployment of the cloned sandbox.

[0122] The method provided in this application suspends the vCPU of the virtual machine where the source sandbox is located during the cloning process to obtain running status information, then resumes the vCPU operation, and configures the target virtual machine based on the obtained running status information. It performs lightweight copying of the running status information of the virtual machine where the source sandbox is located instead of full memory and disk data copying. This shortens the interruption time of the source sandbox while ensuring the consistency of the virtual machine state, avoids the time consumption and IO overhead caused by full snapshot persistence, and thus achieves rapid sandbox cloning while ensuring the continuity of source sandbox services and reducing the impact of the cloning process on the operation of the source sandbox.

[0123] Figure 5 This is a flowchart illustrating another sandbox processing method provided in an embodiment of this application. Figure 5 As shown, the method may further include the following steps:

[0124] S501. When there is a memory write requirement in the source sandbox, generate a memory page copy corresponding to the memory write requirement.

[0125] In this embodiment, a memory write request from the source sandbox refers to a request made by the source sandbox to write data to a specific memory page during its operation. When an application in the source sandbox executes a write operation instruction, a memory write request is generated, specifying the virtual address and data content to be written. A memory page copy refers to a new memory page obtained by copying the memory page corresponding to the memory write request in the source sandbox. This copy has the same data content as the original memory page but is stored at a different physical address.

[0126] In this step, write protection can be set for the source sandbox's memory pages, meaning any write operation to a memory page in the source sandbox will trigger a page fault. After detecting a memory write request from the source sandbox, the corresponding virtual memory page is determined. Since the source sandbox's memory pages are write-protected, this write operation will trigger a page fault, and the corresponding memory page will be captured.

[0127] Then, by querying the source sandbox's page table, the virtual memory page corresponding to the source sandbox's memory write request, and the original physical memory page corresponding to that virtual memory page, are determined. The operating system can then allocate a new physical memory page as a memory page copy for the source sandbox and copy the data from the original physical memory page into this new physical memory page, resulting in a memory page copy. This memory page copy is used to perform the memory write operation corresponding to the source sandbox's memory write request, while the original physical memory page can be used for memory access requests from the cloned sandbox (such as copying the original physical memory page during memory read and write requests), thus reducing the impact of the source sandbox's memory write operation on the cloned sandbox's memory access request execution.

[0128] S502, Utilize memory page copies to execute the source sandbox's memory write requirements.

[0129] Specifically, using memory page copies to execute memory write requests means writing the data to be written from the source sandbox to a memory page copy, rather than the original physical memory page, to ensure that the data in the original physical memory page is not modified, thereby ensuring that the cloned sandbox can obtain the original data when accessing the source sandbox memory.

[0130] One possible implementation is to first take a snapshot of the source sandbox's memory page table, generating a memory page table snapshot. When the clone sandbox needs to use the source sandbox's memory page table (e.g., when a page fault occurs and the corresponding physical memory address needs to be determined based on the source sandbox's memory page table), it can call this snapshot. When the source sandbox uses a memory page copy to execute its memory write requests, it updates the physical address corresponding to the virtual memory page in the memory page table to the physical address corresponding to the memory page copy. In this way, the source sandbox's memory write operation does not affect the data in the original physical memory page, thus ensuring that the clone sandbox can obtain the original data before the write operation when it needs to access the source sandbox's memory, guaranteeing the consistency of the clone sandbox's initial state.

[0131] Another possible implementation is that when the source sandbox uses a memory page copy to execute its memory write requests, it can add a virtual memory page index to the source sandbox's memory page table. This index is then associated with the memory page copy, and a relationship is established between the new and original virtual memory page indices. This allows the source sandbox to perform memory write operations by mapping the new virtual memory page index to the memory page copy. Conversely, when the clone sandbox needs to use the source sandbox's memory page table, it uses the original virtual memory page index to map to the original physical address to obtain the original data before the source sandbox performed the write operation.

[0132] The method provided in this application generates a corresponding memory page copy when there is a memory write requirement in the source sandbox, and performs a write operation based on the memory page copy, while keeping the original physical memory page data unchanged. It also provides stable and consistent original memory data for the clone sandbox in conjunction with memory page table snapshots or the original virtual memory page index, so as to avoid the write operation of the source sandbox from interfering with the memory access of the clone sandbox, and ensure the data isolation and state consistency between the source sandbox and the clone sandbox. Thus, while achieving efficient sandbox cloning, it ensures the stable operation and reliable data of the clone sandbox, and further improves the stability and applicability of the solution in concurrent and long-term operation scenarios.

[0133] Optionally, embodiments of this application may also enable the source sandbox and the clone sandbox to share the source sandbox's file system, thereby further improving the efficiency and real-time performance of sandbox cloning. Figure 6 This is a flowchart illustrating another sandbox processing method provided in an embodiment of this application. Figure 6 As shown, the method may further include the following steps:

[0134] S601. In response to a cloning request for the source sandbox, perform an online snapshot of the root file system of the source sandbox to obtain a root file system index snapshot.

[0135] In this embodiment, the root file system of the source sandbox is a structure used to organize and store files and directories in the source sandbox. It may contain file metadata (such as filename, size, creation time, modification time, permissions, etc.) and file data. Online snapshot processing refers to performing snapshot operations on the root file system of the source sandbox while it is running normally, in order to create a consistent copy of the root file system at a certain point in time.

[0136] A file system index snapshot refers to a metadata snapshot of the root file system obtained through online snapshot processing. It records the metadata information of files and directories in the root file system at the snapshot time, but does not include the actual data content of the files. This function can be implemented by a root file system storage management module, which can run as a daemon (such as the root file system management daemon) or be integrated into a storage system with sandbox lifecycle management.

[0137] The process of performing online snapshot processing on the root file system of the source sandbox can be implemented through the aforementioned root file system management daemon. Specifically, upon receiving a cloning request, the root file system management daemon receives and parses the request, and determines the name and storage location of the root file system index snapshot. Subsequently, through the management interface between the root file system management daemon and the source sandbox root file system, all write operations on the source sandbox root file system are temporarily suspended to ensure the consistency of the root file system index snapshot at any given time. After the source sandbox root file system is frozen, the root file system management daemon reads the metadata information of the source sandbox root file system, creates pointers to the metadata information, and thus forms the root file system index snapshot. Since the root file system index snapshot only contains metadata references and does not copy actual file data, the root file system index snapshot creation process is fast and consumes little space under the control of the root file system management daemon. After the root file system index snapshot is created, the root file system management daemon can resume normal write operations on the source sandbox root file system. The generated root file system index snapshot can be stored inside the source sandbox root file system or on an external storage device.

[0138] S602. Based on the root file system index snapshot, create independent writable layers based on copy-on-write for the source sandbox and the clone sandbox respectively.

[0139] The independent writable layer is used to record the data modifications made by the corresponding sandbox relative to the root file system.

[0140] In this embodiment, the independently writable layer of CoW refers to creating a writable root file system layer for both the source sandbox and the clone sandbox. This layer is based on a file system index snapshot and initially contains no data. Modified file data is copied to the respective independently writable layer only when the source sandbox or the clone sandbox performs a write operation on a file. The root file system data refers to the original file data pointed to by the root file system index snapshot, and this data is shared by the source sandbox and the clone sandbox.

[0141] In this step, an independent writable layer is created for the source sandbox, which is associated with the root filesystem index snapshot. The original root filesystem access path of the source sandbox is redirected to this independent writable layer. When the source sandbox reads a file, it first checks if a modified version of the file exists in the independent writable layer. If not, it reads from the underlying root filesystem data (the data pointed to by the root filesystem index snapshot). When the source sandbox writes a file, it copies the original data of the file from the underlying root filesystem data to the independent writable layer of the source sandbox, and then modifies the file in the independent writable layer.

[0142] An additional independent writable layer is created for the clone sandbox, which is also associated with the root filesystem index snapshot. The clone sandbox's root filesystem access path is redirected to its independent writable layer. When the clone sandbox reads a file, it first checks its own independent writable layer; if it doesn't exist, it reads the data from the underlying root filesystem. When the clone sandbox writes a file, it copies the original data to its own independent writable layer before modifying it.

[0143] The method provided in this application generates a root file system index snapshot by performing an online snapshot of the root file system of the source sandbox, and constructs independent writable layers for copy-on-write for the source sandbox and the clone sandbox based on the index snapshot. This allows the source sandbox and the clone sandbox to share the underlying root file system data. Data copies are only created in their own independent writable layers when they perform write operations, avoiding the copying of the entire root file system data during the cloning process of the clone sandbox, reducing the amount of data processing, and thus further improving the cloning efficiency and real-time performance of the sandbox cloning, and reducing the latency of clone sandbox generation.

[0144] Figure 7 This is a flowchart illustrating another sandbox processing method provided in an embodiment of this application. Figure 7 As shown, the method may further include the following steps:

[0145] S701, maintain the difference log for the clone sandbox.

[0146] The difference log includes data on the differences between the cloned sandbox and the source sandbox at the memory page and root file system levels.

[0147] In this embodiment, the difference log is a log file used to record the changes that occur in the clone sandbox compared to the source sandbox during operation. It can exist in the form of a text file, a binary file, or a database record, and is stored on the node where the clone sandbox is located or on a dedicated log server.

[0148] Write operations at the memory page level include information such as the modified virtual page number, modification timestamp, and optional data differences before and after the modification when the clone sandbox writes to its memory pages. This information can be recorded by capturing copy-on-write events. Write operations at the root file system level include information such as the file path, operation type, operation timestamp, and differences in file content when the clone sandbox creates, modifies, or deletes files. This information can be obtained by monitoring changes in the writable layer through the root file system storage management module.

[0149] In this step, when the clone sandbox performs a write operation on a memory page, the write event can be captured through the hook function of the memory management unit or the user-mode page fault handling mechanism, recording the modified virtual page number and the operation timestamp, and recording the data differences (for example, only recording the modified bytes and their positions).

[0150] When the clone sandbox performs write operations on the file system, file operation events can be captured through file system hook functions or the auditing mechanism of the root file system storage management module. This captures the file path, operation type (such as create, write, delete, rename, etc.), operation timestamp, and differences in file content (e.g., by comparing the hash values ​​before and after file modification or directly recording the modified content blocks). This captured information is written to the difference log in real time, ensuring that the difference log accurately reflects the changes in the clone sandbox.

[0151] S702. When a clone request is initiated again based on the clone sandbox, the secondary clone sandbox is configured according to the difference data generated by the clone sandbox relative to the source sandbox in the difference log.

[0152] In this embodiment, a cloning request initiated again based on a clone sandbox refers to requesting the creation of a new clone sandbox (i.e., a secondary clone sandbox) using the clone sandbox as the new source sandbox. Difference data refers to the data changes recorded in the difference log resulting from write operations at the memory page and file system levels between the clone sandbox and the source sandbox. Configuring a secondary clone sandbox refers to creating a secondary clone sandbox consistent with the current state of the original clone sandbox based on this difference data.

[0153] In this step, when a re-cloning request based on the cloning sandbox is received, the difference data recorded in the cloning sandbox's difference log can be extracted, including the differences at the memory page and file system levels. For the difference data at the memory page level, the physical memory page data corresponding to the virtual page numbers recorded in the difference log can be retrieved from the cloning sandbox's memory (i.e., the difference memory page data). For the difference data at the file system level, the modified file data (i.e., the difference file data) can be retrieved from the writable layer of the cloning sandbox based on the file paths and operation types recorded in the difference log.

[0154] Next, a third virtual machine is created within the secondary clone sandbox, and its basic environment is configured based on the clone sandbox's runtime status information (similar to steps S101 and S401-S403 described above). Then, the underlying file system data of the source sandbox and the differential file data of the clone sandbox are merged to create an independent writable layer for the secondary clone sandbox based on copy-on-write, enabling the secondary clone sandbox to access the current file system state of the clone sandbox. Simultaneously, the differential memory page data of the clone sandbox is loaded into the memory of the secondary clone sandbox, and the secondary clone sandbox's memory page table is updated to map to this differential memory page data. For memory pages and file data that are not modified by the clone sandbox, the secondary clone sandbox can still share the underlying data of the source sandbox, thereby reducing data transfer and storage overhead.

[0155] The method provided in this application maintains a difference log at the memory page and file system levels for the cloning sandbox, and synchronizes only the difference data based on the difference log during the secondary cloning. It combines the underlying shared data of the source sandbox to complete the configuration of the secondary cloning sandbox, thereby avoiding repeated copying and persistence of the full memory and file system data. It supports fast derivation in multi-level chained cloning scenarios, thereby further improving the efficiency of multi-level cloning of sandboxes, reducing data transmission and storage overhead, and improving the scalability and real-time performance of the cloning system.

[0156] To facilitate understanding, the following provides an exemplary system structure for implementing the sandbox processing method in the above embodiments, as well as specific examples of sandbox cloning within the same node and sandbox cloning across nodes, to provide a detailed exemplary description of the sandbox processing method provided in this application embodiment.

[0157] Figure 8 This is a schematic diagram of a sandbox management system provided in an embodiment of this application. Figure 8 As shown, taking the AIAgent platform as an example, this sandbox management system includes: a user application layer, a control plane, and a data plane.

[0158] The user application layer is used to initiate sandbox cloning requests to the control plane on the same node or across nodes, and to receive environment readiness notifications after the sandbox cloning is completed, providing low-latency, high-concurrency sandbox environment call interfaces for upper-layer services such as AI agents.

[0159] The control plane is used for the overall management, resource scheduling, and status monitoring of the sandbox throughout its entire lifecycle. This control plane includes services such as sandbox lifecycle management, sandbox template management, resource scheduling, and monitoring and alerting. Specifically, the sandbox lifecycle management service receives and parses cloning requests from the user application layer, coordinates the data plane to complete sandbox creation, startup, and destruction operations, and maintains the consistency of the sandbox state; the sandbox template management service manages the sandbox base image, configuration templates, and version information, providing a standardized operating environment baseline for cloning sandboxes; the resource scheduling service selects appropriate compute nodes in the cluster to allocate resources based on cloning requests, achieving target node scheduling during cross-node cloning; and the monitoring and alerting service collects real-time resource usage and operational status data for each compute node and sandbox instance, providing alerts and logging for abnormal situations.

[0160] The data plane hosts the actual operation and cloning of sandbox instances, providing intra-node / cross-node memory sharing, file system copy-on-write capabilities, and high-speed data transfer. The data plane includes multiple compute nodes, each of which can be a physical server, cloud server, edge computing node, or other computing device. Each compute node can deploy one or more microvirtual machines, and each virtual machine can host a sandbox environment. The compute node may include a sandbox daemon, which internally includes a microvirtual machine monitor (MicroVM-Hypervisor), a root file system daemon (RootFs-Daemon), and a memory migration daemon. The microvirtual machine monitor is responsible for the lifecycle of the microvirtual machine; the root file system daemon is responsible for the full lifecycle management of the root file system copy-on-write block devices; and the memory migration daemon is responsible for memory sharing and on-demand transfer.

[0161] by Figure 8 Taking the deployment of the source sandbox in computing node 1 as an example, the source sandbox can be cloned using the sandbox processing method in the above method embodiment to generate the corresponding clone sandbox.

[0162] Specifically, the control plane can determine the clone type (same node / cross node) and select the target computing node based on the clone request received from the user application layer by the resource scheduling service, and then the sandbox lifecycle management service can issue a clone command to the sandbox daemon process of the computing node where the source sandbox is located.

[0163] If it is a clone request on the same node, the sandbox daemon of compute node 1 briefly pauses the source sandbox vCPU through the microvirtual machine monitor to obtain the running status, and then resumes vCPU operation; the root file system daemon creates an independent writable layer based on copy-on-write for the source sandbox and the clone sandbox, sharing the underlying file system data; the memory migration daemon realizes the on-demand sharing and loading of the source sandbox memory by the clone sandbox based on the inter-process memory read system call, and completes the creation of the clone sandbox on the same node.

[0164] If it is a cross-node clone request, the management plane routes the clone request to compute node 2. The memory migration daemon of compute node 1 and compute node 2 establishes an RDMA connection to enable on-demand sharing and loading of the source sandbox memory in compute node 1 from the clone sandbox in compute node 2. The root file system daemon creates a write-on-write independent writable layer based on file system index snapshots for the cross-node clone sandbox. The micro virtual machine monitor configures the cross-node clone sandbox according to the source sandbox running status information to realize cross-node sandbox cloning.

[0165] Figure 9A and Figure 9B This is a flowchart illustrating a sandbox cloning method within a node, as provided in an embodiment of this application. Figure 9A , 9B As shown, the method includes:

[0166] S901, the sandbox daemon process receives the cloning request issued by the control plane and obtains the source sandbox identification information.

[0167] The source sandbox identification information may include, for example, the sandbox identifier, the virtual machine identifier of the microvirtual machine where the source sandbox resides, and the node identifier of the compute node where the source sandbox resides. The cloning request may include the source sandbox identification information so that the compute node can determine the source sandbox to be cloned based on this information.

[0168] S902, the sandbox daemon sends a pause command to the microvirtual machine monitor of the source sandbox, pausing the vCPU of the source sandbox.

[0169] S903, the microvirtual machine monitor collects the running status information of the microvirtual machines deployed in the source sandbox and generates microvirtual machine status snapshots.

[0170] S904, Micro Virtual Machine Monitor restores the vCPU operation of the source sandbox.

[0171] The contents of steps S902 to S904 above can be referred to steps S401 to S403 in the aforementioned method embodiment, and will not be repeated here.

[0172] S905, The sandbox daemon starts the memory migration daemon, registers the memory region of the microvirtual machine of the deployment source sandbox, and sets write protection for the memory region.

[0173] Specifically, write protection is set for the memory region of the microvirtual machine in the source sandbox, so that when memory writes are triggered subsequently, the user-mode page fault handling mechanism can be used to capture page fault exceptions and determine the memory page to be written.

[0174] S906. The sandbox daemon calls the root file system storage daemon to perform online snapshot processing on the root file system of the source sandbox and generate a root file system index snapshot.

[0175] S907, the root file system storage daemon, based on the root file system index snapshot, creates root file system devices with independent writable layers, including copy-on-write, for the source sandbox and the clone sandbox to be created.

[0176] Steps S906 to S907 described above can be referred to steps S601 to S602 in the aforementioned method embodiment, and will not be repeated here.

[0177] S908, The sandbox daemon creates a new microvirtual machine monitor process to manage microvirtual machine instances that are cloned from the sandbox.

[0178] In this step, a corresponding micro-virtual machine, as well as a corresponding micro-virtual machine monitor process, root file system daemon process, and memory migration daemon process can be created for the clone sandbox.

[0179] S909, the sandbox daemon configures the microvirtual machine runtime environment of the cloned sandbox based on the obtained microvirtual machine state snapshot and the newly created root file system device.

[0180] The S910 sandbox daemon configures the cloned sandbox's memory to rely on the user-mode page fault handling mechanism to handle memory access page fault exceptions, thereby enabling on-demand loading of memory data.

[0181] In this step, the memory region of the clone sandbox can be registered through the user-mode page fault handling mechanism, and there is no need to allocate physical memory for the clone sandbox. When a memory access request occurs after the clone sandbox runs, the corresponding physical memory is loaded from the memory of the source sandbox as needed according to the memory access request.

[0182] S911, The sandbox daemon starts the microvirtual machine instance of the clone sandbox, and the clone sandbox begins initialization and operation.

[0183] S912: When accessing memory during the operation of the clone sandbox, a page fault is triggered, and a memory read request is initiated to the memory migration daemon through the user-mode page fault handling mechanism.

[0184] S913, the memory migration daemon reads the target physical memory page corresponding to the request from the microvirtual machine process in the source sandbox based on inter-process memory read system calls.

[0185] S914 The memory migration daemon maps the target physical memory pages it reads to the address space of the microvirtual machine in the clone sandbox and updates the memory page table of the clone sandbox.

[0186] The steps S912 to S914 described above can refer to the steps S201 to S202 and S103 in the aforementioned method embodiments, and will not be repeated here.

[0187] S915: The cloned sandbox completes initialization, rebuilds the network stack, maintains external service connections, and enters a ready state to provide services.

[0188] Figure 10A and Figure 10B This is a flowchart illustrating a cross-node sandbox cloning method provided in an embodiment of this application. Figure 10A , 10B As shown, taking the source sandbox located on the first computing node and the clone sandbox located on the second computing node as an example, the method includes:

[0189] S1001, The sandbox daemon of the first computing node receives a cloning request from the control plane, obtains the source sandbox identifier information, and sends a collaboration request to the sandbox daemon of the second computing node.

[0190] S1002, The sandbox daemon of the first computing node sends a pause command to the microvirtual machine monitor of the source sandbox to pause the virtual central processing unit of the source sandbox.

[0191] S1003. The microvirtual machine monitor of the first computing node collects the running status information of the microvirtual machines deployed in the source sandbox and generates a snapshot of the microvirtual machine status.

[0192] S1004, The microvirtual machine monitor of the first compute node resumes the virtual central processing unit operation of the source sandbox.

[0193] The contents of steps S1002 to S1004 above can be referred to steps S401 to S403 in the aforementioned method embodiment, and will not be repeated here.

[0194] S1005. The sandbox daemon of the first compute node starts the memory migration daemon, registers the memory region of the microvirtual machine of the deployment source sandbox, and sets write protection for the memory region.

[0195] Specifically, write protection is set for the memory region of the microvirtual machine in the source sandbox. This allows the user-mode page fault handling mechanism to capture page fault exceptions and identify the memory page to be written when memory writes are triggered. After registration and write protection are completed, the memory migration daemon of the first compute node enters a listening state, ready to handle remote memory read requests from the second compute node.

[0196] S1006. The sandbox daemon of the first computing node calls the root file system storage daemon to perform online snapshot processing on the root file system of the source sandbox and generate a root file system index snapshot.

[0197] S1007. The root file system storage daemon of the first compute node transmits the root file system index snapshot information to the root file system storage daemon of the second compute node, and the sandbox daemon of the first compute node transmits the micro-virtual machine state snapshot to the sandbox daemon of the second compute node.

[0198] Correspondingly, the sandbox daemon of the second compute node receives snapshots of the microvirtual machine state, and the root file system storage daemon of the second compute node receives snapshot information of the root file system index.

[0199] S1008. The root file system storage daemon of the second computing node creates a root file system device with an independent writable layer, including copy-on-write, for the clone sandbox to be created, based on the root file system index snapshot information.

[0200] In this scenario, the root file system device shares the same file system image as the source sandbox of the source node. This step can be referred to steps S601-S602 in the aforementioned method embodiment, and will not be repeated here. Since this is a cross-node scenario, the independent writable layer for copy-on-write needs to support the ability to remotely index to the snapshot layer of the first compute node.

[0201] S1009. The sandbox daemon of the second compute node creates a new microvirtual machine monitor process to manage the microvirtual machine instances of the cloned sandbox.

[0202] In this step, a corresponding micro-virtual machine, as well as a corresponding micro-virtual machine monitor process, root file system daemon process, and memory migration daemon process can be created for the clone sandbox.

[0203] S1010, the sandbox daemon of the second compute node, configures the microvirtual machine runtime environment of the cloned sandbox based on the obtained microvirtual machine state snapshot and the newly created root file system device.

[0204] S1011. The sandbox daemon of the second computing node configures the memory of the cloned sandbox to rely on the user-mode page fault handling mechanism to handle memory access page fault exceptions, so as to realize on-demand loading of memory data.

[0205] In this step, the memory region of the clone sandbox can be registered through the user-mode page fault handling mechanism, and there is no need to allocate physical memory for the clone sandbox. When a memory access request occurs after the clone sandbox runs, the corresponding physical memory is loaded from the memory of the source sandbox on demand according to the memory access request using RDMA technology.

[0206] S1012, The sandbox daemon of the second compute node starts the microvirtual machine instance of the clone sandbox, and the clone sandbox begins initialization and operation.

[0207] S1013. When accessing memory during the operation of the clone sandbox, a page fault is triggered. The user-mode page fault handling mechanism initiates a memory read request to the memory migration daemon of the second computing node.

[0208] S1014. The memory migration daemon of the second computing node initiates a remote memory read request to the memory migration daemon of the first computing node.

[0209] S1015. The memory migration daemon of the first compute node reads the target physical memory page corresponding to the request from the micro virtual machine process in the source sandbox through remote direct memory access technology based on the remote memory read request, and writes the target physical memory page directly into the memory of the second compute node.

[0210] S1016. The memory migration daemon of the second compute node maps the read target physical memory pages to the microvirtual machine address space of the clone sandbox and updates the memory page table of the clone sandbox.

[0211] S1017. The cloned sandbox completes initialization, rebuilds the network stack and maintains external service connections, and enters a ready state to provide services to the outside world.

[0212] Figure 11 This is a schematic diagram of a sandbox processing device provided in an embodiment of this application. Figure 11 As shown, the device may include: a processing module 11, an acquisition module 12, and a control module 13.

[0213] Processing module 11 is used to generate a clone sandbox with physical memory pages to be allocated on the target virtual machine in response to a cloning request for the source sandbox. The running state of the target virtual machine is the same as that of the virtual machine where the source sandbox is located.

[0214] The acquisition module 12 is used to acquire the target physical memory page corresponding to the memory access request from the memory of the source sandbox when there is a memory access request in the clone sandbox.

[0215] The control module 13 is used to update the memory page table of the clone sandbox based on the target physical memory page in order to complete the memory access request.

[0216] Optionally, module 12 is specifically used to retrieve the target physical memory page corresponding to the memory access request from the source sandbox memory based on inter-process memory read system calls when the cloning request is an intra-node cloning request. When the cloning request is a cross-node cloning request, it retrieves the target physical memory page corresponding to the memory access request from the source sandbox memory based on RDMA.

[0217] Optionally, module 12 is specifically used to determine the virtual memory page in the source sandbox corresponding to the memory access request based on the memory access request and the pre-configured page source mapping table between the source sandbox and the clone sandbox. Based on the mapping relationship between the virtual memory pages, the virtual memory pages in the source sandbox, and physical memory, the target physical memory page corresponding to the memory access request is obtained. The page source mapping table includes the virtual memory page correspondence between the source sandbox and the clone sandbox.

[0218] Optionally, when the memory access request includes both memory read and memory write requests, the control module 13 is specifically used to update the physical address of the first memory page in the clone sandbox's memory page table to the physical address of the target physical memory page when there is a memory read request in the clone sandbox, where the first memory page is the virtual memory page corresponding to the memory read request. When there is a memory write request in the clone sandbox, the target physical memory page is copied to the new physical address, and the physical address of the second memory page in the clone sandbox's memory page table is updated to the new physical address, where the second memory page is the virtual memory page corresponding to the memory write request.

[0219] Optionally, when the cloning request is a cross-node cloning request, the processing module 11 is further configured to predict the virtual memory pages required for the initial startup of the clone sandbox based on the historical memory access records of the source sandbox. The acquisition module 12 is further configured to, before the clone sandbox starts, acquire the startup physical memory page corresponding to the virtual memory page required for the initial startup from the memory of the source sandbox based on RDMA. The control module 13 is further configured to load the startup physical memory page into the memory of the clone sandbox.

[0220] Optionally, processing module 11 is further configured to generate a memory page copy corresponding to the memory page required for the memory write operation when there is a memory write requirement in the source sandbox. Control module 13 is further configured to execute the memory write requirement of the source sandbox using the memory page copy.

[0221] Optionally, processing module 11 is further configured to, in response to a cloning request for the source sandbox, perform online snapshot processing on the root file system of the source sandbox to obtain a root file system index snapshot. Based on the root file system index snapshot, independent writable layers based on copy-on-write are created for both the source and clone sandboxes. These independent writable layers are used to record the data modifications made by the corresponding sandbox relative to the root file system.

[0222] Optionally, processing module 11 is also used to maintain a difference log for the clone sandbox, which includes difference data generated by write operations between the clone sandbox and the source sandbox at the memory page and root file system levels. When a clone request is initiated again based on the clone sandbox, a secondary clone sandbox is configured according to the difference data generated by the clone sandbox relative to the source sandbox in the difference log.

[0223] Optionally, processing module 11 is specifically used to suspend the virtual central processing unit (vCPU) of the virtual machine where the source sandbox resides in response to a cloning request. Acquisition module 12 is specifically used to acquire the running status information of the virtual machine where the source sandbox resides. Processing module 11 is specifically used to resume the running of the vCPU of the virtual machine where the source sandbox resides and configure the target virtual machine based on the running status information.

[0224] The sandbox processing device provided in this application embodiment can execute the sandbox processing method in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described again here.

[0225] Figure 12 This is a schematic diagram of an electronic device provided in an embodiment of this application. This electronic device can, for example, be used to execute the aforementioned sandbox processing method. Figure 12 As shown, the electronic device 1200 may include at least one processor 1201 and a memory 1202. In one possible implementation, it may also include a communication interface 1203.

[0226] The memory 1202 is used to store programs. Specifically, the program may include program code, which includes computer operation instructions.

[0227] The memory 1202 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage.

[0228] The processor 1201 is used to execute computer execution instructions stored in the memory 1202 to implement the method described in the foregoing method embodiments. The processor 1201 may be a CPU, an Application Specific Integrated Circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application.

[0229] Processor 1201 can communicate and interact with external devices through communication interface 1203. In specific implementations, if communication interface 1203, memory 1202, and processor 1201 are implemented independently, they can be interconnected via a bus to complete communication. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc., but this does not imply that there is only one bus or one type of bus.

[0230] Optionally, in a specific implementation, if the communication interface 1203, memory 1202 and processor 1201 are integrated on a single chip, then the communication interface 1203, memory 1202 and processor 1201 can communicate through an internal interface.

[0231] This application also provides a computer-readable storage medium, which may include various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk. Specifically, the computer-readable storage medium stores program instructions, which are used in the methods described in the above embodiments.

[0232] This application also provides a program product including executable instructions stored in a readable storage medium. At least one processor of an electronic device can read the executable instructions from the readable storage medium, and the at least one processor executes the executable instructions to cause the electronic device to implement the sandbox processing methods provided in the various embodiments described above.

[0233] The term "multiple" in this document refers to two or more. The term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. Furthermore, the character " / " in this document generally indicates an "or" relationship between the preceding and following related objects; in formulas, " / " indicates a "division" relationship. Additionally, it should be understood that in the description of this application, words such as "first" and "second" are used only for descriptive purposes and should not be construed as indicating or implying relative importance or order.

[0234] It is understood that the various numerical designations used in the embodiments of this application are merely for descriptive convenience and are not intended to limit the scope of the embodiments of this application.

[0235] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A sandboxing method, characterized by, The method includes: In response to a cloning request for the source sandbox, a clone sandbox with physical memory pages to be allocated is generated on the target virtual machine, the target virtual machine having the same running state as the virtual machine containing the source sandbox. When a memory access request exists in the clone sandbox, the target physical memory page corresponding to the memory access request is obtained from the memory of the source sandbox; The clone sandbox's memory page table is updated based on the target physical memory page to complete the memory access request.

2. The method of claim 1, wherein, The step of retrieving the target physical memory page corresponding to the memory access request from the memory of the source sandbox includes: When the cloning request is an intra-node cloning request, the target physical memory page corresponding to the memory access request is obtained from the memory of the source sandbox based on the inter-process memory read system call; When the cloning request is a cross-node cloning request, the target physical memory page corresponding to the memory access request is obtained from the memory of the source sandbox based on remote direct memory access.

3. The method of claim 1, wherein, The step of retrieving the target physical memory page corresponding to the memory access request from the memory of the source sandbox includes: Based on the memory access request and the pre-configured page source mapping table between the source sandbox and the clone sandbox, determine the virtual memory page in the source sandbox corresponding to the memory access request. The page source mapping table includes the virtual memory page correspondence between the source sandbox and the clone sandbox. Based on the mapping relationship between the virtual memory pages, the virtual memory pages of the source sandbox, and physical memory, the target physical memory page corresponding to the memory access request is obtained.

4. The method of claim 3, wherein, The memory access request includes memory read requests and memory write requests. Updating the memory page table of the clone sandbox based on the target physical memory page to complete the memory access request includes: When the clone sandbox has the memory read requirement, the physical address of the first memory page in the memory page table of the clone sandbox is updated to the physical address of the target physical memory page, where the first memory page is the virtual memory page corresponding to the memory read requirement; When the clone sandbox has the memory write requirement, the target physical memory page is copied to a new physical address, and the physical address of the second memory page in the memory page table of the clone sandbox is updated to the new physical address. The second memory page is the virtual memory page corresponding to the memory write requirement.

5. The method of claim 2, wherein, When the cloning request is a cross-node cloning request, the method further includes: Based on the historical memory access records of the source sandbox, the virtual memory pages required for the first startup of the clone sandbox are predicted; Before the clone sandbox is started, the startup physical memory page corresponding to the virtual memory page required for the first startup is obtained from the memory of the source sandbox based on the remote direct memory access; The boot physical memory page is loaded into the memory of the clone sandbox.

6. The method according to claim 1, characterized in that, The method further includes: When there is a memory write requirement in the source sandbox, a memory page copy corresponding to the memory write requirement is generated; The memory page copy is used to execute the memory write requirements of the source sandbox.

7. The method according to claim 1, characterized in that, The method further includes: In response to the cloning request for the source sandbox, an online snapshot of the root file system of the source sandbox is performed to obtain a root file system index snapshot; Based on the root file system index snapshot, independent writable layers based on copy-on-write are created for the source sandbox and the clone sandbox respectively. The independent writable layers are used to record the data modifications made by the corresponding sandbox relative to the root file system.

8. The method according to claim 1, characterized in that, The method further includes: Maintain a difference log for the clone sandbox, the difference log including difference data generated by write operations of the clone sandbox relative to the source sandbox at the memory page and root file system levels; When a cloning request is initiated again based on the clone sandbox, a secondary clone sandbox is configured according to the difference data generated by the clone sandbox relative to the source sandbox in the difference log.

9. The method according to any one of claims 1-8, characterized in that, In response to a cloning request for the source sandbox, the process of configuring the target virtual machine with the cloning sandbox to be allocated physical memory pages, based on the runtime status information of the virtual machine where the source sandbox is deployed, includes: In response to the cloning request, the virtual central processing unit (vCPU) of the virtual machine containing the source sandbox is suspended. Obtain the running status information of the virtual machine where the source sandbox is located; Restore the vCPU of the virtual machine where the source sandbox is located, and configure the target virtual machine according to the running status information.

10. A sandbox processing device, characterized in that, The device includes: The processing module is used to generate a clone sandbox with physical memory pages to be allocated on the target virtual machine in response to a cloning request for the source sandbox, wherein the running state of the target virtual machine is the same as the running state of the virtual machine where the source sandbox is located. The acquisition module is used to acquire the target physical memory page corresponding to the memory access request from the memory of the source sandbox when there is a memory access request in the clone sandbox; The control module is used to update the memory page table of the clone sandbox based on the target physical memory page in order to complete the memory access request.

11. An electronic device, characterized in that, include: Processor and memory; The processor is communicatively connected to the memory; The memory stores computer instructions; The processor executes computer instructions stored in the memory to implement the method as described in any one of claims 1-9.

12. A computer program product, characterized in that, It includes a computer program or instructions that, when executed by a processor, implement the method of any one of claims 1-9.

Images