Virtual machine management method, device and storage medium

Abstract

Embodiments of the present application provide a virtual machine management method, a device and a storage medium. In the embodiments of the present application, graded sleep of virtual machines is used. When a virtual machine is sleeping, the virtual machine is firstly switched to a shallow sleep state. Because shallow sleep is lightweight sleep and the sleep process does not require persistent storage or the release of an underlying physical resource, the shallow sleep process uses few resources and concurrent shallow sleep of a plurality of virtual machines can be supported. Furthermore, on the basis of a sleep load condition of a scheduling domain where a virtual machine that is to sleep is located, a target virtual machine to be switched to a deep sleep state can be determined from virtual machines which are in a shallow sleep state in the scheduling domain, and the virtual machines are not blindly made to fall in deep sleep, thereby preventing sleep overload of the scheduling domain caused by the load of virtual machines switching from a shallow sleep state to a deep sleep state exceeding the load of the scheduling domain, mitigating resource conflicts caused by concurrent sleep of a plurality of virtual machines, and achieving the smooth transition of virtual machines from a running state to a deep sleep state.

Description

Virtual machine management method, device and storage medium

[0001] This application claims priority to the Chinese patent application filed with the China Patent Office on July 27, 2023, with application number 202310940283.7 and application name “Virtual Machine Management Method, Device and Storage Medium”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of cloud service technology, and in particular to a virtual machine management method, device, and storage medium. Background Art

[0003] Server virtualization is a key infrastructure-based technology in cloud computing. It virtualizes physical servers to enable the deployment of multiple virtual machines (VMs) on a single host computer.

[0004] Virtual machine hibernation allows you to permanently store the data of a running virtual machine and release the underlying physical resources. This allows you to use resources on demand while maintaining the services you need, improving resource utilization and reducing user costs.

[0005] Traditional solutions often use a Virtual Machine Manager (VMM) to manage virtual machine hibernation. In this approach, the VMM stops the virtual machine, persistently stores the virtual machine's data in a storage service, and then releases the underlying physical resources used by the virtual machine. However, this approach to virtual machine hibernation is not suitable for concurrent hibernation of multiple virtual machines.

[0006] Summary of the Invention

[0007] Multiple aspects of the present application provide a virtual machine management method, device, and storage medium to achieve a smooth transition between the running and dormant states of a virtual machine and alleviate resource conflicts caused by concurrent dormancy or awakening of multiple virtual machines.

[0008] The present invention provides a method for managing a virtual machine, including:

[0009] In response to a virtual machine sleep event, determining a virtual machine to be hibernated that is associated with the virtual machine sleep event;

[0010] Suspending the operation of the processor of the virtual machine to be dormant to switch the virtual machine to be dormant from a running state to a shallow dormant state;

[0011] Determining a target virtual machine to be switched to a deep sleep state from virtual machines in a shallow sleep state in the scheduling domain according to a sleep load condition of the scheduling domain where the virtual machine to be hibernated is located; the virtual machines in a shallow sleep state include the virtual machine to be hibernated;

[0012] Persistently storing the resource context of the target virtual machine;

[0013] The physical resources occupied by the target virtual machine are released to switch the target virtual machine from the shallow sleep state to the deep sleep state.

[0014] The present invention also provides a method for managing a virtual machine, including:

[0015] Obtaining a predicted wakeup time of a first virtual machine in a deep sleep state;

[0016] Before the predicted wake-up time arrives, reading the resource context of the first virtual machine from a persistent storage medium;

[0017] Creating the first virtual machine on a target host machine according to the resource context of the first virtual machine to convert the first virtual machine from a deep sleep state to a shallow sleep state;

[0018] In response to a wake-up event for the first virtual machine, a processor of the first virtual machine is started to transition the first virtual machine from the shallow sleep state to a running state.

[0019] The present invention also provides a method for managing a virtual machine, including:

[0020] Get the sleep load of the scheduling domain;

[0021] Determining, based on a sleep load condition of a scheduling domain, a target virtual machine to be switched to a second sleep level from virtual machines in the scheduling domain that are in a first sleep level; the first sleep level being any sleep level other than a highest sleep level among a plurality of sleep levels; and the second sleep level having a sleep depth higher than the first sleep level;

[0022] An operation of switching the target virtual machine from the first sleep level to the second sleep level is performed on the target virtual machine, so as to switch the target virtual machine from the first sleep level to the second sleep level.

[0023] The embodiment of the present application further provides a virtual machine management system, comprising: a control node and a computing cluster located in the same scheduling domain; the computing cluster comprises: at least one host machine; the host machine is deployed with a virtual machine;

[0024] The control node is used to execute the steps in the above-mentioned virtual machine management methods.

[0025] An embodiment of the present application further provides a computing device, comprising: a memory and a processor; wherein the memory is used to store a computer program;

[0026] The processor is coupled to the memory and is configured to execute the computer program to perform the steps in the above-mentioned virtual machine management methods.

[0027] An embodiment of the present application further provides a computer-readable storage medium storing computer instructions, which, when executed by one or more processors, causes the one or more processors to execute the steps in the above-mentioned virtual machine management methods.

[0028] In an embodiment of the present application, a hierarchical hibernation method for virtual machines is adopted, and when a virtual machine is in hibernation, the virtual machine is first switched to a shallow sleep state. Since shallow sleep is a lightweight sleep, the sleep process does not require persistent storage, nor does it require the release of underlying physical resources. Therefore, the shallow sleep process uses fewer resources and can support concurrent shallow sleep of multiple virtual machines. Furthermore, based on the sleep load of the scheduling domain where the virtual machine to be hibernated is located, the target virtual machine to be switched to a deep sleep state can be determined from the virtual machines in the shallow sleep state in the scheduling domain, rather than blindly performing deep sleep on the virtual machine. This can prevent the load of the virtual machine switched from shallow sleep to deep sleep from exceeding the load of the scheduling domain, thereby causing the scheduling domain to be overloaded, alleviate the resource conflict caused by the concurrent hibernation of multiple virtual machines, and achieve a smooth transition of the virtual machine from the running state to the deep sleep state. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0030] FIG1 is a schematic diagram of a process of dormancy and awakening of a virtual machine provided by a conventional embodiment;

[0031] FIG2 is a schematic diagram of the structure of a virtual machine management system provided in an embodiment of the present application;

[0032] FIG3 is a schematic diagram of the structure of a host machine or a host machine provided in an embodiment of the present application;

[0033] FIG4 is a schematic diagram of a virtual machine state switching process according to an embodiment of the present application;

[0034] FIG5 is a schematic diagram of a target virtual machine determination process and a deep sleep process according to an embodiment of the present application;

[0035] FIG6 is a schematic diagram of a state switching process of a virtual machine in a shallow sleep state provided by an embodiment of the present application;

[0036] FIG7 is a schematic diagram of a virtual machine management process according to an embodiment of the present application;

[0037] FIG8 is a schematic diagram of a virtual machine wake-up process according to an embodiment of the present application;

[0038] 9 and 10 are flowcharts of a virtual machine management method according to an embodiment of the present application;

[0039] FIG11a is a flow chart of another virtual machine management method provided in an embodiment of the present application;

[0040] FIG11 b is a schematic diagram of the structure of a computing device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0041] To make the purpose, technical solutions, and advantages of this application more clear, the technical solutions of this application will be clearly and completely described below in conjunction with the specific embodiments of this application and the corresponding drawings. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0042] In the virtual machine sleep management solution, virtual machine sleep management based on the Virtual Machine Manager (VMM) is a common method. In this traditional solution, the VMM stops the virtual machine and stores the virtual machine's data persistently in the storage service, and then releases the physical resources occupied by the virtual machine's underlying layer. During the virtual machine wake-up phase, the VMM reads the virtual machine's data from the storage service again and initializes the virtual machine, after which the virtual machine can be re-run. The VMM is independent of the client operating system (Guest Operating System, Guest OS), that is, the operating system of the virtual machine. Therefore, virtual machine sleep management based on the VMM is non-invasive to the virtual machine and can accelerate the startup of the virtual machine. However, in the scenario of large-scale deployment of virtual machines on the cloud, the solution for virtual machine sleep management based on the VMM has the following defects:

[0043] (1) For example, as shown in Figure 1, multiple virtual machines share a storage service. In a scenario where a single storage service is used and multiple virtual machines are hibernating or waking up at the same time, the simultaneous hibernation of multiple virtual machines will bring a burst of upload traffic to the storage service, causing the storage service to be instantly overloaded, extending the data storage time of a single virtual machine, and affecting the virtual machine hibernation experience. The simultaneous waking up of multiple virtual machines will bring a burst of download traffic to the storage service, causing the storage service to be instantly overloaded, extending the data download time of a single virtual machine, and affecting the virtual machine wake-up experience.

[0044] For example, in a cloud desktop scenario, multiple cloud desktops might be woken up simultaneously during work hours and hibernated simultaneously after get off work hours. When multiple cloud desktops are hibernated simultaneously, their data needs to be persisted to the storage service, resulting in a burst of upload traffic to the storage service. When multiple cloud desktops are woken up simultaneously, their data needs to be downloaded from the storage service, resulting in a burst of download traffic to the storage service.

[0045] (2) Multiple virtual machines are deployed on the same host, and multiple virtual machines may be put into sleep or wake up simultaneously on a single host. To avoid interference between virtual machines, the resources allocated to virtual machine sleep on the same host are limited. If multiple virtual machines on the same host are put into sleep or wake up simultaneously, it will cause the host to be overloaded, prolong the sleep or wake up time of a single virtual machine, and affect the sleep experience.

[0046] In order to solve the above technical problems, in some embodiments of the present application, a hierarchical hibernation method of virtual machines is adopted, and when the virtual machine is in hibernation, the virtual machine is first switched to a shallow sleep state. Since shallow sleep is a lightweight sleep, the sleep process does not require persistent storage, nor does it require the release of underlying physical resources. Therefore, the shallow sleep process uses fewer resources and can support concurrent shallow sleep of multiple virtual machines. Furthermore, based on the sleep load of the scheduling domain where the virtual machine to be hibernated is located, the target virtual machine to be switched to a deep sleep state can be determined from the virtual machines in the shallow sleep state in the scheduling domain, rather than blindly performing deep sleep on the virtual machine. This can prevent the load of the virtual machine converted from shallow sleep to deep sleep from exceeding the load of the scheduling domain, thereby causing the scheduling domain to be overloaded, alleviate the resource conflict caused by the concurrent hibernation of multiple virtual machines, and achieve a smooth transition of the virtual machine from the running state to the deep sleep state.

[0047] The following describes in detail the technical solutions provided by various embodiments of the present application in conjunction with the accompanying drawings.

[0048] It should be noted that the same reference numerals denote the same objects in the following drawings and embodiments, and therefore, once an object is defined in one drawing or embodiment, it does not need to be further discussed in the subsequent drawings and embodiments.

[0049] Figure 2 is a schematic diagram of the structure of a virtual machine management system provided in an embodiment of the present application. As shown in Figure 2, the virtual machine management system mainly includes: a control node 10 and a computing cluster 20 located in the same scheduling domain. Computing cluster 20 may include at least one host machine 201. Among them, host machine 201 is a host machine (Worker) in computing cluster 20.

[0050] The control node 10 refers to a computer device that can manage the host machine, respond to the service request of the user terminal 30, and provide computing services to the user by scheduling the host machine 201. It generally has the ability to undertake services and guarantee services. The control node 10 can be a single server device, or a cloud-based server array, or a virtual machine (VM), container, etc. running in a cloud-based server array. In addition, the control node 10 can also refer to other computing devices with corresponding service capabilities, such as terminal devices such as computers (running service programs), etc. In this embodiment, the control node 10 can be deployed in the cloud, such as in the central cloud of the edge cloud system.

[0051] The host machine 201 refers to a computer device that provides computing resources. For the specific implementation form of the host machine 201, please refer to the implementation form of the control node 10, which will not be repeated here. In this embodiment, as shown in Figure 3, in addition to providing computing resources, the host machine 201 can also provide other hardware resources and software resources. Among them, hardware resources may include: computing resources such as processors, storage resources such as memory and disks, and input / output (IO) resources, etc. Among them, the processor can be a central processing unit (CPU), a graphics processing unit (GPU) and / or a field programmable gate array (FPGA), etc. The host machine 201 can be deployed in a central cloud, or it can be implemented as an edge node in an edge cloud network, etc.

[0052] The resources provided by host machine 201 can be divided into internal resources and external resources of host machine 201. Internal resources can include CPU resources, memory resources, etc., while external resources can include disk storage resources, extended computing resources (such as GPUs and FPGAs), and network resources such as network cards. FIG3 illustrates the example of extended computing resources including GPUs, but this does not constitute a limitation.

[0053] The connection between the control node 10 and the host machine 201 may be wireless or wired. Optionally, the host machine 201 can be connected to the host machine 201 through a mobile network. Accordingly, the network standard of the mobile network can be 2G (such as Global System for Mobile Communications (GSM)), 2.5G (such as General Packet Radio Service (GPRS)), 3G (such as Wideband Code Division Multiple Access (WCDMA), Time Division-Synchronous Code Division Multiple Access (TD-SCDMA), Code Division Multiple Access 2000 (CDMA2000), Universal Mobile Telecommunications System (UTMS)), 4G (such as Long Term Evolution (LTE)), 4G+ (such as upgraded version of Long Term Evolution (LTE-Advanced, LTE-A)), 5G, World Interoperability for Microwave Access (WiMax), etc. Optionally, the host machine 201 may also be connected to the control node 10 via Bluetooth, WiFi, infrared, or the like.

[0054] In this embodiment, as shown in Figure 3 , a host machine 201 is deployed with a virtual machine (VM) 202. Virtual machine 202 can also be referred to as a guest of host machine 201. VM 202 has independent resources, such as computing resources like the CPU and GPU, storage resources like memory and disk, and network resources like network cards. As shown in Figure 3 , the CPU corresponding to the virtual machine can be referred to as the virtual CPU (vCPU), and the GPU corresponding to the virtual machine can be referred to as the virtual GPU (vGPU).

[0055] A scheduling domain refers to the area where the control node 10 performs resource scheduling. Host machines 201 within the same scheduling domain can share the same storage service, enabling data sharing. The control node 10 can perform resource scheduling for host machines 201 within the same scheduling domain. In the embodiments of the present application, the scope and size of a scheduling domain are not limited. For example, one or more computer rooms can constitute a scheduling domain. Multiple refers to two or more. For another example, cabinets distributed across different computer rooms can constitute a scheduling domain.

[0056] To ensure service security, servers with independent power and network resources are typically selected from separate computer rooms to form a dispatch domain. This way, if a server's network or power fails, other servers can take over, improving service reliability and security.

[0057] In this embodiment, VMM 203 refers to the logical node that manages virtual machines. It can be deployed on the host machine where the virtual machine resides, such as host machine 201, or on another host machine that communicates with the host machine. In embodiments where VMM 203 is deployed on a host machine, VMM 203 can run on the host machine's CPU. VMM 203 can perform tasks scheduling, load balancing, status monitoring, and sleep management for VMs 202 on the host machine.

[0058] In this embodiment, the virtual machine 202 may be managed by the control node 10. Specifically, the control node 10 may monitor virtual machine sleep events, and upon detecting a virtual machine sleep event, determine a virtual machine to be hibernated associated with the virtual machine sleep event in response to the virtual machine sleep event.

[0059] In the embodiments of the present application, the specific implementation of the virtual machine sleep event is not limited. In some embodiments, as shown in Figure 1, a user can initiate a virtual machine sleep request to the control node 10 via the user terminal 30 when the virtual machine is no longer in use, based on their own needs. The virtual machine sleep request may include: the user identifier and / or the identifier of the virtual machine requested to sleep. For example, in a cloud desktop scenario, a cloud desktop user can initiate a virtual machine sleep request after get off work hours.

[0060] Accordingly, the virtual machine sleep event can be realized as the control node 10 receiving a virtual machine sleep request. Accordingly, the control node 10 can respond to the virtual machine sleep event triggered by the virtual machine sleep request and determine the virtual machine to be sleep according to the virtual machine sleep request.

[0061] Specifically, the control node 10 can obtain the user identifier that initiated the virtual machine sleep request from the virtual machine sleep request; and based on the user identifier, determine that the virtual machine corresponding to the user identifier is the virtual machine to be sleep-delayed. Alternatively, the control node 10 can obtain the identifier of the virtual machine requesting sleep from the virtual machine sleep request; and determine that the virtual machine corresponding to the identifier of the virtual machine requesting sleep is the virtual machine to be sleep-delayed. Alternatively, the control node 10 can obtain the user identifier that initiated the virtual machine sleep request and the identifier of the virtual machine requesting sleep from the virtual machine sleep request; and determine that the virtual machine corresponding to the identifier of the virtual machine requesting sleep is the virtual machine to be sleep-delayed from the virtual machines corresponding to the user identifier.

[0062] The implementation of the virtual machine sleep event shown in the above embodiment is only for illustrative purposes and does not constitute a limitation.

[0063] In an embodiment of the present application, in order to reduce the probability of overload of storage services and host machines caused by concurrent hibernation of multiple virtual machines, a multi-level hibernation mode is introduced, which can achieve a smooth transition between the virtual machine running state and the hibernation state, and alleviate the resource conflicts caused by concurrent hibernation of multiple virtual machines.

[0064] In the embodiments of this application, multi-level hibernation is mainly divided into shallow hibernation and deep hibernation. Among them, deep hibernation is hibernation in the traditional sense. When a virtual machine enters deep hibernation, it not only pauses the operation of the virtual machine's processor, but also requires the virtual machine's resource context to be persistently stored, generally in the storage service. Afterwards, the underlying physical resources occupied by the virtual machine are released.

[0065] Among them, the resource context of a virtual machine refers to information that reflects the resource environment of the virtual machine, which may include: the resource quantity of various resources occupied by the virtual machine and the resource configuration data of various resources. For example, the context of memory resources may include: the size of memory space and the data stored in memory. The context of processor resources may include: the resource quantity of the processor (such as the number of CPU cores, etc.) and the operating status data of the processor. For another example, the peripheral resources of a virtual machine (storage resources, network resources and processor resources, etc.) may include: the resource quantity of peripheral resources and the configuration data of peripheral resources. The storage resources in the peripheral resources are generally persistent storage media, such as disks, hard disks, etc. The storage resources in the peripheral resources may include: the size of storage space and the data stored in the storage medium. The network resources in the peripheral resources may include: the bandwidth size and network mode, etc.

[0066] For a virtual machine in deep sleep state, during the wake-up phase, it is necessary to read the resource context of the virtual machine from the persistent storage medium; and based on the resource context, recreate the virtual machine and restart the virtual machine.

[0067] Compared with deep sleep, shallow sleep is a lightweight sleep and a transitional stage to deep sleep. Shallow sleep pauses the operation of the virtual machine's processor and does not persist the virtual machine's resource context or release the underlying physical resources occupied by the virtual machine. Correspondingly, the wake-up operation corresponding to shallow sleep directly resumes the operation of the virtual machine's processor. Shallow sleep is a lightweight sleep, and the sleep process does not require persistent storage or the release of underlying physical resources. Therefore, the shallow sleep process uses fewer resources and can support concurrent shallow sleep of multiple virtual machines.

[0068] Because shallow sleep does not require persistent storage of the virtual machine's resource context and does not require the release of underlying physical resources, the success rate of shallow sleep is higher than that of deep sleep. Similarly, when waking up a virtual machine from shallow sleep, there is no need to re-download the virtual machine's resource context or recreate the virtual machine. Therefore, the success rate of waking up a virtual machine from shallow sleep is higher than that of a virtual machine from deep sleep.

[0069] If certain physical resources are reused by different virtual machines, the physical resources occupied by the virtual machine in shallow sleep state can be released for use by other virtual machines. For example, for burst-type virtual machines, a credit mechanism can be used to share processor resources with other virtual machines. For burst-type virtual machines, the accumulation and consumption of credits can be stopped during the shallow sleep phase. The processor scheduler corresponding to the burst-type virtual machine in shallow sleep state can stop scheduling the virtual machine in shallow sleep state and let the resources of the virtual machine in shallow sleep state go to other virtual machines in running state. For another example, the virtual peripheral resources shared by multiple virtual machines include: storage resources, network bandwidth resources, and computing resources such as GPUs. Multiple virtual machines can share the peripheral resources of the same host machine. For the virtual peripheral resources of the virtual machine in sleep state, its physical peripheral resources can be stopped from being used, and the physical peripheral resources can be let go for use by other virtual machines in running state.

[0070] In an embodiment of the present application, state switching between virtual machines is supported. For example, as shown in Figure 4, the virtual machine can switch from the running state (S0) to the shallow sleep state (S2), or the virtual machine can be switched directly from the running state (S0) to the deep sleep state (S4). During the virtual machine wake-up phase, a virtual machine in the shallow sleep state (S2) can be directly switched to the running state (S0); a virtual machine in the deep sleep state (S4) can also be directly switched to the running state (S0). Of course, the embodiment of the present application also supports switching between shallow sleep state and deep sleep state. For example, a virtual machine in the shallow sleep state (S2) can be switched to the deep sleep state (S4); during the wake-up phase, a virtual machine in the deep sleep state (S4) can also be switched to the shallow sleep state (S2) first, etc. Among them, the state switching between the running state (S0) and the shallow sleep state (S4) does not require the virtual machine's resource context to be stored or downloaded, nor does it require the underlying resources to be released or reallocated. Therefore, the state switching between the running state (S0) and the shallow sleep state (S4) is lightweight.

[0071] Based on the above-mentioned deep sleep and shallow sleep, after the control node 10 determines the virtual machine to be dormant, it can suspend the operation of the processor of the virtual machine to be dormant, thereby switching the virtual machine to be dormant from the running state (S0) to the shallow sleep state. During this dormant process, there is no need to persist the resource context of the dormant virtual machine, nor is there any need to release the underlying physical resources occupied by the dormant virtual machine. In other words, this dormant process consumes fewer resources, can support concurrent shallow sleep of multiple virtual machines, and can also alleviate resource conflicts during the dormant process of multiple virtual machines.

[0072] Since the virtual machine's shallow sleep mode always occupies the underlying physical resources, in order to improve the utilization of physical resources, when the virtual machine is in sleep mode, the physical resources it occupies are allocated to other running virtual machines. In this embodiment, the virtual machine in shallow sleep mode can also be converted to deep sleep mode.

[0073] Since a virtual machine in shallow sleep state switches to deep sleep state, the resource context of the virtual machine needs to be persistently stored and the physical resources occupied by the virtual machine need to be released. This sleep process consumes a lot of resources. If a large number of virtual machines are in deep sleep concurrently, it may cause the host machine to overload and may also cause the storage service to overload, extending the sleep time of a single virtual machine.

[0074] To solve this problem, a deep sleep scheduler is introduced in the embodiment of the present application. The important goal of the deep sleep scheduler is to smooth out sleep bursts and make the appropriate virtual machines in shallow sleep state enter deep sleep state as soon as possible when system pressure allows.

[0075] Specifically, the control node 10 can monitor the sleep load of the scheduling domain where the virtual machine to be hibernated is located. The sleep load of the scheduling domain refers to the load size for performing sleep in the scheduling domain, which can reflect the resources consumed by performing sleep operations in the scheduling domain.

[0076] To prevent resource overload within the scheduling domain caused by a virtual machine transitioning from a shallow sleep state to a deep sleep state, the control node 10 may determine a target virtual machine to be switched to a deep sleep state from virtual machines in a shallow sleep state within the scheduling domain based on the sleep load of the virtual machine to be hibernated. The virtual machines in a shallow sleep state within the scheduling domain include the aforementioned virtual machines to be hibernated.

[0077] Among them, according to the sleep load situation of the scheduling domain where the virtual machine to be hibernated is located, the target virtual machine to be switched to the deep sleep state is determined from the virtual machines in the shallow sleep state in the scheduling domain, rather than blindly performing deep sleep on the virtual machine. This can prevent the load of the virtual machine converted from shallow sleep to deep sleep from exceeding the load of the scheduling domain, causing the scheduling domain sleep overload, alleviate the resource conflict caused by the concurrent hibernation of multiple virtual machines, and realize the smooth transition of the virtual machine from the running state to the deep sleep state.

[0078] In the embodiment of the present application, the specific implementation method of determining the target virtual machine to be switched from the shallow sleep state to the deep sleep state according to the sleep load of the scheduling domain where the virtual machine to be hibernated is located is not limited.

[0079] In some embodiments, the management and control node 10 may determine the target number of virtual machines transitioning to the deep sleep state supported by the current load of the scheduling domain according to the sleep load of the scheduling domain.

[0080] Specifically, as shown in FIG5 , the hibernation load of the scheduling domain may include: the write load of the storage service shared by the scheduling domain and the resource usage that can be used for virtual machine hibernation in the host machine where the virtual machine in shallow hibernation is deployed in the scheduling domain. For ease of description, the host machine where the virtual machine in shallow hibernation is deployed in the scheduling domain is defined as the first host machine. Accordingly, on the one hand, the management and control node 10 is used to control the write load of the storage service, and can mainly reduce the impact of deep hibernation on the storage service by limiting the total number of virtual machines that switch to deep hibernation in the scheduling domain per unit time. On the other hand, the hibernation load of a single host machine can be controlled, and the excessive consumption of resources of the physical server by deep hibernation can be limited by limiting the number of virtual machines that switch to deep hibernation on a single host machine.

[0081] Based on this, the control node 10 can determine a first number M of virtual machines that can be transitioned to deep sleep and supported by the current load of each first host machine in the scheduling domain based on the resource usage available for virtual machine hibernation in the first host machines in the scheduling domain. Specifically, the control node 10 can determine the number of virtual machines in deep sleep that can be supported by the current remaining resources available for virtual machine hibernation in the first host machines based on the resource usage available for virtual machine hibernation in the first host machines and the total amount of resources available for virtual machine hibernation in the first host machines, as the first number M.

[0082] Furthermore, the control node 10 may determine a second number N of virtual machines currently supported by the scheduling domain for transitioning to deep sleep based on the write load of the storage service shared by the scheduling domain. The target number may include: the first number M of virtual machines currently supported by the current load of each of the first host machines, and the second number N of virtual machines currently supported by the scheduling domain for deep sleep. The relationship between the first number M and the second number N may be determined based on the write load of the storage service shared by the scheduling domain and the resource usage available for virtual machine hibernation on the first host machines.

[0083] Accordingly, the control node 10 may select a target virtual machine from the virtual machines in a shallow sleep state in the scheduling domain based on a first number M of deep sleep virtual machines supported by the current load of each host machine in the scheduling domain and a second number N of deep sleep virtual machines currently supported by the scheduling domain. The total number of target virtual machines is less than or equal to N, and the number of target virtual machines on each host machine in the scheduling domain is less than or equal to the first number M corresponding to the host machine.

[0084] In other embodiments, if the sales of virtual machines in a scheduling domain reach a certain level, continuing to put the virtual machines into deep sleep, releasing the underlying physical resources occupied by the virtual machines, may result in insufficient resource inventory when waking up the virtual machines, resulting in wake-up failure. Based on this, embodiments of the present application propose a method of pre-occupying resources to keep some virtual machines in shallow sleep in shallow sleep, thereby preventing resource preemption and ensuring the success rate of waking up these virtual machines.

[0085] Specifically, the control node 10 can monitor the virtual machine inventory level of the scheduling domain. The virtual machine inventory level represents the idle resources available for deploying virtual machines within the scheduling domain and can be expressed as the ratio of the idle resources in the scheduling domain to the total resources in the scheduling domain. Alternatively, the virtual machine inventory level can be expressed as the ratio of the number of virtual machines available for deployment using the idle resources in the scheduling domain to the total number of virtual machines supported by the total resources in the scheduling domain.

[0086] If the virtual machine inventory level is detected to be less than or equal to a set threshold, a designated virtual machine may be marked among the virtual machines in the scheduling domain. The designated virtual machine is a virtual machine that will not transition to deep sleep after being in shallow sleep. The specific implementation method for determining the designated virtual machine is not limited in this embodiment of the present application.

[0087] In some embodiments, designated virtual machines can be set for certain users. Accordingly, user identifiers for setting designated virtual machines can be pre-stored. Accordingly, when the management and control node 10 detects that the virtual machine inventory level is less than or equal to a set threshold, it can identify the virtual machine corresponding to the pre-set user identifier from the virtual machines in the scheduling domain as the designated virtual machine and mark the designated virtual machine.

[0088] In other embodiments, a designated virtual machine may be set based on the delay sensitivity of the application running on the virtual machine. The delay sensitivity of an application mainly refers to the level of the application's requirement for response delay. Some applications with high real-time requirements have higher delay sensitivity, while some applications with low real-time requirements have lower delay sensitivity. Specifically, the management and control node 10 may determine the delay sensitivity of the application running on the virtual machine based on the service type of the application running on the virtual machine; and may determine the designated virtual machine based on the delay sensitivity of the application running on the virtual machine. For example, the virtual machine with the highest delay sensitivity of the running application may be marked as the designated virtual machine. Alternatively, the virtual machine with the delay sensitivity of the running application belonging to the set delay sensitivity level may be marked as the designated virtual machine, etc.

[0089] After being in a shallow sleep state, the designated virtual machine does not switch to a deep sleep state, which can prevent the resources of the designated virtual machine from being preempted. Accordingly, when the control node 10 determines the target virtual machine to be switched to a deep sleep state from the virtual machines in a shallow sleep state, it can pre-exclude the designated virtual machine from the virtual machines in a shallow sleep state. Specifically, the control node 10 can determine the virtual machine belonging to the designated virtual machine from the virtual machines in a shallow sleep state in the scheduling domain; and according to the sleep load situation of the scheduling domain, determine the target virtual machine to be switched to a deep sleep from the virtual machines in a shallow sleep state in the scheduling domain other than the above-mentioned designated virtual machines. Regarding the specific implementation method of determining the target virtual machine to be switched to a deep sleep from the virtual machines in a shallow sleep state in the scheduling domain other than the above-mentioned designated virtual machines according to the sleep load situation of the scheduling domain, please refer to the above-mentioned content of determining the target virtual machine to be switched to a deep sleep from the virtual machines in a shallow sleep state in the scheduling domain according to the sleep load situation of the scheduling domain, which will not be repeated here.

[0090] When a virtual machine hibernation event occurs for a virtual machine, the virtual machine will be switched to a shallow sleep state. The virtual machine can remain in the shallow sleep state for a period of time. If a wake-up event occurs for the virtual machine during the shallow sleep state, the virtual machine can be switched from the shallow sleep state to the running state, and the operation of the virtual machine's processor can be restored, thereby switching the virtual machine from the shallow sleep state to the running state, and the virtual machine is lightly awakened from the shallow sleep state. Therefore, frequent hibernation and wake-up of a single virtual machine can be filtered out at a lower resource cost. If the virtual machine remains in the shallow sleep state for a period of time and no wake-up event occurs for the virtual machine, the virtual machine enters the deep sleep preparation stage. Among them, the virtual machine that enters the deep sleep preparation stage can execute the operation of switching from shallow sleep to deep sleep.

[0091] In the embodiments of the present application, the specific implementation of the virtual machine wake-up event is not limited. In some embodiments, a user can initiate a virtual machine wake-up request to the management and control node 10 via the user terminal 30 when they need to use the virtual machine based on their own needs. The virtual machine wake-up request may include: the user identifier and / or the identifier of the virtual machine requested to be woken up. For example, in a cloud desktop scenario, a cloud desktop user may initiate a virtual machine wake-up request during working hours.

[0092] Accordingly, the virtual machine wake-up event may be realized as the control node 10 receiving a virtual machine wake-up request. Accordingly, the control node 10 may determine the virtual machine to be woken up according to the virtual machine wake-up request in response to the virtual machine wake-up event triggered by the virtual machine wake-up request.

[0093] Specifically, the control node 10 may obtain the user identifier that initiated the virtual machine wake-up request from the virtual machine wake-up request, and based on the user identifier, determine that the virtual machine corresponding to the user identifier is the virtual machine to be awakened. Alternatively, the control node 10 may obtain the identifier of the virtual machine requested to be awakened from the virtual machine wake-up request, and determine that the virtual machine corresponding to the identifier of the virtual machine requested to be awakened is the virtual machine to be awakened. Alternatively, the control node 10 may obtain the user identifier that initiated the virtual machine wake-up request and the identifier of the virtual machine requested to be awakened from the virtual machine wake-up request, and determine that the virtual machine corresponding to the identifier of the virtual machine requested to be awakened is the virtual machine to be awakened from the virtual machines corresponding to the user identifier.

[0094] In other embodiments, the control node 10 may predict the virtual machine's wakeup time based on historical user wakeup behavior data for the virtual machine. When the predicted virtual machine wakeup time arrives, the control node 10 may send a virtual machine wakeup prompt to the user terminal 30. The historical user wakeup behavior data for the virtual machine includes, for example, historical times when users requested to wake up the virtual machine. The control node 10 may perform statistical analysis on the historical times when users requested to wake up the virtual machine to obtain information on the time patterns of user requests to wake up the virtual machine. Subsequently, based on this information, the control node 10 may predict the virtual machine's wakeup time, etc.

[0095] Accordingly, the user can continue to hibernate the virtual machine or wake it up according to their needs. If the user chooses to wake up the virtual machine, they can confirm the virtual machine wake-up prompt information. In response to the confirmation operation for the virtual machine wake-up prompt information, the user terminal 30 can send a virtual machine wake-up confirmation message to the control node 10. Upon receiving the virtual machine wake-up confirmation message, the control node 10 determines that a virtual machine wake-up event has been detected.

[0096] Accordingly, the virtual machine wakeup event can be realized as receiving virtual machine wakeup confirmation information. In response to the virtual machine wakeup event triggered by receiving the virtual machine wakeup confirmation information, the management node 10 can determine the virtual machine confirmed to be woken up by the virtual machine wakeup confirmation information as the virtual machine to be woken up.

[0097] The implementation forms of the wake-up events of the virtual machines shown in the above embodiments are merely exemplary and do not constitute limitations.

[0098] Among them, the period of time that the above-mentioned virtual machine maintains a shallow sleep state is defined as the expiration time, that is, the timing starts from the time when the virtual machine enters the shallow sleep state. If the timing time reaches the expiration time and no wake-up event for the virtual machine is detected, the virtual machine enters the deep sleep preparation stage. For example, the example of switching from a shallow sleep state (S2) to a deep sleep state (S4) in Figure 6. If a wake-up event for the virtual machine is detected before the timing time reaches the expiration time, the operation of the processor of the virtual machine is restored, thereby switching the virtual machine from the shallow sleep state to the running state, and the virtual machine is lightly awakened from the shallow sleep state. For example, the virtual machine in Figure 6 switches from a shallow sleep state (S2) to a running state (S0).

[0099] The expiration period can be a pre-set duration, determined based on the historical wake-up behavior of the virtual machine user. If the virtual machine user frequently sleeps and wakes up the virtual machine within a certain historical time period (generally on the order of hours), the expiration period can be the minimum, lowest, or average time interval between two consecutive wake-ups of the virtual machine by the user during that historical time period. The specific value is determined by the user's wake-up interval for the virtual machine, generally on the order of minutes, such as 3 minutes, 5 minutes, or 10 minutes.

[0100] Based on the expiration time of each virtual machine, the control node 10 can monitor any virtual machine A in a shallow sleep state for a wakeup event. Starting from the moment virtual machine A enters the shallow sleep state, if no wakeup event is detected after the timer reaches the expiration time corresponding to virtual machine A, the control node 10 determines that virtual machine A has entered the deep sleep preparation phase. Using the same method, any virtual machine in a shallow sleep state can be monitored for wakeup events and determined to be in the deep sleep preparation phase.

[0101] The expiration periods corresponding to each virtual machine may be the same or different. In some embodiments, to prevent virtual machines that enter shallow sleep from expiring at the same time, i.e., simultaneously entering the deep sleep preparation phase, which would cause a sudden load surge in the virtual machines switching from shallow sleep to deep sleep, a random expiration period variable (i.e., a time variable) may be introduced for each virtual machine based on the set expiration period. This can reduce the probability of multiple virtual machines expiring at the same time. The expiration period variable refers to a time increment, which is the length of time added to the set expiration period.

[0102] Specifically, for any virtual machine A, an expiration duration variable can be randomly generated; and the expiration duration variable corresponding to virtual machine A is added to the set expiration duration to serve as the expiration duration corresponding to virtual machine A. The set expiration duration is a pre-set time length, and its determination method can be found in the above-mentioned relevant content regarding the expiration duration. Because the expiration duration variable is a randomly generated time variable, even if multiple virtual machines enter a shallow sleep state at the same time, the introduction of the random time variable will cause the expiration times of the virtual machines entering the shallow sleep state to be different, thereby reducing the probability of multiple virtual machines expiring at the same time, and further reducing the concurrent probability of multiple virtual machines switching from a shallow sleep state to a deep sleep state.

[0103] In other embodiments, in order to avoid the simultaneous expiration of virtual machines that enter shallow sleep, that is, to avoid the simultaneous entry of virtual machines into deep sleep preparation phase, which results in a load burst of virtual machines that switch from shallow sleep to deep sleep, different expiration periods can be set for each virtual machine. For example, different expiration periods can be set based on the response delay requirements of the tasks executed by the virtual machine. The more sensitive the virtual machine is to response delay, the shorter the expiration period. Alternatively, it can be flexibly set based on the historical wake-up behavior data of the users corresponding to each virtual machine. Due to the different usage habits of different users, the wake-up time intervals in the historical wake-up behavior data will also be different, and the expiration periods of the obtained virtual machines will also be different. In either case, different expiration periods can be set for virtual machines. Even if multiple virtual machines enter shallow sleep at the same time, the expiration times of the virtual machines are different, thereby reducing the probability of multiple virtual machines expiring at the same time, and further reducing the concurrent probability of multiple virtual machines switching from shallow sleep to deep sleep.

[0104] For virtual machines in the deep sleep preparation stage, an operation of switching from a shallow sleep state to a deep sleep state can be executed. Therefore, when the control node 10 determines the target virtual machine to be switched to a deep sleep state from the virtual machines in the shallow sleep state in the scheduling domain based on the sleep load of the scheduling domain where the virtual machine to be hibernated is located, it can determine the virtual machine in the deep sleep preparation stage from the virtual machines in the shallow sleep state in the scheduling domain; further, it can determine the target virtual machine to be switched to a deep sleep state from the virtual machines in the deep sleep preparation stage based on the sleep load of the scheduling domain.

[0105] Specifically, with reference to Figures 5 and 7 , the management and control node 10 includes a deep sleep scheduler and a deep sleep controller. The deep sleep scheduler is configured to perform the aforementioned operation of determining a target virtual machine to be switched to a deep sleep state from virtual machines in the deep sleep preparation phase based on the sleep load of the scheduling domain. After the deep sleep scheduler determines the target virtual machine, it transmits the identifier of the target virtual machine to the deep sleep controller. The deep sleep controller can control the target virtual machine to switch from a shallow sleep state to a deep sleep state.

[0106] Among them, regarding the specific implementation method of determining the target virtual machine to be switched to the deep sleep state from the virtual machines in the deep sleep preparation stage according to the sleep load situation of the scheduling domain, please refer to the above-mentioned content of determining the target virtual machine to be switched to the deep sleep state from the virtual machines in the shallow sleep state in the scheduling domain according to the sleep load situation of the scheduling domain, which will not be repeated here.

[0107] After determining the target virtual machine to be switched to the deep sleep state, the control node 10 can perform an operation of switching the target virtual machine from the shallow sleep state to the deep sleep state. Specifically, the deep sleep controller in the control node 10 can control the target virtual machine to switch from the shallow sleep state to the deep sleep state.

[0108] Specifically, the control node 10 may persistently store the resource context of the target virtual machine. In some embodiments, the control node 10 may persistently store the resource context of the target virtual machine in a storage service. Of course, the control node 10 may also persistently store the resource context of the target virtual machine in a local persistent storage medium, etc.

[0109] Furthermore, the management and control node 10 may release the physical resources occupied by the target virtual machine, thereby switching the target virtual machine from the shallow sleep state to the deep sleep state.

[0110] Specifically, referring to Figures 5 and 7 , the control node 10 can control the VMM 203 in the target host machine 201 where the target virtual machine resides to persistently store the target virtual machine's resource context. For example, the VMM 203 can persistently store the target virtual machine's resource context in a storage service. Furthermore, the control node 10 can control the VMM 203 to release the physical resources occupied by the target virtual machine 202. The VMM 203 can release the physical resources occupied by the target virtual machine 202.

[0111] In some embodiments, referring to Figures 5 and 7 , after determining the target virtual machine, the control node 10 may issue a deep sleep instruction to the target host machine 201 where the target virtual machine resides. The deep sleep instruction may include the identifier of the target virtual machine. In response to the deep sleep instruction, the VMM 203 in the target host machine 201 may obtain the resource context of the target virtual machine based on the identifier of the target virtual machine and persistently store the resource context of the target virtual machine. Furthermore, the VMM 203 may release the physical resources occupied by the target virtual machine 202.

[0112] In an embodiment of the present application, a hierarchical hibernation method for virtual machines is adopted, and when a virtual machine is in hibernation, the virtual machine is first switched to a shallow sleep state. Since shallow sleep is a lightweight sleep, the sleep process does not require persistent storage, nor does it require the release of underlying physical resources. Therefore, the shallow sleep process uses fewer resources and can support concurrent shallow sleep of multiple virtual machines. Furthermore, based on the sleep load of the scheduling domain where the virtual machine to be hibernated is located, the target virtual machine to be switched to a deep sleep state can be determined from the virtual machines in the shallow sleep state in the scheduling domain, rather than blindly performing deep sleep on the virtual machine. This can prevent the load of the virtual machine switched from shallow sleep to deep sleep from exceeding the load of the scheduling domain, thereby causing the scheduling domain to be overloaded, alleviate the resource conflict caused by the concurrent hibernation of multiple virtual machines, and achieve a smooth transition of the virtual machine from the running state to the deep sleep state.

[0113] The above embodiment shows the process of virtual machine hibernation. For a virtual machine in a dormant state, virtual machine wake-up management can also be performed when a wake-up event occurs for the virtual machine. The virtual machine wake-up process provided by the embodiment of the present application is exemplarily described below.

[0114] For a virtual machine in a shallow sleep state, if a wake-up event for the virtual machine in the shallow sleep state is detected, the operation of the processor of the virtual machine can be directly restored, thereby switching the virtual machine from the shallow sleep state to the running state, thereby waking up the virtual machine.

[0115] In the embodiment of the present application, regarding the specific implementation form of the wake-up event of the virtual machine, please refer to the relevant content of the above embodiment, which will not be repeated here.

[0116] For VMs in deep sleep, waking them requires reading the VM's resource context from persistent storage and recreating and starting the VM based on the context. The transition from deep sleep to a running state consumes significant resources. Concurrently waking up multiple VMs can lead to resource conflicts.

[0117] To mitigate resource conflicts caused by concurrently waking up multiple virtual machines, some embodiments of the present application enable early waking up of virtual machines in deep sleep. The waking up process for virtual machines in deep sleep is the same. The following uses the first virtual machine in deep sleep as an example to illustrate the waking up process for a virtual machine in deep sleep. The first virtual machine is any virtual machine in deep sleep.

[0118] Specifically, as shown in Figure 8 , the management and control node 10 may obtain the predicted wakeup time of the first virtual machine. In the embodiment of the present application, the specific implementation method of obtaining the predicted wakeup time of the first virtual machine is not limited.

[0119] In some embodiments, the management node 10 may predict the wakeup time of the virtual machine in deep sleep state (i.e., predicted wakeup time) in advance and store the predicted wakeup time. Subsequently, the predicted wakeup time of the first virtual machine may be read from the pre-stored predicted wakeup time of the virtual machine.

[0120] Specifically, the control node 10 may obtain historical wake-up behavior data of a target user for a virtual machine. The target user is the user of the first virtual machine. Furthermore, the control node 10 may predict the wake-up time of the first virtual machine based on the historical wake-up behavior data of the target user for the virtual machine, and use this as the predicted wake-up time of the first virtual machine.

[0121] In the embodiment of the present application, the specific implementation method of the control node 10 predicting the wake-up time of the first virtual machine based on the historical wake-up behavior data of the target user on the virtual machine is not limited.

[0122] In some embodiments, the management and control node 10 may obtain the historical times at which the target user requested to wake up the virtual machine from the target user's historical wake-up behavior data for the virtual machine. Furthermore, the management and control node 10 may perform statistical analysis on the historical times at which the target user requested to wake up the virtual machine to obtain information on the temporal patterns of the user's requests to wake up the virtual machine. Subsequently, the management and control node 10 may predict the wake-up time of the first virtual machine based on the temporal pattern information of the target user's requests to wake up the virtual machine. For example, the temporal pattern information of the target user's requests to wake up the virtual machine may include: if the target user requests to wake up the virtual machine during a specific time period within a set time period, the wake-up time of the first virtual machine may be predicted to be the earliest time within the specific time period corresponding to each set time period. For example, assuming that the target user wakes up the virtual machine between 8:30 AM and 9:00 AM every day, the predicted wake-up time of the first virtual machine may be 8:30 AM.

[0123] In other embodiments, in order to improve the accuracy of predicting the wake-up time, a neural network model may be introduced. In the embodiments of the present application, the specific implementation form of the neural network model is not limited. Optionally, the neural network model may be a convolutional neural network (CNN), a deep learning neural network (DNN), a recurrent neural network (RNN), or a convolutional neural tensor network (CNTN), etc., but is not limited thereto.

[0124] As shown in Figures 7 and 8, a neural network model is used to predict the wake-up time of a virtual machine, and is defined as a wake-up time prediction model. The wake-up time prediction model is obtained by training an initial neural network model using historical wake-up behavior data of a user (defined as a first user) on the virtual machine as training samples. The first user can be one or more users. The first user may or may not include the target user described above. The input of the wake-up time prediction model can be: historical wake-up behavior data of the user to which the virtual machine belongs, and the output is: the predicted wake-up time of the virtual machine.

[0125] Based on the wake-up time prediction model, the target user's historical wake-up behavior data for the virtual machine can be input into the wake-up time prediction model. Furthermore, in the wake-up time prediction model, the wake-up time of the first virtual machine can be predicted based on the target user's historical wake-up behavior data for the virtual machine, as the predicted wake-up time of the first virtual machine (corresponding to the predicted wake-up event in FIG8 ). The historical wake-up behavior data used to predict the wake-up time of the first virtual machine can be historical wake-up behavior data from a recent period of time (e.g., the last week, the last two weeks, the last month, or the last several months).

[0126] After determining the predicted wakeup time for the first virtual machine, the management node 10 may switch the first virtual machine from a deep sleep state to a shallow sleep state before the predicted wakeup time arrives, thereby waking up the first virtual machine in advance. With reference to Figures 7 and 8 , the operation of switching the first virtual machine from a deep sleep state to a shallow sleep state may be performed by a wakeup controller in the management node 10.

[0127] Specifically, the management and control node 10 may read the resource context of the first virtual machine from the persistent storage medium before the predicted wake-up time arrives.

[0128] In some embodiments, the management and control node 10 may read the resource context of the first virtual machine from the persistent storage medium at a time point that is a set time period before the predicted wake-up time. In the embodiments of the present application, the specific value of the set time period is not limited. The set time period may be in minutes, such as 10 minutes, 30 minutes, 40 minutes, or 1 hour, but is not limited thereto.

[0129] Furthermore, the management and control node 10 may create the first virtual machine on the target host machine according to the resource context of the first virtual machine, thereby converting the first virtual machine from the deep sleep state to the shallow sleep state (corresponding to “early wake-up” in FIG8 ).

[0130] Specifically, based on the resource requirements in the resource context of the first virtual machine, a target host machine with free resources that meet the resource requirements can be selected from the computing cluster; and based on the resource requirements, target resources are allocated to the first virtual machine on the target host machine. The target resources may include all resources required by the virtual machine, including storage resources (such as memory and persistent storage resources), processor resources (such as CPU, GPU, etc.), and network resources.

[0131] Afterwards, a first virtual machine may be created using the target resources; and the first virtual machine may be initialized according to the resource configuration data in the resource context of the first virtual machine to obtain the first virtual machine.

[0132] Specifically, the memory storage data in the resource context of the first virtual machine can be written into the memory included in the target resource; the data stored in the persistent storage resource in the resource context of the first virtual machine can also be written into the persistent storage space included in the target resource; and the network resource information can be configured according to the network configuration data included in the resource context of the first virtual machine, thereby realizing the initialization of the first virtual machine.

[0133] Furthermore, the management and control node 10 may monitor a wake-up event for the first virtual machine, and when a wake-up event for the first virtual machine is detected, the management and control node 10 may start the processor of the first virtual machine in response to the wake-up event for the first virtual machine, thereby converting the first virtual machine from a shallow sleep state to a running state (corresponding to "wake-up" in Figure 8).

[0134] In this embodiment, by predicting the wake-up time of a virtual machine in a deep sleep state, the virtual machine is woken up in advance before the predicted wake-up time arrives, so that the virtual machine is transferred from the deep sleep state to the shallow sleep state, and resources are occupied in advance. This can enable the virtual machine to avoid the wake-up peak, and alleviate the resource pressure brought by the wake-up peak to the storage service and the host machine, and alleviate the resource conflict caused by the wake-up peak.

[0135] To prevent incorrect wake-up time predictions and pre-wake up virtual machines that do not require wake-up, in some embodiments, the management and control node 10 may monitor wake-up events for a first virtual machine. If no wake-up event for the first virtual machine is detected within a set period of time after the predicted wake-up time arrives, the first virtual machine may be re-transferred from a shallow sleep state to a deep sleep state. Specifically, the resource context of the first virtual machine may be persistently stored, and the physical resources occupied by the first virtual machine may be re-configured to re-transfer the first virtual machine from a shallow sleep state to a deep sleep state.

[0136] If the deep sleep virtual machine has not been pre-awakened to the light sleep state, if a wake-up event for the virtual machine is detected, the virtual machine can be directly converted from the deep sleep state to the running state (corresponding to the direct wake-up in Figure 8).

[0137] Specifically, if a wakeup event for a first virtual machine in deep sleep is detected, the resource context of the first virtual machine can be read from a persistent storage medium in response to the wakeup event. Furthermore, based on the resource context of the first virtual machine, the first virtual machine can be created on the target host machine and the processor of the first virtual machine can be started, thereby transitioning the first virtual machine from a deep sleep state to a running state, thereby waking up the virtual machine (corresponding to the direct wakeup in FIG8 ).

[0138] In addition to the above-mentioned virtual machine management system embodiment, the embodiment of the present application also provides a virtual machine management method. The virtual machine management method provided by the embodiment of the present application is exemplarily described below.

[0139] FIG9 is a flow chart of a virtual machine management method provided by an embodiment of the present application. As shown in FIG9 , the method mainly includes:

[0140] 901. In response to a virtual machine hibernation event, determine a virtual machine to be hibernated that is associated with the virtual machine hibernation event.

[0141] 902. Suspend the operation of the processor of the virtual machine to be hibernated to switch the virtual machine to be hibernated from a running state to a shallow sleep state.

[0142] 903. Determine a target virtual machine to be switched to a deep sleep state from virtual machines in a shallow sleep state in the scheduling domain according to the sleep load of the virtual machine to be hibernated. The virtual machines in a shallow sleep state include the virtual machine to be hibernated.

[0143] 904. Persistently store the resource context of the target virtual machine.

[0144] 905 : Release the physical resources occupied by the target virtual machine to switch the target virtual machine from the shallow sleep state to the deep sleep state.

[0145] In this embodiment, a virtual machine sleep event is monitored, and if a virtual machine sleep event is detected, a virtual machine to be hibernated associated with the virtual machine sleep event can be determined in response to the virtual machine sleep event in step 901. Regarding the specific implementation of the virtual machine sleep event and the specific implementation method of determining the virtual machine to be hibernated associated with the virtual machine sleep event, please refer to the relevant content of the above embodiment and will not be repeated here.

[0146] In an embodiment of the present application, in order to reduce the probability of overload of storage services and host machines caused by concurrent hibernation of multiple virtual machines, a multi-level hibernation mode is introduced, which can achieve a smooth transition between the virtual machine running state and the hibernation state, and alleviate the resource conflicts caused by concurrent hibernation of multiple virtual machines.

[0147] In the embodiment of the present application, the multi-level sleep is mainly divided into: shallow sleep and deep sleep. For the description of shallow sleep and deep sleep, please refer to the relevant content of the above embodiment, which will not be repeated here.

[0148] Because shallow sleep does not require persistent storage of the virtual machine's resource context and does not require the release of underlying physical resources, the success rate of shallow sleep is higher than that of deep sleep. Similarly, when waking up a virtual machine from shallow sleep, there is no need to re-download the virtual machine's resource context or recreate the virtual machine. Therefore, the success rate of waking up a virtual machine from shallow sleep is higher than that of a virtual machine from deep sleep.

[0149] Based on the above-described deep sleep and shallow sleep, after the virtual machine to be hibernated is determined, in step 902, the operation of the processor of the virtual machine to be hibernated can be suspended, thereby switching the virtual machine to be hibernated from the running state (S0) to the shallow sleep state. During this hibernation process, there is no need to persist the resource context of the virtual machine to be hibernated, nor is there any need to release the underlying physical resources occupied by the virtual machine to be hibernated. In other words, this hibernation process consumes fewer resources, can support concurrent shallow sleep of multiple virtual machines, and can also alleviate resource conflicts during the hibernation of multiple virtual machines.

[0150] Since the virtual machine's shallow sleep mode always occupies the underlying physical resources, in order to improve the utilization of physical resources, when the virtual machine is in sleep mode, the physical resources it occupies are allocated to other running virtual machines. In this embodiment, the virtual machine in shallow sleep mode can also be converted to deep sleep mode.

[0151] Since a virtual machine in shallow sleep state switches to deep sleep state, the resource context of the virtual machine needs to be persistently stored and the physical resources occupied by the virtual machine need to be released. This sleep process consumes a lot of resources. If a large number of virtual machines are in deep sleep concurrently, it may cause the host machine to overload and may also cause the storage service to overload, extending the sleep time of a single virtual machine.

[0152] To solve this problem, a deep sleep scheduler is introduced in the embodiment of the present application. The important goal of the deep sleep scheduler is to smooth out sleep bursts and make the appropriate virtual machines in shallow sleep state enter deep sleep state as soon as possible when system pressure allows.

[0153] Specifically, the sleep load of the scheduling domain where the virtual machine to be hibernated resides can be monitored. To prevent resource overload within the scheduling domain caused by a virtual machine transitioning from a shallow sleep state to a deep sleep state, in step 903, a target virtual machine to be switched to a deep sleep state can be determined from virtual machines in a shallow sleep state within the scheduling domain based on the sleep load of the scheduling domain where the virtual machine to be hibernated resides. The virtual machines in a shallow sleep state within the scheduling domain include the aforementioned virtual machines to be hibernated.

[0154] Among them, according to the sleep load situation of the scheduling domain where the virtual machine to be hibernated is located, the target virtual machine to be switched to the deep sleep state is determined from the virtual machines in the shallow sleep state in the scheduling domain, rather than blindly performing deep sleep on the virtual machine. This can prevent the load of the virtual machine converted from shallow sleep to deep sleep from exceeding the load of the scheduling domain, causing the scheduling domain sleep overload, alleviate the resource conflict caused by the concurrent hibernation of multiple virtual machines, and realize the smooth transition of the virtual machine from the running state to the deep sleep state.

[0155] In the embodiment of the present application, the specific implementation method of determining the target virtual machine to be switched from the shallow sleep state to the deep sleep state according to the sleep load of the scheduling domain where the virtual machine to be hibernated is located is not limited.

[0156] In some embodiments, the target number of virtual machines transitioning to the deep sleep state supported by the current load of the scheduling domain may be determined according to the sleep load of the scheduling domain.

[0157] Specifically, the hibernation load situation of the scheduling domain may include: the write load situation of the storage service shared by the scheduling domain and the resource usage situation of the first host machine in the scheduling domain that can be used for virtual machine hibernation. Among them, the first host machine is the host machine in the scheduling domain where the above-mentioned virtual machine in shallow hibernation is deployed. Based on this, the first number M of virtual machines that can be switched to deep hibernation supported by the current load of each first host machine in the scheduling domain can be determined according to the resource usage situation of the first host machine in the scheduling domain that can be used for virtual machine hibernation. Specifically, the number of deep hibernation virtual machines that can be supported by the current remaining resources available for hibernation in the host machine can be determined as the first number M according to the resource usage situation of the first host machine that can be used for virtual machine hibernation and the total amount of resources available for virtual machine hibernation in the first host machine.

[0158] Furthermore, a second number N of virtual machines transitioning to deep sleep currently supported by the scheduling domain can be determined based on the write load of the storage service shared by the scheduling domain. The target number may include: the first number M of virtual machines in deep sleep supported by the current load of each first host machine in the scheduling domain, and the second number N of virtual machines in deep sleep currently supported by the scheduling domain.

[0159] Accordingly, a target virtual machine can be selected from the virtual machines in a shallow sleep state in the scheduling domain based on a first number M of deep sleep virtual machines supported by the current load of each first host machine in the scheduling domain and a second number N of deep sleep virtual machines currently supported by the scheduling domain. The total number of target virtual machines is less than or equal to N, and the number of target virtual machines on each first host machine in the scheduling domain is less than or equal to the first number M corresponding to the first host machine.

[0160] In other embodiments, if the sales of virtual machines in a scheduling domain reach a certain level, continuing to put the virtual machines into deep sleep, releasing the underlying physical resources occupied by the virtual machines, may result in insufficient resource inventory when waking up the virtual machines, resulting in wake-up failure. Based on this, embodiments of the present application propose a method of pre-occupying resources to keep some virtual machines in shallow sleep in shallow sleep, thereby preventing resource preemption and ensuring the success rate of waking up these virtual machines.

[0161] Specifically, the virtual machine inventory level of the scheduling domain can be monitored. The description of the virtual machine inventory level can refer to the relevant content of the above embodiment and will not be repeated here.

[0162] If the virtual machine inventory level is detected to be less than or equal to a set threshold, a designated virtual machine may be marked among the virtual machines in the scheduling domain. The designated virtual machine is one that will not transition to deep sleep after entering shallow sleep. For details on how to determine the designated virtual machine, please refer to the relevant content of the above embodiment and will not be repeated here.

[0163] After being in a shallow sleep state, the designated virtual machine does not switch to a deep sleep state, which can avoid the resources of the designated virtual machine from being preempted. Accordingly, when determining the target virtual machine to be switched to a deep sleep state from the virtual machines in a shallow sleep state, the designated virtual machine in the virtual machines in a shallow sleep state can be excluded in advance. Specifically, the virtual machines belonging to the designated virtual machine can be determined from the virtual machines in a shallow sleep state in the scheduling domain; and based on the sleep load situation of the scheduling domain, the target virtual machine to be switched to a deep sleep state can be determined from the virtual machines in a shallow sleep state in the scheduling domain other than the above-mentioned designated virtual machines. Regarding the specific implementation method of determining the target virtual machine to be switched to a deep sleep state from the virtual machines in a shallow sleep state in the scheduling domain other than the above-mentioned designated virtual machines in a shallow sleep state based on the sleep load situation of the scheduling domain, please refer to the above-mentioned content of determining the target virtual machine to be switched to a deep sleep state from the virtual machines in a shallow sleep state in the scheduling domain based on the sleep load situation of the scheduling domain, which will not be repeated here.

[0164] When a virtual machine hibernation event occurs for a virtual machine, the virtual machine will be switched to a shallow sleep state. The virtual machine can remain in the shallow sleep state for a period of time. If a wake-up event occurs for the virtual machine during the shallow sleep state, the virtual machine can be switched from the shallow sleep state to the running state, and the operation of the virtual machine's processor can be restored, thereby switching the virtual machine from the shallow sleep state to the running state, and the virtual machine is lightly awakened from the shallow sleep state. Therefore, frequent hibernation and wake-up of a single virtual machine can be filtered out at a lower resource cost. If the virtual machine remains in the shallow sleep state for a period of time and no wake-up event occurs for the virtual machine, the virtual machine enters the deep sleep preparation stage. Among them, the virtual machine that enters the deep sleep preparation stage can execute the operation of switching from shallow sleep to deep sleep.

[0165] Among them, the period of time that the above-mentioned virtual machine maintains a shallow sleep state is defined as the expiration duration, that is, the timing starts from the time the virtual machine enters the shallow sleep state. If the timing reaches the expiration duration and no wake-up event for the virtual machine is detected, the virtual machine enters the deep sleep preparation stage.

[0166] Based on the expiration time of the virtual machine, any virtual machine A in the shallow sleep state can be monitored for a wake-up event for virtual machine A. A timer starts counting from the moment virtual machine A enters the shallow sleep state. If no wake-up event for virtual machine A is detected after the timer reaches the expiration time corresponding to virtual machine A, it is determined that virtual machine A has entered the deep sleep preparation phase. Using the same method, any virtual machine in the shallow sleep state can be monitored for wake-up events and the deep sleep preparation phase can be determined.

[0167] The expiration times corresponding to each virtual machine may be the same or different. In some embodiments, in order to avoid the virtual machines that enter shallow sleep at the same time from expiring at the same time, that is, entering the deep sleep preparation stage at the same time, resulting in a load burst of the virtual machine that switches from shallow sleep to deep sleep, for each virtual machine, a random expiration time variable (i.e., time variable) can be introduced on the basis of the set expiration time, so as to reduce the probability of multiple virtual machines expiring at the same time. Specifically, for any virtual machine A, an expiration time variable can be randomly generated; and the expiration time variable corresponding to the virtual machine A is added to the set expiration time as the expiration time corresponding to virtual machine A. Since the expiration time variable is a randomly generated random time variable, even if multiple virtual machines enter shallow sleep at the same time, the introduction of the random time variable will cause the expiration times of the virtual machines that enter shallow sleep at the same time to be different, thereby reducing the probability of multiple virtual machines expiring at the same time, and further reducing the concurrent probability of multiple virtual machines switching from shallow sleep to deep sleep.

[0168] For virtual machines in the deep sleep preparation stage, an operation can be performed to switch from a shallow sleep state to a deep sleep state. Therefore, step 903 can be implemented as follows: from the virtual machines in the shallow sleep state in the scheduling domain, a virtual machine in the deep sleep preparation stage is determined; further, based on the sleep load of the scheduling domain, a target virtual machine to be switched to the deep sleep state can be determined from the virtual machines in the deep sleep preparation stage.

[0169] Among them, regarding the specific implementation method of determining the target virtual machine to be switched to the deep sleep state from the virtual machines in the deep sleep preparation stage according to the sleep load situation of the scheduling domain, please refer to the above-mentioned content of determining the target virtual machine to be switched to the deep sleep state from the virtual machines in the shallow sleep state in the scheduling domain according to the sleep load situation of the scheduling domain, which will not be repeated here.

[0170] After determining the target virtual machine to be switched to a deep sleep state, the target virtual machine may be switched from a shallow sleep state to a deep sleep state. Specifically, as shown in step 904, the resource context of the target virtual machine may be persistently stored. In some embodiments, the resource context of the target virtual machine may be persistently stored in a storage service. Of course, the resource context of the target virtual machine may also be persistently stored in a local persistent storage medium, etc.

[0171] Furthermore, in step 905 , the physical resources occupied by the target virtual machine may be released, thereby switching the target virtual machine from the shallow sleep state to the deep sleep state.

[0172] Specifically, the VMM in the target host machine where the target virtual machine resides can be controlled to persistently store the target virtual machine's resource context. For example, the VMM can persistently store the target virtual machine's resource context in a storage service. Furthermore, the VMM can be controlled to release the physical resources occupied by the target virtual machine. The VMM can release the physical resources occupied by the target virtual machine.

[0173] In an embodiment of the present application, a hierarchical hibernation method for virtual machines is adopted, and when a virtual machine is in hibernation, the virtual machine is first switched to a shallow sleep state. Since shallow sleep is a lightweight sleep, the sleep process does not require persistent storage, nor does it require the release of underlying physical resources. Therefore, the shallow sleep process uses fewer resources and can support concurrent shallow sleep of multiple virtual machines. Furthermore, based on the sleep load of the scheduling domain where the virtual machine to be hibernated is located, the target virtual machine to be switched to a deep sleep state can be determined from the virtual machines in the shallow sleep state in the scheduling domain, rather than blindly performing deep sleep on the virtual machine. This can prevent the load of the virtual machine switched from shallow sleep to deep sleep from exceeding the load of the scheduling domain, thereby causing the scheduling domain to be overloaded, alleviate the resource conflict caused by the concurrent hibernation of multiple virtual machines, and achieve a smooth transition of the virtual machine from the running state to the deep sleep state.

[0174] The above embodiment shows the process of virtual machine hibernation. For a virtual machine in a dormant state, virtual machine wake-up management can also be performed when a wake-up event occurs for the virtual machine. The virtual machine wake-up process provided by the embodiment of the present application is exemplarily described below.

[0175] For a virtual machine in a shallow sleep state, if a wake-up event for the virtual machine in the shallow sleep state is detected, the operation of the virtual machine's processor can be directly resumed, thereby switching the virtual machine from the shallow sleep state to the running state, thereby waking up the virtual machine. For the specific implementation of the virtual machine wake-up event, please refer to the relevant content of the above embodiment and will not be repeated here.

[0176] For VMs in deep sleep, waking them requires reading the VM's resource context from persistent storage and recreating and starting the VM based on the context. The transition from deep sleep to a running state consumes significant resources. Concurrently waking up multiple VMs can lead to resource conflicts.

[0177] In order to alleviate the resource conflicts caused by the concurrent awakening of multiple virtual machines, in some embodiments of the present application, a virtual machine in a deep sleep state can be awakened in advance. The awakening process of a virtual machine in a deep sleep state is the same. The following takes the first virtual machine in a deep sleep state as an example to illustrate the awakening process of a virtual machine in a deep sleep state. The first virtual machine is any virtual machine in a deep sleep state. Specifically, as shown in Figure 10, the virtual machine management method mainly includes:

[0178] 1001. Obtain a predicted wakeup time of a first virtual machine in a deep sleep state.

[0179] 1002. Before the predicted wake-up time arrives, read the resource context of the first virtual machine from a persistent storage medium.

[0180] 1003. Create the first virtual machine on the target host machine according to the resource context of the first virtual machine, so as to convert the first virtual machine from a deep sleep state to a shallow sleep state.

[0181] 1004 : In response to a wake-up event for the first virtual machine, start a processor of the first virtual machine to switch the first virtual machine from a shallow sleep state to a running state.

[0182] In step 1001, a predicted wakeup time of the first virtual machine may be obtained. In the embodiment of the present application, the specific implementation method of obtaining the predicted wakeup time of the first virtual machine is not limited.

[0183] In some embodiments, the wake-up time of the virtual machine in the deep sleep state (ie, the predicted wake-up time) can be predicted in advance and the predicted wake-up time can be stored. Afterwards, the predicted wake-up time of the first virtual machine can be read from the pre-stored predicted wake-up time of the virtual machine.

[0184] Specifically, historical wake-up behavior data of a target user for a virtual machine can be obtained. The target user is the user of the first virtual machine. Furthermore, based on the historical wake-up behavior data of the target user for the virtual machine, a wake-up time of the first virtual machine can be predicted as the predicted wake-up time of the first virtual machine.

[0185] In the embodiment of the present application, the specific implementation method of predicting the wake-up time of the first virtual machine based on the historical wake-up behavior data of the target user on the virtual machine is not limited.

[0186] In some embodiments, the historical time when the target user requests to wake up the virtual machine can be obtained from the target user's historical wake-up behavior data of the virtual machine; further, the historical time when the target user requests to wake up the virtual machine can be statistically analyzed to obtain the time regularity information of the user's request to wake up the virtual machine; thereafter, the wake-up time of the first virtual machine can be predicted based on the time regularity information of the target user's request to wake up the virtual machine.

[0187] In other embodiments, in order to improve the accuracy of predicting the wake-up time, a neural network model may be introduced. For the specific implementation form of the neural network model, please refer to the relevant content of the above embodiment and will not be repeated here. The neural network model is used to predict the wake-up time of the virtual machine and is defined as a wake-up time prediction model. The wake-up time prediction model is obtained by training the initial neural network model using the historical wake-up behavior data of the user (defined as the first user) on the virtual machine as a training sample. Among them, the first user may be one or more users. The first user may include the above-mentioned target user or may not include the target user. Among them, the input of the wake-up time prediction model may be: the historical wake-up behavior data of the user to which the virtual machine belongs to the virtual machine, and the input is: the predicted wake-up time of the virtual machine.

[0188] Based on the wake-up time prediction model, the target user's historical wake-up behavior data for the virtual machine can be input into the wake-up time prediction model. Furthermore, the wake-up time prediction model can predict the wake-up time of the first virtual machine based on the target user's historical wake-up behavior data for the virtual machine, as the predicted wake-up time of the first virtual machine.

[0189] After determining the predicted wakeup time of the first virtual machine, the first virtual machine can be switched from a deep sleep state to a shallow sleep state before the predicted wakeup time arrives, thereby waking up the first virtual machine in advance. Specifically, in step 1002, the resource context of the first virtual machine can be read from a persistent storage medium before the predicted wakeup time arrives.

[0190] In some embodiments, the resource context of the first virtual machine may be read from the persistent storage medium at a time point that is a set period of time away from the predicted wake-up time.

[0191] Furthermore, in step 1003, the first virtual machine may be created on the target host machine according to the resource context of the first virtual machine, thereby converting the first virtual machine from the deep sleep state to the shallow sleep state (corresponding to "early wake-up" in FIG8 ).

[0192] Specifically, based on the resource requirements in the resource context of the first virtual machine, a target host machine with free resources that meet the resource requirements can be selected from the computing cluster; and based on the resource requirements, target resources are allocated to the first virtual machine on the target host machine. The target resources may include all resources required by the virtual machine, including storage resources (such as memory and persistent storage resources), processor resources (such as CPU, GPU, etc.), and network resources.

[0193] Afterwards, a first virtual machine may be created using the target resources; and the first virtual machine may be initialized according to the resource configuration data in the resource context of the first virtual machine to obtain the first virtual machine.

[0194] Specifically, the memory storage data in the resource context of the first virtual machine can be written into the memory included in the target resource; the data stored in the persistent storage resource in the resource context of the first virtual machine can also be written into the persistent storage space included in the target resource; and the network resource information can be configured according to the network configuration data included in the resource context of the first virtual machine, thereby realizing the initialization of the first virtual machine.

[0195] Furthermore, a wake-up event for the first virtual machine can be monitored, and when a wake-up event for the first virtual machine is detected, in step 1004, the processor of the first virtual machine is started in response to the wake-up event for the first virtual machine, thereby converting the first virtual machine from a shallow sleep state to a running state.

[0196] In this embodiment, by predicting the wake-up time of a virtual machine in a deep sleep state, the virtual machine is woken up in advance before the predicted wake-up time arrives, so that the virtual machine is transferred from the deep sleep state to the shallow sleep state, and resources are occupied in advance. This can enable the virtual machine to avoid the wake-up peak, and alleviate the resource pressure brought by the wake-up peak to the storage service and the host machine, and alleviate the resource conflict caused by the wake-up peak.

[0197] To prevent incorrect wake-up time predictions and pre-wake up virtual machines that do not require wake-up, in some embodiments, a wake-up event for a first virtual machine may be monitored. If no wake-up event for the first virtual machine is detected within a set period of time after the predicted wake-up time arrives, the first virtual machine may be re-transferred from a shallow sleep state to a deep sleep state. Specifically, the resource context of the first virtual machine may be persistently stored, and the physical resources occupied by the first virtual machine may be re-configured to re-transfer the first virtual machine from a shallow sleep state to a deep sleep state.

[0198] If a deep-sleep virtual machine has not been pre-awakened to a shallow sleep state, if a wake-up event for the virtual machine is detected, the virtual machine can be directly switched from the deep-sleep state to the running state. Specifically, if a wake-up event for a deep-sleep first virtual machine is detected, the resource context of the first virtual machine can be read from a persistent storage medium in response to the wake-up event. Furthermore, based on the resource context of the first virtual machine, the first virtual machine can be created on the target host machine, and the processor of the first virtual machine can be started, thereby switching the first virtual machine from the deep-sleep state to the running state and waking up the virtual machine.

[0199] The above embodiment only takes the virtual machine's multi-level sleep being divided into shallow sleep and deep sleep as an example to illustrate the virtual machine management method, and does not constitute a limitation. Of course, in addition to shallow sleep and deep sleep, the virtual machine's multi-level sleep can be further divided into multiple sleep levels. Multiple means 2 or more. Among them, different sleep levels correspond to different sleep depths, and the required sleep operations are different. For example, for the highest sleep level among multiple sleep levels, it is necessary to perform the above-mentioned deep sleep sleep operation on the virtual machine: pause (Pause) the operation of the virtual machine's processor, persistently store the virtual machine's resource context, and release all the underlying physical resources occupied by the virtual machine. For the lowest sleep level among multiple sleep levels, it is necessary to perform the above-mentioned shallow sleep sleep operation on the virtual machine: pause (Pause) the operation of the virtual machine's processor, do not persistently store the virtual machine's resource context, and do not release all the underlying physical resources occupied by the virtual machine.

[0200] Of course, for other sleep levels between the lowest sleep level and the highest sleep level, they can be divided according to the proportion of the underlying physical resources occupied by the virtual machine released, where the virtual machine with the highest sleep level releases a higher proportion of the underlying physical resources. For example, the sleep operation corresponding to one of the sleep levels between the lowest sleep level and the highest sleep level may be: pausing the operation of the virtual machine's processor, persistently storing the virtual machine's resource context, but not releasing all the underlying physical resources occupied by the virtual machine. The sleep operation corresponding to another sleep level between the lowest sleep level and the highest sleep level may be: pausing the operation of the virtual machine's processor, persistently storing the virtual machine's resource context, releasing 50% of all the underlying physical resources occupied by the virtual machine, and so on.

[0201] The following is an exemplary description of the virtual machine multi-level hibernation management method provided in the embodiment of the present application. As shown in Figure 11a, the virtual machine management method mainly includes:

[0202] 1101. Obtain the sleep load status of the scheduling domain.

[0203] 1102. According to the sleep load of the scheduling domain, determine the target virtual machine to be switched to the second sleep level from the virtual machines in the scheduling domain that are in the first sleep level; the first sleep level is any sleep level among multiple sleep levels except the highest sleep level; the sleep depth of the second sleep level is higher than the first sleep level.

[0204] 1103 : Perform a sleep operation on the target virtual machine to switch from the first sleep level to the second sleep level, so as to switch the target virtual machine from the first sleep level to the second sleep level.

[0205] In this embodiment, the description of the sleep load of the scheduling domain can be found in the relevant content of the above embodiment and will not be repeated here. In this embodiment, multiple sleep levels correspond to different sleep operations. The higher the sleep level, the deeper the sleep of the virtual machine. The highest sleep level among the multiple sleep levels can be the deep sleep mentioned above.

[0206] In this embodiment, to prevent resource overload within the scheduling domain caused by a virtual machine transitioning from a first sleep level state to a second sleep level, a target virtual machine to be switched to the second sleep level may be determined from virtual machines in the scheduling domain that are in the first sleep level based on the sleep load of the scheduling domain. The second sleep level has a deeper sleep depth than the first sleep level. The second sleep level may be any sleep level with a deeper sleep depth than the first sleep level. For example, the second sleep level may be the sleep level immediately preceding the first sleep level, or may be a sleep level that spans one or more levels of the first sleep level. Multiple levels refers to two or more levels.

[0207] Among them, the target virtual machine to be switched to the second sleep state is determined according to the sleep load situation of the scheduling domain, rather than blindly switching the virtual machine to the second sleep level. This can prevent the load of the virtual machine converted from the first sleep level to the second sleep level from exceeding the load of the scheduling domain, causing the scheduling domain sleep overload, alleviate the resource conflict caused by the concurrent sleep of multiple virtual machines, and realize the smooth transition of the virtual machine from the first sleep level to the second sleep level.

[0208] In the embodiment of the present application, the specific implementation method of determining the target virtual machine for switching from the first sleep level to the second sleep level according to the sleep load of the scheduling domain where the virtual machine to be hibernated is located is not limited.

[0209] In some embodiments, the target number of virtual machines transitioning from the first sleep level to the second sleep level supported by the current load of the scheduling domain may be determined according to the sleep load of the scheduling domain.

[0210] Specifically, the hibernation load of the scheduling domain may include: the write load of the storage service shared by the scheduling domain and the resource usage that can be used for virtual machine hibernation in the host machine of the virtual machine deployed in the scheduling domain at the first hibernation level. For the sake of convenience of description, the host machine of the virtual machine deployed in the scheduling domain at the first hibernation level is defined as the second host machine. Accordingly, on the one hand, the write load of the storage service can be controlled, and the impact of switching to the second hibernation level on the storage service can be reduced mainly by limiting the total number of virtual machines switched to the second hibernation level in the scheduling domain per unit time. On the other hand, the hibernation load of a single host machine can be controlled, and the excessive consumption of physical server resources by deep hibernation can be limited by limiting the number of virtual machines switched to the second hibernation level on a single host machine.

[0211] Based on this, a third number P of virtual machines that can be switched from the first sleep level to the second sleep level and that can be supported by the current load of each second host machine in the scheduling domain can be determined based on the resource usage available for virtual machine hibernation on the second host machines in the scheduling domain. Specifically, based on the resource usage available for virtual machine hibernation on the second host machines and the total amount of resources available for virtual machine hibernation on the first host machine, the number of virtual machines that can be supported by the current remaining resources available for virtual machine hibernation on the second host machines and that can be switched from the first sleep level to the second sleep level can be determined as the third number P.

[0212] Furthermore, a fourth number Q of virtual machines currently supported by the scheduling domain for transitioning to the second sleep level can be determined based on the write load of the storage service shared by the scheduling domain. The target number can include: a third number P of virtual machines currently supported by the current load of each of the second host machines for transitioning from the first sleep level to the second sleep level, and a fourth number Q of virtual machines currently supported by the scheduling domain for transitioning from the first sleep state to the second sleep state. The relationship between the third number P and the fourth number Q can be determined based on the write load of the storage service shared by the scheduling domain and the resource usage available for virtual machine hibernation on the second host machines.

[0213] Accordingly, a target virtual machine can be selected from the virtual machines in the first sleep state in the scheduling domain based on a third number P of virtual machines that can be switched from the first sleep level to the second sleep level and supported by the current load of each second host machine in the scheduling domain, and a fourth number Q of virtual machines that can be switched from the first sleep level to the second sleep level and currently supported by the scheduling domain. The total number of target virtual machines is less than or equal to Q, and the number of target virtual machines on each second host machine in the scheduling domain is less than or equal to the third number P corresponding to that host machine.

[0214] Furthermore, a sleep operation may be performed on the target virtual machine to switch from a first sleep level to a second sleep level, where the target virtual machine is switched from the first sleep level to the second sleep level. The first sleep level and the second sleep level are different, and different sleep operations are required to be performed to switch from the first sleep level to the second sleep level.

[0215] For example, in some embodiments, the first sleep level is the above-mentioned shallow sleep, and the second sleep level is the above-mentioned deep sleep. Then, performing the sleep operation of switching the target virtual machine from the first sleep level to the second sleep level includes: persistently storing the resource context of the target virtual machine and releasing all physical resources occupied by the target virtual machine.

[0216] For another example, the first sleep level is the above-mentioned shallow sleep, and the second sleep level is: suspending the operation of the virtual machine's processor and persistently storing the resource context of the target virtual machine. Then, the sleep operation of switching the target virtual machine from the first sleep level to the second sleep level includes: persistently storing the resource context of the target virtual machine.

[0217] For another example, the first sleep level is: suspending the operation of the virtual machine's processor and persistently storing the resource context of the target virtual machine; the second sleep level is the above-mentioned deep sleep, then the sleep operation of switching the target virtual machine from the first sleep level to the second sleep level includes: releasing all physical resources occupied by the target virtual machine.

[0218] For another example, the first sleep level suspends the execution of the virtual machine's processor and persistently stores the target virtual machine's resource context; the second sleep level suspends the execution of the virtual machine's processor, persistently stores the target virtual machine's resource context, and releases a set percentage of the physical resources occupied by the target virtual machine. The set percentage is greater than 0 and less than 100%. Therefore, switching the target virtual machine from the first sleep level to the second sleep level includes releasing the set percentage of the physical resources occupied by the target virtual machine.

[0219] For another example, the first sleep level is light sleep, and the second sleep level is to: suspend the operation of the virtual machine's processor, persistently store the target virtual machine's resource context, and release a set proportion of the physical resources occupied by the target virtual machine. Where the set proportion is greater than 0 and less than 100%, then executing the sleep operation of switching the target virtual machine from the first sleep level to the second sleep level includes: persistently storing the target virtual machine's resource context and releasing the set proportion of the physical resources occupied by the target virtual machine.

[0220] The sleep operation of switching the target virtual machine from the first sleep level to the second sleep level shown in the above embodiment is only an example and does not constitute a limitation.

[0221] In this embodiment, a hierarchical hibernation method is adopted. According to the sleep load of the scheduling domain where the virtual machine to be hibernated is located, a target virtual machine to be switched to a deeper sleep state can be determined from the virtual machines in the first sleep level in the scheduling domain, rather than blindly switching the sleep level of the virtual machine. This can prevent the load of the virtual machine converted from the first sleep level to the second sleep level from exceeding the load of the scheduling domain, thereby causing the scheduling domain to be overloaded, alleviate the resource conflict caused by the concurrent sleep level switching of multiple virtual machines, and achieve a smooth transition of the virtual machine from the first sleep level to the second sleep level.

[0222] It should be noted that the execution entity of each step of the method provided in the above embodiment can be the same device, or the method can be executed by different devices. For example, the execution entity of steps 901 and 902 can be device A; for another example, the execution entity of step 901 can be device A, and the execution entity of step 902 can be device B; and so on.

[0223] In addition, some of the processes described in the above embodiments and the accompanying drawings include multiple operations that appear in a specific order. However, it should be clearly understood that these operations may not be executed in the order in which they appear in this document or may be executed in parallel. The sequence numbers of the operations, such as 901 and 902, are merely used to distinguish between different operations and do not represent any execution order. In addition, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel.

[0224] Accordingly, an embodiment of the present application further provides a computer-readable storage medium storing computer instructions. When the computer instructions are executed by one or more processors, the one or more processors are caused to execute the steps in the above-mentioned virtual machine management methods.

[0225] Figure 11b is a schematic diagram of the structure of a computing device provided in an embodiment of the present application. As shown in Figure 11b, the computing device mainly includes: a memory 11a and a processor 11b; wherein the memory 11a is used to store computer programs.

[0226] The processor 11b is coupled to the memory 11a and is used to execute a computer program for: determining, in response to a virtual machine sleep event, a virtual machine to be hibernated that is associated with the virtual machine sleep event; suspending the operation of the processor of the virtual machine to be hibernated to switch the virtual machine to be hibernated from a running state to a shallow sleep state; determining, based on the sleep load of the scheduling domain where the virtual machine to be hibernated is located, a target virtual machine to be switched to a deep sleep state from virtual machines in a shallow sleep state in the scheduling domain; the virtual machines in the shallow sleep state include the virtual machine to be hibernated; persistently storing the resource context of the target virtual machine; and releasing the physical resources occupied by the target virtual machine to switch the target virtual machine from the shallow sleep state to the deep sleep state.

[0227] In some embodiments, the virtual machine sleep event includes receiving a virtual machine sleep request. Accordingly, when the processor 11b determines the virtual machine to be hibernated associated with the sleep event in response to the virtual machine sleep event, it is specifically configured to: obtain an identifier of the virtual machine requesting hibernation from the virtual machine sleep request; and determine the virtual machine to be hibernated based on the identifier of the virtual machine requesting hibernation.

[0228] Optionally, when processor 11b determines the target virtual machine to be switched to the deep sleep state from the virtual machines in the shallow sleep state in the scheduling domain, it is specifically used to: determine the target number of virtual machines that can be switched to the deep sleep state supported by the current load based on the sleep load of the scheduling domain; and, based on the target number, select the target virtual machine from the virtual machines in the shallow sleep state in the scheduling domain.

[0229] Furthermore, the sleep load situation of the scheduling domain includes: the write load situation of the storage service shared by the scheduling domain and the resource usage situation of the first host machine in the scheduling domain that can be used for the sleep of the virtual machine. The first host machine is the host machine in the shallow sleep state deployed in the scheduling domain. Accordingly, when the processor 11b determines the target number of virtual machines that are switched to the deep sleep state supported by the current load based on the sleep load situation of the scheduling domain, it is specifically used to: determine the first number of virtual machines that are switched to the deep sleep state supported by the current load of each first host machine in the scheduling domain based on the resource usage situation of the first host machine in the scheduling domain that can be used for the sleep of the virtual machine; determine the second number of virtual machines that are switched to the deep sleep state currently supported by the scheduling domain based on the write load situation of the storage service shared by the scheduling domain; the target number includes: the first number and the second number.

[0230] Correspondingly, when processor 11b selects a target virtual machine from the virtual machines in a shallow sleep state in the scheduling domain according to the target number, it is specifically used to: select a target virtual machine from the virtual machines in a shallow sleep state in the scheduling domain according to the first number and the second number; wherein the total number of target virtual machines is less than or equal to the second number, and the number of target virtual machines on each first host machine in the scheduling domain is less than or equal to the first number corresponding to the first host machine.

[0231] In some embodiments, the processor 11b is further configured to: monitor the virtual machine inventory level of the scheduling domain; when the virtual machine inventory level is less than or equal to a set level threshold, mark a specified virtual machine among the virtual machines in the scheduling domain; and mark the specified virtual machine as a virtual machine that will not be switched to deep sleep after being in shallow sleep. Accordingly, when determining the target virtual machine to be switched to deep sleep from the virtual machines in shallow sleep in the scheduling domain based on the sleep load of the scheduling domain where the virtual machine to be hibernated is located, the processor 11b is specifically configured to: determine the specified virtual machine from the virtual machines in shallow sleep in the scheduling domain; and, based on the sleep load of the scheduling domain, determine the target virtual machine to be switched to deep sleep from the virtual machines in shallow sleep other than the specified virtual machine in the scheduling domain.

[0232] In other embodiments, the processor 11b is further configured to: monitor a wake-up event for any virtual machine in a shallow sleep state; and determine that any virtual machine has entered a deep sleep preparation phase if no wake-up event is detected for any virtual machine when the timing starts from the time when any virtual machine enters the shallow sleep state and the timing reaches the expiration time corresponding to any virtual machine. Accordingly, when the processor 11b determines a target virtual machine to be switched to a deep sleep state from the virtual machines in a shallow sleep state in the scheduling domain based on the sleep load of the scheduling domain where the virtual machine to be hibernated is located, the processor is specifically configured to: determine a virtual machine in a deep sleep preparation phase from the virtual machines in a shallow sleep state in the scheduling domain; and determine a target virtual machine to be switched to a deep sleep state from the virtual machines in the deep sleep preparation phase based on the sleep load of the scheduling domain.

[0233] Optionally, the processor 11b is further configured to: randomly generate an expiration time variable for any virtual machine; and add the expiration time variable to the set expiration time as the expiration time corresponding to any virtual machine.

[0234] In some embodiments of the present application, the processor 11b is further used to: obtain a predicted wake-up time of the first virtual machine in a deep sleep state; read the resource context of the first virtual machine from a persistent storage medium before the predicted wake-up time arrives; create the first virtual machine on the target host machine based on the resource context of the first virtual machine to convert the first virtual machine from a deep sleep state to a shallow sleep state; and then, in response to a wake-up event for the first virtual machine, start the processor of the first virtual machine to convert the first virtual machine from the shallow sleep state to the running state.

[0235] Optionally, when obtaining the predicted wake-up time of the first virtual machine, the processor 11b is specifically used to: obtain the historical wake-up behavior data of the target user on the virtual machine; the target user is the user to whom the first virtual machine belongs; and, based on the historical wake-up behavior data of the target user on the virtual machine, predict the wake-up time of the first virtual machine as the predicted wake-up time.

[0236] Furthermore, when the processor 11b predicts the wake-up time of the first virtual machine based on the historical wake-up behavior data, it is specifically used to: input the historical wake-up behavior data of the target user on the virtual machine into the wake-up time prediction model; wherein the wake-up time prediction model is trained using the historical wake-up behavior data of the first user on the virtual machine as a training sample; the first user includes or does not include the target user; in the wake-up time prediction model, the wake-up time of the first virtual machine is predicted based on the historical wake-up behavior data of the target user on the virtual machine as the predicted wake-up time.

[0237] In some embodiments, the processor 11b is also used to: if no wake-up event for the first virtual machine is detected within a set period of time after the predicted wake-up time arrives, the resource context of the first virtual machine is persistently stored, and the physical resources occupied by the first virtual machine are released to convert the first virtual machine from a shallow sleep state to a deep sleep state.

[0238] Optionally, when the processor 11b creates the first virtual machine on the target host machine based on the resource context of the first virtual machine, it is specifically used to: select a target host machine whose idle resources meet the resource demand from the computing cluster based on the resource demand in the resource context of the first virtual machine; allocate target resources to the first virtual machine on the target host machine based on the resource demand; and create the first virtual machine using the target resources; and initialize the first virtual machine based on the resource configuration data in the resource context of the first virtual machine to obtain the first virtual machine.

[0239] In some embodiments, the processor 11b is further used to: if a wake-up event for the first virtual machine in the deep sleep state is detected when the first virtual machine is in the deep sleep state; in response to the wake-up event for the first virtual machine in the deep sleep state, read the resource context of the first virtual machine from the persistent storage medium; create the first virtual machine on the target host machine according to the resource context of the first virtual machine; and start the processor of the first virtual machine to convert the first virtual machine from the deep sleep state to the running state.

[0240] In some embodiments of the present application, the processor 11b is also used to: obtain the sleep load status of the scheduling domain; determine the target virtual machine to be switched to the second sleep level from the virtual machines in the scheduling domain that are in the first sleep level according to the sleep load status of the scheduling domain; the first sleep level is any sleep level among multiple sleep levels except the highest sleep level; the sleep depth of the second sleep level is higher than the first sleep level; and, perform a sleep operation on the target virtual machine to switch from the first sleep level to the second sleep level, so as to switch the target virtual machine from the first sleep level to the second sleep level.

[0241] In some optional embodiments, as shown in Figure 11b, the computing device may further include optional components such as a communication component 11c and a power supply component 11d. Figure 11b only schematically illustrates some components, which does not mean that the computing device must include all of the components shown in Figure 11b, nor does it mean that the computing device can only include the components shown in Figure 11b.

[0242] The computing device provided in this embodiment can adopt a hierarchical sleep virtual machine method, and when the virtual machine is in sleep mode, the virtual machine is first switched to a shallow sleep state. Since shallow sleep is a lightweight sleep, the sleep process does not require persistent storage, nor does it require the release of underlying physical resources. Therefore, the shallow sleep process uses fewer resources and can support concurrent shallow sleep of multiple virtual machines. Furthermore, based on the sleep load of the scheduling domain where the virtual machine to be sleep is located, the target virtual machine to be switched to a deep sleep state can be determined from the virtual machines in the shallow sleep state in the scheduling domain, rather than blindly performing deep sleep on the virtual machine. This can prevent the load of the virtual machine switching from shallow sleep to deep sleep from exceeding the load of the scheduling domain, thereby causing the scheduling domain to be overloaded, alleviate the resource conflict caused by the concurrent sleep of multiple virtual machines, and achieve a smooth transition of the virtual machine from the running state to the deep sleep state.

[0243] In an embodiment of the present application, the memory is used to store computer programs and can be configured to store various other data to support operations on the device where it is located. The processor can execute the computer program stored in the memory to implement the corresponding control logic. The memory can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random-access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk.

[0244] In the embodiment of the present application, the processor can be any hardware processing device that can execute the logic of the above method. Optionally, the processor can be a central processing unit (CPU), a graphics processing unit (GPU) or a microcontroller unit (MCU); it can also be a programmable device such as a field programmable gate array (FPGA), a programmable array logic device (PAL), a general array logic device (GAL), a complex programmable logic device (CPLD); or an advanced reduced instruction set (RISC) processor (Advanced RISC Machines, ARM) or a system on chip (SoC), etc., but is not limited thereto.

[0245] In an embodiment of the present application, the communication component is configured to facilitate wired or wireless communication between the device in which it is located and other devices. The device in which the communication component is located can access a wireless network based on a communication standard, such as Wireless Fidelity (WiFi), 2G or 3G, 4G, 5G or a combination thereof. In an exemplary embodiment, the communication component receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component can also be based on Near Field Communication (NFC) technology, Radio Frequency Identification (RFID) technology, Infrared Data Association (IrDA) technology, Ultra Wide Band (UWB) technology, Bluetooth (BT) technology or other technologies.

[0246] In an embodiment of the present application, the display component may include a liquid crystal display (LCD) and a touch panel (TP). If the display component includes a touch panel, the display component may be implemented as a touch screen to receive input signals from a user. The touch panel includes one or more touch sensors to sense touches, slides, and gestures on the touch panel. The touch sensor can not only sense the boundaries of a touch or slide action, but also detect the duration and pressure associated with the touch or slide operation.

[0247] In embodiments of the present application, a power supply assembly is configured to provide power to various components of the device in which it is located. The power supply assembly may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device in which the power supply assembly is located.

[0248] In an embodiment of the present application, the audio component may be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC), and when the device where the audio component is located is in an operating mode, such as call mode, recording mode, and voice recognition mode, the microphone is configured to receive external audio signals. The received audio signal may be further stored in a memory or sent via a communication component. In some embodiments, the audio component further includes a speaker for outputting audio signals. For example, for a device with a language interaction function, voice interaction with the user can be achieved through the audio component.

[0249] It should be noted that the descriptions such as "first" and "second" in this article are used to distinguish different messages, devices, modules, etc., and do not represent the order of precedence, nor do they limit "first" and "second" to different types.

[0250] Those skilled in the art will appreciate that the embodiments of the present application can be provided as methods, systems, or computer program products. Therefore, the application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the application can adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, compact disc read-only memory (Compact Disc Read-Only Memory, CD-ROM), optical storage, etc.) that contain computer-usable program code.

[0251] The present application is described with reference to the flow chart and / or block diagram of the method, device (system), and computer program product according to the embodiment of the present application. It should be understood that each flow process and / or box in the flow chart and / or block diagram and the combination of the flow process and / or box in the flow chart and / or block diagram can be realized by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processing machine or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device produce a device for realizing the function specified in one flow chart flow or multiple flows and / or one box or multiple boxes of the block diagram.

[0252] These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce a product including an instruction device that implements the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0253] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0254] In a typical configuration, a computing device includes one or more processors (CPU, etc.), input / output interfaces, network interfaces, and memory.

[0255] Memory may include non-permanent storage in a computer-readable medium, random-access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0256] Computer storage media is readable storage media, also known as computer-readable media. Computer-readable storage media include permanent and non-permanent, removable and non-removable media that can be implemented using any method or technology to store information. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic disk storage or other magnetic storage devices, or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media, such as modulated data signals and carrier waves.

[0257] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus comprising a series of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprising a..." does not preclude the presence of additional identical elements in the process, method, commodity, or apparatus comprising the aforementioned elements.

[0258] The above contents are merely embodiments of the present application and are not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application should all be included within the scope of the claims of the present application.

Claims

1. A virtual machine management method, characterized in that: include: In response to a virtual machine sleep event, determining a virtual machine to be sleep-protected that is associated with the virtual machine sleep event; Suspending the operation of the processor of the virtual machine to be dormant, so as to switch the virtual machine to be dormant from a running state to a shallow dormant state; According to the sleep load of the scheduling domain where the to-be-sleep virtual machine is located, determining a target virtual machine to be switched to a deep sleep state from the virtual machines in the scheduling domain that are in a shallow sleep state; the virtual machines in a shallow sleep state include the to-be-sleep virtual machine; Persistently storing the resource context of the target virtual machine; The physical resources occupied by the target virtual machine are released to switch the target virtual machine from the shallow sleep state to the deep sleep state.

2. The method according to claim 1, characterized in that The step of determining a target virtual machine to be switched to a deep sleep state from virtual machines in a shallow sleep state in the scheduling domain according to the sleep load of the scheduling domain where the virtual machine to be sleep is located comprises: Determining a target number of virtual machines that are switched to a deep sleep state and supported by the current load according to the sleep load of the scheduling domain; According to the target number, a target virtual machine is selected from virtual machines in a shallow sleep state in the scheduling domain.

3. The method according to claim 2, characterized in that The hibernation load of the scheduling domain includes: the write load of the storage service shared by the scheduling domain and the resource usage of the first host in the scheduling domain that can be used for the virtual machine hibernation; the first virtual machine is the host on which the virtual machine in shallow hibernation state is deployed; The step of determining the target number of virtual machines that are switched to a deep sleep state and supported by the current load according to the sleep load of the scheduling domain includes: Determine, according to the resource usage of the first host machine in the scheduling domain that can be used for virtual machine hibernation, a first number of virtual machines that are switched to deep hibernation and that are supported by the current load of the first host machine; Determine, according to the write load of the storage service shared by the scheduling domain, a second number of virtual machines that are currently supported by the scheduling domain and are converted to deep sleep; the target number includes: the first number and the second number; The step of selecting a target virtual machine from virtual machines in a shallow sleep state in the scheduling domain according to the target number includes: selecting a target virtual machine from virtual machines in a shallow sleep state in the scheduling domain according to the first number and the second number; The total number of the target virtual machines is less than or equal to the second number, and the number of the target virtual machines on each first host machine is less than or equal to the first number corresponding to the first host machine.

4. The method according to claim 1, characterized in that: Also includes: Monitoring the virtual machine inventory level of the scheduling domain; When the virtual machine inventory water level is less than or equal to the set water level threshold, marking a designated virtual machine in the virtual machines of the scheduling domain; the designated virtual machine is a virtual machine that does not switch to a deep sleep state after being in a shallow sleep state; The step of determining a target virtual machine to be switched to a deep sleep state from virtual machines in a shallow sleep state in the scheduling domain according to the sleep load of the scheduling domain where the virtual machine to be sleep is located comprises: Determine the designated virtual machine from the virtual machines in the scheduling domain that are in a shallow sleep state; According to the sleep load condition of the scheduling domain, a target virtual machine to be switched to deep sleep is determined from virtual machines in the scheduling domain other than the designated virtual machine that are in shallow sleep state.

5. The method according to claim 1, characterized in that Also includes: For any virtual machine in the shallow sleep state, monitoring a wake-up event for the any virtual machine; Starting from the time when any virtual machine enters the shallow sleep state, when the timing duration reaches the expiration duration corresponding to any virtual machine, and no wake-up event for any virtual machine is detected, it is determined that any virtual machine enters the deep sleep preparation stage; The step of determining a target virtual machine to be switched to a deep sleep state from virtual machines in a shallow sleep state in the scheduling domain according to the sleep load of the scheduling domain where the virtual machine to be sleep is located comprises: Determine a virtual machine in the deep sleep preparation stage from the virtual machines in the shallow sleep state in the scheduling domain; According to the sleep load condition of the scheduling domain, a target virtual machine to be switched to the deep sleep state is determined from the virtual machines in the deep sleep preparation stage.

6. The method according to claim 5, characterized in that Also includes: For any of the virtual machines, randomly generate an expiration time variable; The expiration time variable is added to the set expiration time as the expiration time corresponding to any one of the virtual machines.

7. The method according to any one of claims 1 to 6, characterized in that: Also includes: For a first virtual machine in a deep sleep state, obtaining a predicted wake-up time of the first virtual machine; Before the predicted wake-up time arrives, reading the resource context of the first virtual machine from a persistent storage medium; Creating the first virtual machine on the target host machine according to the resource context of the first virtual machine to convert the first virtual machine from a deep sleep state to a shallow sleep state; In response to a wake-up event for the first virtual machine, a processor of the first virtual machine is started to convert the first virtual machine from the shallow sleep state to a running state.

8. The method according to claim 7, characterized in that The obtaining the predicted wake-up time of the first virtual machine includes: Acquire historical wake-up behavior data of a target user on a virtual machine; the target user is a user to which the first virtual machine belongs; predicting the wake-up time of the first virtual machine based on the historical wake-up behavior data of the target user on the virtual machine, as the predicted wake-up time.

9. The method according to claim 8, characterized in that The predicting the wake-up time of the first virtual machine according to the historical wake-up behavior data includes: Inputting the historical wake-up behavior data of the target user on the virtual machine into the wake-up time prediction model; wherein the wake-up time prediction model is trained using the historical wake-up behavior data of the first user on the virtual machine as a training sample; the first user includes or does not include the target user; In the wake-up time prediction model, the wake-up time of the first virtual machine is predicted according to the historical wake-up behavior data of the target user on the virtual machine, as the predicted wake-up time.

10. The method according to claim 7, characterized in that Also includes: If no wake-up event for the first virtual machine is detected within a set time after the predicted wake-up time arrives, the resource context of the first virtual machine is persistently stored, and the physical resources occupied by the first virtual machine are released to convert the first virtual machine from the shallow sleep state back to the deep sleep state.

11. The method according to claim 7, characterized in that The step of creating the first virtual machine on the target host machine according to the resource context of the first virtual machine includes: According to the resource demand in the resource context of the first virtual machine, selecting a target host machine whose idle resources meet the resource demand from the computing cluster; Allocating target resources to the first virtual machine on the target host machine according to the resource demand; The first virtual machine is created by using the target resources; and the first virtual machine is initialized according to the resource configuration data in the resource context of the first virtual machine to obtain the first virtual machine.

12. The method according to claim 7, characterized in that Also includes: If, when the first virtual machine is in a deep sleep state, a wake-up event for the first virtual machine in the deep sleep state is detected; In response to a wakeup event for the first virtual machine in the deep sleep state, reading a resource context of the first virtual machine from a persistent storage medium; Creating the first virtual machine on the target host machine according to the resource context of the first virtual machine; The processor of the first virtual machine is started to convert the first virtual machine from the deep sleep state to a running state.

13. A virtual machine management method, characterized in that: include: Obtaining a predicted wake-up time of a first virtual machine in a deep sleep state; Before the predicted wake-up time arrives, reading the resource context of the first virtual machine from a persistent storage medium; Creating the first virtual machine on the target host machine according to the resource context of the first virtual machine to convert the first virtual machine from a deep sleep state to a shallow sleep state; In response to a wake-up event for the first virtual machine, a processor of the first virtual machine is started to convert the first virtual machine from the shallow sleep state to a running state.

14. A virtual machine management method, characterized in that: include: Get the sleep load status of the scheduling domain; According to the sleep load of the scheduling domain, determine a target virtual machine to be switched to a second sleep level from virtual machines in the scheduling domain at a first sleep level; the first sleep level is any sleep level among multiple sleep levels except the highest sleep level; the sleep depth of the second sleep level is higher than the first sleep level; A sleep operation of switching from the first sleep level to the second sleep level is performed on the target virtual machine, so as to switch the target virtual machine from the first sleep level to the second sleep level.

15. A computing device, characterized in that: include: A memory and a processor; wherein the memory is used to store a computer program; The processor is coupled to the memory and configured to execute the computer program to perform the steps of the method according to any one of claims 1 to 14.

16. A computer-readable storage medium storing computer instructions, characterized in that: When the computer instructions are executed by one or more processors, the one or more processors are caused to execute the steps in the method according to any one of claims 1 to 14.

Images