Bare metal instance management and control method and apparatus, device, and storage medium

Abstract

The present disclosure relates to the technical field of computers, and in particular to the technical fields of cloud computing, cloud services, bare metal products and the like, and provides a bare metal instance management and control method and apparatus, a device, and a storage medium. The specific implementation solution is: a smart card receives an operation request for a bare metal instance; and on the basis of an interface provided by a virtualization library, the smart card performs, on the bare metal instance, a target operation corresponding to the operation request.

Description

Methods, devices, equipment, and storage media for the management of bare metal instances

[0001] This application claims priority to Chinese Patent Application No. 202411896139.9, filed on December 20, 2024, entitled "Method, Apparatus, Device and Storage Medium for Controlling Bare Metal Examples", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This disclosure relates to the field of computer technology, and in particular to the fields of cloud computing, cloud services, and bare metal products. Background Technology

[0003] With the continuous evolution of cloud computing technology, bare metal products are also constantly integrating the advantages of cloud computing, enabling users to enjoy the high performance of physical machines while also experiencing the efficient operation and maintenance and flexible expansion capabilities brought by cloud computing. This further expands its application scope in key business areas of various industries and lays a solid foundation for the widespread application of cloud computing in more complex and high-performance demand scenarios. Summary of the Invention

[0004] This disclosure provides a method, apparatus, device, and storage medium for managing bare metal instances.

[0005] According to one aspect of this disclosure, a method for managing bare metal instances is provided, comprising:

[0006] The smart card receives an operation request for the bare metal instance;

[0007] The smart card performs the target operation corresponding to the operation request on the bare metal instance based on the interface provided by the virtualization library.

[0008] According to another aspect of this disclosure, a control device for a bare metal sample is provided, comprising:

[0009] The receiving module is used to receive operation requests for bare metal instances via a smart card;

[0010] The execution module is used to perform the target operation corresponding to the operation request on the bare metal instance through the interface provided by the smart card and the virtualization library.

[0011] According to another aspect of this disclosure, an electronic device is provided, comprising:

[0012] At least one processor; and

[0013] The memory is communicatively connected to the at least one processor; wherein,

[0014] The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform any of the methods described in the present disclosure.

[0015] According to another aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions, wherein the computer instructions are used to cause the computer to perform any of the methods according to embodiments of this disclosure.

[0016] According to another aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements any of the methods according to embodiments of this disclosure.

[0017] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0018] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure.

[0019] Figure 1 is a flowchart illustrating a method for controlling bare metal samples according to an embodiment of the present disclosure.

[0020] Figure 2 is a timing diagram of creating a bare metal instance according to an embodiment of the present disclosure.

[0021] Figure 3 is a timing diagram of a bare metal startup example provided according to an embodiment of the present disclosure.

[0022] Figure 4 is a timing diagram of an example of shutting down bare metal via soft shutdown according to an embodiment of the present disclosure.

[0023] Figure 5 is a timing diagram of an example of shutting down bare metal by hard shutdown according to an embodiment of the present disclosure.

[0024] Figure 6a is a timing diagram of an example of bare metal release according to an embodiment of the present disclosure.

[0025] Figure 6b is a framework diagram of an example of releasing bare metal according to an embodiment of the present disclosure.

[0026] Figure 7 is a timing diagram of device mounting in a bare metal example according to an embodiment of the present disclosure.

[0027] Figure 8 is a timing diagram of the unloading of a device in a bare metal example according to an embodiment of the present disclosure.

[0028] Figure 9 is a timing diagram of system disk expansion in a bare metal example according to an embodiment of the present disclosure.

[0029] Figure 10 is a framework diagram of a method for controlling bare metal instances according to an embodiment of the present disclosure.

[0030] Figure 11 is a framework diagram of libvirt provided according to an embodiment of the present disclosure.

[0031] Figure 12 is a schematic diagram of the structure of a control device for a bare metal example according to an embodiment of the present disclosure.

[0032] Figure 13 is a block diagram of an electronic device used to implement the bare metal example control method of the embodiments of the present disclosure. Detailed Implementation

[0033] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0034] The terms “first,” “second,” etc., used in this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion, such as including a series of steps or units. A method, system, product, or apparatus is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to these processes, methods, products, or apparatuses.

[0035] For ease of understanding, the terms used in the embodiments of this disclosure are explained below:

[0036] Bare metal instances: Bare metal instances are a computing resource provision method in cloud computing service models. They aim to provide users with a complete physical server without an intermediate virtualization layer. This allows users to directly access the server's hardware resources, including CPU (Central Processing Unit), memory, storage devices, and network interfaces, just like using a traditional physical server.

[0037] Libvirt (Virtual Machine Manager): Also known as a virtualization management toolkit, Libvirt is an open-source project that provides a set of tools for managing virtual machine instances. Libvirt itself is a client-server architecture, including an RPC client and an RPC server. The RPC channel supports communication methods such as UnixSocket and TCP, and the client can interact with other servers.

[0038] Libvirtd (hypervisor): is a daemon in Libvirt that is responsible for scheduling and managing virtual machines.

[0039] QEMU (Quick Emulato): QEMU is a widely used open-source computer emulator and virtual machine software. As a standalone hypervisor, QEMU can run virtual machines at the application level and also supports compatible virtualization modes.

[0040] IOemu (Input-Output QEMU): IOemu is short for IO Qemu; Qemu is an open-source virtualization software and hardware emulator. In this embodiment, to accommodate unified management of bare metal instances and virtual machine instances, IOemu is used instead of Qemu in the virtual machine instance management tool.

[0041] QMP (QEMU Machine Protocol, Qemu monitoring protocol): It is a JSON-based protocol provided by QEMU that allows users to query and configure QEMU instances through a socket interface.

[0042] Nova (OpenStack Nova, Compute Control Plane): A core component of OpenStack (a cloud computing platform), primarily responsible for the management and scheduling of computing resources. In this embodiment, Nova is used to respond to operation requests, calling interfaces provided by the virtualization library to send the target instructions corresponding to the operation request to the hypervisor.

[0043] A smart card is a card-type device that integrates a microprocessor and storage unit. It can also be understood as a server-like device. In this embodiment, the smart card integrates key components such as Nova, Libvirtd, and IOemu for managing bare metal instances.

[0044] With the continuous development of cloud computing technology, in order to meet the diverse needs of different users, two key computing products have emerged at the IaaS (Infrastructure as a Service) layer: bare metal products and virtual machine products.

[0045] However, these two computing products have some problems that urgently need to be solved in practical applications, which seriously affect the overall efficiency and user experience of cloud computing services, and also bring many challenges and increased costs to the R&D and operation and maintenance teams.

[0046] On the one hand, the different architectures used by bare metal and virtual machine instances result in higher R&D and maintenance costs.

[0047] On the other hand, the success rate of using the CSOC (Cloud Service Onboarding and Commissioning) installation service is low, with a test result of about 95%, which has become a bottleneck restricting the improvement of the overall success rate of bare metal products.

[0048] In view of this, embodiments of this disclosure provide a method for managing bare metal instances. Management of smart card bare metal instances can be achieved by managing virtual machine instances, thereby unifying the management architecture of bare metal instances and virtual machine instances. Figure 1 shows a flowchart of the bare metal instance management method provided in this disclosure, which mainly includes the following:

[0049] S101, the smart card receives an operation request for the bare metal instance.

[0050] It is understandable that bare metal instances essentially run directly on the physical machine hardware. One bare metal instance corresponds to one physical machine.

[0051] A smart card is a card-type device that integrates a microprocessor and storage unit, and can serve as a medium for receiving operation requests from bare metal instances. These operation requests can be management requests for the bare metal instances. For example, a cloud service user may initiate an operation request through a specific management platform, hoping to perform operations such as configuration modifications, disk expansion, and application deployment on the bare metal products they manage.

[0052] S102, the smart card performs the target operation corresponding to the operation request on the bare metal instance based on the interface provided by the virtualization library.

[0053] The virtualization library (Libvirt) is an interface library that encapsulates and integrates numerous interfaces. These interfaces shield the complexity and diversity of the underlying hardware, enabling smart cards to receive bare metal instance operation requests in a unified and standardized manner. For example, it converts bare metal instance operation requests from C++ (C++ plus plus) format to Python (Python programming language) format, facilitating the use of the same architecture as virtual machine management to manage bare metal instances.

[0054] In this embodiment, by leveraging the standardized interface of the virtualization library, operation requests for bare metal instances can be received and executed by the smart card in a unified and standardized manner. This helps to build a more reliable and easier-to-maintain cloud computing environment, reducing the development and maintenance costs caused by the different architectures used by bare metal and virtual machine instances. By using the smart card to execute the target operation corresponding to the operation request on the bare metal instance through the interface provided by the virtualization library, the installation service CSOC can be replaced, eliminating the need for CSOC network communication. This limits the management of bare metal instances to the smart card and the physical machine, shortening management time, further improving the success rate of bare metal instance operations, optimizing cloud computing resource management processes and efficiency, and enhancing the stability and scalability of cloud services.

[0055] In this embodiment, the smart card integrates several key components, including Nova, the hypervisor (Libvirtd), IPMITool (Intelligent Platform Management Interface Tool), and IOemu. These components work together to effectively handle various operation requests for bare metal instances. The specific functions of these components are as follows:

[0056] (1) Nova is a core component of OpenStack (a cloud computing platform), primarily responsible for the management and scheduling of computing resources. In this embodiment, Nova is used to respond to operation requests, calling the interfaces provided by the virtualization library to send the target instructions corresponding to the operation request to the hypervisor. In this embodiment, the interface fields and their meanings provided by the virtualization library are the same as those for managing virtual machine instances, but the field values ​​are different. Specifically, for managing bare metal instances, the field values ​​use the metadata of the bare metal instance; for managing virtual machine instances, the field values ​​use the metadata of the virtual machine instance.

[0057] Taking the operation request of a bare metal instance as an example of expanding the system disk in the bare metal instance, Nova calls the corresponding interface through the virtualization library, and then converts the operation request into target instructions that the hypervisor can recognize and process. The hypervisor then performs further processing to ensure that the entire operation process can proceed in sequence.

[0058] (2) The virtual machine management program refines the target instructions sent from Nova and generates execution instructions that can be actually executed. It generates execution instructions based on the target instructions and sends them to IPMITool and / or IOemu to perform the corresponding operations.

[0059] In this embodiment, the hypervisor can be Libvirtd, which can manage various virtualization technologies through its internally provided general interfaces. This allows for the creation, configuration, startup, shutdown, and management of bare metal instances in a unified manner, without needing to concern themselves with the specific details of the underlying technologies. Furthermore, the hypervisor integrates various components, including (a)-(c):

[0060] (a) Application programming interface (Libvirt_api), used to receive target instructions sent by Nova;

[0061] (b) Domain Connection Management Object (virConnectPtr), used to call the client driver (RemoteDriver) to send execution instructions to the fast emulator driver based on the target instruction;

[0062] (c) Quick Emulator Driver (QemuDriver) for communicating with IOemu and / or IPMITool.

[0063] The application programming interface (API) serves as the interaction channel, ensuring standardized communication. The domain connection management object, acting as the hub of the entire process, processes the target instructions and then calls the client driver to send execution instructions to the fast emulator driver, thereby enabling communication with IOemu and / or IPMITool. The fast emulator driver plays a crucial role in bridging the gap between these components, and the entire architecture is unified with the virtual machine instance management architecture, enabling the management of bare metal instances and reducing maintenance and development costs.

[0064] During implementation, after receiving the target instruction from Nova via the application programming interface (API), the hypervisor analyzes the specific components involved in the target instruction through the domain connection management object. Then, it calls the client driver to send execution instructions to IOemu and / or IPMITool to perform the corresponding operations. For example, if the target instruction involves operations related to the system disk in a bare metal instance, the hypervisor will send the corresponding execution instructions to the IOemu component responsible for system disk operations, which will then execute the specific tasks related to the system disk. If the target instruction involves power management operations in a bare metal instance, the hypervisor will send the corresponding execution instructions to IPMITool for subsequent related operations.

[0065] (3) IPMITool is used to perform power management operations on bare metal instances.

[0066] IPMITool is a tool for remotely managing and monitoring server hardware. It can access and control server hardware based on the Intelligent Platform Management Interface (IPMI) standard protocol.

[0067] IPMTool allows for power management operations on bare metal instances, enabling various operations on these instances without relying on the server's operating system. These operations include powering on, powering off, restarting, power status monitoring, and modifying the BIOS (Basic Input / Output System).

[0068] (4) IOemu is used to perform at least one of the following operations on bare metal instances: mounting devices, unmounting devices, and expanding disks.

[0069] In this embodiment of the disclosure, IOemu mainly implements the smart card and physical machine's offloading device and disk expansion related operations, as well as communication with SDPCIe (Software-Define-PCIe), and simulates PCIe Switch (Peripheral Component Interconnect Express Switch) through SDPCIe.

[0070] In summary, in order to adapt to the operation consistent with the virtual machine instance management architecture, the embodiments of this disclosure add an IOemu component, which can be used to simulate disk devices and implement operations such as mounting, unmounting, and expanding disk devices through corresponding instructions; it can also be used to simulate network cards to provide network connectivity functions.

[0071] Taking device mounting as an example, when the hypervisor sends relevant execution instructions, IOemu will simulate the corresponding hardware read / write and device interaction process. By cooperating with the storage and device management modules of the bare metal instance, it will correctly connect the device to be mounted into the bare metal instance so that it can be recognized and used by the system.

[0072] During disk expansion, IOemu will execute instructions to simulate the disk space allocation and expansion process, and reasonably expand the disk resources of the bare metal instance to meet the business's storage capacity requirements.

[0073] During implementation, QMP message communication is used between the hypervisor and IOemu. By using QMP, it is ensured that the message communication method between the hypervisor and IOemu is compatible with the management architecture of the virtual machine instances, avoiding cloud service failures caused by communication problems, thereby improving the success rate of installation services.

[0074] In this embodiment, the Nova, hypervisor, IPMITool, and IOemu components in the smart card work together to form a complete mechanism for performing various operations on bare metal instances. This helps improve the management and usage efficiency of bare metal instances, meets diverse needs in different application scenarios, and is consistent with the management architecture of virtual machine instances, thus reducing development and maintenance costs.

[0075] To make the bare metal instance management method provided in this disclosure easier to understand, the operation requests for bare metal instances can be described in detail from several key aspects. Specifically, these may include: creating a bare metal instance, starting a bare metal instance, closing a bare metal instance, releasing a bare metal instance, mounting a bare metal device, unmounting a bare metal device, and expanding the disk, etc.

[0076] When the operation request includes creating a bare metal instance, the smart card performs the target operation corresponding to the operation request on the bare metal instance based on the interface provided by the virtualization library. The execution flow can be presented by the timing diagram shown in Figure 2, and the detailed steps are as follows:

[0077] S201, when the operation request includes creating an instance, the interface defining the instance type in the virtualization library is called through Nova.

[0078] That is, when Nova receives a request to create an instance, it calls the instance type definition interface in the virtualization library. In S202, Nova sends the instance creation command to the hypervisor.

[0079] The instance creation request and instance creation command have different formats and some differences in content. The instance creation request is a description of the instance specification, such as in JSON format. The instance creation command is a description of the virtual machine's form, such as in XML format.

[0080] Nova needs to schedule a suitable physical machine to create a bare metal instance based on the instance creation operation request. After scheduling a suitable physical machine, it schedules the hypervisor to create the bare metal instance based on the instance creation instruction. Therefore, the instance creation instruction can be understood as a subset of the instance creation operation request.

[0081] The instance creation command may contain key parameters of the bare metal instance form factor, such as the number, type and configuration information of network cards, as well as the number, capacity and type of system disks.

[0082] S203 creates a bare metal instance by responding to the instance creation command through the hypervisor.

[0083] In other words, after receiving the instruction, the hypervisor constructs a bare metal instance that meets the requirements according to the definition of Nova, thereby preparing the basic hardware environment for the startup and operation of the bare metal instance.

[0084] In this embodiment, by calling the defined instance type interface in the virtualization library through Nova, a standardized interface is established between Nova and the underlying hypervisor, hardware drivers, and management tools. This unifies the management process and interface for virtual machines and bare metal instances. Based on this standardized interface, the hypervisor can respond more accurately to instance creation commands and create bare metal instances, laying a solid foundation for the stable operation of bare metal instances.

[0085] When the operation request includes launching a bare metal instance, the execution flow of the target operation corresponding to the operation request on the bare metal instance based on the interface provided by the virtualization library can be presented by the timing diagram shown in Figure 3. The detailed steps are as follows:

[0086] S301, when the operation request includes starting a bare metal instance, calls the start instance interface in the virtualization library via Nova.

[0087] S302, based on the instance startup interface, Nova sends instance startup commands to the hypervisor.

[0088] S303: After the hypervisor receives the startup command sent by Nova, it then sends the startup command to IOemu.

[0089] S304 initializes the system disk and network card of the bare metal instance based on the boot command via IOemu.

[0090] S305, upon successful startup of IOemu, sends a power-on command to IPMITool via the hypervisor.

[0091] If IOemu starts successfully, it means that the initialization of the system disk and network card has been completed smoothly. The hypervisor will detect this status change, determine that the physical machine can be powered on, and send a power-on command to the IPMITool component.

[0092] S306, through IPMITool based on power-on commands, instructs the physical machine corresponding to the bare metal instance to perform a power-on operation.

[0093] The power-on operation involves IPMITool sending a corresponding signal to the physical machine's power management module based on the power-on command to turn on the power, so as to change the physical machine's power state from the off state to the on state (active).

[0094] In this embodiment, Nova calls the instance startup interface in the virtualization library to send an instance startup command to the hypervisor, which then sends a startup command to IOemu. Upon successful startup, a power-on command is sent to IPMITool. This orderly transmission of commands among components throughout the process ensures a smooth startup process and enhances the stability of cloud service operation.

[0095] Continuing with Figure 3 as an example, after the physical machine corresponding to the bare metal instance performs a power-on operation, the power status of the physical machine will be checked in S307 using IPMITool.

[0096] During implementation, IPMITool sends specific IPMI commands to the physical machine's management controller, which then returns power status information about the physical machine, such as whether the power is on.

[0097] S308, after confirming that the physical machine has been successfully powered on, sends the power status to the virtual machine management program via IPMITool.

[0098] S309 updates the power state of the bare metal instance to the power-on state via the hypervisor. For example, it sets the power state of the bare metal instance to the active state to synchronize the power state with Nova.

[0099] In this embodiment, by checking the power status of the physical machine, it can be ensured that the physical machine has been correctly powered on according to the previous power-on command, avoiding errors in subsequent operations due to power failure or incomplete power-on. After the power status of the bare metal instance is updated, this status is synchronized to Nova, allowing Nova to schedule subsequent operations according to a pre-set process.

[0100] In this embodiment, shutting down a bare metal instance can be divided into a soft shutdown operation and a hard shutdown operation. A soft shutdown operation refers to actively shutting down the physical machine, then monitoring the power status of the physical machine through a hypervisor, and stopping the IOemu process to release resources after detecting that the physical machine's power status is shut down. A hard shutdown operation refers to forcibly stopping the bare metal instance in an abnormal situation where the physical machine cannot be shut down normally.

[0101] In practical use cases, considering factors such as the stability of cloud services and the rational utilization of resources, soft shutdown is usually preferred in order to more effectively ensure the operation of cloud services. This reduces the potential risks and adverse effects of hard shutdown on cloud services and resources, and ensures the smooth operation and efficient management of the entire cloud service.

[0102] When the operation request includes closing the bare metal instance, the smart card performs the target operation corresponding to the operation request on the bare metal instance based on the interface provided by the virtualization library. The execution flow can be presented by the timing diagram shown in Figure 4, and the detailed steps are as follows:

[0103] S401, in cases where the operation request includes shutting down the bare metal instance, calls the soft shutdown interface in the virtualization library via Nova.

[0104] S402, Nova sends a soft shutdown command to the hypervisor.

[0105] S403 responds to the soft shutdown command through the hypervisor and sends the shutdown command to IPMITool.

[0106] S404, via IPMITool, requests the physical machine of the bare metal instance to perform a shutdown operation based on the shutdown command.

[0107] S405 uses IPMITool to poll the physical machine's power status to determine if the physical machine is powered off.

[0108] S406: If the physical machine's power status is determined to be off, the IPMITool is used to notify the hypervisor to update the power status of the bare metal instance to off.

[0109] S407, through the virtual machine management program, shuts down IOemu based on the shutdown state.

[0110] During implementation, IPMITool sends a shutdown command data packet conforming to the IPMI protocol to the intelligent platform management interface of the physical machine based on the shutdown command. After receiving the command, the management controller will perform a shutdown operation on the physical machine of the bare metal instance according to the pre-set hardware control logic.

[0111] After each shutdown command is sent to the physical machine, IPMITool checks the power status. If the power status is not powered off, the call returns. That is, the current shutdown and power status check operation ends, and the process returns to the point where the operation was initially initiated, resending the shutdown command until the physical machine's power status is powered off or after a certain number of resentments, an error alarm is issued.

[0112] If the power state is determined to be off, the hypervisor updates the power state of the bare metal instance to off. Simultaneously, it sends a command such as "system powerdown" to IOemu to shut down the IOemu process.

[0113] In this embodiment of the disclosure, by stopping the IOemu process through a soft shutdown, it is possible to ensure that all disk write operations have been completed, prevent file system corruption, and realize the shutdown operation of the bare metal instance.

[0114] Correspondingly, if a soft shutdown fails, a hard shutdown can be performed. The specific execution flow can be shown in the timing diagram in Figure 5, and the detailed steps are as follows:

[0115] In the event of a failed soft shutdown, the S501 invokes the hard shutdown interface in the virtualization library via Nova.

[0116] S502, Nova sends a hard shutdown command to the hypervisor.

[0117] S503 responds to hard shutdown commands via the hypervisor and sends shutdown commands to IPMITool.

[0118] S504, through IPMITool, requests the physical machine of the bare metal instance to perform a shutdown operation based on the shutdown command.

[0119] The S505 polls the physical machine's power status using IPMITool.

[0120] S506, if the power status of the physical machine is found to be "on" within a preset time period, shuts down IOemu through the virtual machine management program.

[0121] Unlike a soft shutdown, after IPMITool polls the physical machine's power status for more than a preset duration of m, the hypervisor can forcibly terminate the IOemu process using a command such as "kill -15".

[0122] In this embodiment, terminating the IOemu process via a hard shutdown avoids situations such as the IOemu process getting stuck in an infinite loop. This process architecture enables the successful shutdown of bare metal instances.

[0123] In a cloud computing environment, resources can be reclaimed from allocated and used bare metal instances. This involves clearing all data and configurations related to previous user usage from the bare metal instance's physical machine and releasing all system resources associated with the instance, restoring it to a state where it can be reallocated and used. This process is called releasing a bare metal instance. Before performing this operation, it is essential to ensure that the bare metal instance is shut down. Performing the release operation while it is running may lead to data loss, system errors, and other problems.

[0124] In this embodiment of the disclosure, when the operation request includes releasing the bare metal instance, the execution flow of the smart card performing the target operation corresponding to the operation request on the bare metal instance based on the interface provided by the virtualization library can be presented by the timing diagram shown in Figure 6a. The detailed steps are as follows:

[0125] S601, if the operation request includes releasing the bare metal instance, Nova calls the release instance interface in the virtualization library if it is determined that the bare metal instance will be closed.

[0126] S602, Nova sends the release command to the hypervisor.

[0127] S603 responds to the release command through the hypervisor, creates a write-zero operating system on the physical machine corresponding to the bare metal instance based on the image file, and erases the target data on the physical machine based on the write-zero operating system.

[0128] In practice, the process is similar to that of creating a bare metal instance. When a write-zero operating system is created, the relevant management components will also receive a special instruction request for creating a write-zero operating system.

[0129] For example, Nova sends a request to create a write-zero operating system to the hypervisor, which then processes the request and completes the operation of creating a write-zero operating system based on the image file onto the physical machine corresponding to the bare metal instance through the corresponding execution component.

[0130] After creating the write-zero operating system, Nova can call the erase interface in the virtualization library to send erase commands to the hypervisor. The hypervisor then sends the erase commands to the physical machine through the control channel between the write-zero operating system and the physical machine to erase the data on the corresponding disk.

[0131] In this embodiment of the disclosure, a write-zero operating system is created based on the image file and written to the physical machine corresponding to the bare metal instance. The target data on the physical machine is then erased based on the write-zero operating system to ensure the release of the bare metal instance. This helps to improve the success rate of new instance deployment.

[0132] Correspondingly, after erasing the target data on the physical machine based on the write-zero operating system, it is necessary to check whether the erasure is complete. If the erasure is complete, the write-zero operating system also needs to be shut down. Continuing with Figure 6a as an example:

[0133] S604 uses Nova to call the image system in the virtualization library to close the interface.

[0134] S605, Nova sends the image system shutdown command to the hypervisor.

[0135] S606 responds to the image system's shutdown command through the hypervisor and sends the shutdown command to IPMITool.

[0136] S607, through IPMITool, requests the physical machine of the bare metal instance to perform a shutdown operation based on the shutdown command.

[0137] In this embodiment, the image system shutdown command is sent to the hypervisor by calling the image system shutdown interface in the virtualization library through Nova. Then, the hypervisor sends the command to IPMITool to perform a shutdown operation on the physical machine. This releases the physical resources occupied by the zero-write operating system, which facilitates subsequent system deployment and management operations.

[0138] In summary, to further understand the operation request for releasing bare metal instances, see Figure 6b:

[0139] First, Nova sends a shutdown command to the hypervisor to shut down the bare metal instance (initially using the soft shutdown interface). The hypervisor then sends this shutdown command to IPMITool, which, using a command such as "power off," requests the physical machine of the bare metal instance to perform a shutdown operation. This completes the preparatory operations before releasing the bare metal instance.

[0140] Then, Nova sends an operation request command to the hypervisor to create and start a write-zero operating system. The hypervisor then sends this operation request command to IPMITool, which uses a command such as "power on" to complete the operation of creating and starting the write-zero operating system on the physical machine corresponding to the bare metal instance.

[0141] After completing the creation and startup of the write-zero operating system, Nova sends an erase command to the hypervisor. The hypervisor then sends the erase command to the write-zero operating system on the physical machine through the control channel between the write-zero operating system and the physical machine to erase the data on the corresponding disk.

[0142] Finally, Nova sends an operation request command to the hypervisor to shut down and delete the write-zero operating system. The hypervisor then sends this operation request command to IPMITool, which uses a command such as "power off" to complete the shutdown and deletion of the write-zero operating system on the physical machine corresponding to the bare metal instance.

[0143] When the operation request includes mounting a device, the smart card performs the target operation corresponding to the operation request on the bare metal instance based on the interface provided by the virtualization library. The execution flow can be presented by the timing diagram shown in Figure 7, and the detailed steps are as follows:

[0144] S701, when the operation request includes mounting a device, calls the mount interface in the virtualization library through Nova.

[0145] S702, Nova sends the first mount command to the hypervisor; the first mount command includes the first device type and mount method.

[0146] The first device type may include a network card or a disk.

[0147] Mounting methods may include hot-plugging or cold-plugging. Hot-plugging means inserting or removing the first device while the bare metal instance is running; cold-plugging means inserting or removing the first device only after the bare metal instance is shut down.

[0148] S703, through the hypervisor, modifies the metadata corresponding to the first device type in the bare metal instance based on the first mount command.

[0149] In the case of cold plugging and unplugging, after modifying the metadata and restarting the bare metal instance, the mounted device can be simulated and used by starting IOemu. For details, please refer to the subsequent S704-S705.

[0150] When the S704 is mounted in a hot-swappable manner, it sends a second mount command to IOemu through the hypervisor.

[0151] S705, via IOemu based on the second mount command, requests to simulate a device of the first device type in a bare metal instance through the serial bus interface.

[0152] The second mount command is derived from the first mount command. In implementation, the "chardev-add" instruction in the second mount command can be used to create a socket file, enabling data exchange between the hypervisor and IOemu. Then, IOemu uses the "device add" instruction to send the device to SDPCIe for mounting, thus simulating a device of the first device type in a bare metal instance.

[0153] In this embodiment, Nova, a hypervisor, and IOemu are used to mount devices on bare metal instances. The hypervisor can handle mounting operations in a relatively consistent manner, and the hypervisor and IOemu can flexibly support multiple mounting types and devices.

[0154] When the operation request includes unloading the device, the smart card performs the target operation corresponding to the operation request on the bare metal instance based on the interface provided by the virtualization library. The execution flow can be presented by the timing diagram shown in Figure 8, and the detailed steps are as follows:

[0155] S801, when the operation request includes unloading the device, calls the unloading interface in the virtualization library via Nova.

[0156] S802, Nova sends a first uninstallation command to the hypervisor; the first uninstallation command includes the second device type and uninstallation method.

[0157] The second device type may include unmounting a network interface card (NIC) or an unmounting disk. The unmounting method may include hot-plugging or cold-plugging.

[0158] S803 modifies the metadata corresponding to the second device type in the bare metal instance through the hypervisor based on the first unload instruction.

[0159] When the unloading method is hot-plugging, S804 sends a second unloading command to IOemu through the hypervisor.

[0160] S805, IOemu requests the unloading of a device of the second device type in a bare metal instance via the serial bus interface based on the second unloading instruction.

[0161] The second unload command is derived from the first unload command. In practice, the "device_del" command in the second unload command can be used to unload the device of the second device type, and then the "chardev-remove" command can be used to delete the socket file, thereby unloading the device of the second device type from the bare metal instance.

[0162] In this embodiment, Nova, a hypervisor, and IOemu are used to offload the bare metal instance. The hypervisor can better coordinate resource reclamation, including computing, storage, and network resources, thereby improving system resource utilization. The combination of the hypervisor and IOemu can support various device offloading methods, and new devices can be adapted by updating the simulation module.

[0163] When the operation request includes disk expansion, the smart card performs the target operation corresponding to the operation request on the bare metal instance based on the interface provided by the virtualization library. The execution flow can be presented by the timing diagram shown in Figure 9, and the detailed steps are as follows:

[0164] S901, when the operation request includes disk expansion, calls the expansion interface in the virtualization library through Nova.

[0165] S902, Nova sends a first expansion command to the virtual machine hypervisor; the first expansion command includes the expansion capacity and the expansion method.

[0166] The expanded capacity refers to the increased disk space. Expansion methods include hot-swapping and cold-swapping.

[0167] S903 modifies the metadata corresponding to the disk in the bare metal instance based on the first expansion instruction through the virtual machine hypervisor.

[0168] When the expansion method is hot-swappable, the S904 sends a second expansion command to IOemu through the hypervisor.

[0169] The S905, based on the second expansion command via IOemu, requests expansion of the disk in the bare metal instance by the required capacity through the serial bus interface.

[0170] In this embodiment, Nova, a hypervisor, and IOemu are used to expand the disk capacity of bare metal instances. The combination of the hypervisor and IOemu can flexibly adapt to diverse expansion needs, cope with different scales, types, and storage formats, and improve the success rate of expansion.

[0171] In summary, the overall framework of the bare metal instance control method provided in this disclosure is shown in Figure 10, and mainly includes two parts:

[0172] Part 1: Northbound Interface. This is the application programming interface (API) exposed by the hypervisor to Nova, allowing Nova to call the same interfaces in the virtualization library as the virtual machine to operate the bare metal instance. The interfaces in the virtualization library and the application programming interface in the hypervisor are identical in format and semantics.

[0173] Part Two: Southbound Interface. The hypervisor uses the Intelligent Platform Management Interface Tool (IPMITool) based on the target instructions to implement power operations for bare metal instances. It also implements device mounting, unmounting, and disk expansion operations for bare metal instances by encapsulating a QMP message request input / output simulator (IOemu).

[0174] As shown in Figure 10, in S1001, Nova responds to operation requests and calls the interfaces provided by the virtualization library. In S1002, Nova encapsulates the target instruction corresponding to the operation request into an RPC message and sends it to the hypervisor. The operation request may include: creating a bare metal instance, starting a bare metal instance, closing a bare metal instance, releasing a bare metal instance, mounting a bare metal device, unmounting a bare metal device, expanding disk capacity, etc.

[0175] In S1003, the hypervisor can receive target instructions sent by Nova via the application programming interface (API). In S1004, the domain connection management object calls the client driver to send the target instructions to the fast simulator driver, which then calls different components to perform the target operation corresponding to the operation request on the bare metal instance.

[0176] Since the hypervisor does not support direct connection to the serial bus interface (SDPCie), to avoid the additional development and management issues caused by direct connection, the implementation can proceed as follows: In S1005, the fast simulator driver encapsulates the target instruction into a QMP message and sends it to IOemu. Then, in S1006, IOemu converts the QMP message into an RPC message and sends it to the serial bus interface. Finally, in S1007, the serial bus interface inputs this message to the Field-Programmable Gate Array (FPGA) to complete communication with the physical machine. This allows for the mounting and unmounting of bare-metal instance devices and disk expansion operations via IOemu.

[0177] Alternatively, in S1008, the target instruction is interpreted into a target instruction that the physical machine can understand via Bash (Bourne-Again Shell, a command interpreter) and sent to IPMITool. Then, in S1009, the power supply of the bare metal instance is managed via a smart card and the Baseboard Management Controller (BMC) in the physical machine.

[0178] Figure 11 illustrates the bare-metal instance management architecture based on a smart card provided in this embodiment. In S1101, the smart card can call an interface in the virtualization library to send the target instruction corresponding to the operation request to the hypervisor. Then, in S1102, the hypervisor receives the target instruction based on the application programming interface (API). Next, in S1103, the domain connection management object encapsulates the target instruction into an RPC message and sends it to the fast emulator driver by calling its internal client driver. In S1104, the fast emulator driver communicates with IOemu based on QMP messages. The hypervisor includes the API shown in Figure 11, the domain connection management object and its internal client driver, the fast emulator driver which communicates with the client driver via the RPC protocol, and IOemu which communicates with the fast emulator driver based on QMP messages.

[0179] In summary, the bare metal instance management method provided in this disclosure unifies the management planes of virtual machines and bare metal instances, reducing the workload of related interface development and testing, and shortening the product backend system release cycle, thereby reducing the R&D and maintenance costs of bare metal products. Furthermore, the operation path of bare metal instances no longer depends on components such as CSOC, reducing component dependencies and improving product delivery efficiency. Experimental data also shows that it can improve the product's operation success rate from the original 95% to 99.9%. Operation time can be shortened from the original 20 minutes to approximately 5 minutes. Unifying the management structure of bare metal instances with the operation interface of virtual machine instances can reduce the workload of OpenStack related interface development and testing, and shorten the product backend system release cycle.

[0180] Based on the same technical concept, this disclosure also proposes a control device 1200 for bare metal samples, as shown in Figure 12, including:

[0181] The receiving module 1201 is used to receive operation requests for bare metal instances via a smart card;

[0182] The execution module 1202 is used to perform the target operation corresponding to the operation request on the bare metal instance through the interface provided by the smart card based on the virtualization library.

[0183] In some embodiments, the smart card includes Nova, a hypervisor, the smart platform management interface tool IPMITool, and IOemu;

[0184] Nova is used to respond to operation requests, call the interfaces provided by the virtualization library, and send the target instructions corresponding to the operation request to the hypervisor.

[0185] A hypervisor, used to generate execution instructions based on target instructions and send them to IPMITool and / or IOemu;

[0186] IPMITool is used to perform power management operations on bare metal instances;

[0187] IOemu is used to perform at least one of the following operations on bare metal instances: mounting devices, unmounting devices, and expanding disks.

[0188] In some embodiments, the execution module includes a creation unit for:

[0189] When the operation request includes creating an instance, the instance creation command is sent to the hypervisor by calling the defined instance type interface in the virtualization library through Nova.

[0190] A bare metal instance is created by responding to the instance creation command through the hypervisor.

[0191] In some embodiments, the execution module includes a startup unit for:

[0192] When the operation request includes starting an instance, the instance start command is sent to the hypervisor through the Nova instance start interface in the virtualization library;

[0193] Send the startup command to IOemu through the hypervisor;

[0194] The system disk and network card of the bare metal instance are initialized using IOemu based on the boot command;

[0195] If IOemu starts successfully, the power-on command is sent to IPMITool through the hypervisor;

[0196] IPMITool, based on the power-on command, instructs the physical machine corresponding to the bare metal instance to perform a power-on operation.

[0197] In some embodiments, a synchronization unit is further included, for:

[0198] Check the physical machine's power status using IPMITool;

[0199] Once the physical machine is confirmed to have been successfully powered on, the power status is sent to the hypervisor via IPMITool;

[0200] The power state of the bare metal instance is updated to power-on state via the hypervisor to synchronize the power state with Nova.

[0201] In some embodiments, the execution module includes a first shutdown unit for:

[0202] In cases where the operation request includes shutting down the bare metal instance, the soft shutdown command is sent to the hypervisor by calling the soft shutdown interface in the virtualization library through Nova.

[0203] The hypervisor responds to the soft shutdown command and sends the shutdown command to IPMITool.

[0204] Using IPMITool, a shutdown command is used to request the physical machine of the bare metal instance to perform a shutdown operation;

[0205] By polling the power status of the physical machine using IPMITool, and determining that the physical machine is in a power-off state, the virtual machine hypervisor is notified to update the power status of the bare metal instance to a power-off state.

[0206] IOemu can be shut down using the hypervisor based on the shutdown status.

[0207] In some embodiments, the execution module includes a second shutdown unit for:

[0208] In the event of a failed soft shutdown, the hard shutdown command is sent to the hypervisor by calling the hard shutdown interface in the virtualization library through Nova.

[0209] The hypervisor responds to the hard shutdown command by sending the shutdown command to IPMITool;

[0210] Using IPMITool, a shutdown command is used to request the physical machine of the bare metal instance to perform a shutdown operation;

[0211] Poll the physical machine's power status using IPMITool;

[0212] If the power status of the physical machine is found to be "on" within a preset time period, IOemu is shut down via the hypervisor.

[0213] In some embodiments, the execution module includes a release unit for:

[0214] If the operation request includes releasing the bare metal instance, Nova calls the release instance interface in the virtualization library to send the release command to the hypervisor if it is determined that the bare metal instance will be shut down.

[0215] The hypervisor responds to the release command and creates a write-zero operating system to the physical machine corresponding to the bare metal instance based on the image file;

[0216] The target data on the physical machine is erased using a virtual machine hypervisor based on a write-zero operating system.

[0217] In some embodiments, a clearing module is further included, for:

[0218] The image system shutdown command is sent to the hypervisor by calling the image system shutdown interface in the virtualization library through Nova.

[0219] The hypervisor responds to the image system's shutdown command by sending the shutdown command to IPMITool;

[0220] IPMITool requests the physical machine of the bare metal instance to perform a shutdown operation based on the shutdown command.

[0221] In some embodiments, the execution module includes a mounting unit for:

[0222] When the operation request includes mounting a device, the mount interface in the virtualization library is called through Nova to send a first mount command to the virtual machine hypervisor; the first mount command includes the first device type and mount method;

[0223] The hypervisor modifies the metadata corresponding to the first device type in the bare metal instance based on the first mount command.

[0224] When the mounting method is hot-plug, the second mount command is sent to IOemu through the hypervisor;

[0225] Based on the second mount command, IOemu requests, via the serial bus interface, to simulate a device of the first device type in a bare metal instance.

[0226] In some embodiments, the execution module includes an unloading unit for:

[0227] When the operation request includes unloading a device, the unloading interface in the virtualization library is called through Nova to send a first unloading instruction to the hypervisor; the first unloading instruction includes the second device type and the unloading method;

[0228] The hypervisor modifies the metadata corresponding to the second device type in the bare metal instance based on the first uninstallation command;

[0229] When the unloading method is hot-plugging, the second unloading command is sent to IOemu through the hypervisor;

[0230] IOemu, based on the second unload instruction, requests the unloading of a device of the second device type in a bare metal instance via the serial bus interface.

[0231] In some embodiments, the execution module includes a scaling unit for:

[0232] When the operation request includes disk expansion, the expansion interface in the virtualization library is called through Nova to send a first expansion instruction to the hypervisor; the first expansion instruction includes the expansion capacity and the expansion method;

[0233] The metadata corresponding to the disk in the bare metal instance is modified using the hypervisor based on the first expansion instruction.

[0234] When the expansion method is hot-swappable, the hypervisor sends a second expansion command to IOemu.

[0235] Using IOemu based on the second expansion command, a request is made via the serial bus interface to expand the disk in the bare metal instance by the required capacity.

[0236] In some embodiments, the hypervisor and IOemu communicate using the Quick Emulator Monitoring Protocol (QMP) message communication.

[0237] In some embodiments, the hypervisor includes:

[0238] Application Programming Interface (API) is used to receive target instructions sent by Nova;

[0239] The domain connection management object is used to invoke the client driver to send execution instructions to the fast emulator driver based on the target instruction;

[0240] The fast simulator driver is used to communicate with IOemu and / or IPMITool.

[0241] The specific functions and examples of each module and submodule of the apparatus in this disclosure can be found in the relevant descriptions of the corresponding steps in the above method embodiments, and will not be repeated here.

[0242] The acquisition, storage, and application of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0243] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0244] Figure 13 illustrates a schematic block diagram of an example electronic device 1300 that can be used to implement embodiments of the present disclosure. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0245] As shown in Figure 13, device 1300 includes a computing unit 1301, which can perform various appropriate actions and processes according to a computer program stored in read-only memory (ROM) 1302 or a computer program loaded from storage unit 1308 into random access memory (RAM) 1303. The RAM 1303 may also store various programs and data required for the operation of device 1300. The computing unit 1301, ROM 1302, and RAM 1303 are interconnected via bus 1304. Input / output (I / O) interface 1305 is also connected to bus 1304.

[0246] Multiple components in device 1300 are connected to I / O interface 1305, including: input unit 1306, such as keyboard, mouse, etc.; output unit 1307, such as various types of monitors, speakers, etc.; storage unit 1308, such as disk, optical disk, etc.; and communication unit 1309, such as network card, modem, wireless transceiver, etc. Communication unit 1309 allows device 1300 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0247] The computing unit 1301 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 1301 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 1301 performs the various methods and processes described above, such as the bare metal instance management method. For example, in some embodiments, the bare metal instance management method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 1308. In some embodiments, part or all of the computer program may be loaded and / or installed on device 1300 via ROM 1302 and / or communication unit 1309. When the computer program is loaded into RAM 1303 and executed by the computing unit 1301, one or more steps of the bare metal instance management method described above may be performed. Alternatively, in other embodiments, computing unit 1301 may be configured to perform a management method for bare metal instances by any other suitable means (e.g., by means of firmware).

[0248] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0249] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0250] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0251] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0252] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with embodiments of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0253] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0254] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0255] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A method for controlling bare metal instances, comprising: The smart card receives an operation request for the bare metal instance; The smart card performs the target operation corresponding to the operation request on the bare metal instance based on the interface provided by the virtualization library.

2. The method according to claim 1, wherein, The smart card includes a computing control plane Nova, a virtual machine hypervisor, a smart platform management interface tool IPMITool, and an input / output simulator IOemu; The Nova is used to respond to the operation request by calling the interface provided by the virtualization library and sending the target instruction corresponding to the operation request to the virtual machine management program; The virtual machine management program is used to generate execution instructions based on the target instructions and send them to the IPMITool and / or the IOemu; The IPMITool is used to perform power management operations on the bare metal instance; The IOemu is used to perform at least one of the following operations on the bare metal instance: mounting a device, unmounting a device, and expanding the disk.

3. The method according to claim 2, wherein, The smart card, based on the interface provided by the virtualization library, performs the target operation corresponding to the operation request on the bare metal instance, including: If the operation request includes creating an instance, the instance creation instruction is sent to the hypervisor by calling the instance type definition interface in the virtualization library through Nova. The bare metal instance is created by the hypervisor responding to the instance creation command.

4. The method according to claim 2 or 3, wherein, The smart card, based on the interface provided by the virtualization library, performs the target operation corresponding to the operation request on the bare metal instance, including: If the operation request includes starting an instance, the instance startup command is sent to the hypervisor via the Nova based on the instance startup interface in the virtualization library; The hypervisor sends a startup command to the IOemu. The IOemu initializes the system disk and network card of the bare metal instance based on the boot command; If the IOemu is successfully started, the power-on command is sent to the IPMITool through the hypervisor; The IPMITool, based on the power-on command, instructs the physical machine corresponding to the bare metal instance to perform a power-on operation.

5. The method according to claim 4, further comprising: Check the power status of the physical machine using the IPMITool; Once it is confirmed that the physical machine has been successfully powered on, the power status is sent to the virtual machine management program via the IPMITool; The power state of the bare metal instance is updated to power-on state by the hypervisor, so as to synchronize the power state with Nova.

6. The method according to claim 2, wherein, The smart card, based on the interface provided by the virtualization library, performs the target operation corresponding to the operation request on the bare metal instance, including: If the operation request includes shutting down the bare metal instance, the soft shutdown command is sent to the hypervisor by calling the soft shutdown interface in the virtualization library through Nova. The hypervisor responds to the soft shutdown command by sending the shutdown command to IPMITool; The IPMITool requests the physical machine of the bare metal instance to perform a shutdown operation based on the shutdown command. The IPMITool polls the power status of the physical machine. If the power status of the physical machine is determined to be off, the virtual machine hypervisor is notified to update the power status of the bare metal instance to off. The IOemu is shut down using the hypervisor based on the shutdown status.

7. The method according to claim 2 or 6, wherein, The smart card, based on the interface provided by the virtualization library, performs the target operation corresponding to the operation request on the bare metal instance, including: In the event that a soft shutdown fails, the Nova calls the hard shutdown interface in the virtualization library to send a hard shutdown command to the hypervisor. The hypervisor responds to the hard shutdown command by sending a shutdown command to the IPMITool; The IPMITool requests the physical machine of the bare metal instance to perform a shutdown operation based on the shutdown command. The power status of the physical machine is polled using the IPMITool; If the power status of the physical machine is found to be "on" within a preset time period, the IOemu is shut down through the virtual machine management program.

8. The method according to claim 2, wherein, The smart card, based on the interface provided by the virtualization library, performs the target operation corresponding to the operation request on the bare metal instance, including: If the operation request includes releasing the bare metal instance, Nova, upon determining that the bare metal instance should be shut down, calls the release instance interface in the virtualization library to send the release instruction to the hypervisor. The hypervisor responds to the release command and creates a write-zero operating system on the physical machine corresponding to the bare metal instance based on the image file. The target data on the physical machine is erased by the hypervisor based on the write-zero operating system.

9. The method according to claim 8, further comprising: The image system shutdown command is sent to the virtual machine management program by calling the image system shutdown interface in the virtualization library through Nova. The hypervisor responds to the image system's shutdown command by sending the shutdown command to IPMITool; The IPMITool requests the physical machine of the bare metal instance to perform a shutdown operation based on the shutdown command.

10. The method according to claim 2, wherein, The smart card, based on the interface provided by the virtualization library, performs the target operation corresponding to the operation request on the bare metal instance, including: If the operation request includes mounting a device, the Nova calls the mount interface in the virtualization library to send a first mount instruction to the hypervisor; the first mount instruction includes a first device type and a mount method; The virtual machine management program modifies the metadata corresponding to the first device type in the bare metal instance based on the first mount instruction. When the mounting method is hot-plug, the hypervisor sends a second mount command to the IOemu. Based on the second mount command, the IOemu requests, via the serial bus interface, to simulate a device of the first device type in the bare metal instance.

11. The method according to claim 2, wherein, The smart card, based on the interface provided by the virtualization library, performs the target operation corresponding to the operation request on the bare metal instance, including: If the operation request includes uninstalling a device, the Nova calls the uninstallation interface in the virtualization library to send a first uninstallation command to the hypervisor; the first uninstallation command includes a second device type and an uninstallation method; The hypervisor modifies the metadata corresponding to the second device type in the bare metal instance based on the first uninstallation instruction. When the unloading method is hot-plugging, the hypervisor sends a second unloading command to the IOemu. Based on the second unload instruction, the IOemu requests the unloading of the device of the second device type from the bare metal instance via the serial bus interface.

12. The method according to claim 2, wherein, The smart card, based on the interface provided by the virtualization library, performs the target operation corresponding to the operation request on the bare metal instance, including: If the operation request includes disk expansion, the Nova calls the expansion interface in the virtualization library to send a first expansion instruction to the hypervisor; the first expansion instruction includes the expansion capacity and the expansion method. The virtual machine management program modifies the metadata corresponding to the disk in the bare metal instance based on the first expansion instruction. When the expansion method is hot-plugging, the hypervisor sends a second expansion command to the IOemu. The IOemu, based on the second expansion command, requests, via the serial bus interface, to expand the disk capacity of the bare metal instance.

13. The method according to any one of claims 2-12, wherein, The hypervisor and IOemu communicate using the Quick Emulator Monitoring Protocol (QMP).

14. The method according to any one of claims 2-13, wherein, The hypervisor includes: Application programming interface (API) for receiving target instructions sent by Nova; The domain connection management object is used to call the client driver to send execution instructions to the fast emulator driver based on the target instruction; The fast simulator driver is used to communicate with the IOemu and / or IPMITool.

15. A control device for a bare metal sample, comprising: The receiving module is used to receive operation requests for bare metal instances via a smart card; The execution module is used to perform the target operation corresponding to the operation request on the bare metal instance through the interface provided by the smart card based on the virtualization library.

16. The apparatus according to claim 15, wherein, The smart card includes a computing control plane Nova, a virtual machine hypervisor, a smart platform management interface tool IPMITool, and an input / output simulator IOemu; The Nova is used to respond to the operation request by calling the interface provided by the virtualization library and sending the target instruction corresponding to the operation request to the virtual machine management program; The virtual machine management program is used to generate execution instructions based on the target instructions and send them to the IPMITool and / or the IOemu; The IPMITool is used to perform power management operations on the bare metal instance; The IOemu is used to perform at least one of the following operations on the bare metal instance: mounting a device, unmounting a device, and expanding the disk.

17. The apparatus according to claim 16, wherein, The execution module includes a creation unit, used for: If the operation request includes creating an instance, the instance creation instruction is sent to the hypervisor by calling the instance type definition interface in the virtualization library through Nova. The bare metal instance is created by the hypervisor responding to the instance creation command.

18. The apparatus according to claim 16 or 17, wherein, The execution module includes a startup unit, used for: If the operation request includes starting an instance, the instance startup command is sent to the hypervisor via the Nova based on the instance startup interface in the virtualization library; The hypervisor sends a startup command to the IOemu. The IOemu initializes the system disk and network card of the bare metal instance based on the boot command; If the IOemu is successfully started, the power-on command is sent to the IPMITool through the hypervisor; The IPMITool, based on the power-on command, instructs the physical machine corresponding to the bare metal instance to perform a power-on operation.

19. The apparatus of claim 18, further comprising a synchronization unit for: Check the power status of the physical machine using the IPMITool; Once it is confirmed that the physical machine has been successfully powered on, the power status is sent to the virtual machine management program via the IPMITool; The power state of the bare metal instance is updated to power-on state by the hypervisor, so as to synchronize the power state with Nova.

20. The apparatus according to claim 16, wherein, The execution module includes a first shutdown unit, used for: If the operation request includes shutting down the bare metal instance, the soft shutdown command is sent to the hypervisor by calling the soft shutdown interface in the virtualization library through Nova. The hypervisor responds to the soft shutdown command by sending the shutdown command to IPMITool; The IPMITool requests the physical machine of the bare metal instance to perform a shutdown operation based on the shutdown command. The IPMITool polls the power status of the physical machine. If the power status of the physical machine is determined to be off, the virtual machine hypervisor is notified to update the power status of the bare metal instance to off. The IOemu is shut down using the hypervisor based on the shutdown status.

21. The apparatus according to claim 16 or 20, wherein, The execution module includes a second shutdown unit, used for: In the event that a soft shutdown fails, the Nova calls the hard shutdown interface in the virtualization library to send a hard shutdown command to the hypervisor. The hypervisor responds to the hard shutdown command by sending a shutdown command to the IPMITool; The IPMITool requests the physical machine of the bare metal instance to perform a shutdown operation based on the shutdown command. The power status of the physical machine is polled using the IPMITool; If the power status of the physical machine is found to be "on" within a preset time period, the IOemu is shut down through the virtual machine management program.

22. The apparatus according to claim 16, wherein, The execution module includes a release unit, used for: If the operation request includes releasing the bare metal instance, Nova, upon determining that the bare metal instance should be shut down, calls the release instance interface in the virtualization library to send the release instruction to the hypervisor. The hypervisor responds to the release command and creates a write-zero operating system on the physical machine corresponding to the bare metal instance based on the image file. The target data on the physical machine is erased by the hypervisor based on the write-zero operating system.

23. The apparatus of claim 22, further comprising a cleaning module for: The image system shutdown command is sent to the virtual machine management program by calling the image system shutdown interface in the virtualization library through Nova. The hypervisor responds to the image system's shutdown command by sending the shutdown command to IPMITool; The IPMITool requests the physical machine of the bare metal instance to perform a shutdown operation based on the shutdown command.

24. The apparatus according to claim 16, wherein, The execution module includes a mounting unit, used for: If the operation request includes mounting a device, the Nova calls the mount interface in the virtualization library to send a first mount instruction to the hypervisor; the first mount instruction includes a first device type and a mount method; The hypervisor modifies the metadata corresponding to the first device type in the bare metal instance based on the first mount command: When the mounting method is hot-plug, the hypervisor sends a second mount command to the IOemu. Based on the second mount command, the IOemu requests, via the serial bus interface, to simulate a device of the first device type in the bare metal instance.

25. The apparatus according to claim 16, wherein, The execution module includes an unloading unit, used for: If the operation request includes uninstalling a device, the Nova calls the uninstallation interface in the virtualization library to send a first uninstallation command to the hypervisor; the first uninstallation command includes a second device type and an uninstallation method; The hypervisor modifies the metadata corresponding to the second device type in the bare metal instance based on the first uninstallation instruction. When the unloading method is hot-plugging, the hypervisor sends a second unloading command to the IOemu. Based on the second unload instruction, the IOemu requests the unloading of the device of the second device type from the bare metal instance via the serial bus interface.

26. The apparatus according to claim 16, wherein, The execution module includes a capacity expansion unit, used for: If the operation request includes disk expansion, the Nova calls the expansion interface in the virtualization library to send a first expansion instruction to the hypervisor; the first expansion instruction includes the expansion capacity and the expansion method. The virtual machine management program modifies the metadata corresponding to the disk in the bare metal instance based on the first expansion instruction. When the expansion method is hot-plugging, the hypervisor sends a second expansion command to the IOemu. The IOemu, based on the second expansion command, requests, via the serial bus interface, to expand the disk capacity of the bare metal instance.

27. The apparatus according to any one of claims 16-26, wherein, The hypervisor and IOemu communicate using the Quick Emulator Monitoring Protocol (QMP).

28. The apparatus according to any one of claims 16-27, wherein, The hypervisor includes: Application programming interface (API) for receiving target instructions sent by Nova; The domain connection management object is used to call the client driver to send execution instructions to the fast emulator driver based on the target instruction; The fast simulator driver is used to communicate with the IOemu and / or IPMITool.

29. An electronic device comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-14.

30. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-14.

31. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1-14.

Images