Driver management method, device and equipment

Abstract

The invention provides a driver management method, device and equipment, and the method comprises the steps: receiving a first load request sent by user equipment of a target user, and the first load request is used for requesting to distribute virtual machine resources; a target virtual machine of a target version is selected for the target user from a first resource pool, the first resource pool comprises a plurality of virtual machines, the plurality of virtual machines comprise the target virtual machine, and at least two virtual machines in the plurality of virtual machines correspond to different versions; one virtual machine is obtained by preheating a virtual machine driver of a corresponding version; and allocating the target virtual machine to the target user. According to the method, the target virtual machine can be flexibly selected from the first resource pool based on the target version, and the practicability is higher.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, and in particular to a driver management method, apparatus, and device. Background Technology

[0002] With the rise and development of serverless computing, preheating resource pools face new challenges. To better adapt to this technology, resource pools need to distribute resources at extremely high speeds to support the elastic demands of serverless computing. Specifically, while maintaining extremely rapid and elastic distribution, artificial intelligence (AI) hardware drivers need to be installed simultaneously on the preheated virtual machines. However, currently available single-virtual-machine driver solutions lack flexibility and cannot meet the evolving needs of serverless computing technology. Summary of the Invention

[0003] This application provides a driver management method, apparatus, and device to meet users' needs for multiple driver versions, effectively improve resource utilization, and reduce resource preheating costs.

[0004] Firstly, a cloud service-based driver management method is provided, applicable to a cloud management platform. The cloud management platform manages the infrastructure providing cloud services, which includes facilities located in multiple regions, each region including at least one cloud data center. The cloud service runs on at least one server in at least one cloud data center located in one of the multiple regions. The method includes: receiving a first load request sent by a user device of a target user, the first load request requesting the allocation of virtual machine resources; selecting a target virtual machine of a target version from a first resource pool for the target user, the first resource pool including multiple virtual machines, the multiple virtual machines including the target virtual machine, at least two of the multiple virtual machines corresponding to different versions, one of the virtual machines being pre-warmed using a corresponding version of the virtual machine driver; and allocating the target virtual machine to the target user. Through this method, this embodiment configures different versions of virtual machines in the resource pool during driver management and can allocate pre-warmed virtual machines of suitable versions according to the actual needs of the load request, ensuring that even during a slow driver upgrade process, the user's need for the corresponding version of the virtual machine when creating a load can be met, thereby achieving rapid deployment.

[0005] In one possible implementation, the multiple virtual machines each correspond to the same major version. In this method, it can be understood that at least two virtual machines in the first resource pool correspond to different minor versions of the same major version. By dividing the driver versions into major and minor versions, the use of virtual machine preheating resources can be minimized while better managing driver upgrades for minor versions of virtual machines. Specifically, configuring virtual machines with different minor versions under the same major version in the resource pool allows for more granular allocation of preheated virtual machines with suitable minor versions based on the actual load request requirements, while still adhering to the same major version, thus better meeting the more detailed requirements of users regarding the corresponding virtual machine version when creating loads. In another possible implementation, at least two virtual machines in the multiple virtual machines correspond to different major versions. In this method, it can be understood that at least two virtual machines in the first resource pool correspond to different major versions, while virtual machines under the same major version can correspond to different minor versions or the same minor version. By dividing the driver versions into major and minor versions, the use of virtual machine preheating resources can be minimized while better managing driver upgrades for both major and minor versions of virtual machines. The resource pool is configured with virtual machines of different major versions, which can allocate a more suitable major version according to the actual needs of load requests, and better ensure the user's general needs for virtual local machines when creating loads.

[0006] In one possible implementation, the first load request is further used to indicate the target version. In this method, embodiments of this application provide a way to determine the target version, such as by indicating the target version through a first load request. This enriches the load request functionality and enables the cloud management platform to more quickly determine the virtual machine driver version requirements for different load requests, thereby allocating suitable virtual machines accordingly.

[0007] In one possible implementation, the first load request is further configured to indicate a desired major version, and when the first resource pool includes virtual machines corresponding to the desired major version, the target virtual machine is the virtual machine corresponding to the latest minor version included in the desired major version in the first resource pool; or, when the first load request is further configured to indicate a desired major version, and the first resource pool does not include virtual machines corresponding to the desired major version, the target virtual machine is the virtual machine corresponding to the latest minor version included in the latest major version in the first resource pool. In this method, embodiments of this application provide two scenarios for allocating virtual machines based on the target version indicated by the first load request, thereby enabling better determination of the allocated virtual machine based on the actual virtual machine versions included in the resource pool, combined with the target version indicated by the first load request, resulting in greater adaptability.

[0008] In one possible implementation, the first load request is further configured to indicate a desired minor version, and when the first resource pool includes virtual machines corresponding to the desired minor version, the target virtual machine is the virtual machine in the first resource pool corresponding to the desired minor version; or, the first load request is further configured to indicate a desired minor version, and when the first resource pool does not include virtual machines corresponding to the desired minor version, but includes virtual machines corresponding to the same major version as the desired minor version, the target virtual machine is the virtual machine in the first resource pool corresponding to the latest minor version included in the same major version; or, the first load request is further configured to indicate a desired minor version, and when the first resource pool does not include virtual machines corresponding to the desired minor version, nor does it include virtual machines corresponding to the same major version as the desired minor version, the target virtual machine is the virtual machine in the first resource pool corresponding to the latest minor version included in the latest major version. In this method, embodiments of this application provide two scenarios for virtual machine allocation based on the target version indicated by the first load request, thereby enabling better determination of the allocated virtual machine based on the actual virtual machine versions included in the resource pool, combined with the target version indicated by the first load request, resulting in greater adaptability.

[0009] In one possible implementation, the first load request is further configured to indicate multiple desired versions, each corresponding to a different priority. When the first resource pool includes a virtual machine corresponding to at least one of the multiple desired versions, the target virtual machine is the virtual machine in the first resource pool corresponding to the first desired version, where the first desired version is the desired version with the highest priority among the at least one desired version. Alternatively, the first load request is further configured to indicate multiple desired versions, each corresponding to a different priority. When the first resource pool does not include a virtual machine corresponding to any of the multiple desired versions, the target virtual machine is the virtual machine in the first resource pool corresponding to the latest minor version included in the latest major version. In this method, the embodiments of this application provide two scenarios for allocating virtual machines based on the target version indicated by the first load request, thereby enabling better determination of the allocated virtual machine based on the actual virtual machine versions included in the resource pool, combined with the target version indicated by the first load request, resulting in greater adaptability.

[0010] In one possible implementation, the target virtual machine is the virtual machine corresponding to the latest minor version included in the latest major version of the first resource pool. In this method, embodiments of this application provide a way to determine the target virtual machine, such as fixing the latest version of the virtual machine in the first resource pool as the target virtual machine. By adapting the load request to the latest version of the virtual machine, the needs of version iteration updates can be better met.

[0011] In one possible implementation, the target virtual machine is a virtual machine with the same version number configured for the second load request sent by the target user; the second load request is earlier than the first load request. In this method, embodiments of this application provide a way to determine the target virtual machine, such as determining the virtual machine allocated to the current load request based on other associated load requests. By comprehensively considering the relationships between multiple processes, the virtual machines among associated load requests can be better matched and run more smoothly.

[0012] In one possible implementation, the first load request and the second load request are load requests under the same load task. In this method, embodiments of this application provide a case where the first load request and the second load request are associated. For example, if the two load requests are triggered by the same load task, then the first load request and the second load request are considered to be associated, thereby allowing the associated load requests to be adapted to the same version of the virtual machine.

[0013] In one possible implementation, the first resource pool is a resource pool configured for the target user. In this method, embodiments of this application provide a first resource pool attribute scenario, such as the first resource pool being a resource pool for a specific user. This allows for better driver management of virtual machines in the first resource pool based on user application habits and other information, making the configured first resource pool more aligned with the user's specific needs and effectively improving the user experience.

[0014] In one possible implementation, the method further includes: when there are unallocated virtual machines in the first resource pool for more than a first threshold time, and the resource pool level of the second resource pool is lower than a second threshold, using some or all of the unallocated virtual machines in the first resource pool as virtual machines in the second resource pool, where the second resource pool is a shared resource pool configured for multiple users. In this method, to better utilize resources, this embodiment detects virtual machines in the resource pool during driver management and moves virtual machines from the idle resource pool to the high-demand resource pool, thereby improving processing response and resource utilization, achieving dynamic management.

[0015] In one possible implementation, the method further includes updating the version number of the virtual machines in the first resource pool at set intervals. In this method, the version number of the virtual machines in the first resource pool in this embodiment is not static, but can be dynamically upgraded, making it more adaptable.

[0016] Secondly, a drive management device is provided, which can be applied to a cloud management platform for managing infrastructure providing cloud services. The infrastructure includes facilities located in multiple regions, each region including at least one cloud data center, and cloud services running on at least one server located in at least one cloud data center in one of the multiple regions. The device includes:

[0017] The load management module is used to receive a first load request sent by the user device of the target user, the load request being used to request the allocation of virtual machine resources; the virtual machine management module is used to select a target virtual machine of a target version for the target user from a first resource pool, the first resource pool including multiple virtual machines, at least two of the multiple virtual machines corresponding to different versions, one of the virtual machines being obtained by preheating with a virtual machine driver of the corresponding version; and to allocate the target virtual machine to the target user.

[0018] In one possible implementation, the plurality of virtual machines each correspond to the same major version.

[0019] In one possible implementation, at least two of the plurality of virtual machines correspond to different major versions.

[0020] In one possible implementation, the first load request is also used to indicate the target version.

[0021] In one possible implementation, the first load request is further configured to indicate a desired major version, and when the first resource pool includes virtual machines corresponding to the desired major version, the target virtual machine is the virtual machine in the first resource pool corresponding to the latest minor version included in the desired major version; or, when the first load request is further configured to indicate a desired major version, and the first resource pool does not include virtual machines corresponding to the desired major version, the target virtual machine is the virtual machine in the first resource pool corresponding to the latest minor version included in the latest major version.

[0022] In one possible implementation, the first load request is further configured to indicate a desired minor version, and when the first resource pool includes virtual machines corresponding to the desired minor version, the target virtual machine is a virtual machine in the first resource pool corresponding to the desired minor version; or, the first load request is further configured to indicate a desired minor version, and when the first resource pool does not include virtual machines corresponding to the desired minor version, but includes virtual machines corresponding to the same major version as the desired minor version, the target virtual machine is a virtual machine in the first resource pool corresponding to the latest minor version included in the same major version; or, the first load request is further configured to indicate a desired minor version, and when the first resource pool does not include virtual machines corresponding to the desired minor version, nor does it include virtual machines corresponding to the same major version as the desired minor version, the target virtual machine is a virtual machine in the first resource pool corresponding to the latest minor version included in the latest major version.

[0023] In one possible implementation, the first load request is further configured to indicate multiple expected versions, each corresponding to a different priority. When the first resource pool includes a virtual machine corresponding to at least one of the multiple expected versions, the target virtual machine is a virtual machine in the first resource pool corresponding to a first expected version, and the first expected version is the expected version with the highest priority among the at least one expected version. Alternatively, the first load request is further configured to indicate multiple expected versions, each corresponding to a different priority. When the first resource pool does not include a virtual machine corresponding to any of the multiple expected versions, the target virtual machine is a virtual machine in the first resource pool corresponding to the latest minor version included in the latest major version.

[0024] In one possible implementation, the target virtual machine is the virtual machine corresponding to the latest minor version included in the latest major version of the first resource pool.

[0025] In one possible implementation, the target virtual machine is a virtual machine with the same version number configured for the second load request sent to the target user; the second load request is earlier than the first load request.

[0026] In one possible implementation, the first load request and the second load request are load requests under the same load task.

[0027] In one possible implementation, the first resource pool is a resource pool configured for the target user.

[0028] In one possible implementation, the method further includes: when there are unallocated virtual machines in the first resource pool for a period of time exceeding a first threshold, and the resource pool level of the second resource pool is lower than a second threshold, using some or all of the unallocated virtual machines in the first resource pool as virtual machines in the second resource pool, wherein the second resource pool is a shared resource pool configured for multiple users.

[0029] In one possible implementation, the method further includes updating the version number of the virtual machines in the first resource pool at set intervals.

[0030] The second aspect or any embodiment of the second aspect is a step implementation of the apparatus corresponding to the first aspect or any embodiment of the first aspect. The description in the first aspect or any embodiment of the first aspect is applicable to the second aspect or any embodiment of the second aspect, and will not be repeated here.

[0031] Thirdly, a computing device cluster is provided, including at least one computing device, each computing device including a processor and a memory. The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device, causing the computing device cluster to perform the methods disclosed in the first aspect and any possible implementation thereof.

[0032] Fourthly, this application provides a computer program product containing instructions that, when executed by a cluster of computer devices, cause the cluster of computer devices to implement the method disclosed in the first aspect and any possible implementation thereof.

[0033] Fifthly, this application provides a computer-readable storage medium including computer program instructions that, when executed by a cluster of computing devices, cause the cluster of computing devices to perform the methods disclosed in the first aspect and any possible implementation thereof.

[0034] In a sixth aspect, this application also provides a computer chip connected to a memory, the chip being used to read and execute a software program stored in the memory, and to execute the method provided in the first aspect or any possible implementation thereof. Attached Figure Description

[0035] Figure 1 A schematic diagram of a system architecture provided for an embodiment of this application;

[0036] Figure 2 Another system architecture diagram provided for an embodiment of this application;

[0037] Figure 3 Another system architecture diagram provided for an embodiment of this application;

[0038] Figure 4 Another system architecture diagram provided for an embodiment of this application;

[0039] Figure 5 This is a schematic diagram of a driver management method provided in an embodiment of this application;

[0040] Figure 6 A schematic diagram of a first resource pool provided in an embodiment of this application;

[0041] Figure 7 A schematic diagram of another scenario for a first resource pool provided in an embodiment of this application;

[0042] Figure 8 A schematic diagram of another scenario for a first resource pool provided in an embodiment of this application;

[0043] Figure 9 A schematic diagram of another scenario for a first resource pool provided in an embodiment of this application;

[0044] Figure 10 This application provides a schematic diagram of a virtual machine borrowing scenario between a first resource pool and a second resource pool, as illustrated in an embodiment of the present application.

[0045] Figure 11 A schematic diagram of the structure of an apparatus provided in an embodiment of this application;

[0046] Figure 12 This is a schematic diagram of the structure of a computing device provided in an embodiment of this application;

[0047] Figure 13 This is a schematic diagram of a computing device cluster provided in an embodiment of this application. Detailed Implementation

[0048] This application provides a drive management method, apparatus, and device. Some concepts involved in this application are described below.

[0049] (1) Serverless AI.

[0050] Serverless AI is a technology that combines serverless architecture with AI workloads, integrating three technological trends: serverless cloud computing, service-oriented AI models, and event-driven architecture. The core goal of Serverless AI is to allow developers to avoid managing the underlying infrastructure and dynamically allocate resources through the cloud platform, thereby enabling them to better focus on the development, deployment, and operation of AI models.

[0051] (2) Resource pool.

[0052] A resource pool consisting of physical server clusters is used to provide underlying resources for AI services, such as computing, storage, and network resources.

[0053] (3) Virtual machine.

[0054] The virtual machine is the smallest dynamically allocated computing unit in the resource pool, used to deploy AI services. In other words, the virtual machine is the carrier that runs the AI ​​model.

[0055] (4) Driver version and version upgrade.

[0056] Driver version refers to the version identifier of the interface program that communicates between hardware devices (such as graphics processing units (GPUs), network cards, and printers) and the operating system. It is used for hardware resource scheduling, bug fixing, and performance optimization. Major version upgrades are often used to address accumulated architectural defects, such as upgrading from version V1.0 to V2.0, which involves a complete change. Generally, major version upgrades require code adaptation and data migration, resulting in high overall upgrade costs. Minor version upgrades, on the other hand, are often used to optimize specific areas, such as upgrading from V2.1 to V2.1.1. These are backward compatibility changes and can usually be directly replaced, resulting in lower overall upgrade costs.

[0057] (5) Warm pool.

[0058] The preheating resource pool is a core optimization mechanism in cloud computing designed to address cold start latency in serverless services. It preloads new versions of models into memory / GPUs before traffic arrives, avoiding cold start delays. In other words, the essence of the preheating resource pool is to pre-create and initialize a batch of "standby" computing instances. When a request arrives, these instances can be directly invoked to handle tasks, skipping resource allocation and initialization, achieving millisecond-level response times. For example, during version releases, preheating ensures that the new version of the virtual machine responds quickly to requests, which is especially crucial for large AI models (such as LLMs).

[0059] It should be noted that the preheating resource pool in this application embodiment is not a traditional resource reservation, but a smart preloading. That is, compared with the permanent resource pool with fixed expenditure, the preheating resource pool is flexible and time-sensitive.

[0060] (6) Load and load balancer.

[0061] In this embodiment, the load can be understood as the traffic generated by user requests for AI services. The load balancer can be understood as distributing traffic to service instances on different virtual machines. When the load is too high, the resource pool automatically expands, for example, by adding new virtual machines. However, newly added virtual machines need to be warmed up before they can receive traffic; otherwise, response latency will spike. Therefore, the load balancer needs to be version-aware and implement canary releases, directing some traffic to the new version.

[0062] (7) Tenant resource pool.

[0063] In this embodiment, the tenant resource pool is used to isolate a dedicated set of physical resources (central processing unit (CPU) / memory / GPU / storage) for a specific tenant (enterprise / project group) to ensure its resource exclusivity and service level agreement (SLA).

[0064] (8) Public resource pool.

[0065] In this embodiment, the cloud platform is a set of dynamic resources shared by all tenants and allocated on demand.

[0066] (9) Water level in the resource pool.

[0067] The resource pool level refers to the real-time percentage of resource consumption in the resource pool, and is a core indicator for capacity management.

[0068] The resource pool level satisfies the following formula: Resource pool level = Allocated resources / Total available resources × 100%.

[0069] In the description of the embodiments of this application, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, a feature defined with "first" and "second" may explicitly or implicitly include one or more of that feature.

[0070] It should be understood that in the embodiments of this application, "at least one" means one or more, and "more than one" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, a and b, a and c, b and c, or a, b, and c, where a, b, and c can be single or multiple.

[0071] The preceding text introduced some terms and concepts involved in the embodiments of this application. The following text introduces the technical solutions involved in the embodiments of this application.

[0072] This application provides a driver management method, apparatus, and device to address the lack of flexibility in current virtual machine driver solutions. Specifically, during driver management, this application configures different versions of virtual machines in a resource pool and can allocate pre-warmed virtual machines of suitable versions according to the actual needs of load requests. This ensures that even during slow driver upgrade processes, the user's need for the corresponding version of virtual machine when creating a load can be met, thereby achieving rapid deployment. The method and apparatus are based on the same inventive concept. Since the principles by which the method and apparatus solve the problem are similar, their implementations can be mutually referenced, and repeated details will not be elaborated further.

[0073] Please refer to Figure 1 This is a schematic diagram illustrating an application scenario of the method provided in this application embodiment. The scenario may include a cloud management platform 100, which manages multiple cloud data centers set up by cloud vendors in different regions. The cloud management platform can provide interfaces related to public cloud services, such as web pages or application programming interfaces (APIs), for users to remotely access public cloud services. Users can log in to the cloud management platform on the public cloud access page using a pre-registered account and password. After successful login, users can select and purchase public cloud services provided by the cloud data center in the region they have selected, such as object storage services, virtual machine services, container services, or the driver management service involved in this application embodiment.

[0074] The cloud management platform 100 manages the infrastructure providing cloud services. This infrastructure includes facilities located in multiple regions, each region comprising at least one cloud data center. Cloud services run on at least one server in at least one cloud data center located in one of these regions. A region refers to the geographical location of a cloud service. Cloud services can be categorized by region based on geographical location and network latency. Cloud services within the same region use infrastructure located in the same geographical area. For example, if a cloud service selects South China as its region, then it will use cloud data centers in the South China region to provide that cloud service. A region may include one or more availability zones (AZs). An AZ is a collection of one or more cloud data centers with independent water and electricity supply. Within an availability zone, computing, network, and storage resources are logically further divided into multiple clusters. Multiple availability zones within a region are connected via high-speed fiber optic cables to meet users' needs for building high-availability systems across AZs.

[0075] See Figure 1 As shown, the cloud management platform 100 can provide a client 400, which can be used to display the relevant interface of the driver management service. Users 500 can configure and view the results of the driver management service of the application system 200 through this interface. For example, users can configure service requirements for the driver management service and the system configuration information of the application system 200 through the driver management service interface. Additionally, users can view the driver management results through the driver management service interface. Optionally, the client 400 can be implemented through a terminal device or a functional module (such as a webpage or application) within the terminal device. For example, the terminal device can be a personal computer (PC), tablet computer (PAD), or mobile phone, etc., with no specific limitations.

[0076] For example, Figure 1 In the scenario shown, user 500 can access cloud management platform 100 via client 400 through internet 300. User 500 can purchase device driver management services for application system 200 on cloud management platform 100. User 500 can input / select relevant configuration information and service requirements of application system 200 on cloud management platform 100 through client 400. Cloud management platform can run driver management services for application system 200 according to user 500's relevant configuration information and service requirements. Figure 1 As shown: Taking cloud data center A-region 1 as an example, user 500 inputs the relevant configuration information and service requirements of application system 200 through cloud management platform 100. User 500's application system 200 will then be managed and driven by cloud data center A in region 1. Specifically, application system 200 accesses cloud data center A in region 1 via the Internet through cloud management platform 100. It should be noted that the cloud data center in which region service user 500's application system 200 is assigned can be chosen by user 500 through cloud management platform 100, or user 500 can choose no cloud data center, and cloud management platform 100 can randomly assign a cloud data center to service application system 200. There is no limitation on the allocation method of cloud data center service for application system 200.

[0077] The cloud management platform 100, also known as a driver management platform or driver management system, is used to provide driver management services for the application system 200. Optionally, the driver management service can be a service that performs driver management for the application system 200.

[0078] In some embodiments, the cloud management platform 100 may be independent of the application system 200, meaning that the resources relied upon by the cloud management platform 100 and the application system 200 are unrelated. The cloud management platform 100 can obtain the data required for driver management of the application system 200, such as the application system 200's runtime data, to perform driver management on the application system 200 based on this data. Optionally, the cloud management platform 100 may be a dedicated cloud management platform for the application system 200, or it may be a shared cloud management platform for multiple application systems 200, meaning that the cloud management platform 100 can provide driver management services to multiple application systems 200.

[0079] In some embodiments, the cloud management platform 100 and the application system 200 may belong to the same system, meaning they may rely on the same system resources. For example, the cloud management platform 100 may be part of the application system 200, or vice versa. For instance, in this embodiment, the cloud management platform 100 may directly obtain data required for driver management in the application system 200, such as the application system 200's runtime data, to allocate virtual machines to the application system 200 based on this data.

[0080] In this embodiment, the cloud management platform 100 can be implemented in software or hardware. For example, in a software implementation, the cloud management platform 100 may include code running on computing instances. These computing instances can be at least one of physical hosts (computing devices), virtual machines, containers, etc. Optionally, there may be one or more computing devices. For example, the cloud management platform 100 may include code running on multiple hosts / virtual machines / containers. As another example, in a hardware implementation, the cloud management platform 100 may include at least one computing device, such as a server. Alternatively, the cloud management platform 100 may be implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof. The computing devices included in the cloud management platform 100 can be referred to as driver management devices.

[0081] Application system 200 provides the infrastructure required for applications (or services), and this infrastructure is located in at least one region, where each region includes at least one cloud data center (or database). In other words, application system 200 provides backend services for applications (or services). The application system 200 involved in the embodiments of this application can adopt any possible architectural topology.

[0082] As a possible example, please refer to Figure 2 This is a schematic diagram of the topology of the application system 200 provided in an embodiment of this application. (See reference...) Figure 2 The architecture topology of the application system 200 may include a combination of resource vertical topology and application horizontal topology. Resource vertical topology can be understood as the dependencies between system resources; that is, it is an architecture topology divided according to the hierarchy of system resources. Application horizontal topology can be understood as an architecture topology divided according to the hierarchy of application programs (or components).

[0083] According to the resource vertical topology, application system 200 may include the following:

[0084] (1) Region. A region is a collection of geographically located data centers. Regions help users distribute system resources across different geographical locations to improve disaster recovery capabilities and reduce latency. For example, for an application system 200 with multiple regions, the region of the application system 200 can refer to the geographical location of the system resources that the application system 200 provides services to. Backend services within the same region use infrastructure located in the same geographical location. For example, if a service within an application system 200 selects the South China region as its region, then the system resources of the South China region will be used to provide the service.

[0085] (2) Availability Zone (AZ): Each zone can contain one or more AZs. Each AZ is a cluster of one or more data centers with independent power, network, and cooling systems to ensure high availability and fault tolerance. By distributing applications across different AZs, users can achieve greater redundancy and reliability.

[0086] (3) Host Groups: Each AZ may include one or more host groups. Each host group is a collection of physical machines, typically used for centralized management and configuration to simplify resource deployment and maintenance.

[0087] (3) Physical machine (PM): Each host group includes one or more physical machines. For example, a physical machine can be an actual hardware server. Unlike virtual machines, a physical machine does not have a virtualization layer but runs the operating system and applications directly. Physical machines can provide complete hardware resources and provide direct hardware access and control.

[0088] (4) Virtual Machine (VM): A physical machine may contain one or more VMs. A VM is a virtualized instance created and run using virtualization technology, allowing multiple VMs to share the same hardware resources. Each VM has its own independent operating system and application environment. One or more containers can run on each VM, such as... Figure 2 The application container shown can be used to run the application corresponding to application system 200.

[0089] (5) Bare Metal Server (BMS): Also known as a single-tenant physical server, a BMS consists of one or more independent servers. It is a computing service that combines the performance of an elastic cloud server and a physical machine. It can provide enterprises with dedicated physical servers in the cloud, offering excellent computing performance and data security for core databases, critical application systems, high-performance computing, big data, and other businesses. Each BMS can run one or more containers, such as... Figure 2 The database container shown can be used to implement the database-related functions corresponding to application system 200.

[0090] According to the application-level topology, application system 200 may include the following:

[0091] (1) Application services: An application system 200 may provide one or more application services. For example, if the application system 200 is a financial system, an application service may be a deposit service or a lending service, etc.; or, if the application system 200 is an education system, an application service may be a course selection service or an online course service, etc.; or, if the application system 200 is a food delivery system, an application service may be a food delivery service or an errand service, etc., without any restrictions.

[0092] (2) Microservices, also known as service groups, middleware, etc., are a combination of one or more microservices to implement an application's business logic. Microservices are essentially a software architecture pattern where application logic is broken down into small, independently deployable services, each responsible for specific business functions. Each microservice typically has its own database and business logic, and can be developed, deployed, and scaled independently.

[0093] (3) Components, also known as units, business units, service units, or microservice units, can be one or more components. A component usually refers to a modular part within a single application, and a component can be understood as a function under a microservice.

[0094] (4) Basic modules: A component may include one or more basic functional modules. A basic module can be understood as the smallest functional unit in an application system 200.

[0095] (5) Containers. Containers are a lightweight, portable virtualization technology used to package and run applications and their dependencies. Containers provide a consistent runtime environment, allowing applications to run consistently across different systems and environments. For example... Figure 2 As shown, in this embodiment, containers can be divided into database containers and application containers based on their different functions. Database containers can be used to implement database-related functions corresponding to application system 200, and different database containers can be divided according to the different types of data they store. For example, database container A is used to store and detect data for users 1-100, and database container B is used to store and detect data for users 101-200. Application containers can be used to run applications corresponding to application system 200; different application containers can run the same or different applications.

[0096] The above-mentioned A including B can be understood as B being a component of A, or A's implementation depending on B, or B's implementation depending on A, or B being deployed on A, etc.

[0097] See Figure 3 The diagram shown is an architectural schematic of a driver management system 300 provided in an embodiment of this application. The driver management system may include a user device 310, a virtual machine manager 320, a first resource pool 330, a second resource pool 340, and virtual machines 350, etc.

[0098] User device 310 refers to the device used to request, access, or operate a virtual machine.

[0099] The user equipment involved in the embodiments of this application may be referred to as a terminal device, terminal, mobile station (MS), mobile terminal (MT), etc. Currently, examples of terminal devices include: mobile phones, tablets, laptops, PDAs, mobile internet devices (MIDs), wearable devices, virtual reality (VR) devices, augmented reality (AR) devices, wireless terminals in industrial control, wireless terminals in vehicle-to-everything (V2X) communication, wireless terminals in vehicle-to-everything (V2X) communication, intelligent vehicles, in-vehicle infotainment systems (or onboard transmitters) (T-boxes), and machine-to-machine / machine-type communication. Wireless terminals in communications (M2M / MTC) and Internet of Things (IoT) applications include communication devices, M2M / MTC terminal devices, and IoT terminal devices. For example, terminal devices can be in-vehicle equipment, vehicle-mounted modules, vehicles, on-board units (OBUs), roadside units (RSUs), T-boxes, chips, or systems-on-chips (SoCs), which can be installed in vehicles, OBUs, RSUs, or T-boxes. Wireless terminals in industrial control can be cameras, robots, etc. Wireless terminals in smart homes can be televisions, air conditioners, robot vacuums, speakers, set-top boxes, etc.Terminal devices can also be V2X devices, such as smart cars, digital cars, unmanned cars, driverless cars, pilotless cars, autonomous cars, pure electric vehicles (EVs), hybrid electric vehicles (HEVs), range-extended electric vehicles (REEVs), plug-in hybrid electric vehicles (PHEVs), new energy vehicles, and roadside units (RSUs). Terminal devices can also be devices used in device-to-device (D2D) communication, such as electricity meters and water meters.

[0100] Virtual Machine Manager 320 is used to create, run, and manage all virtual machines.

[0101] In practical applications, the Virtual Machine Manager 320 can virtualize resources, such as pooling the CPU, memory, storage, and network resources of a physical server and allocating them to each virtual machine as needed; it can also perform lifecycle management, such as performing operations such as starting, shutting down, pausing, migrating, and taking snapshots of virtual machines; and it can also ensure the operational isolation and security between different virtual machines.

[0102] The first resource pool 330 and the second resource pool 340 refer to resource pools used for maintaining virtual machine resources. It is understood that the first and second resource pools are merely examples in this application embodiment, and other resource pools may also be included.

[0103] In practical applications, the first resource pool and the second resource pool can have different functional attributes. The following example illustrates this, with the first resource pool being a private resource pool and the second resource pool being a public resource pool. In other implementation scenarios, the first resource pool can also be a public resource pool; this application does not specifically limit this.

[0104] A user can be associated with one or more primary resource pools. These primary resource pools are generally only accessible to the associated user. The primary resource pool can also be called a pre-warmed resource pool. By pre-creating and maintaining a virtual machine resource pool for users, the delivery time when users request resources can be greatly shortened, achieving resource allocation at the second or minute level, thereby improving user experience and resource utilization.

[0105] Multiple users can share a second resource pool, which reflects the total resource capacity of the entire system. The second resource pool can include a collection of physical hardware resources (CPU, memory, storage clusters, network) that are not allocated to any specific virtual machine. When the first resource pool needs to be expanded, resources can be allocated from the second resource pool to create new virtual machines.

[0106] Virtual machine 350 refers to the basic computing unit in the driver management architecture, the service entity ultimately delivered to the user during the driver management process. Each virtual machine can contain virtualized CPU, memory, disk, and network resources to run a complete guest operating system (such as Windows or Linux) and applications.

[0107] The driver management system can include virtual machines in various states, such as virtual machines in a pre-warmed state, virtual machines in an allocated state, and virtual machines in a template state. A pre-warmed virtual machine refers to a virtual machine that has been created, started, and is running in the lowest power mode (or hibernation state), waiting for user connections. Pre-warmed virtual machines are also the main type of virtual machines in the resource pool. A allocated virtual machine refers to a virtual machine that has been assigned to a specific user and is running normally and working. A template virtual machine refers to a clean, unallocated golden image (template) used to create new pre-warmed virtual machines in batches.

[0108] In the above Figure 3 Based on the above, the drive management system 300 provided in this application embodiment may further include, as shown below: Figure 4 The load manager 360, user request manager 370, and load monitoring module 380 shown are among them.

[0109] Load Manager 360 is used to perform resource coordination across the entire system.

[0110] In practical applications, load managers can manage pool capacity, such as continuously monitoring the size of the resource pool and determining when to add or remove virtual machines from the resource pool based on preset resource pool adjustment strategies. Load managers can also create and reclaim resources, such as instructing virtual machine managers to obtain resources from the public resource pool and create new virtual machines in batches based on the golden image, preheating them before adding them to the private resource pool, and deciding whether to reset and reclaim virtual machines to the preheating resource pool or destroy them and release their resources back to the public resource pool when users release virtual machines. Load managers can also achieve intelligent placement, such as determining which physical server newly created virtual machines should run on to balance the load and avoid hotspots.

[0111] In this embodiment, the load manager can specifically be used to receive a load creation request sent by a user, parse the load request, determine the virtual machine information that the load request needs to configure, and send the virtual machine information that needs to be configured to the virtual machine manager, so that the virtual machine manager can create an adapted virtual machine according to the virtual machine information and distribute it to the corresponding user.

[0112] User Request Manager 370 refers to the system's front-end entry point and business logic control center.

[0113] In practical applications, the user request manager can perform authentication and authorization, such as verifying user identity and determining whether they are authorized to request resources and what type of resources they can request. The user request manager can also handle requests, such as receiving user resource requests. Furthermore, it can perform resource matching, such as querying a private resource pool to find a virtual machine that meets the user's requirements and is in a preheated state. The user request manager can also act as a delivery and connection agent, such as assigning the matched virtual machine to the corresponding user and providing connection information (Internet Protocol (IP) address, connection token, etc.) to the user device. Finally, the user request manager can perform status tracking, such as maintaining a database to record which virtual machine was assigned to which user.

[0114] This application embodiment can preset some operating indicators, and determine whether expansion is needed based on the preset operating indicators, thereby triggering subsequent virtual machine allocation requests, etc.

[0115] The load monitoring module 380 provides data for the load manager to make decisions.

[0116] In practical applications, the load monitoring module can perform performance monitoring, such as collecting real-time performance metrics of physical servers and virtual machines, including CPU utilization, memory usage, disk input / output (I / O), and network traffic. It can also perform capacity monitoring, such as monitoring the remaining capacity of public and private resource pools. Furthermore, it can perform demand forecasting, such as predicting future resource needs based on historical usage data and trend analysis, and informing the load manager in advance to perform preheating operations. Finally, it can perform health checks, such as monitoring the health status of virtual machines and physical servers.

[0117] The functions of the above-mentioned modules can be further divided into different sub-modules, or the functions of multiple modules in the above-mentioned modules can be merged into one block. For example, the load monitoring module can be a functional module in the load manager. This application embodiment does not impose specific limitations on this.

[0118] The driver management method provided in this application will now be described with reference to the accompanying drawings. It is understood that in this application, terminal devices and / or network devices may execute some or all of the steps described herein. These steps are merely examples, and this application may also execute other steps or variations thereof. Furthermore, the steps may be executed in different orders as presented in this application, and it is not necessary to execute all the steps described herein.

[0119] refer to Figure 5 This is a flowchart illustrating a driver management method provided in an embodiment of this application. This method can be applied to the above-mentioned... Figures 1-4 In any system architecture, such as the embodiments of this application, it can be applied to driver management in scenarios including performance degradation of cloud computing microservices and order delays in financial transaction systems. The method may include the following steps:

[0120] Step 501: The cloud server receives a first load request sent by the target user's user device. The first load request is used to request the allocation of virtual machine resources.

[0121] The first load request refers to an instruction or operation initiated by system management components, such as the load manager or user request manager, aimed at adjusting the resource pool status and capacity, and allocating virtual resources.

[0122] Regarding the sending of the first load request, there are several possible sending scenarios in practical applications. Here are three possible sending scenarios.

[0123] Sending scenario 1: User login and session initiation.

[0124] The first scenario refers to a user initiating a connection request through client software or a browser. For example, taking a user logging into a virtual desktop infrastructure as an example, suppose a user opens the VMware Horizon client on their computer, enters their account and password to log in, the cloud management platform receives the request, confirms that they have the right to use a "Windows 10 Design Desktop", then finds a virtual machine that meets the requirements and is in a ready state from the private resource pool (preheated resource pool), assigns the virtual machine to Zhang San, sends the connection information back to the client, and the user sees their desktop and starts working within seconds.

[0125] Sending scenario 2: Task triggered or on-demand calculation.

[0126] The second scenario refers to a user triggering a task via API calls, form submissions, or button clicks. For example, consider a user submitting a task that needs to run in a new environment. Suppose a user pushes new code to a Git version control system repository, triggering a build task on the continuous integration tool Jenkins. The user's device (Jenkins, as the "user") initiates a virtual machine allocation request to the cloud management platform via API, requesting a "build machine with an Ubuntu operating system running Java programming language and Maven project build tools." The cloud management platform then allocates a VM to Jenkins from its pool. Jenkins executes the build and test tasks on this VM. After the tasks are completed, the VM is released. The VM is reclaimed and reset by the system, ready for future use.

[0127] Scenario 3: Expanding existing applications.

[0128] Scenario 3 refers to situations where existing applications are under excessive load, requiring the addition of new virtual machines to distribute traffic. For example, assuming a monitoring system detects high load and an administrator or automated script initiates a scaling request, suppose an e-commerce website is holding a flash sale, and the load monitor detects that the CPU utilization of the World Wide Web (Web) server cluster consistently exceeds 80%. The website's automated scaling script (as the "user") initiates a virtual machine allocation request via the cloud platform API according to a pre-defined strategy: "Please allocate 2 more virtual machines for the 'Web server image'." The user request manager allocates 2 virtual machines from the preheated resource pool and registers them with the load balancer. User traffic is automatically distributed to the new servers, alleviating the pressure.

[0129] The embodiments of this application will continue below. Figure 5 The content shown will be introduced.

[0130] Step 502: The cloud server selects a target virtual machine of the target version for the target user from the first resource pool.

[0131] The first resource pool includes multiple virtual machines, including the target virtual machine. At least two of the multiple virtual machines correspond to different versions, and one of the virtual machines is obtained by preheating with the corresponding version of the virtual machine driver.

[0132] A version refers to an identifier consisting of a set of numbers and / or letters, used to identify a specific state of software, files, documents, or products during their development lifecycle, and to distinguish different iterations of release. In this application's embodiments, the virtual machine version can refer to the identifier corresponding to different iterations of the virtual machine. Versions can specifically be divided into major versions and minor versions.

[0133] Major versions, also known as primary versions, refer to architectural, significant functional innovations and major improvements. They typically introduce new features, new management interfaces, or major API changes. In version numbers, the number before the decimal point is usually changed (e.g., from 7.0 to 8.0).

[0134] Minor versions, also known as minor version numbers, update packages, or patch sets, refer to incremental feature enhancements, the introduction of critical new features, bug fixes, security patches, and hardware support updates. In version numbering, the decimal places are typically changed (e.g., from 7.1 to 7.2).

[0135] The target user can refer to the user who needs to allocate virtual machines. In this embodiment, the target user can be a user authorized to use the driver management method of this application to drive virtual machines. One target user can correspond to at least one user device; in this embodiment, the user device of the target user can refer to the user device on which the target user needs to allocate virtual machines.

[0136] The target version can refer to the virtual machine version that meets the virtual machine requirements of the target user, or the virtual machine version that meets the requirements of the user device. For example, when all user devices belonging to the target user have the same requirements, the target version refers to the virtual machine version that meets the requirements of the target user, that is, the target version corresponding to the user devices belonging to the target user is the same; as another example, when the target user belongs to multiple user devices, and the virtual machine requirements of the multiple user devices are different, the target version can refer to the virtual machine version that meets the requirements of the user devices, that is, the target version corresponding to different user devices belonging to the target user can be different.

[0137] The target virtual machine refers to the virtual machine selected from the first resource pool based on the target version. The first resource pool can be called the preheating resource pool.

[0138] In some implementation scenarios, the first resource pool can be a private resource pool or a tenant resource pool, such as setting up different first resource pools for different target users or different user devices. For example, suppose a first resource pool A is set up for target user A, and target user A includes user devices 1 to 4. Then user devices 1 to 4 can jointly use the first resource pool A. As another example, suppose target user A includes user devices 1 to 3. A first resource pool A is set up for user device 1, a first resource pool B is set up for user device 2, and a first resource pool C is set up for user device 3. Then, different user devices use their respective first resource pools.

[0139] In other implementation scenarios, the first resource pool can also be a public resource pool or a shared resource pool, such as a resource pool that different users can use.

[0140] Regarding the multiple virtual machines included in the first resource pool, there are several possible scenarios in practical applications. Here are two examples of virtual machine scenarios included in the first resource pool.

[0141] This includes scenario one, where the first resource pool contains multiple virtual machines that correspond to the same major version.

[0142] The first scenario refers to a first resource pool where all virtual machines belong to the same major version. Different virtual machines within the same major version can correspond to different minor versions. In this case, the first resource pool can be called a resource pool configured with a fixed major version. For example, consider a resource pool configured with a fixed major version... Figure 6 As shown, the first resource pool A is configured with a fixed major version 7.0. The first resource pool A includes virtual machines 1 to 4. Therefore, the major version number of all virtual machines 1 to 4 included in the first resource pool A is 7.0. However, under the same major version 7.0, different virtual machines can have different minor versions. For example, the version corresponding to virtual machine 1 is 7.1, the version corresponding to virtual machine 2 is 7.2, the version corresponding to virtual machine 3 is 7.3, and the version corresponding to virtual machine 4 is 7.2.

[0143] Version management can be implemented for scenario one, such as during version upgrades, where version management can be performed under the corresponding fixed major version. For example, continuing with the above... Figure 6 Taking this as an example, when upgrading a version, if a new virtual machine version 7.4 is released, then minor versions of the virtual machines in the first resource pool can be updated in a rolling manner. For example, if the earliest released version 7.1 virtual machine is updated to version 7.4, the virtual machines included in the first resource pool A after the update and upgrade will be: virtual machine 1 with version 7.4, virtual machine 2 with version 7.2, virtual machine 3 with version 7.3, and virtual machine 4 with version 7.2.

[0144] This includes scenario two, where at least two of the multiple virtual machines in the first resource pool correspond to different major versions.

[0145] The second scenario could refer to the first resource pool containing at least two major version numbers of virtual machines. In some implementation scenarios, the first resource pool may also include virtual machines corresponding to one or more minor version numbers under each major version number.

[0146] In the first scenario, the first resource pool can include multiple virtual machines with a fixed major version. In this case, the first resource pool can also be referred to as the resource pool configured with a fixed major version. For example, suppose... Figure 7As shown, the first resource pool A is configured with two fixed major versions, 7.0 and 8.0. The first resource pool A includes virtual machines 1 to 7. Virtual machines 1 to 4 all correspond to major version 7.0. Under the same major version 7.0, different virtual machines can correspond to different minor versions. For example, virtual machine 1 corresponds to version 7.1, virtual machine 2 corresponds to version 7.2, virtual machine 3 corresponds to version 7.3, and virtual machine 4 corresponds to version 7.2. Virtual machines 5 to 7 all correspond to major version 8.0. Under the same major version 8.0, different virtual machines can correspond to different minor versions. For example, virtual machine 5 corresponds to version 8.1, virtual machine 6 corresponds to version 8.2, and virtual machine 7 corresponds to version 8.3.

[0147] For the first scenario, version management can be implemented, such as during version upgrades, by performing version management within the corresponding fixed major version. For example, continuing with the above... Figure 7 Taking this as an example, when upgrading a version, if a new virtual machine version 7.4 is released, the minor versions of the virtual machines under the major version 7.0 in the first resource pool B can be updated on a rolling basis, while the virtual machines under other major versions remain unchanged. For example, if the earliest released version 7.1 virtual machine is updated to version 7.4, the virtual machines included in the first resource pool B after the update will be: virtual machine 1 with version 7.4, virtual machine 2 with version 7.2, virtual machine 3 with version 7.3, virtual machine 4 with version 7.2, virtual machine 5 with version 8.1, virtual machine 6 with version 8.2, and virtual machine 7 with version 8.3.

[0148] In the second scenario, the first resource pool can include multiple major version virtual machines; however, it is not required that all virtual machines included in the first resource pool correspond to a major version. For example, suppose... Figure 8 As shown, at the first moment, the first resource pool A includes virtual machines 1 to 5, where virtual machines 1 to 3 all correspond to major version 7.0, and virtual machines 4 to 5 all correspond to major version 8.0; while at the second moment, the first resource pool A includes virtual machines 1 to 5, where virtual machine 1 corresponds to major version 9.0, virtual machines 2 and 3 correspond to major version 7.0, and virtual machines 4 and 5 correspond to major version 8.0, that is, the major versions of the virtual machines included in the first resource pool B are not fixed.

[0149] For this second scenario, version management can be implemented. For example, during a version upgrade, version management can be performed on the overall version corresponding to the first resource pool. Figure 9Taking this as an example, assume that the first resource pool C includes virtual machines 1 to 5. The major version corresponding to virtual machines 1 to 3 is 7.0, such as version 7.1 corresponding to virtual machine 1, version 7.2 corresponding to virtual machine 2, and version 7.3 corresponding to virtual machine 3. The major version corresponding to virtual machines 4 to 5 is 8.0, such as version 8.1 corresponding to virtual machine 4, and version 8.2 corresponding to virtual machine 5.

[0150] When performing a version upgrade, if a new virtual machine version 7.4 is released, the minor versions of virtual machines under the major version 7.0 in the first resource pool C can be rolled over for updates, while virtual machines under other major versions remain unchanged. For example, if the earliest released virtual machine version 7.1 is updated to version 7.4, the virtual machines included in the first resource pool C after the update will be: virtual machine 1 with version 7.4, virtual machine 2 with version 7.2, virtual machine 3 with version 7.3, virtual machine 4 with version 8.1, and virtual machine 5 with version 8.2.

[0151] For example, continuing with Figure 9 Taking this as an example, when upgrading a version, if a new virtual machine version 9.1 is released, a rolling update can be performed on the overall major version in the first resource pool C. For example, if the virtual machine corresponding to the earliest major version 7.0 is updated to the virtual machine version 9.1, the virtual machines included in the first resource pool C after the update and upgrade will be as follows: virtual machines 1 to 3 correspond to version 9.1, virtual machine 4 corresponds to version 8.1, and virtual machine 5 corresponds to version 8.2.

[0152] For example, continuing with Figure 9 Taking this as an example, when upgrading a version, if a new virtual machine version 9.1 is released, a rolling update can be performed on the overall minor versions of the virtual machines in the first resource pool C. For example, if the earliest released version 7.1 virtual machine is updated to version 9.1, the virtual machines included in the first resource pool C after the update will be: virtual machine 1 with version 9.1, virtual machine 2 with version 7.2, virtual machine 3 with version 7.3, virtual machine 4 with version 8.1, and virtual machine 5 with version 8.2.

[0153] Understandably, the above example only introduces virtual machine version upgrades and does not limit the number of virtual machines that can be updated. In the actual execution of the first resource pool management process, the virtual machine data in the first resource pool can also be updated, which is not limited here.

[0154] After introducing the virtual machine versions and update status included in the first resource pool, the following section describes how to select the target version of the target virtual machine for the target user. Regarding the method of determining the target version, there are several possible scenarios in practical applications; three methods are listed here.

[0155] Method 1 for determining the target version: Determine the target version based on the first load.

[0156] In this application embodiment, the first load request sent by the user equipment to the cloud server may carry or indicate information about the target version. The information in the first load request indicating the target version is not limited to the following:

[0157] Message 1: The first load request directly indicates the target version.

[0158] When determining the target virtual machine based on this information 1, after receiving the first load balancing request from the user device, the cloud server can directly select a virtual machine with the target version from the first resource pool corresponding to the user device as the target virtual machine, according to the target version indicated by the first load balancing request. For example, assuming the first load balancing request indicates a target version of 7.3, and the first resource pool includes virtual machines 1 to 4, where virtual machine 1 corresponds to version 7.1, virtual machine 2 corresponds to version 8.1, virtual machine 3 corresponds to version 7.3, and virtual machine 4 corresponds to version 8.2, then virtual machine 3 is determined as the target virtual machine. If the first resource pool does not contain a virtual machine with the target version indicated by the first load balancing request, the cloud server can report a virtual machine allocation failure to the user device and resend the first load balancing request; or, the cloud server can use a preset default virtual machine allocation scheme, such as defaulting to using the latest minor version of the latest major version in the first resource pool as the target virtual machine.

[0159] Message 2: The first load request indicates a major version is expected.

[0160] When a cloud server receives a first load request from a user device, and selects a target virtual machine from the first resource pool corresponding to the user device based on the expected version indicated by the first load request, there are multiple ways to determine the target virtual machine in practical applications, based on the virtual machines included in the first resource pool. Two methods for determining the target virtual machine are listed here.

[0161] (1) Determine the target virtual machine in method 1: When the first load request indicates the expected major version and the first resource pool includes virtual machines with the corresponding expected major version, the target virtual machine is the virtual machine corresponding to the latest minor version included in the expected major version in the first resource pool.

[0162] For example, suppose the first load request indicates that the major version is 8.0, and the first resource pool includes virtual machines 1 to 4. Virtual machine 1 corresponds to version 7.1, virtual machine 2 corresponds to version 8.1, virtual machine 3 corresponds to version 7.3, and virtual machine 4 corresponds to version 8.2. Among them, the virtual machines under the major version 8.0 include virtual machine 2 and virtual machine 4, and virtual machine 4 is the latest minor version. Then virtual machine 4 is determined as the target virtual machine.

[0163] (2) Method 2 for determining the target virtual machine: When the first load request indicates the expected major version and the first resource pool does not include the virtual machine corresponding to the expected major version, the target virtual machine is the virtual machine corresponding to the latest minor version included in the latest major version in the first resource pool.

[0164] For example, suppose the first load request indicates that the major version is 7.0, and the first resource pool includes virtual machines 1 to 4. Virtual machine 1 corresponds to version 8.1, virtual machine 2 corresponds to version 8.1, virtual machine 3 corresponds to version 8.2, and virtual machine 4 corresponds to version 8.3. However, the first resource pool does not include virtual machines under major version 7.0. In this case, virtual machine 4 is determined as the target virtual machine.

[0165] Message 3: The first load request indicates a minor version is expected.

[0166] When a cloud server receives a first load request from a user device, and selects a target virtual machine from the first resource pool corresponding to the user device based on the expected minor version indicated by the first load request, there are multiple ways to determine the target virtual machine in practical applications, based on the virtual machines included in the first resource pool. Here are three ways to determine the target virtual machine.

[0167] (1) Determine the target virtual machine in method 1: When the first load request indicates the desired minor version and the first resource pool includes virtual machines with the corresponding desired minor version, the target virtual machine is the virtual machine with the corresponding desired minor version in the first resource pool.

[0168] For example, suppose the first load request indicates that the minor version is 7.3, and the first resource pool includes virtual machines 1 to 4. Virtual machine 1 corresponds to version 8.1, virtual machine 2 corresponds to version 7.3, virtual machine 3 corresponds to version 8.2, and virtual machine 4 corresponds to version 7.2. Among them, the first resource pool includes virtual machines under minor version 7.3, then virtual machine 2 is determined as the target virtual machine.

[0169] (2) Method 2 for determining the target virtual machine: The first load request indicates the desired minor version, and the first resource pool does not include the virtual machine corresponding to the desired minor version, but includes the virtual machine corresponding to the same major version as the desired minor version. The target virtual machine is the virtual machine corresponding to the latest minor version included in the same major version in the first resource pool.

[0170] For example, suppose the first load balancing request indicates a desired minor version of 7.3, and the first resource pool includes virtual machines 1 to 4. Virtual machine 1 corresponds to version 8.1, virtual machine 2 corresponds to version 7.2, virtual machine 3 corresponds to version 7.1, and virtual machine 4 corresponds to version 7.2. The first resource pool does not include virtual machines under minor version 7.3, but includes virtual machines 2 to 4 belonging to the same major version as the desired minor version 7.3. Virtual machines 2 and 4 are the latest minor versions under major version 7.0. Then, virtual machine 2 or virtual machine 4 is determined as the target virtual machine.

[0171] (3) Determine the target virtual machine in method 3: When the first load request indicates the desired minor version and the first resource pool does not include the virtual machine corresponding to the desired minor version, nor does it include the virtual machine corresponding to the same major version as the desired minor version, the target virtual machine is the virtual machine corresponding to the latest minor version included in the latest major version in the first resource pool.

[0172] For example, suppose the first load request indicates that the minor version is 7.3, and the first resource pool includes virtual machines 1 to 4. Virtual machine 1 corresponds to version 8.1, virtual machine 2 corresponds to version 6.3, virtual machine 3 corresponds to version 8.2, and virtual machine 4 corresponds to version 6.2. The first resource pool does not include virtual machines under minor version 7.3. Then virtual machine 3 is determined as the target virtual machine.

[0173] Message 4: The first load request indicates multiple expected versions, each with a different priority.

[0174] When a cloud server receives a first load request from a user device, and selects a target virtual machine from the first resource pool corresponding to the user device based on the multiple expected versions indicated by the first load request, there are multiple ways to determine the target virtual machine in practical applications, based on the virtual machine information included in the first resource pool. Two methods for determining the target virtual machine are listed here.

[0175] (1) Determine the target virtual machine in method 1: The first load request indicates multiple expected versions, each of which corresponds to a different priority. When the first resource pool includes a virtual machine corresponding to at least one of the multiple expected versions, the target virtual machine is the virtual machine in the first resource pool corresponding to the first expected version. The first expected version is the expected version with the highest priority among the at least one expected version.

[0176] For example, suppose the first load balancing request indicates multiple desired versions, with priorities from highest to lowest: desired version 7.3, desired version 7.2, and desired version 8.1. The first resource pool includes virtual machines 1 through 4. Virtual machine 1 corresponds to version 8.1, virtual machine 2 corresponds to version 7.2, virtual machine 3 corresponds to version 8.2, and virtual machine 4 corresponds to version 6.2. Since the first resource pool includes virtual machine 2 with desired version 7.2 and virtual machine 1 with desired version 8.1, then virtual machine 2, with the highest priority, is determined as the target virtual machine.

[0177] (2) Determine the target virtual machine in method 2: The first load request indicates multiple expected versions, each with a different priority. When the first resource pool does not include any virtual machine corresponding to any of the multiple expected versions, the target virtual machine is the virtual machine of the latest minor version included in the latest major version in the first resource pool.

[0178] For example, suppose the first load balancing request indicates multiple desired versions, with priorities from highest to lowest: desired version 7.3, desired version 7.2, and desired version 8.1. The first resource pool includes virtual machines 1 through 4, where virtual machine 1 corresponds to version 8.2, virtual machine 2 corresponds to version 7.4, virtual machine 3 corresponds to version 8.2, and virtual machine 4 corresponds to version 8.3. The first resource pool may or may not include any virtual machines with desired versions. In this case, virtual machine 4, which corresponds to the latest minor version within the latest major version in the first resource pool, is determined as the target virtual machine.

[0179] Method 2 for determining the target version: The target virtual machine is the virtual machine corresponding to the latest minor version, which is the latest major version in the first resource pool.

[0180] When a cloud server receives a first load balancing request from a user device, it selects a target virtual machine from the first resource pool corresponding to the user device. The target virtual machine is the one corresponding to the latest minor version within the latest major version in the first resource pool. For example, if the first resource pool includes virtual machines 1 through 4, where virtual machine 1 corresponds to version 8.2, virtual machine 2 to version 7.4, virtual machine 3 to version 8.2, and virtual machine 4 to version 8.3, then virtual machine 4, corresponding to the latest minor version within the latest major version in the first resource pool, is selected as the target virtual machine.

[0181] Method 3 for determining the target version: The target virtual machine is a virtual machine with the same version number configured for the second load request sent to the target user; the second load request is earlier than the first load request.

[0182] In one implementation, the first load request and the second load request in this embodiment are load requests under the same load task.

[0183] After receiving the first load request for load task A from the user device, the cloud server can refer to the virtual machine allocated for the second load request previously sent for load task A to determine the target virtual machine to be allocated for the first load request.

[0184] For example, if load task A sends a second load request to the cloud server at the first moment, and the second load request indicates a target version 7.3, and the first resource pool includes virtual machines 1 to 4, where virtual machine 1 corresponds to version 8.2, virtual machine 2 corresponds to version 7.3, virtual machine 3 corresponds to version 7.3, and virtual machine 4 corresponds to version 8.3, then the cloud server can determine virtual machine 3 in the first resource pool as the target virtual machine allocated by the second load request based on the target version 7.3 indicated by the second load request.

[0185] If load task A needs to be expanded while running on virtual machine 3, and triggers the sending of the first load request to the cloud server at the second moment, at this time the first load request does not indicate the target version information, the second moment is later than the first moment, and virtual machine 2 in the first resource pool has not yet been allocated, then the cloud server can determine virtual machine 2 in the first resource pool as the target virtual machine allocated by the first load request based on the target version 7.3 indicated by the second load request.

[0186] If load task A needs to be expanded while running on virtual machine 3, and a first load request is sent to the cloud server at the second moment, and the first load request does not indicate the target version information, the second moment is later than the first moment, and there is no virtual machine of version 7.3 in the first resource pool, then the cloud server can determine the virtual machine of the latest minor version, including the latest major version, in the first resource pool as the target virtual machine.

[0187] The embodiments of this application will continue below. Figure 5 The content shown will be introduced.

[0188] Step 503: The cloud server assigns the target virtual machine to the target user.

[0189] After selecting a target virtual machine (VM), the cloud server can unassociate the VM from the original general template and bind it to the current user device. For example, a cloud agent (Cloud-Init / Azure Agent, etc.) can inject the user device's key pair, hostname, and custom data into the target VM. Based on user requests, such as the basic configuration information indicated in the first load request, an IP address can be assigned to the target VM, virtual switch ports can be configured, and security group (firewall) rules can be set. After completing the above configuration, the VM is started. Once the VM starts successfully, the resource pool data is updated, changing the VM's status from "preheating" to "running." This application proposes a complete driver management process within the preheating resource pool. By differentiating between major and minor driver versions for VM preheating and employing dynamic target VM selection, it can more quickly and conveniently determine the target VM while minimizing the use of preheating VM resources. This adapts to various complex VM allocation scenarios and can meet the user's need for the corresponding version of VM when creating a load, even during slower driver upgrade processes, thus achieving rapid deployment.

[0190] To better utilize resources, this application embodiment can also detect virtual machines in the resource pool during the driver management process. By calling virtual machines in the idle resource pool to the tense resource pool, the processing response is improved while the resource utilization rate is increased, thus realizing dynamic management.

[0191] For example, such as Figure 10 As shown, this application embodiment includes a first resource pool and a second resource pool. The first resource pool A is a dedicated resource pool for user A, the first resource pool B is a dedicated resource pool for user B, and the second resource pool is a shared resource pool for user A and user B. In order to effectively improve resource utilization, this application embodiment can track virtual machines that have not been allocated for a long time in the first resource pool A and the first resource pool B in real time. When the water level of the second resource pool is low, virtual machines in the first resource pool A and / or the first resource pool B can be borrowed.

[0192] Furthermore, to ensure that the virtual machines in the resource pool meet the driver version requirements when creating the above workload, this embodiment of the application can periodically and automatically upgrade the drivers of the pre-warmed virtual machines. Two upgrade methods are listed here:

[0193] Upgrade Method 1: Rolling upgrades are performed on minor versions corresponding to major versions.

[0194] This upgrade method refers to the rolling upgrade of minor versions of existing major versions after a new minor version is released. For example, suppose the current first resource pool includes virtual machines 1-4, where virtual machine 1 corresponds to version 7.1, virtual machine 2 to version 7.1, virtual machine 3 to version 7.2, and virtual machine 4 to version 8.1. During a version upgrade, if a new virtual machine version 7.3 is released, the minor versions of the virtual machines in the first resource pool can be updated. For instance, if virtual machines 1 and 2, which are the earliest released versions under version 7.0 (version 7.1), are updated to version 7.3, the first resource pool will then include virtual machines with versions 7.3 for virtual machine 1, 7.3 for virtual machine 2, 7.23 for virtual machine 3, and 8.1 for virtual machine 4.

[0195] Upgrade Method Two: Rolling upgrades for major versions.

[0196] The second upgrade method refers to replacing the oldest existing major version in the first resource pool with the new major version after a new major version is released, achieving rolling upgrades for major versions. For example, suppose the current first resource pool includes virtual machines 1 to 4, where virtual machine 1 corresponds to version 7.1, virtual machine 2 corresponds to version 7.1, virtual machine 3 corresponds to version 7.2, and virtual machine 4 corresponds to version 8.1. When upgrading, if a new virtual machine version 9.1 is released, a rolling update can be performed on the major versions of the virtual machines in the first resource pool. For example, if virtual machines 1 to 3 under version 7.0 are all updated to virtual machines of version 9.1, the first resource pool after the upgrade will then include virtual machines with versions 9.1 for virtual machine 1, 9.1 for virtual machine 2, 9.1 for virtual machine 3, and 8.1 for virtual machine 4.

[0197] Based on the same inventive concept, embodiments of this application also disclose a drive management device that can be applied to a cloud management platform for managing infrastructure that provides cloud services. The infrastructure includes multiple regions, each region including at least one cloud data center, and cloud services running on at least one server in at least one cloud data center located in one of the multiple regions. Figure 11 This is a schematic diagram of the structure of a drive management device provided in an embodiment of this application, as shown below. Figure 11 As shown, the device includes:

[0198] The load management module 1110 is used to receive a first load request sent by the user equipment of the target user, the load request being used to request the allocation of virtual machine resources;

[0199] The virtual machine management module 1120 is used to select a target virtual machine of a target version from a first resource pool for the target user. The first resource pool includes multiple virtual machines, at least two of which correspond to different versions, and one of the virtual machines is obtained by preheating with a virtual machine driver of the corresponding version; and to allocate the target virtual machine to the target user.

[0200] In one possible implementation, the plurality of virtual machines each correspond to the same major version.

[0201] In one possible implementation, at least two of the plurality of virtual machines correspond to different major versions.

[0202] In one possible implementation, the first load request is also used to indicate the target version.

[0203] In one possible implementation, the first load request is further configured to indicate a desired major version, and when the first resource pool includes virtual machines corresponding to the desired major version, the target virtual machine is the virtual machine in the first resource pool corresponding to the latest minor version included in the desired major version; or, when the first load request is further configured to indicate a desired major version, and the first resource pool does not include virtual machines corresponding to the desired major version, the target virtual machine is the virtual machine in the first resource pool corresponding to the latest minor version included in the latest major version.

[0204] In one possible implementation, the first load request is further configured to indicate a desired minor version, and when the first resource pool includes virtual machines corresponding to the desired minor version, the target virtual machine is a virtual machine in the first resource pool corresponding to the desired minor version; or, the first load request is further configured to indicate a desired minor version, and when the first resource pool does not include virtual machines corresponding to the desired minor version, but includes virtual machines corresponding to the same major version as the desired minor version, the target virtual machine is a virtual machine in the first resource pool corresponding to the latest minor version included in the same major version; or, the first load request is further configured to indicate a desired minor version, and when the first resource pool does not include virtual machines corresponding to the desired minor version, nor does it include virtual machines corresponding to the same major version as the desired minor version, the target virtual machine is a virtual machine in the first resource pool corresponding to the latest minor version included in the latest major version.

[0205] In one possible implementation, the first load request is further configured to indicate multiple expected versions, each corresponding to a different priority. When the first resource pool includes a virtual machine corresponding to at least one of the multiple expected versions, the target virtual machine is a virtual machine in the first resource pool corresponding to a first expected version, and the first expected version is the expected version with the highest priority among the at least one expected version. Alternatively, the first load request is further configured to indicate multiple expected versions, each corresponding to a different priority. When the first resource pool does not include a virtual machine corresponding to any of the multiple expected versions, the target virtual machine is a virtual machine in the first resource pool corresponding to the latest minor version included in the latest major version.

[0206] In one possible implementation, the target virtual machine is the virtual machine corresponding to the latest minor version included in the latest major version of the first resource pool.

[0207] In one possible implementation, the target virtual machine is a virtual machine with the same version number configured for the second load request sent to the target user; the second load request is earlier than the first load request.

[0208] In one possible implementation, the first load request and the second load request are load requests under the same load task.

[0209] In one possible implementation, the first resource pool is a resource pool configured for the target user.

[0210] In one possible implementation, the virtual machine management module 1120 is further configured to:

[0211] When there are unallocated virtual machines in the first resource pool for more than a first threshold time, and the resource pool level of the second resource pool is lower than the second threshold, some or all of the unallocated virtual machines in the first resource pool are used as virtual machines in the second resource pool. The second resource pool is a shared resource pool configured for multiple users.

[0212] In one possible implementation, the virtual machine management module 1120 is further configured to:

[0213] The version number of the virtual machines in the first resource pool is updated at set intervals.

[0214] This device can be used to perform, for example Figure 5 The method steps shown in the embodiments are therefore relevant to the description of the apparatus. Figure 5 The description of the illustrated embodiments will not be repeated here.

[0215] It should be noted that each of the above modules can be implemented in software or hardware. For example, the implementation of the virtual machine management module 1120 will be described below. Similarly, the implementation of other modules can be based on the implementation of the virtual machine management module 1120.

[0216] When implemented in software, the virtual machine management module 1120 can be an application or code block running on a computer device. The computer device can be at least one of a physical host, virtual machine, container, or other computing device. Furthermore, there can be one or more computer devices. For example, the virtual machine management module 1120 can be an application running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the application can be distributed within the same availability zone (AZ) or in different AZs. The multiple hosts / virtual machines / containers used to run the application can be distributed within the same region or in different regions. Typically, a region can include multiple AZs.

[0217] Similarly, multiple hosts / virtual machines / containers used to run the application can be distributed within the same Virtual Private Cloud (VPC) or across multiple VPCs. Typically, a single region can include multiple VPCs, and a single VPC can include multiple Availability Zones (AZs).

[0218] When implemented in hardware, the virtual machine management module 1120 may include at least one computing device, such as a server. Alternatively, the cloud resource configuration virtual machine management module 1120 may also be a device implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be implemented using a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), generic array logic (GAL), or any combination thereof.

[0219] The virtual machine management module 1120 includes multiple computing devices that can be distributed within the same Availability Zone (AZ) or in different AZs. Similarly, the virtual machine management module 11201 includes multiple computing devices that can be distributed within the same Virtual Private Cloud (VPC) or in multiple VPCs. These multiple computing devices can be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, and GALs.

[0220] It should be noted that each of the above modules can be used to execute some or all of the steps in the cloud service-based driver management method.

[0221] The cloud-based driver management device disclosed in this application has a clear division of labor and close cooperation among its various modules. The modules work together to efficiently complete driver management for user devices.

[0222] This application also provides a computing device, which will be described below. Figure 12 , Figure 12 This is a schematic diagram of a computing device 1200 that runs a cloud service-based driver management method according to an embodiment of this application. The computing device 1200 includes a bus 1201, a processor 1203, a memory 1202, and a communication interface 1204. The processor 1203, memory 1202, and communication interface 1204 communicate with each other via the bus 1201. The computing device 1200 can be a server or a terminal device. It should be understood that this application does not limit the number of processors and memories in the computing device 1200.

[0223] Bus 1201 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be divided into address buses, data buses, control buses, etc. For ease of representation, Figure 12 The bus 1204 may be represented by a single line, but this does not mean that there is only one bus or one type of bus. The bus 1204 may include a path for transmitting information between various components of the computing device 1200 (e.g., memory 1202, processor 1203, communication interface 1204).

[0224] The processor 1203 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0225] The memory 1202 may include volatile memory, such as random access memory (RAM). The processor 1203 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0226] The memory 1202 stores executable program code that, when executed, enables a cloud-based fault demarcation method. In other words, the memory 1202 contains instructions from the cloud management platform for executing the cloud-based fault demarcation method.

[0227] The communication interface 1204 uses transceiver modules such as, but not limited to, network interface cards and transceivers to enable communication between the computing device 1200 and other devices or communication networks.

[0228] This application also provides a computing device cluster. The computing device cluster includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smartphone.

[0229] Please see below Figure 13 , Figure 13 This is a schematic diagram of the structure of a computing device cluster that executes a cloud-based fault demarcation method according to an embodiment of this application. The computing device cluster includes at least one computing device 1200. The memory 1202 of one or more computing devices 1200 in the computing device cluster may store the same cloud management platform instructions for the cloud-based fault demarcation method.

[0230] In some possible implementations, one or more computing devices 1200 in the computing device cluster can also be used to execute some instructions of the cloud service-based fault demarcation method. In other words, a combination of one or more computing devices 1200 can jointly execute the instructions of the cloud service-based fault demarcation method.

[0231] It should be noted that the memory 1202 in different computing devices 1200 within the computing device cluster can store different instructions for executing some functions of the cloud management platform. That is, the instructions stored in the memory 1202 of different computing devices 1200 can achieve the aforementioned... Figure 11 The functionality of one or more modules within it.

[0232] This application also provides a computer program product containing instructions. This computer program product may be a software or program product containing instructions, capable of running on a computing device or stored on any available medium. When the computer program product is run on at least one computer device, it causes the at least one computer device to perform the aforementioned fault delimitation method applied to a cloud management platform for cloud-based services.

[0233] This application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that a computing device can store, or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to execute the aforementioned fault demarcation method applied to a cloud management platform for performing cloud-based services.

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

Claims

1. A drive management method, characterized in that, Applied to cloud servers, including: Receive a first load request sent by the user equipment of the target user, the first load request being used to request the allocation of virtual machine resources; Select a target virtual machine of a target version from the first resource pool for the target user. The first resource pool includes multiple virtual machines, including the target virtual machine. At least two of the multiple virtual machines correspond to different versions. One of the virtual machines is obtained by preheating with a virtual machine driver of the corresponding version. The target virtual machine is assigned to the target user.

2. The method as described in claim 1, characterized in that, The multiple virtual machines each correspond to the same major version.

3. The method as described in claim 1, characterized in that, At least two of the multiple virtual machines correspond to different major versions.

4. The method according to any one of claims 1 to 3, characterized in that, The first load request is also used to indicate the target version.

5. The method according to any one of claims 1 to 3, characterized in that, The first load request is further configured to indicate a desired major version, and when the first resource pool includes virtual machines corresponding to the desired major version, the target virtual machine is the virtual machine in the first resource pool corresponding to the latest minor version included in the desired major version; or, The first load request is further used to indicate a desired major version, and when the first resource pool does not include a virtual machine corresponding to the desired major version, the target virtual machine is the virtual machine corresponding to the latest minor version included in the latest major version in the first resource pool.

6. The method according to any one of claims 1 to 3, characterized in that, The first load request is further configured to indicate a desired minor version, and when the first resource pool includes a virtual machine corresponding to the desired minor version, the target virtual machine is the virtual machine in the first resource pool corresponding to the desired minor version; or, The first load request is further used to indicate a desired minor version, and the first resource pool does not include virtual machines corresponding to the desired minor version, but includes virtual machines corresponding to the same major version as the desired minor version, in which case the target virtual machine is the virtual machine corresponding to the latest minor version included in the same major version in the first resource pool; or, The first load request is further used to indicate a desired minor version, and when the first resource pool does not include virtual machines corresponding to the desired minor version, nor does it include virtual machines corresponding to the same major version as the desired minor version, the target virtual machine is the virtual machine corresponding to the latest minor version included in the latest major version in the first resource pool.

7. The method according to any one of claims 1 to 3, characterized in that, The first load request is further used to indicate multiple desired versions, each corresponding to a different priority. When the first resource pool includes a virtual machine corresponding to at least one of the multiple desired versions, the target virtual machine is the virtual machine in the first resource pool corresponding to the first desired version, and the first desired version is the desired version with the highest priority among the at least one desired version; or The first load request is also used to indicate multiple desired versions, each of which corresponds to a different priority. When the first resource pool does not include a virtual machine corresponding to any of the multiple desired versions, the target virtual machine is a virtual machine in the first resource pool that corresponds to the latest minor version of the latest major version.

8. The method according to any one of claims 1 to 3, characterized in that, The target virtual machine is the virtual machine corresponding to the latest minor version, which is included in the latest major version in the first resource pool.

9. The method as described in claim 1, characterized in that, The target virtual machine is a virtual machine with the same version number configured for the second load request sent to the target user; the second load request is earlier than the first load request.

10. The method as described in claim 9, characterized in that, The first load request and the second load request are load requests under the same load task.

11. The method according to any one of claims 1 to 10, characterized in that, The first resource pool is a resource pool configured for the target user.

12. The method as described in claim 11, characterized in that, The method further includes: When there are unallocated virtual machines in the first resource pool for more than a first threshold time, and the resource pool level of the second resource pool is lower than the second threshold, some or all of the unallocated virtual machines in the first resource pool are used as virtual machines in the second resource pool. The second resource pool is a shared resource pool configured for multiple users.

13. The method according to any one of claims 1 to 12, characterized in that, The method further includes: The version number of the virtual machines in the first resource pool is updated at set intervals.

14. A drive management device, characterized in that, The drive management device includes: The load management module is used to receive a first load request sent by the user equipment of the target user, the load request being used to request the allocation of virtual machine resources; The virtual machine management module is used to select a target virtual machine of a target version from a first resource pool for the target user. The first resource pool includes multiple virtual machines, at least two of which correspond to different versions, and one of the virtual machines is obtained by preheating with a virtual machine driver of the corresponding version; and to allocate the target virtual machine to the target user.

15. A computing device, characterized in that, The computing device includes a processor and memory; The memory is used to store computer program instructions; The processor executes computer program instructions in the memory to perform the method as described in any one of claims 1 to 13.

16. A computer-readable storage medium, characterized in that, When the computer-readable storage medium is executed by a computing device, the computing device performs the method according to any one of claims 1 to 13.

Images