Cloud desktop system based on terminal bare metal technology and bare metal starting method

Abstract

The invention discloses a cloud desktop system based on a terminal bare metal technology and a bare metal starting method. When a terminal device is started, a normal boot flow of loading a local system is interrupted by initializing an initialization script in a memory disk system; starting the bare metal client, and obtaining connection information and user authentication information of the cloud platform server through the bare metal client; calling an API interface of a cloud platform server, and obtaining a virtual machine list supporting starting of the bare metal; determining a target virtual machine from the virtual machine list based on user selection; mounting a target disk file corresponding to the target virtual machine to the terminal equipment in a block equipment form through a network; and guiding an operating system in the target disk file to enable the target virtual machine to run on the terminal equipment in a bare metal mode, and directly calling a graphic processing unit of the terminal equipment to carry out graphic rendering and output. The problem that a traditional cloud desktop is insufficient in performance under high-load graphic application scenes such as 3D rendering and high-definition videos is solved.

Description

Technical Field

[0001] This application relates to the field of computers, and in particular to a cloud desktop system based on bare metal terminal technology and a bare metal boot method. Background Technology

[0002] Currently, in cloud platforms based on domestic processors such as Phytium, Loongson, and Kunpeng, mainstream cloud desktop solutions generally adopt KVM and QEMU as the underlying virtualization architecture. QEMU integrates a SPICE server, enabling the widespread application of cloud desktops based on the SPICE transmission protocol. However, this conventional SPICE protocol is mainly geared towards ordinary office scenarios such as document editing and web browsing. Its graphics transmission mechanism often fails to deliver satisfactory results when facing high graphics load demands such as running professional 3D design software or playing high-definition videos, exhibiting noticeable stuttering and latency.

[0003] To improve the media playback experience, the industry has proposed video streaming solutions based on SPICE streaming agents. However, this solution is essentially a software-encoded streaming media transmission method, which cannot fundamentally avoid frame drops caused by network fluctuations. More importantly, video data needs to be encoded on the server side and then decoded on the client side. This multiple encoding and decoding process not only introduces additional processing latency but also leads to a significant difference between the final displayed image and the original rendering effect on the server side, resulting in a loss of color, detail, and smoothness.

[0004] In summary, existing virtualized cloud desktop technologies are limited by their architecture and face inherent bottlenecks in graphics processing, such as high performance loss and low transmission efficiency, making it difficult to meet the requirements of application scenarios with stringent graphics performance requirements. Summary of the Invention

[0005] This application provides a cloud desktop system and a bare metal boot method based on terminal bare metal technology, which can solve the problems of high graphics performance loss, inability to directly call terminal GPU hardware, high latency and poor image quality when running 3D applications or high-definition videos in existing virtualized cloud desktops.

[0006] In a first aspect, this application provides a cloud desktop system based on bare metal terminal technology, comprising: Terminal devices, cloud platform servers, initialization memory disk systems, and bare metal clients; The terminal device is equipped with a graphics processing unit and a network interface to provide local computing and display capabilities. The cloud platform server provides API interfaces for querying and managing candidate virtual machines, and manages and stores the virtual machine disk files corresponding to the candidate virtual machines; The initialization of the memory disk system is deployed on the terminal device and is loaded into memory and run by the bootloader during the terminal device's boot process. The memory disk system initialization contains an initialization script, which is configured to interrupt the normal boot process of loading the local system and start the bare metal client. The bare metal client provides a user interface to obtain connection information and user authentication information from the cloud platform server; it calls API interfaces to obtain a list of virtual machines that support bare metal booting; and it determines the target virtual machine selected by the user based on the user's selection and the list of virtual machines. Based on the target virtual machine and the virtual machine disk file, a request is sent to the cloud platform server to mount the target disk file corresponding to the target virtual machine to the terminal device in the form of a block device. After successful mounting, the operating system in the target disk file is booted so that the target virtual machine can run on the terminal device in bare metal mode and directly call the graphics processing unit for graphics rendering and output.

[0007] Secondly, this application provides a cloud desktop method based on bare metal terminal technology, including: When the terminal device starts up, the normal boot process of loading the local system is interrupted by initializing the initialization script in the memory disk system. Launch the bare metal client to obtain connection information and user authentication information from the cloud platform server. Call the API interface of the cloud platform server to obtain a list of virtual machines that support bare metal booting; Based on user selection, the target virtual machine is determined from the list of virtual machines; Mount the target disk file corresponding to the target virtual machine to the terminal device via the network as a block device; The operating system in the target disk file is booted so that the target virtual machine can run on the terminal device in a bare metal manner and directly call the terminal device's graphics processing unit for graphics rendering and output.

[0008] This application provides a cloud desktop system and bare metal boot method based on terminal bare metal technology. When the terminal device boots, the normal boot process of the local system is interrupted by initializing the initialization script in the memory disk system; a bare metal client is launched to obtain connection information and user authentication information from the cloud platform server; the API interface of the cloud platform server is called to obtain a list of virtual machines supporting bare metal boot; based on user selection, a target virtual machine is determined from the list; the target disk file corresponding to the target virtual machine is network mounted to the terminal device as a block device; the operating system in the target disk file is booted, enabling the target virtual machine to run on the terminal device in bare metal mode and directly call the terminal device's graphics processing unit for graphics rendering and output. This solves the problem of insufficient performance of traditional cloud desktops in high-load graphics application scenarios such as 3D rendering and high-definition video.

[0009] The further effects of the aforementioned non-conventional preferred method will be explained below in conjunction with specific embodiments. Attached Figure Description

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

[0011] Figure 1 A schematic diagram of the structure of a cloud desktop system based on bare metal terminal technology is provided in one embodiment of this application; Figure 2 A flowchart illustrating a bare-metal boot method for a cloud desktop system provided in an embodiment of this application; Figure 3 This is a flowchart illustrating another bare-metal boot method for a cloud desktop system provided in an embodiment of this application. Detailed Implementation

[0012] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0013] Currently, in cloud platforms based on domestic processors such as Phytium, Loongson, and Kunpeng, mainstream cloud desktop solutions generally adopt KVM and QEMU as the underlying virtualization architecture. QEMU integrates a SPICE server, enabling the widespread application of cloud desktops based on the SPICE transmission protocol. However, this conventional SPICE protocol is mainly geared towards ordinary office scenarios such as document editing and web browsing. Its graphics transmission mechanism often fails to deliver satisfactory results when facing high graphics load demands such as running professional 3D design software or playing high-definition videos, exhibiting noticeable stuttering and latency.

[0014] To improve the media playback experience, the industry has proposed video streaming solutions based on SPICE streaming agents. However, this solution is essentially a software-encoded streaming media transmission method, which cannot fundamentally avoid frame drops caused by network fluctuations. More importantly, video data needs to be encoded on the server side and then decoded on the client side. This multiple encoding and decoding process not only introduces additional processing latency but also leads to a significant difference between the final displayed image and the original rendering effect on the server side, resulting in a loss of color, detail, and smoothness.

[0015] In summary, existing virtualized cloud desktop technologies are limited by their architecture and face inherent bottlenecks in graphics processing, such as high performance loss and low transmission efficiency, making it difficult to meet the requirements of application scenarios with stringent graphics performance requirements.

[0016] To address this issue, this application proposes a cloud desktop system based on bare metal terminal technology. (See attached document.) Figure 1 As shown, this system aims to address issues such as high graphics performance degradation in existing virtualized cloud desktops, inability to directly access terminal GPU hardware, and high latency and poor image quality when running 3D applications or high-definition videos. In this embodiment, a cloud desktop system based on bare metal terminal technology includes: a terminal device 101, a cloud platform server 102, an initialization memory disk system 103, and a bare metal client 104.

[0017] The cloud desktop system employs an innovative architecture design, breaking through the performance bottlenecks of traditional virtualized cloud desktops. Unlike conventional cloud desktop solutions, this system intervenes in the boot process during the terminal device's 101 startup phase, directly mounting the cloud virtual machine disk file to the local terminal as a network block device, enabling the virtual machine operating system to run directly on the terminal hardware. The core advantage of this architecture design is that the virtual machine, when running on the terminal, can bypass the cloud platform's virtualization layer and remote display protocol layer, directly utilizing the terminal's physical GPU hardware, thereby achieving near-physical machine graphics performance.

[0018] Terminal device 101 is equipped with a graphics processing unit and a network interface to provide local computing and display capabilities.

[0019] As the physical carrier and execution environment of the system, terminal device 101 is responsible for running a virtual machine operating system and providing high-performance graphics output. Its graphics processing unit (GPU) is the hardware foundation for achieving high-quality graphics rendering, and can directly handle tasks such as 3D graphics calculation, video decoding, and high-definition image output.

[0020] The network interface is responsible for establishing a network connection with the cloud platform server 102, mounting virtual machine disk files on remote storage, and synchronizing data when necessary. The combination of the local computing power of the terminal device 101 and the management capabilities of the cloud allows users to enjoy the advantages of centralized management and rapid deployment of cloud desktops, while also obtaining a user experience and graphics performance close to that of a local physical machine.

[0021] Cloud platform server 102 is used to provide API interfaces for querying and managing alternative virtual machines, and to manage and store the virtual machine disk files corresponding to the alternative virtual machines.

[0022] As the management hub of the entire cloud desktop system, the cloud platform server 102 provides services such as virtual machine query, authentication and authorization, and resource allocation to the terminal device 101 through standardized API interfaces, enabling the bare metal client 104 to obtain the list of virtual machines that the current user is authorized to access and their detailed configuration information.

[0023] Meanwhile, the cloud platform server 102 maintains a complete virtual machine disk file storage system. These disk files can run in the cloud using traditional virtualization methods, enjoying advanced management functions such as snapshots, backups, and hot migration. Alternatively, they can be exposed to terminal devices via network storage protocols for bare-metal booting. This dual-mode design ensures system flexibility, allowing the same virtual machine to run in the cloud in a traditional way for maintenance and management, and also to run on the terminal in a bare-metal manner to achieve ultimate performance.

[0024] The cloud platform server 102 is built on a domestic processor architecture; the domestic processor architecture includes Phytium architecture, Loongson architecture and Kunpeng architecture; the virtualization layer adopts a combination architecture of KVM and QEMU.

[0025] In recent years, domestically developed processors such as Phytium, Loongson, and Kunpeng have made significant progress in performance and ecosystem development, and are now capable of supporting the stable operation of large-scale cloud computing platforms. KVM, as a native virtualization module of the Linux kernel, provides efficient hardware virtualization capabilities, while QEMU is responsible for device emulation and virtual machine management. This mature virtualization technology stack has been fully adapted and optimized for domestic processor platforms, providing stable and reliable underlying support for cloud desktops.

[0026] The memory disk system 103 is initialized and deployed on the terminal device 101. It is used to be loaded into memory and run by the boot loader during the startup process of the terminal device 101. The memory disk system 103 contains an initialization script, which is configured to interrupt the normal boot process of loading the local system and start the bare metal client 104.

[0027] The initialization of the RAM disk system 103 plays a role in the specific time window after the kernel is loaded and before the root file system is mounted. This embodiment takes advantage of the customizability of this boot phase by modifying the initialization script in the initialization of the RAM disk system 103 to redirect the process originally used to boot the local operating system to the bare metal client 104.

[0028] This intervention method does not require modification of the BIOS, boot loader, or kernel itself; it can be implemented simply by modifying the script logic within the initialization memory disk system 103. It boasts advantages such as ease of implementation and good compatibility. The initialization memory disk system 103 provides the necessary runtime environment for bare-metal booting, including basic functions such as network drivers and storage protocol support. This enables the system to complete network communication with the cloud platform and remote disk mounting operations even before an actual root file system is mounted.

[0029] After the initialization script runs, it disables the original root file system loading instructions of the local system; sets environment variables to support network communication and block device access; and executes the shell command to start the bare metal client, transferring system boot control to the bare metal client 104.

[0030] Disabling the original root file system loading instructions means the system will no longer mount and boot the locally installed system on the terminal according to the default path, thus freeing up control of the boot process for loading the cloud virtual machine disk. Environment variable settings provide necessary configuration support for subsequent network and block device operations, such as network interface configuration and iSCSI client parameters. Finally, by executing a shell command to start the bare metal client 104, the system's boot control is completely handed over, making the bare metal client 104 the new leader of the boot process. This design ensures the continuity of the boot process while achieving a seamless switch from local boot to cloud disk boot.

[0031] The bare metal client 104 is used to provide a user interface to obtain connection information and user authentication information from the cloud platform server 102; call the API interface to obtain a list of virtual machines corresponding to the candidate virtual machines that support bare metal boot; and determine the target virtual machine selected by the user based on the user selection and the list of virtual machines.

[0032] The bare metal client 104 handles a series of tasks, including user interaction, authentication, virtual machine selection, and remote mounting. In the early stages of system startup, users input necessary connection parameters and authentication credentials through the interface provided by the bare metal client 104. This information enables the client to establish a secure communication channel with the cloud platform server.

[0033] By calling the API interface of the cloud platform server 102, the bare metal client 104 can obtain a list of virtual machines that the current user has access to and that support bare metal booting. This list may contain key metadata such as the name, configuration information, and storage location of the virtual machines. The user selects the target virtual machine to boot from the list according to their needs, and the bare metal client 104 is responsible for recording this selection and preparing for subsequent disk mounting and system booting operations.

[0034] The bare metal client 104 is implemented based on the Shell scripting language and provides a character-based interactive interface; connection information includes the terminal IP address and the server IP address; user authentication information includes the username and password.

[0035] Shell scripts have natural compatibility with the Linux initrd environment, requiring no additional runtime environment or dependency libraries, and can run stably in the early stages of system startup. Secondly, shell scripts are easy to write and maintain, and can easily call system commands and network tools to perform operations such as interacting with cloud platform APIs, establishing iSCSI connections, and mounting devices. While the character-based interactive interface is simple, it is the most reliable interaction method during startup, as it does not rely on loading a graphical system.

[0036] The terminal IP address is used to configure the local network interface, ensuring that the terminal can communicate with the cloud platform network; the server IP address points to the cloud platform's API and storage services and is the target address for establishing connections. The username and password serve as authentication credentials, ensuring that only authorized users can access the corresponding virtual machine resources, thus guaranteeing system security.

[0037] Based on the target virtual machine and the virtual machine disk file, a request is sent to the cloud platform server 102 to mount the target disk file corresponding to the target virtual machine to the terminal device 101 in the form of a block device.

[0038] Block devices are abstract interfaces in operating systems used to manage storage devices. Through network block device protocols, remote disk files can be mapped as device nodes similar to local hard drive partitions. The key advantage of this mounting method is that it makes the remote disk appear almost identical to a local physical disk to the terminal system, allowing the operating system's bootloader to directly read the boot information, file system, and kernel files. Compared to traditional cloud desktops that transmit the display screen via remote desktop protocols, this block-level storage access is more low-level and direct, laying the foundation for subsequently launching virtual machine operating systems directly from the terminal.

[0039] The bare metal client 104 establishes a connection with the storage system of the cloud platform server 102 through the network storage protocol; maps the target disk file located in the storage system to the block device node of the terminal device 101; parses the partition structure of the block device node, identifies the root partition, and mounts the root partition to the temporary directory of the terminal device 101.

[0040] Network storage protocols are the technological foundation for remote disk mounting, defining the communication specifications and data transmission methods between the client and the storage server. Once the bare metal client 104 successfully establishes a connection with the cloud platform storage system, the remote virtual machine disk file will be mapped as a block device node on the terminal device 101.

[0041] At this point, the bare metal client 104 needs to perform partition table resolution on this block device to identify the various partitions, especially the root partition containing the operating system's root file system. The root partition contains the system's core files, configuration information, and various programs required for startup. After mounting the root partition to the terminal's temporary directory, the bare metal client 104 can access the virtual machine operating system's file structure and transfer boot control to the virtual machine operating system's bootloader, completing the boot switch from the bare metal client 104 to the virtual machine operating system.

[0042] The network storage protocol is iSCSI; the bare metal client 104 connects to a specific iSCSI target on the storage system via an iSCSI initiator to map the target disk file as a local block device.

[0043] iSCSI (Internet Small Computer System Interface) is a mature and widely used network storage protocol that allows SCSI commands to be transmitted over TCP / IP networks, enabling remote storage devices to be accessed like local SCSI devices. In this cloud desktop system, the storage system of the cloud platform server 102 exposes virtual machine disk files through the iSCSI Target, while terminal devices initiate connections as clients through the iSCSI Initiator.

[0044] Each virtual machine disk file corresponds to a specific iSCSI target, identified by a unique identifier. The bare metal client 104 loads the iSCSI kernel module and configures the initiator parameters in the initialized memory disk system 103 environment, then initiates a connection request to the specified iSCSI target. Once the connection is established, the iSCSI protocol stack creates the corresponding block device node on the terminal device, making the virtual machine disk file accessible to the system like a physical hard drive. The choice of the iSCSI protocol ensures both good compatibility and performance while simplifying the complexity of storage access.

[0045] After successful mounting, the operating system in the target disk file is booted so that the target virtual machine runs on the terminal device 101 in bare metal mode and directly calls the graphics processing unit for graphics rendering and output.

[0046] After the root partition of the virtual machine disk is successfully mounted to the terminal device 101, the bare metal client 104 uses techniques such as chroot to switch the root directory of the system to the root partition of the virtual machine disk, and then continues to execute the boot program inside the virtual machine operating system.

[0047] Since the virtual machine operating system runs directly on the physical hardware of the terminal device 101, rather than in a virtual machine environment on a cloud platform, it can directly access and control all hardware resources of the terminal, especially the graphics processing unit.

[0048] Graphics applications running in a virtual machine operating system can communicate directly with the hardware through standard GPU drivers to perform tasks such as graphics rendering, 3D calculations, and video decoding, completely bypassing the performance overhead of the virtualization layer and remote display protocols. This operating mode enables cloud-managed virtual machines to achieve near-physical machine graphics performance on the terminal, perfectly combining the centralized management advantages of cloud desktops with the performance advantages of local execution.

[0049] The type and version of the local system and operating system must be consistent.

[0050] The local system refers to the operating system originally installed on the terminal device, while the operating system refers to the target operating system contained in the virtual machine disk file. Since the bare-metal boot process requires the terminal's initialization memory disk system 103 and kernel to boot the system on the virtual machine disk, significant differences in their types or versions can lead to driver incompatibility, unrecognized file systems, and boot program failures. Maintaining consistency ensures the compatibility of critical components such as hardware drivers, file system support, and system libraries, enabling the virtual machine operating system to be successfully loaded and started by the terminal's boot program.

[0051] When the target virtual machine runs on the terminal device 101 in a bare metal manner, it bypasses the virtualization layer and video encoding stream transmission layer of the cloud platform server 102 and directly accesses and calls the graphics processing unit to perform graphics rendering and output.

[0052] In traditional virtualized cloud desktop architectures, virtual machines run on cloud servers, and their graphics output requires multiple layers of processing: first, rendering is performed in the virtualization layer by software simulating the GPU or through GPU virtualization technology; then, the rendering result is encoded into a video stream and transmitted to the terminal via SPICE or other remote desktop protocols; finally, it is decoded and displayed on the terminal. This process introduces performance overhead from GPU virtualization in the virtualization layer, image quality loss and latency in the encoding and decoding processes, and network transmission can also cause stuttering and frame drops.

[0053] In the bare-metal approach, the virtual machine operating system runs directly on the terminal hardware. Graphics applications can send rendering commands directly to the graphics processing unit through the local GPU driver, just like on a physical machine. After the GPU completes the calculation, it directly outputs the results to the display. The entire process is completed locally, without any virtualization loss, encoding / decoding loss, or network transmission latency. This enables the system to run professional 3D design software, high-definition video playback, games, and other applications with extremely high graphics performance requirements smoothly, truly achieving a breakthrough for cloud desktops in high-performance graphics application scenarios.

[0054] As can be seen from the above technical solutions, the beneficial effects of this embodiment are: This application provides a cloud desktop system based on bare metal terminal technology, including a terminal device, a cloud platform server, an initialization memory disk system, and a bare metal client. The terminal device is configured with a graphics processing unit and a network interface to provide local computing and display capabilities. The cloud platform server provides API interfaces for querying and managing candidate virtual machines, and manages and stores the virtual machine disk files corresponding to the candidate virtual machines. The initialization memory disk system is deployed on the terminal device and is used to be initialized during the terminal device's boot process. The loader loads into memory and runs; the memory disk system is initialized internally with an initialization script configured to interrupt the normal boot process of the local system and start the bare metal client; the bare metal client provides a user interface to obtain connection information and user authentication information from the cloud platform server; it calls the API interface to obtain a list of virtual machines corresponding to the candidate virtual machines that support bare metal booting; based on the user selection and the list of virtual machines, it determines the target virtual machine selected by the user; based on the target virtual machine and the virtual machine disk file, it sends a request to the cloud platform server to mount the target disk file corresponding to the target virtual machine to the terminal device as a block device; after successful mounting, it boots the operating system in the target disk file so that the target virtual machine runs on the terminal device in bare metal mode and directly calls the graphics processing unit for graphics rendering and output. It achieves an organic combination of centralized cloud management of virtual machines and high-performance local operation on the terminal. By bypassing the virtualization layer and remote display protocol to directly call the terminal GPU, the graphics performance of the cloud desktop reaches a level close to that of a physical machine. It effectively solves the problems of insufficient performance, image quality loss and high latency of traditional cloud desktops in high-load graphics application scenarios such as 3D rendering and high-definition video. At the same time, it retains the flexible management capabilities of cloud desktops such as snapshots, backups and migrations, and is particularly suitable for cloud platform environments based on domestic processor architecture.

[0055] like Figure 2 The image shows a specific embodiment of a bare-metal boot method for a cloud desktop system according to this application.

[0056] In this embodiment, a bare-metal boot method for a cloud desktop system is applied to... Figure 1 The cloud desktop system shown includes the following steps: Step 201: When the terminal device starts up, interrupt the normal boot process of loading the local system by initializing the initialization script in the memory disk system.

[0057] When a user powers on their terminal device, the system first performs a hardware self-test and initialization via the BIOS or UEFI firmware, then hands control over to the boot loader (such as GRUB). The boot loader locates the Linux kernel file and the initialization memory disk file (initrd) based on the configuration and loads them into memory. After the kernel boots, it mounts the initrd as a temporary root file system, at which point the pre-defined initialization scripts within the initrd begin execution.

[0058] In a conventional system boot process, the initialization script loads necessary hardware drivers, detects and mounts the actual root file system, and then switches to the real root file system via mechanisms such as `switch_root` to complete the full system boot. This embodiment, however, modifies the initrd initialization script by inserting conditional logic at key execution points to determine whether bare-metal boot is necessary. If so, the script skips the step of loading the local root file system and executes the bare-metal client program instead. This interruption method preserves the system's normal boot capabilities while creating an opportunity for bare-metal boot to intervene, allowing the system to transfer control to the bare-metal boot process at the lowest-level boot stage.

[0059] Step 202: Start the bare metal client and obtain the connection information and user authentication information of the cloud platform server through the bare metal client.

[0060] After the initialization script transfers control, the bare metal client program is launched and takes over the system's boot process. Since the system is currently in the initrd environment and a complete file system has not yet been mounted, the bare metal client presents a character-based interface, displaying clear and concise input prompts to the user. The user needs to enter the terminal IP address, subnet mask, gateway, and other network configuration parameters, as well as the IP address or domain name of the cloud platform server. This information is used to establish network connectivity between the terminal device and the cloud platform. Next, the user enters their username and password. This authentication information is used to verify the user's identity with the cloud platform, ensuring that only authorized users can access their corresponding virtual machine resources.

[0061] The bare metal client performs necessary security measures on this sensitive information, such as not displaying characters when passwords are entered, and using encrypted channels to protect authentication credentials in subsequent network transmissions. After all necessary information is collected, the bare metal client configures the terminal's network interface using commands such as ip and ifconfig based on the user's network configuration, enabling the terminal to communicate with the cloud platform network and establishing a network foundation for subsequent API calls and storage mounting operations.

[0062] Step 203: Call the API interface of the cloud platform server to obtain a list of virtual machines that support bare metal booting.

[0063] After network configuration is complete and connectivity with the cloud platform is confirmed, the bare metal client begins interacting with the cloud platform server. The client uses network tools such as curl and wget to construct HTTP or HTTPS requests, carrying the user's authentication information to call the API interfaces provided by the cloud platform. The API interfaces are standardized service interfaces exposed by the cloud platform, used for functions such as virtual machine management, user authentication, and resource querying.

[0064] The bare metal client first calls the authentication interface to verify the username and password. Upon successful authentication, it obtains an access token or session identifier. Next, the client calls the virtual machine query interface, passing the current user's identity and specific filtering conditions (such as virtual machines marked as supporting bare metal booting). The server, based on the access control policy, returns a list of virtual machines that the user has the right to access and that support bare metal booting. The returned data is typically organized in JSON or XML format and contains key metadata for each virtual machine, such as its name, unique identifier, configuration information, storage location, and iSCSI Target information. The bare metal client parses this returned data, extracts the valid virtual machine information, and displays it to the user in a readable manner, such as showing the virtual machine's serial number, name, and configuration specifications, facilitating user selection.

[0065] Step 204: Based on user selection, determine the target virtual machine from the list of virtual machines.

[0066] Once the list of virtual machines is displayed to the user, the user selects the virtual machine to launch based on their actual needs. For example, a user might need to launch a development environment virtual machine containing specific 3D design software, or a workstation virtual machine configured with professional video editing tools.

[0067] Users indicate their selection by entering the virtual machine's serial number or name. After receiving the user input, the bare metal client extracts the corresponding virtual machine's detailed information from the previously parsed virtual machine list data. This information includes the virtual machine's unique identifier, the location of the virtual machine's disk file in the storage system, the iSCSI Target's IQN identifier, LUN number, and key parameters such as the storage server's IP address and port.

[0068] To improve user experience, bare metal clients may also display basic configuration information of the virtual machine, such as the number of CPU cores, memory size, and operating system version, for user confirmation. After the user confirms their selection, the bare metal client saves this information to a memory variable.

[0069] Step 205: Mount the target disk file corresponding to the target virtual machine to the terminal device as a block device over the network.

[0070] After identifying the target virtual machine, the bare metal client begins the disk mounting operation. First, the client needs to ensure that the iSCSI-related kernel modules are loaded. If not, it uses the `modprobe` command to load necessary modules such as `iscsi_tcp`, enabling the terminal to have iSCSI client capabilities. Next, the client configures the iSCSI initiator parameters, including the initiator name and authentication method.

[0071] Then, the client uses the iscsiadm tool to initiate a discovery operation with the cloud platform storage system to find available iSCSI targets on the storage server. Based on the iSCSI target information of the target virtual machine obtained from the API, the client performs a login operation to establish a session connection with the specific iSCSI target. Once the connection is successfully established, the Linux kernel's iSCSI driver automatically creates the corresponding block device node in the / dev / directory. At this point, the remote virtual machine disk files are presented in the terminal system as local block devices.

[0072] Subsequently, the bare-metal client uses tools such as fdisk, parted, or blkid to parse the partition table of the block device, identify the various partitions, especially the partition containing the root file system, and mount the root partition to a temporary mount point in the initrd environment. At this point, the contents of the virtual machine disk files are accessible to the terminal system, preparing for subsequent system booting.

[0073] Step 206: Boot the operating system in the target disk file so that the target virtual machine runs on the terminal device in bare metal mode and directly calls the graphics processing unit of the terminal device for graphics rendering and output.

[0074] Once the root partition of the virtual machine disk is successfully mounted, the bare metal client enters the final boot phase. The client first checks the file system structure at the mount point to confirm that it contains valid Linux system files. Then, the client performs a series of preparatory tasks, including binding and mounting the virtual file system to the appropriate location on the virtual machine's root partition, ensuring that the virtual machine system can access the kernel interface and device files correctly after startup.

[0075] After completing these preparations, the bare metal client uses the `chroot` command to switch the system's root directory to the mount point of the virtual machine disk. At this point, the process's file system view has become the virtual machine operating system environment. Next, the client executes system calls such as `switch_root` or `pivot_root` to officially establish the virtual machine's root file system as the new root file system and start the virtual machine operating system's init process.

[0076] After the init process starts, it follows the virtual machine operating system's own startup procedure, sequentially starting various system services, loading device drivers, and initializing the graphics environment. Since the virtual machine operating system runs directly on the terminal's physical hardware, when the system starts the graphical interface or runs a 3D application, the GPU driver can directly communicate with the terminal's graphics processing unit, sending rendering commands and receiving rendering results, completely bypassing the cloud platform's virtualization layer and remote display protocol. The image seen by the user on the monitor is the direct output of the GPU, without any encoding / decoding or network transmission, thus achieving almost the same smoothness, clarity, and responsiveness as a physical machine, realizing the goal of a high-performance cloud desktop.

[0077] As can be seen from the above technical solution, the beneficial effects of this embodiment are as follows: When the terminal device starts up, the normal boot process of loading the local system is interrupted by initializing the initialization script in the memory disk system; the bare metal client is started, and the connection information and user authentication information of the cloud platform server are obtained through the bare metal client; the API interface of the cloud platform server is called to obtain a list of virtual machines that support bare metal boot; based on the user selection, the target virtual machine is determined from the list of virtual machines; the target disk file corresponding to the target virtual machine is mounted to the terminal device in the form of a block device; the operating system in the target disk file is booted so that the target virtual machine runs on the terminal device in bare metal mode, and directly calls the graphics processing unit of the terminal device for graphics rendering and output. This breaks through the graphics performance bottleneck of traditional virtualization architecture and can smoothly support high-load graphics application scenarios such as 3D rendering and high-definition video.

[0078] Figure 2 The above is only a basic embodiment of a bare metal boot method for a cloud desktop system according to this application. With certain optimizations and extensions, other preferred embodiments of a bare metal boot method for a cloud desktop system can be obtained.

[0079] like Figure 3 The image shown is another specific embodiment of a bare metal boot method for a cloud desktop system according to this application.

[0080] In this embodiment, a bare-metal boot method for a cloud desktop system includes the following steps: 301. When the terminal device starts up, the normal boot process of loading the local system is interrupted by initializing the initialization script in the memory disk system.

[0081] 302. Start the bare metal client and obtain the connection information and user authentication information of the cloud platform server through the bare metal client.

[0082] 303. Call the API interface of the cloud platform server to obtain a list of virtual machines that support bare metal booting.

[0083] 304. Based on user selection, determine the target virtual machine from the list of virtual machines.

[0084] 305. Mount the target disk file corresponding to the target virtual machine to the terminal device as a block device over the network.

[0085] 306. Use the iSCSI protocol to establish a connection with the storage system on the cloud platform server.

[0086] After identifying the target virtual machine and obtaining its storage information, the bare-metal client begins establishing a connection with the cloud platform's storage system using the iSCSI protocol. First, the client loads the relevant iSCSI kernel modules using the modprobe command. These kernel modules provide complete iSCSI protocol stack support for the Linux system, enabling the terminal device to act as an iSCSI initiator.

[0087] Next, the client needs to configure the iSCSI initiator's identity information, including setting a unique identifier to uniquely identify the terminal device within the iSCSI network. After configuration, the bare metal client uses the iscsiadm tool to perform target discovery, sending discovery requests to the storage server via the sendtargets method to obtain a list of all available iSCSI targets on the server. From the returned target list, the client locates the corresponding iSCSI target based on the unique identifier of the target virtual machine previously obtained from the cloud platform API.

[0088] Subsequently, the client performs a login operation, initiating a session establishment request to the specified Target. During this process, the iSCSI protocol stack negotiates parameters, including maximum data transfer length, whether to use header and data digests, and connection timeout settings, ensuring consistency of communication parameters between the client and server. Once the session is successfully established, a stable TCP connection channel is formed between the client and the storage system. At this point, SCSI commands can be transmitted over the network through this TCP channel, allowing the remote storage device to be accessed like a local SCSI device.

[0089] 307. Map the target disk file to a block device node of the terminal device.

[0090] Once the iSCSI session is successfully established, the Linux kernel's SCSI subsystem begins to function, automatically recognizing the remote iSCSI LUN (Logical Unit Number) as a local SCSI device. The kernel's device manager (such as udev) will create a corresponding block device node for this newly recognized device in the / dev directory, typically in the form of / dev / sdX, where X is a letter assigned according to the device discovery order.

[0091] For example, if the terminal already has a local hard drive / dev / sda, then a remote disk mounted via iSCSI might be recognized as / dev / sdb. In this case, from the operating system's perspective, this block device node is almost indistinguishable from a physically connected local hard drive, and the system can perform all the usual block device operations on it, such as reading, writing, partition resolution, and file system mounting.

[0092] The bare-metal client confirms the successful creation of a new block device node by monitoring changes in the ` / dev` directory or querying kernel interfaces such as ` / sys / class / scsi_device`. To accurately identify which block device corresponds to the target virtual machine disk, the client may need to match it using the device's WWN (World Wide Name), serial number, or other unique identifiers to avoid confusion when multiple iSCSI devices exist. Once the correct block device node is identified, the client records the device path to prepare for subsequent partition resolution and file system mounting.

[0093] This mapping mechanism makes network storage access completely transparent, eliminating the need for upper-layer applications and system tools to concern themselves with whether data is actually stored remotely or locally, greatly simplifying system implementation complexity. Furthermore, because it uses a standard block device interface, the virtual machine operating system's bootloader can access this device as if it were a local disk, reading the bootloader, kernel files, and file system within it.

[0094] 308. Parse the partition structure of the block device node, identify the root partition, and mount the root partition to the temporary directory of the terminal device.

[0095] After obtaining the block device node, the bare metal client needs to parse the device's partition structure to identify the partition containing the virtual machine operating system's root file system. The client first uses tools such as fdisk, parted, or blkid to read the block device's partition table. The partition table records information such as the starting position, size, and type of each partition on the disk. Virtual machine disks typically use standard partitioning schemes, such as MBR or GPT partition tables, and include boot partitions, root partitions, data partitions, and swap partitions.

[0096] The client needs to determine which partition is the root partition based on information such as the partition's file system type, mount point identifier, or partition label. The root partition typically contains the complete Linux system directory structure, including directories such as / bin, / boot, / etc, / lib, and / usr, and is the core of the operating system's startup and operation. After identifying the root partition, the kernel automatically creates a corresponding device node for that partition; for example, / dev / sdb2 represents the second partition on the / dev / sdb device.

[0097] Next, the bare metal client creates a temporary mount point in the initrd environment, such as / mnt / vm_root or / sysroot, and then uses the mount command to mount the root partition to this temporary directory. When performing the mount operation, the client needs to specify the correct file system type, such as ext4, xfs, or btrfs, to ensure that the kernel can correctly resolve the file system structure in the partition.

[0098] After successful mounting, all files and directories of the virtual machine's operating system can be accessed through the temporary mount point. The bare metal client will verify the correctness of the mount, for example, by checking whether files such as / etc / fstab and / bin / bash exist under the mount point, confirming that this is a valid Linux root file system.

[0099] In addition, the client may need to mount other necessary partitions, such as the / boot partition if it is a separate partition, or data partitions such as / data, to ensure the integrity of the virtual machine system's file structure. To enable the virtual machine operating system to access the kernel interface and device files correctly during subsequent startup, the client will also mount virtual file systems such as / proc, / sys, and / dev to the corresponding locations on the virtual machine's root partition using bind mount.

[0100] Once all these mounting operations are completed, the virtual machine operating system's runtime environment is ready. The system can switch to this environment via chroot and continue executing the virtual machine's own boot process, ultimately completing the full boot switch from the initrd environment to the virtual machine operating system.

[0101] 309. Boot the operating system in the target disk file so that the target virtual machine can run on the terminal device in bare metal mode and directly call the graphics processing unit of the terminal device for graphics rendering and output.

[0102] As can be seen from the above technical solutions, the beneficial effects of this embodiment are: through the standardized iSCSI network storage protocol and block device mapping mechanism, the transparent conversion of cloud virtual machine disk files to terminal local block devices is realized, enabling remote storage resources to be directly accessed by the system boot program like local physical hard drives, laying the technical foundation for bare metal booting of virtual machine operating systems on terminal hardware, while maintaining good compatibility with existing storage architectures and virtualization management systems.

[0103] Those skilled in the art will understand that the embodiments of this application can be provided as methods or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or a combination of software and hardware.

[0104] The various embodiments in this application are described in a progressive manner. The same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on describing the differences from other embodiments.

[0105] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0106] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A cloud desktop system based on terminal bare metal technology, characterized in that, The application relates to a terminal device, a cloud platform server, an initialization memory disk system and a bare metal client. The terminal device is configured with a graphic processing unit and a network interface, and is used for providing local computing and display capabilities. The cloud platform server is used for providing an API interface for querying and managing alternative virtual machines, and managing and storing virtual machine disk files corresponding to the alternative virtual machines. The initialization memory disk system is deployed on the terminal device, is loaded into memory by a Boot loader during a startup process of the terminal device and is run, an initialization script is internally contained in the initialization memory disk system, the initialization script is configured to interrupt a normal booting process of a local system and start the bare metal client. The bare metal client is used for providing a user interactive interface to obtain connection information and user authentication information of the cloud platform server. The API interface is called to obtain a virtual machine list corresponding to the alternative virtual machines supporting bare metal startup; according to user selection and the virtual machine list, a target virtual machine corresponding to the user selection is determined. Based on the target virtual machine and the virtual machine disk file, a request is initiated to the cloud platform server, and a target disk file corresponding to the target virtual machine is network-mounted to the terminal device in the form of a block device. After successful mounting, an operating system in the target disk file is booted to enable the target virtual machine to run on the terminal device in a bare metal mode, and the graphic processing unit is directly called for graphic rendering and output. The initialization script is configured to interrupt the normal booting process of the local system, and the initialization script is configured to disable original root file system loading instructions of the local system after being run, set environment variables to support network communication and block device access, and execute a shell command for starting the bare metal client to transfer system booting control to the bare metal client.

2. The system of claim 1, wherein, The bare metal client is realized based on a shell script language and provides a character interactive interface; the connection information includes a terminal IP address and a server IP address; and the user authentication information includes a username and a password. The bare metal client establishes a connection with a storage system of the cloud platform server through a network storage protocol, maps the target disk file located in the storage system to a block device node of the terminal device, analyzes a partition structure of the block device node, identifies a root partition and mounts the root partition to a temporary directory of the terminal device. The network storage protocol is an iSCSI protocol; the bare metal client is connected to a specific iSCSI target on the storage system through an iSCSI initiator to map the target disk file to a local block device. The type and version of the local system and the operating system are consistent.

3. The system of claim 1, wherein, ​ 4. The system of claim 1, wherein, ​ ​ ​ ​ 5. The system of claim 4, wherein, ​ 6. The system of claim 1, wherein, ​ 7. The system of claim 1, wherein, When the target virtual machine runs on the terminal device in the bare metal mode, the virtualization layer and the video coding streaming layer of the cloud platform server are bypassed, and the graphic processing unit is directly accessed and called for graphic rendering and output.

8. The system of claim 7, wherein, The cloud platform server is built based on a domestic processor architecture, which includes Feiteng architecture, Loongson architecture and Kunpeng architecture, and the virtualization layer adopts a combined architecture of KVM and QEMU.

9. A method for bare metal booting of a cloud desktop system, the method being applied to the system of any of claims 1-8, characterized in that, The method comprises the steps of: When the terminal device is started, an initialization script in a memory disk system is initialized to interrupt the normal booting process of a local system; A bare metal client is started, and connection information and user authentication information of the cloud platform server are obtained through the bare metal client; An API interface of the cloud platform server is called to obtain a virtual machine list supporting bare metal starting; Based on user selection, a target virtual machine is determined from the virtual machine list; A target disk file corresponding to the target virtual machine is network-mounted to the terminal device in the form of a block device; An operating system in the target disk file is booted to make the target virtual machine run on the terminal device in the bare metal mode, and the graphic processing unit of the terminal device is directly called for graphic rendering and output.

10. The method of claim 9, wherein, The target disk file corresponding to the target virtual machine is network-mounted to the terminal device in the form of a block device, which comprises the steps of: An iSCSI protocol is used to establish a connection with a storage system of the cloud platform server; The target disk file is mapped as a block device node of the terminal device; The partition structure of the block device node is parsed, the root partition is identified, and the root partition is mounted to a temporary directory of the terminal device.

Images