Virtual machine management method and device and storage medium

Abstract

The embodiment of the invention provides a virtual machine management method and device and a storage medium. In the embodiment of the invention, a mode of hierarchical dormancy of the virtual machine is adopted, and when the virtual machine is dormant, the virtual machine is firstly switched to a shallow dormancy state. The shallow dormancy is lightweight dormancy, and the dormancy process does not need persistent storage and does not need to release bottom physical resources, so that the shallow dormancy process uses less resources and can support concurrent shallow dormancy of multiple virtual machines. Furthermore, the target virtual machine to be switched to the deep dormancy state can be determined from the virtual machines in the shallow dormancy state in the scheduling domain according to the dormancy load condition of the scheduling domain where the virtual machine to be dormant is located, the virtual machines are not blindly subjected to deep dormancy, the load of the virtual machine which is switched to the deep dormancy state from the shallow dormancy state can be prevented from exceeding the load of the scheduling domain, and the user experience is improved. And resource conflicts caused by concurrent dormancy of multiple virtual machines are relieved, and smooth transition of the virtual machines from the running state to the deep dormancy state can be realized.

Description

Technical Field

[0001] 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

[0002] Server virtualization technology is a key technology based on the infrastructure layer in cloud computing. This technology virtualizes physical servers to deploy multiple virtual machines (VMs) on a single host machine.

[0003] Virtual machine hibernation means storing the data of a virtual machine in the running state persistently and releasing the physical resources occupied by the underlying virtual machine. Virtual machine hibernation can use resources on demand while maintaining the services required by users, thereby improving resource utilization and reducing user costs.

[0004] In some traditional solutions, virtual machine hibernation management based on a virtual machine manager (VMM) is a common method. In this traditional solution, the VMM stops the operation of the virtual machine and stores the data of the virtual machine persistently in the storage service, and then releases the physical resources occupied by the underlying virtual machine. However, this virtual machine hibernation method is not suitable for concurrent hibernation of multiple virtual machines. Summary of the invention

[0005] 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 sleeping states of a virtual machine and alleviate resource conflicts caused by concurrent sleeping or waking of multiple virtual machines.

[0006] The present application provides a virtual machine management method, including:

[0007] 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;

[0008] 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;

[0009] 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;

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

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

[0012] The present application also provides a virtual machine management method, including:

[0013] Obtaining a predicted wake-up time of a first virtual machine in a deep sleep state;

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

[0015] 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;

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

[0017] The present application also provides a virtual machine management method, including:

[0018] Get the sleep load status of the scheduling domain;

[0019] 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;

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

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

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

[0023] The 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;

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

[0025] An embodiment of the present application also 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.

[0026] In an embodiment of the present application, a hierarchical hibernation method is adopted for virtual machines. 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 and does not 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, according to 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 resource conflicts 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

[0027] 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:

[0028] Figure 1 A schematic diagram of a process of sleeping and waking up a virtual machine provided in a conventional embodiment;

[0029] Figure 2 A schematic diagram of the structure of a virtual machine management system provided in an embodiment of the present application;

[0030] Figure 3 A schematic diagram of the structure of a host machine or a host machine provided in an embodiment of the present application;

[0031] Figure 4 A schematic diagram of a virtual machine state switching process provided in an embodiment of the present application;

[0032] Figure 5 A schematic diagram of a target virtual machine determination process and a deep sleep process provided in an embodiment of the present application;

[0033] Figure 6 A schematic diagram of a state switching process of a virtual machine in a shallow sleep state provided in an embodiment of the present application;

[0034] Figure 7 A schematic diagram of a virtual machine management process provided in an embodiment of the present application;

[0035] Figure 8A schematic diagram of a virtual machine wake-up process provided in an embodiment of the present application;

[0036] Fig. 9 and Fig.10 A flowchart of a virtual machine management method provided in an embodiment of the present application;

[0037] Fig.11a A flowchart of another virtual machine management method provided in an embodiment of the present application;

[0038] Fig.11b A schematic diagram of the structure of a computing device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0039] In order to make the purpose, technical solution and advantages of the present application clearer, the technical solution of the present application will be clearly and completely described below in combination with the specific embodiments of the present application and the corresponding drawings. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present application.

[0040] 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 underlying virtual machine. During the virtual machine wake-up phase, the VMM re-reads the virtual machine's data from the storage service and initializes the virtual machine, after which the virtual machine can be re-run. 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 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 VMM has the following defects:

[0041] (1) For example, Figure 1 As shown in the figure, multiple virtual machines share the storage service. In the scenario where a single storage service is used and multiple virtual machines are hibernating or awakened at the same time, the hibernation of multiple virtual machines will bring sudden upload traffic to the storage service, causing the storage service to be instantly overloaded, prolonging the storage time of the single virtual machine's data, and affecting the virtual machine hibernation experience. The simultaneous awakening of multiple virtual machines will bring sudden download traffic to the storage service, causing the storage service to be instantly overloaded, prolonging the download time of a single virtual machine, and affecting the virtual machine wake-up experience.

[0042] For example, in a cloud desktop scenario, multiple cloud desktops may be woken up at the same time during working hours, and hibernated at the same time during off-get off work hours. When multiple cloud desktops are hibernated at the same time, the data of multiple cloud desktops needs to be persisted to the storage service, resulting in a burst of upload traffic to the storage service; and when the cloud desktops are woken up at the same time, the data of each cloud desktop needs to be downloaded from the storage service, resulting in a burst of download traffic to the storage service.

[0043] (2) Multiple virtual machines are deployed on the same host, and multiple virtual machines are put into sleep or wake-up at the same time on a single host. To avoid interference between virtual machines, the resources allocated to virtual machines for sleep on the same host are limited. If multiple virtual machines on the same host are put into sleep or wake-up at the same time, the host will be overloaded, prolonging the sleep or wake-up time of a single virtual machine and affecting the sleep experience.

[0044] 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 need to release underlying physical resources. Therefore, the shallow sleep process uses fewer resources and can support concurrent shallow sleep of multiple virtual machines. Furthermore, according to 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, resulting in an overload of the scheduling domain sleep, 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.

[0045] The technical solutions provided by various embodiments of the present application are described in detail below in conjunction with the accompanying drawings.

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

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

[0048] 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 and guarantee services. The control node 10 can be a single server device, or a cloud server array, or a virtual machine (Virtual Machine, VM), container, etc. running in a cloud 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.

[0049] 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. Figure 3 As shown, in addition to providing computing resources, the host machine 201 can also provide other hardware resources and software resources. Among them, the hardware resources may include: computing resources such as processors, storage resources such as memory and disk, 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 the central cloud, or it can be implemented as an edge node in an edge cloud network, etc.

[0050] The resources provided by the host machine 201 can be divided into built-in resources and peripheral resources of the host machine 201. The built-in resources can be CPU resources, memory resources, etc., and the peripheral resources can be disk storage resources, extended computing resources (such as GPU, FPGA) and network resources such as network cards, etc. Figure 3 The example in which the extended computing resources include a GPU is used for illustration only, but does not constitute a limitation.

[0051] The control node 10 and the host machine 201 may be connected wirelessly or by wire. 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 through Bluetooth, WiFi, infrared, etc.

[0052] In this embodiment, if Figure 3 As shown, a host machine 201 is deployed with a virtual machine (VM) 202. The virtual machine 202 can also be called a client (Guest) of the host machine 201. VM202 has independent resources, such as computing resources such as CPU and GPU, storage resources such as memory and disk, and network resources such as network card. Figure 3 As shown, the CPU corresponding to the virtual machine can be called a virtual machine CPU (Virtual CPU, vCPU), the GPU corresponding to the virtual machine can be called a virtual machine GPU (Virtual GPU, vGPU), etc.

[0053] The scheduling domain refers to the area where the management and control node 10 performs resource scheduling. The host machines 201 in the same scheduling domain can share the same storage service and realize data sharing. The management and control node 10 can perform resource scheduling on the host machines 201 in the same scheduling domain. In the embodiment of the present application, the size of the scheduling domain is not limited. For example, one or more computer rooms can be a scheduling domain. Multiple refers to 2 or more. For another example, cabinets scattered in different computer rooms can form a scheduling domain, etc.

[0054] For the sake of service security, servers with independent power and network are usually selected from independent power and network rooms to form a dispatching domain. In this way, once a server network or power failure occurs, other servers can take over the failed server to provide services, which can improve service reliability and security.

[0055] In this embodiment, VMM 203 refers to a logical node for managing virtual machines, which can be deployed on a host machine where the virtual machine is located, such as host machine 201, or on other host machines that communicate with the host machine. For an embodiment in which VMM 203 is deployed on a host machine, VMM 203 can run on the CPU of the host machine. VMM 203 can perform task scheduling, load balancing, status monitoring, and sleep management on VM 202 on the host machine.

[0056] In this embodiment, the virtual machine 202 may be managed by the control node 10. Specifically, the control node 10 may monitor a virtual machine sleep event, and when a virtual machine sleep event is detected, in response to the virtual machine sleep event, determine a virtual machine to be hibernated associated with the virtual machine sleep event.

[0057] In the embodiments of the present application, the specific implementation form of the virtual machine sleep event is not limited. Figure 1 As shown, the user can initiate a virtual machine sleep request to the management node 10 through the user terminal 30 when the virtual machine is not needed according to the user's own needs for using the virtual machine. The virtual machine sleep request may include: a user identifier and / or an identifier of the virtual machine requested to sleep, etc. For example, in a cloud desktop scenario, a cloud desktop user can initiate a virtual machine sleep request at off-duty time.

[0058] 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 determine the virtual machine to be sleep according to the virtual machine sleep request in response to receiving the virtual machine sleep event triggered by the virtual machine sleep request.

[0059] Specifically, the control node 10 can obtain the user identifier of the virtual machine sleep request from the virtual machine sleep request; and determine, based on the user identifier, the virtual machine corresponding to the user identifier as the virtual machine to be sleep. Alternatively, the control node 10 can obtain the identifier of the virtual machine requesting sleep from the virtual machine sleep request; and determine the virtual machine corresponding to the identifier of the virtual machine requesting sleep as the virtual machine to be sleep. Alternatively, the control node 10 can obtain the user identifier of the virtual machine sleep request and the identifier of the virtual machine requesting sleep from the virtual machine sleep request; and determine, from the virtual machines corresponding to the user identifier, the virtual machine corresponding to the identifier of the virtual machine requesting sleep as the virtual machine to be sleep.

[0060] The implementation forms of the virtual machine sleep events shown in the above embodiments are only exemplary and do not constitute limitations.

[0061] In an embodiment of the present application, in order to reduce the probability of overloading the storage service and the host machine due to the concurrent hibernation of multiple virtual machines, a multi-level hibernation mode is introduced to achieve a smooth transition between the virtual machine running state and the hibernation state, thereby alleviating the resource conflicts caused by the concurrent hibernation of multiple virtual machines.

[0062] In the embodiment of the present application, multi-level sleep is mainly divided into: shallow sleep and deep sleep. Among them, deep sleep is sleep in the traditional sense. When a virtual machine is in deep sleep, it will not only pause the operation of the processor of the virtual machine, but also need to persist the resource context of the virtual machine, generally, the resource context of the virtual machine is persisted in the storage service. After that, the underlying physical resources occupied by the virtual machine are released.

[0063] Among them, the resource context of a virtual machine refers to information reflecting 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 the 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 (storage resources, network resources, and processor resources, etc.) of a virtual machine 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 the network mode, etc.

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

[0065] Compared with deep sleep, shallow sleep is a lightweight sleep and a transitional stage to deep sleep. Shallow sleep will pause the operation of the virtual machine's processor, and will not persist the resource context of the virtual machine, nor 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, 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.

[0066] Since 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, since a virtual machine in shallow sleep does not need to re-download the virtual machine's resource context or recreate the virtual machine when waking up, the success rate of waking up a virtual machine in shallow sleep is higher than that of a virtual machine in deep sleep.

[0067] If some physical resources are reused by different virtual machines, the physical resources occupied by the virtual machine in shallow sleep state can be released to other virtual machines for use. For example, for burst-type virtual machines, a points mechanism can be used to share processor resources with other virtual machines. For burst-type virtual machines, the accumulation and consumption of points can be stopped during the shallow sleep stage, and 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 GPU. 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.

[0068] In the embodiment of the present application, state switching between virtual machines is supported. Figure 4As shown, the virtual machine can switch from the running state (S0) to the shallow sleep state (S2), or the virtual machine can be directly switched from the running state (S0) to the deep sleep state (S4). In the virtual machine wake-up phase, the virtual machine in the shallow sleep state (S2) can be directly switched to the running state (S0); the 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 the shallow sleep state and the deep sleep state. For example, a virtual machine in the shallow sleep state (S2) can be switched to the deep sleep state (S4); in 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 storage or downloading of the resource context of the virtual machine, nor does it require the release or reallocation of underlying resources. Therefore, the state switching between the running state (S0) and the shallow sleep state (S4) is lightweight.

[0069] Based on the above-mentioned deep sleep and shallow sleep, after determining the virtual machine to be dormant, the control node 10 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 the dormant process, there is no need to persist the resource context of the virtual machine to be dormant, nor is there any need to release the underlying physical resources occupied by the virtual machine to be dormant, that is, the dormant process occupies 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.

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

[0071] Since a virtual machine in a shallow sleep state is converted to a 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. The 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 be overloaded, and may also cause the storage service to be overloaded, thereby extending the sleep time of a single virtual machine.

[0072] In order to solve this problem, in the embodiment of the present application, deep sleep scheduling is introduced. The important goal of the deep sleep scheduler is to smooth the sleep burst and make the virtual machine in the appropriate shallow sleep state enter the deep sleep state as soon as possible when the system pressure allows.

[0073] 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 for performing sleep operations in the scheduling domain.

[0074] In order to prevent the resource overload in the scheduling domain caused by the virtual machine switching from the shallow sleep state to the deep sleep state, the control node 10 can determine 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 of the scheduling domain where the virtual machine to be hibernated is located. The virtual machines in the shallow sleep state in the scheduling domain include the virtual machines to be hibernated.

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

[0076] 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 condition of the scheduling domain where the virtual machine to be hibernated is located is not limited.

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

[0078] Specifically, Figure 5 As shown, 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 that can be used for the hibernation of the virtual machine in the host machine where the virtual machine in shallow hibernation is deployed in the scheduling domain. For the convenience 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.

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

[0080] Further, the control node 10 may determine the second number N of virtual machines that are currently supported by the scheduling domain to switch to deep sleep according to the write load of the storage service shared by the scheduling domain. The above target number may include: the first number M of deep sleep virtual machines supported by the current load of each of the above first host machines and the second number N of deep sleep virtual machines currently supported by the scheduling domain. The relationship between the first number M and the second number N may be determined according to the write load of the storage service shared by the scheduling domain and the resource usage in the first host machine that can be used for virtual machine hibernation.

[0081] Accordingly, the control node 10 may select a target virtual machine from the virtual machines in shallow sleep in the scheduling domain according to the first number M of deep sleep virtual machines supported by the current load of each host machine in the scheduling domain and the 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.

[0082] In other embodiments, if the sales of virtual machines in the scheduling domain reach a certain level, if the virtual machines continue to be put into deep sleep and the underlying physical resources occupied by the virtual machines are released, insufficient resource inventory may occur when waking up the virtual machines, resulting in a wake-up failure. Based on this, the embodiment of the present application proposes a method of pre-occupying resources, so that some virtual machines in shallow sleep state remain in shallow sleep state, so as to avoid resource preemption and ensure the success rate of waking up these virtual machines.

[0083] Specifically, the control node 10 can monitor the virtual machine inventory level of the scheduling domain. The virtual machine inventory level is used to characterize the idle resources in the scheduling domain that can still deploy virtual machines, and can be represented by the ratio of the idle resources in the scheduling domain to the total resources in the scheduling domain. Of course, the virtual machine inventory level can also be represented by the ratio of the number of virtual machines that can be deployed by the idle resources in the scheduling domain to the total number of virtual machines that can be deployed by the total resources of the scheduling domain.

[0084] When it is detected that the virtual machine inventory water level is less than or equal to the set water level threshold, the designated virtual machine can be marked in the virtual machines of the scheduling domain. The designated virtual machine is a virtual machine that does not switch to deep sleep after being in a shallow sleep state. In the embodiment of the present application, the specific implementation method of determining the designated virtual machine is not limited.

[0085] In some embodiments, a designated virtual machine may be set for certain users. Accordingly, a user identifier that can set the designated virtual machine may be pre-stored. Accordingly, the management and control node 10 may determine 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, when the virtual machine inventory water level is detected to be less than or equal to the set water level threshold.

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

[0087] After the designated virtual machine is in a shallow sleep state, it does not switch to a deep sleep state, which can avoid 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 machines 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 designated virtual machines mentioned above. 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 designated virtual machines mentioned above 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.

[0088] 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 at a relatively small 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 perform the operation of switching from shallow sleep to deep sleep.

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

[0090] 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 receiving the virtual machine wake-up event triggered by the virtual machine wake-up request.

[0091] Specifically, the control node 10 can obtain the user identifier that initiates the virtual machine wake-up request from the virtual machine wake-up request; and determine, based on the user identifier, the virtual machine corresponding to the user identifier as the virtual machine to be awakened. Alternatively, the control node 10 can obtain the identifier of the virtual machine requested to be awakened from the virtual machine wake-up request; and determine the virtual machine corresponding to the identifier of the virtual machine requested to be awakened as the virtual machine to be awakened. Alternatively, the control node 10 can obtain the user identifier that initiates 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, from the virtual machines corresponding to the user identifier, the virtual machine corresponding to the identifier of the virtual machine requested to be awakened as the virtual machine to be awakened.

[0092] In other embodiments, the management and control node 10 may predict the wake-up time of the virtual machine based on the historical wake-up behavior data of the virtual machine user; and when the predicted wake-up time of the virtual machine arrives, the management and control node 10 may send a virtual machine wake-up prompt message to the user terminal 30. The historical wake-up behavior data of the user for the virtual machine includes: the historical time when the user requested to wake up the virtual machine, etc. The management and control node 10 may perform statistical analysis on the historical time when the user requested to wake up the virtual machine to obtain the time regularity information when the user requested to wake up the virtual machine; then, the management and control node 10 may predict the wake-up time of the virtual machine, etc., based on the time regularity information when the user requested to wake up the virtual machine.

[0093] Accordingly, the user can continue to hibernate the virtual machine or wake up the virtual machine according to his own needs. If the user chooses to wake up the virtual machine, the user 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 initiate a virtual machine wake-up confirmation message to the control node 10. The control node 10 receives the virtual machine wake-up confirmation message and determines that a virtual machine wake-up event is detected.

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

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

[0096] The period of time that the virtual machine maintains the shallow sleep state is defined as the expiration time, that is, the time starts from when the virtual machine enters the shallow sleep state. If the 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. Figure 6 In the example of switching from a shallow sleep state (S2) to a deep sleep state (S4) in FIG. 1 , if a wake-up event for the virtual machine is detected before the timing duration reaches the expiration duration, the operation of the processor of the virtual machine is resumed, 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, Figure 6 A virtual machine switches from a shallow sleep state (S2) to a running state (S0).

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

[0098] Based on the expiration time of the virtual machine, the control node 10 can monitor the wake-up event for any virtual machine A in the shallow sleep state; and start timing from the time when virtual machine A enters the shallow sleep state. When the timing time reaches the expiration time corresponding to virtual machine A, if no wake-up event for virtual machine A is detected, it is determined that virtual machine A enters the deep sleep preparation stage. In the same way, the wake-up event monitoring and deep sleep preparation stage determination can be performed for any virtual machine in the shallow sleep state.

[0099] The expiration durations corresponding to each virtual machine may be the same or different. In some embodiments, in order to avoid the simultaneous expiration of virtual machines that enter shallow sleep, that is, simultaneously enter the deep sleep preparation stage, resulting in a load burst of the virtual machine that switches from shallow sleep to deep sleep, for each virtual machine, a random expiration duration variable (i.e., time variable) may be introduced based on the set expiration duration, which can reduce the probability of multiple virtual machines expiring at the same time. The expiration duration variable refers to the time increment, which is the length of time added based on the set expiration duration.

[0100] 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 the virtual machine A. The set expiration time is a pre-set time length, and its determination method can refer to the relevant content of the above expiration time. Since the expiration time variable is a randomly generated time variable, even if multiple virtual machines enter the shallow sleep state at the same time, the introduction of the random time variable will cause the expiration time of the virtual machines entering the shallow sleep state 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 the shallow sleep state to the deep sleep state.

[0101] In other 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, different expiration times can be set for each virtual machine. For example, different expiration times can be set according to the response delay requirements of the tasks executed by the virtual machine. The more sensitive the virtual machine is to the response delay of the executed task, the shorter the expiration time. Alternatively, it can also be flexibly set according to 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 time of the obtained virtual machine will also be different. In either way, different expiration times can be made 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 then reducing the concurrent probability of multiple virtual machines switching from shallow sleep to deep sleep.

[0102] For a virtual machine in the deep sleep preparation stage, an operation of switching from a shallow sleep state to a deep sleep state can be performed. 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 according to the sleep load of the scheduling domain where the virtual machine to be sleep is located, the virtual machine in the deep sleep preparation stage can be determined from the virtual machines in the shallow sleep state in the scheduling domain; further, the target virtual machine to be switched to a deep sleep state can be determined from the virtual machines in the deep sleep preparation stage according to the sleep load of the scheduling domain.

[0103] Specifically, combined Figure 5 and Figure 7 The control node 10 includes: a deep sleep scheduler and a deep sleep controller. The deep sleep scheduler is used to perform the above operation 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 of the scheduling domain. After the deep sleep scheduler determines the target virtual machine, the identifier of the target virtual machine can be transmitted to the deep sleep controller. The deep sleep controller can control the target virtual machine to switch from the shallow sleep state to the deep sleep state.

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

[0105] After determining the target virtual machine to be switched to the deep sleep state, the control node 10 can switch 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.

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

[0107] 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 a shallow sleep state to a deep sleep state.

[0108] Specifically, combined Figure 5 and Figure 7 , the control node 10 can control the VMM 203 in the target host machine 201 where the target virtual machine is located to persistently store the resource context of the target virtual machine, such as the VMM 203 can persistently store the resource context of the target virtual machine in the storage service. Further, the control node 10 can also 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.

[0109] In some embodiments, in combination Figure 5 and Figure 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 is located. The deep sleep instruction may include: the identifier of the target virtual machine. The VMM 203 in the target host machine 201 may respond to the deep sleep instruction, obtain the resource context of the target virtual machine according to the identifier of the target virtual machine, and store the resource context of the target virtual machine persistently; further, the VMM 203 may release the physical resources occupied by the target virtual machine 202.

[0110] In an embodiment of the present application, a hierarchical hibernation method is adopted for virtual machines. 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 and does not 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, according to 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 resource conflicts 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.

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

[0112] For a virtual machine in a shallow sleep state, if a wake-up event for the virtual machine in a 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.

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

[0114] For a deep sleep virtual machine, when waking up a deep sleep virtual machine, it is necessary to read the virtual machine's resource context from the persistent storage medium, and recreate and start the virtual machine based on the virtual machine's resource context. The process of a virtual machine going from deep sleep to running state consumes a lot of resources. Concurrently waking up multiple virtual machines may cause resource conflicts.

[0115] In order to alleviate the resource conflict caused by the concurrent awakening of multiple virtual machines, in some embodiments of the present application, the virtual machine in deep sleep state can be awakened in advance. The awakening process of the virtual machine in deep sleep state is the same. The following takes the first virtual machine in deep sleep state as an example to illustrate the awakening process of the virtual machine in deep sleep state. The first virtual machine is any virtual machine in deep sleep state.

[0116] Specifically, Figure 8 As shown, the management and control node 10 can obtain the predicted wake-up time of the first virtual machine. In the embodiment of the present application, the specific implementation method of obtaining the predicted wake-up time of the first virtual machine is not limited.

[0117] In some embodiments, the management and control node 10 may predict the wake-up time of the virtual machine in deep sleep state (ie, predicted wake-up time) in advance and store the predicted wake-up time. Afterwards, the predicted wake-up time of the first virtual machine may be read from the pre-stored predicted wake-up time of the virtual machine.

[0118] Specifically, the control node 10 may obtain historical wake-up behavior data of the target user on the virtual machine. The target user is the user to which the first virtual machine belongs. Further, 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 on the virtual machine as the predicted wake-up time of the first virtual machine.

[0119] 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 according to the historical wake-up behavior data of the target user on the virtual machine is not limited.

[0120] In some embodiments, the control node 10 may obtain the historical time when the target user requests to wake up the virtual machine from the historical wake-up behavior data of the target user on the virtual machine; further, the historical time when the target user requests to wake up the virtual machine may 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 may be predicted based on the time regularity information of the target user's request to wake up the virtual machine. For example, the time regularity information of the target user's request to wake up the virtual machine includes: if the target user requests to wake up the virtual machine in a specific time period of a set time period, the wake-up time of the first virtual machine may be predicted to be the earliest time in 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 and 9:00 a.m. every day, the predicted wake-up time of the first virtual machine may be 8:30 a.m.

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

[0122] like Figure 7 and Figure 8As shown, the neural network model is used to predict the wake-up time of the virtual machine, which is defined as the wake-up time prediction model. The wake-up time prediction model is obtained by training the initial neural network model with the historical wake-up behavior data of the user (defined as the first user) on the virtual machine as the training sample. Among them, the first user can 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 output is: the predicted wake-up time of the virtual machine.

[0123] Based on the wake-up time prediction model, the historical wake-up behavior data of the target user on the virtual machine can be input into the wake-up time prediction model. Further, in the wake-up time prediction model, the wake-up time of the first virtual machine can be predicted according to the historical wake-up behavior data of the target user on the virtual machine, as the predicted wake-up time of the first virtual machine (corresponding to Figure 8 The historical wake-up behavior data used to predict the wake-up time of the first virtual machine may be historical wake-up behavior data in a recent period of time (such as the last week, the last 2 weeks, the last month, or the last few months) from the current time.

[0124] After determining the predicted wake-up time of the first virtual machine, the management and control node 10 may switch the first virtual machine from a deep sleep state to a shallow sleep state before the predicted wake-up time arrives, thereby waking up the first virtual machine in advance. Figure 7 and Figure 8 The operation of switching the first virtual machine from the deep sleep state to the shallow sleep state may be performed by a wake-up controller in the management and control node 10 .

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

[0126] 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 from the predicted wake-up time. In the embodiments of the present application, the specific value of the set time is not limited. The set time may be in the order of minutes, such as 10 minutes, 30 minutes, 40 minutes, or 1 hour, but is not limited thereto.

[0127] Further, the 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 Figure 8 in the "Early Wake-up" section).

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

[0129] Afterwards, the target resource may be used to create a first virtual machine; 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.

[0130] 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 resources can also be configured with information based on the network configuration data included in the resource context of the first virtual machine, thereby initializing the first virtual machine.

[0131] Further, the management and control node 10 may monitor a wake-up event for the first virtual machine, and in response to a wake-up event for the first virtual machine, start the processor of the first virtual machine, thereby converting the first virtual machine from a shallow sleep state to a running state (corresponding to Figure 8 in the “Wake Up” dialog box).

[0132] 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 switched from a deep sleep state to a shallow sleep state, and resources are occupied in advance. This allows the virtual machine to avoid the wake-up peak, thereby alleviating the resource pressure on the storage service and the host machine caused by the wake-up peak, and can alleviate the resource conflict caused by the wake-up peak.

[0133] In order to prevent the prediction error of the wake-up time and pre-wake up the virtual machine without the wake-up demand, in some embodiments, the management and control node 10 can monitor the wake-up event for the first virtual machine. If the wake-up event for the first virtual machine is not detected within the set time after the predicted wake-up time arrives, the first virtual machine can be converted from the shallow sleep state to the deep sleep state. Specifically, the resource context of the first virtual machine can be persistently stored, and the physical resources occupied by the first virtual machine can be re-checked to convert the first virtual machine from the shallow sleep state to the deep sleep state.

[0134] If a deep sleep virtual machine is not pre-awakened to a 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 Figure 8 Direct wakeup in ).

[0135] Specifically, if a wake-up 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 wake-up event. Further, the first virtual machine can be created on the target host machine according to the resource context of the first virtual machine, and the processor of the first virtual machine can be started, so as to convert the first virtual machine from a deep sleep state to a running state, thereby realizing the wake-up of the virtual machine (corresponding to Figure 8 Direct wakeup in ).

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

[0137] Fig. 9 A flowchart of a virtual machine management method provided in an embodiment of the present application. Fig. 9 As shown, the method mainly includes:

[0138] 901. In response to a virtual machine sleep event, determine a virtual machine to be sleep-protected that is associated with the virtual machine sleep event.

[0139] 902. Suspend the operation of the processor of the virtual machine to be hibernated to switch the virtual machine to be hibernated from the running state to the shallow hibernation state.

[0140] 903. According to the sleep load of the scheduling domain where the virtual machine to be hibernated is located, 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; the virtual machines in a shallow sleep state include the virtual machine to be hibernated.

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

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

[0143] In this embodiment, a virtual machine sleep event is monitored, and when 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. For 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, which will not be repeated here.

[0144] In an embodiment of the present application, in order to reduce the probability of overloading the storage service and the host machine due to the concurrent hibernation of multiple virtual machines, a multi-level hibernation mode is introduced to achieve a smooth transition between the virtual machine running state and the hibernation state, thereby alleviating the resource conflicts caused by the concurrent hibernation of multiple virtual machines.

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

[0146] Since 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, since a virtual machine in shallow sleep does not need to re-download the virtual machine's resource context or recreate the virtual machine when waking up, the success rate of waking up a virtual machine in shallow sleep is higher than that of a virtual machine in deep sleep.

[0147] Based on the above 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, so as to switch the virtual machine to be hibernated from the running state (S0) to the shallow sleep state. In the hibernation process, there is no need to persist the resource context of the virtual machine to be hibernated, and there is no need to release the underlying physical resources occupied by the virtual machine to be hibernated, that is, the hibernation process occupies fewer resources, can support concurrent shallow sleep of multiple virtual machines, and can also alleviate resource conflicts in the hibernation process of multiple virtual machines.

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

[0149] Since a virtual machine in a shallow sleep state is converted to a 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. The 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 be overloaded, and may also cause the storage service to be overloaded, thereby extending the sleep time of a single virtual machine.

[0150] In order to solve this problem, in the embodiment of the present application, deep sleep scheduling is introduced. The important goal of the deep sleep scheduler is to smooth the sleep burst and make the virtual machine in the appropriate shallow sleep state enter the deep sleep state as soon as possible when the system pressure allows.

[0151] Specifically, the sleep load of the scheduling domain where the virtual machine to be dormant is located can be monitored. In order to prevent the resource overload in the scheduling domain caused by the virtual machine switching from the shallow sleep state to the deep sleep state, in step 903, the target virtual machine to be switched to the deep sleep state can be determined from the virtual machines in the shallow sleep state in the scheduling domain according to the sleep load of the scheduling domain where the virtual machine to be dormant is located. Among them, the virtual machines in the shallow sleep state in the scheduling domain include the above-mentioned virtual machines to be dormant.

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

[0153] 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 condition of the scheduling domain where the virtual machine to be hibernated is located is not limited.

[0154] In some embodiments, the target number of virtual machines that are converted to a deep sleep state and that are supported by the current load of the scheduling domain may be determined according to the sleep load of the scheduling domain.

[0155] 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 that can be used for the hibernation of the virtual machine in the first host machine in the scheduling domain. 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 converted 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 that can be used for the hibernation of the virtual machine in the first host machine in the scheduling domain. 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 that can be used for the hibernation of the virtual machine in the first host machine and the total amount of resources that can be used for the hibernation of the virtual machine in the first host machine.

[0156] Further, the second number N of virtual machines that are currently supported by the scheduling domain and are converted to deep sleep may be determined according to the write load of the storage service shared by the scheduling domain. The above 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.

[0157] Accordingly, the target virtual machine can be selected from the virtual machines in shallow sleep state in the scheduling domain according to the first number M of deep sleep virtual machines supported by the current load of each first host machine in the scheduling domain and the 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.

[0158] In other embodiments, if the sales of virtual machines in the scheduling domain reach a certain level, if the virtual machines continue to be put into deep sleep and the underlying physical resources occupied by the virtual machines are released, insufficient resource inventory may occur when waking up the virtual machines, resulting in a wake-up failure. Based on this, the embodiment of the present application proposes a method of pre-occupying resources, so that some virtual machines in shallow sleep state remain in shallow sleep state, so as to avoid resource preemption and ensure the success rate of waking up these virtual machines.

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

[0160] When it is detected that the virtual machine inventory water level is less than or equal to the set water level threshold, the designated virtual machine can be marked in the virtual machines of the scheduling domain. The designated virtual machine is a virtual machine that does not switch to deep sleep after being in a shallow sleep state. For the specific implementation method of determining the designated virtual machine, please refer to the relevant content of the above embodiment, which will not be repeated here.

[0161] 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 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 pre-excluded. 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 according to 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 designated virtual machines mentioned above. 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 designated virtual machines mentioned above 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 state 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.

[0162] 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 at a relatively small 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 perform the operation of switching from shallow sleep to deep sleep.

[0163] 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 virtual machine entering the shallow sleep state. If the timing duration reaches the expiration duration and no wake-up event for the virtual machine is detected, the virtual machine enters the deep sleep preparation stage.

[0164] Based on the expiration time of the virtual machine, the wake-up event for virtual machine A can be monitored for any virtual machine A in the shallow sleep state; and the timing starts from when virtual machine A enters the shallow sleep state. When the timing reaches the expiration time corresponding to virtual machine A, if the wake-up event for virtual machine A is still not detected, it is determined that virtual machine A enters the deep sleep preparation stage. In the same way, the wake-up event monitoring and deep sleep preparation stage determination can be performed for any virtual machine in the shallow sleep state.

[0165] The expiration durations 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 expiring, 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 duration variable (i.e., time variable) can be introduced on the basis of the set expiration duration, so as to reduce the probability of multiple virtual machines expiring at the same time. Specifically, for any virtual machine A, an expiration duration variable can be randomly generated; and the expiration duration variable corresponding to the virtual machine A is added to the set expiration duration as the expiration duration corresponding to virtual machine A. Since the expiration duration 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.

[0166] For a virtual machine in the deep sleep preparation stage, an operation of switching from a shallow sleep state to a deep sleep state may be performed. Therefore, step 903 may 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, according to the sleep load of the scheduling domain, a target virtual machine to be switched to a deep sleep state may be determined from the virtual machines in the deep sleep preparation stage.

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

[0168] After determining the target virtual machine to be switched to the deep sleep state, the target virtual machine may be switched from the shallow sleep state to the 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.

[0169] Further, 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.

[0170] Specifically, the VMM in the target host where the target virtual machine is located can be controlled to persistently store the resource context of the target virtual machine, such as the VMM can persistently store the resource context of the target virtual machine in the storage service. Further, the VMM can also 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.

[0171] In an embodiment of the present application, a hierarchical hibernation method is adopted for virtual machines. 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 and does not 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, according to 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 resource conflicts 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.

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

[0173] For a virtual machine in a shallow sleep state, if a wake-up event for the virtual machine in a 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, and waking up the virtual machine. For 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.

[0174] For a deep sleep virtual machine, when waking up a deep sleep virtual machine, it is necessary to read the virtual machine's resource context from the persistent storage medium, and recreate and start the virtual machine based on the virtual machine's resource context. The process of a virtual machine going from deep sleep to running state consumes a lot of resources. Concurrently waking up multiple virtual machines may cause resource conflicts.

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

[0176] 1001. Obtain a predicted wake-up time of a first virtual machine in a deep sleep state.

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

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

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

[0180] In step 1001, the predicted wake-up time of the first virtual machine may be obtained. In the embodiment of the present application, the specific implementation method of obtaining the predicted wake-up time of the first virtual machine is not limited.

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

[0182] Specifically, historical wake-up behavior data of the target user on the virtual machine may be obtained, wherein the target user is a user to which the first virtual machine belongs. Further, the wake-up time of the first virtual machine may be predicted based on the historical wake-up behavior data of the target user on the virtual machine as the predicted wake-up time of the first virtual machine.

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

[0184] 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 time regularity information when the user requests 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 when the target user requests to wake up the virtual machine.

[0185] 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, which 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 with 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.

[0186] Based on the wake-up time prediction model, the historical wake-up behavior data of the target user on the virtual machine can be input into the wake-up time prediction model. Further, in the wake-up time prediction model, the wake-up time of the first virtual machine can be predicted according to the historical wake-up behavior data of the target user on the virtual machine as the predicted wake-up time of the first virtual machine.

[0187] After determining the predicted wake-up 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 wake-up time arrives, so as to realize early wake-up of the first virtual machine. Specifically, in step 1002, the resource context of the first virtual machine can be read from a persistent storage medium before the predicted wake-up time arrives.

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

[0189] Further, 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 Figure 8 in the "Early Wake-up" section).

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

[0191] Afterwards, the target resource may be used to create a first virtual machine; 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.

[0192] 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 resources can also be configured with information based on the network configuration data included in the resource context of the first virtual machine, thereby initializing the first virtual machine.

[0193] Further, 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, in response to the wake-up event for the first virtual machine, the processor of the first virtual machine is started, thereby converting the first virtual machine from a shallow sleep state to a running state.

[0194] 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 switched from a deep sleep state to a shallow sleep state, and resources are occupied in advance. This allows the virtual machine to avoid the wake-up peak, thereby alleviating the resource pressure on the storage service and the host machine caused by the wake-up peak, and can alleviate the resource conflict caused by the wake-up peak.

[0195] In order to prevent the prediction error of the wake-up time, the virtual machine without the wake-up demand is pre-wake-up. In some embodiments, the wake-up event for the first virtual machine can be monitored. If the wake-up event for the first virtual machine is not detected within the set time after the predicted wake-up time arrives, the first virtual machine can be re-converted from the shallow sleep state to the deep sleep state. Specifically, the resource context of the first virtual machine can be persistently stored, and the physical resources occupied by the first virtual machine can be re-converted to the deep sleep state from the shallow sleep state.

[0196] 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 converted 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. Further, 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 converting the first virtual machine from the deep-sleep state to the running state and realizing the wake-up of the virtual machine.

[0197] The above embodiment only takes the virtual machine multi-level sleep 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 multi-level sleep can be further divided into multiple sleep levels. Multiple refers to 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 resource context of the virtual machine, 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 resource context of the virtual machine, and do not release all the underlying physical resources occupied by the virtual machine.

[0198] 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, wherein the virtual machine with the highest sleep level has a higher proportion of the underlying physical resources released. 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 processor of the virtual machine, persistently storing the resource context of the virtual machine, 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 processor of the virtual machine, persistently storing the resource context of the virtual machine, releasing 50% of all the underlying physical resources occupied by the virtual machine, and so on.

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

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

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

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

[0203] In this embodiment, for the description of the sleep load of the scheduling domain, please refer to the relevant content of the above embodiment, which will not be repeated here. In this embodiment, multiple sleep levels correspond to different sleep operations, and the higher the sleep level, the higher the sleep depth of the virtual machine. The highest sleep level among the multiple sleep levels can be the above deep sleep.

[0204] In this embodiment, in order to prevent the resource overload in the scheduling domain caused by the virtual machine switching from the first sleep level state to the second sleep state, the target virtual machine to be switched to the second sleep level can be determined from the virtual machines in the scheduling domain at the first sleep level according to the sleep load of the scheduling domain. The sleep depth of the second sleep level is higher than the first sleep level. The second sleep level can be any sleep level with a higher sleep depth than the first sleep level. For example, the second sleep level can be the previous sleep level of the first sleep level, or it can be a sleep level across one or multiple levels of the first sleep level. Multiple levels refers to 2 levels or more.

[0205] 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 achieve a smooth transition of the virtual machine from the first sleep level to the second sleep level.

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

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

[0208] 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 that can be used for the hibernation of the virtual machine in the host machine of the virtual machine deployed at the first hibernation level in the scheduling domain. For the convenience of description, the host machine of the virtual machine deployed at the first hibernation level in the scheduling domain 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 resources of the physical server by deep hibernation can be limited by limiting the number of virtual machines switched to the second hibernation level on the single host machine.

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

[0210] Further, the fourth number Q of virtual machines that are currently supported by the scheduling domain and switched to the second sleep level may be determined according to the write load of the storage service shared by the scheduling domain. The target number may include: the third number P of virtual machines that are switched from the first sleep level to the second sleep level supported by the current load of each of the second host machines, and the fourth number Q of virtual machines that are currently supported by the scheduling domain and switched from the first sleep state to the second sleep state. The relationship between the third number P and the fourth number Q may be determined according to the write load of the storage service shared by the scheduling domain and the resource usage that can be used for virtual machine sleep in the second host machine.

[0211] Accordingly, the target virtual machine can be selected from the virtual machines in the first sleep state in the scheduling domain according to the third number P of virtual machines that are 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 the fourth number Q of virtual machines that are 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 the host machine.

[0212] Furthermore, a sleep operation of switching from a first sleep level to a second sleep level may be performed on the target virtual machine to switch the target virtual machine 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 need to be performed to switch from the first sleep level to the second sleep level.

[0213] 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, 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.

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

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

[0216] For another example, the first sleep level is to suspend the operation of the processor of the virtual machine and persistently store the resource context of the target virtual machine; the second sleep level is to suspend the operation of the processor of the virtual machine, persistently store the resource context of the target virtual machine, and release a set proportion of physical resources occupied by the target virtual machine. The set proportion is greater than 0 and less than 100%. Then, the sleep operation of switching the target virtual machine from the first sleep level to the second sleep level includes: releasing the set proportion of physical resources occupied by the target virtual machine.

[0217] For another example, the first sleep level is shallow sleep, and the second sleep level is: suspending the operation of the processor of the virtual machine, persistently storing the resource context of the target virtual machine, and releasing a set proportion of physical resources occupied by the target virtual machine. Wherein, the set proportion is greater than 0 and less than 100%. 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 the set proportion of physical resources occupied by the target virtual machine.

[0218] 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 exemplary description and does not constitute a limitation.

[0219] In this embodiment, a hierarchical hibernation method is adopted. According to the hibernation load of the scheduling domain where the virtual machine to be hibernated is located, a target virtual machine to be switched to a higher hibernation depth can be determined from the virtual machines in the first hibernation 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 hibernation of the scheduling domain to be overloaded, alleviate resource conflicts caused by 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.

[0220] It should be noted that the execution subject 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 subject of steps 901 and 902 can be device A; for another example, the execution subject of step 901 can be device A, and the execution subject of step 902 can be device B; and so on.

[0221] In addition, in some of the processes described in the above embodiments and the accompanying drawings, multiple operations appearing in a specific order are included, but 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, and the sequence numbers of the operations, such as 901, 902, etc., are only used to distinguish between different operations, and the sequence numbers themselves do not represent any execution order. In addition, these processes may include more or fewer operations, and these operations may be executed in sequence or in parallel.

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

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

[0224] 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 to-be-slept virtual machine associated with the virtual machine sleep event; suspending the operation of the processor of the to-be-slept virtual machine to switch the to-be-slept virtual machine from a running state to a shallow sleep state; determining, according to a sleep load condition of a scheduling domain where the to-be-slept virtual machine 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 a shallow sleep state include the to-be-slept virtual machine; persistently storing a resource context of the target virtual machine; and releasing physical resources occupied by the target virtual machine to switch the target virtual machine from a shallow sleep state to a deep sleep state.

[0225] 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 sleep associated with the sleep event in response to the virtual machine sleep event, it is specifically configured to: obtain the identifier of the virtual machine requesting sleep from the virtual machine sleep request; and determine the virtual machine to be sleep according to the identifier of the virtual machine requesting sleep.

[0226] Optionally, when the 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 according to the sleep load of the scheduling domain; and, according to the target number, select the target virtual machine from the virtual machines in the shallow sleep state in the scheduling domain.

[0227] Further, the hibernation 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 that can be used for the virtual machine hibernation in the first host machine in the scheduling domain. The first host machine is the host machine in shallow sleep state deployed in the scheduling domain. Accordingly, when the processor 11b determines the target number of virtual machines that are converted to deep sleep state supported by the current load according to the hibernation load situation of the scheduling domain, it is specifically used to: determine the first number of virtual machines that are converted to deep sleep supported by the current load of each first host machine in the scheduling domain according to the resource usage situation that can be used for the virtual machine hibernation in the first host machine in the scheduling domain; determine the second number of virtual machines that are converted to deep sleep currently supported by the scheduling domain according to the write load situation of the storage service shared by the scheduling domain; the target number includes: the first number and the second number.

[0228] Correspondingly, when processor 11b selects a target virtual machine from virtual machines in a shallow sleep state in the scheduling domain according to a target number, it is specifically used to: select a target virtual machine from virtual machines in a shallow sleep state in the scheduling domain according to a first number and a 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.

[0229] In some embodiments, the processor 11b is further used to: monitor the inventory water level of the virtual machine in the scheduling domain; when the inventory water level of the virtual machine is less than or equal to the set water level threshold, mark the specified virtual machine in the virtual machine in the scheduling domain; and specify the virtual machine that is not switched to deep sleep after being in shallow sleep state. Accordingly, when the processor 11b determines the target virtual machine to be switched to deep sleep state from the virtual machines in 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, it is specifically used to: determine the specified virtual machine from the virtual machines in shallow sleep state in the scheduling domain; and determine the target virtual machine to be switched to deep sleep from the virtual machines in shallow sleep state other than the specified virtual machine in the scheduling domain according to the sleep load of the scheduling domain.

[0230] In some other embodiments, the processor 11b is further used to: monitor the wake-up event for any virtual machine in the shallow sleep state; start timing from when any virtual machine enters the shallow sleep state, and when the timing duration reaches the expiration duration corresponding to any virtual machine, and no wake-up event for any virtual machine is detected, then determine that any virtual machine enters the deep sleep preparation stage. Accordingly, when the 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 according to the sleep load of the scheduling domain where the virtual machine to be hibernated is located, it is specifically used to: determine the virtual machine in the deep sleep preparation stage from the virtual machines in the shallow sleep state in the scheduling domain; and determine 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 of the scheduling domain.

[0231] 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 a set expiration time as the expiration time corresponding to any virtual machine.

[0232] In some embodiments of the present application, the processor 11b is also used to: obtain a predicted wake-up time of a first virtual machine in a deep sleep state; read a resource context of the first virtual machine from a persistent storage medium before the predicted wake-up time arrives; create a first virtual machine on a 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 a processor of the first virtual machine to convert the first virtual machine from a shallow sleep state to a running state.

[0233] 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 which 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.

[0234] Further, 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.

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

[0236] Optionally, when the processor 11b creates the first virtual machine on the target host machine according to 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 according to 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 according to the resource demand; and create the first virtual machine using the target resources; and initialize the first virtual machine according to the resource configuration data in the resource context of the first virtual machine to obtain the first virtual machine.

[0237] In some embodiments, the processor 11b is further used for: 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, reading the resource context of the first virtual machine from the persistent storage medium; creating the first virtual machine on the target host machine according to the resource context of the first virtual machine; and starting the processor of the first virtual machine to convert the first virtual machine from the deep sleep state to the running state.

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

[0239] In some optional embodiments, such as Fig.11b As shown, the computing device may also include optional components such as a communication component 11c and a power component 11d. Fig.11b The components are shown schematically only and do not necessarily include Fig.11b The components shown do not necessarily mean that the computing device can only include Fig.11b Components shown.

[0240] The computing device provided in this embodiment can adopt a hierarchical sleep virtual machine method. 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 mode, the sleep process does not require persistent storage and does not require the release of underlying physical resources. Therefore, the shallow sleep process uses fewer resources and can support multiple virtual machines in concurrent shallow sleep. Furthermore, according to 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 converted from shallow sleep to deep sleep from exceeding the load of the scheduling domain, thereby causing the scheduling domain to be overloaded, alleviate resource conflicts 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.

[0241] In an embodiment of the present application, the memory is used to store a computer program and can be configured to store various other data to support operations on the device where it is located. Among them, 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 (Static Random-Access Memory, SRAM), electrically erasable programmable read only memory (Electrically Erasable Programmable Read Only Memory, EEPROM), erasable programmable read only memory (Electrical Programmable Read Only Memory, EPROM), programmable read only memory (Programmable Read Only Memory, PROM), read only memory (Read Only Memory, ROM), magnetic memory, flash memory, magnetic disk or optical disk.

[0242] 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 field programmable gate array (FPGA), a programmable array logic device (PAL), a general array logic device (GAL), a complex programmable logic device (CPLD) and other programmable devices; or an advanced reduced instruction set (RISC) processor (Advanced RISC Machines, ARM) or a system on chip (SoC), etc., but not limited to this.

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

[0244] 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 touch, slide, and gestures on the touch panel. The touch sensor may 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.

[0245] In an embodiment of the present application, a power supply component is configured to provide power to various components of the device in which it is located. The power supply component 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 component is located.

[0246] 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 (Microphone, MIC), and when the device where the audio component is located is in an operating mode, such as a call mode, a recording mode, and a speech recognition mode, the microphone is configured to receive an external audio signal. The received audio signal may be further stored in a memory or sent via a communication component. In some embodiments, the audio component also includes a speaker for outputting an audio signal. For example, for a device with a language interaction function, voice interaction with a user can be achieved through an audio component.

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

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

[0249] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0250] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0251] 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, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

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

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

[0254] The storage medium of a computer is a readable storage medium, which may also be referred to as a readable medium. The readable storage medium includes permanent and non-permanent, removable and non-removable media that can be used to store information by any method or technology. The information can be a computer-readable instruction, a data structure, a module of a program, 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 technology, CD-ROM, digital versatile disc (DVD) or other optical storage, magnetic cassettes, 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 temporary computer-readable media (transitory media), such as modulated data signals and carrier waves.

[0255] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of further restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the above elements.

[0256] The above contents are only 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 modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should 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; 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.

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