An OpenStack image integrity pre-inspection system and method based on sandbox verification

Abstract

This invention proposes an OpenStack image integrity pre-inspection system and method based on sandbox verification. The pre-inspection system is integrated into the Glance service of the OpenStack platform and includes: a Glance check module, deployed within the glance-api service or as its extension component, used to perform integrity pre-inspection during the image upload process; the Glance check module includes two core sub-modules: a check format sub-module and a SandboxValidator sub-module; the CheckFormat sub-module is used to determine the format validity at the initial stage of image data stream transmission; the SandboxValidator sub-module is asynchronously triggered after the image file is stored and its status changes to active, responsible for functional verification of the image's startup availability. This facilitates users in quickly locating and correcting image problems.

Description

Technical Field

[0001] This invention belongs to the field of software testing technology, specifically relating to an OpenStack image integrity pre-inspection system and method based on sandbox verification. Background Technology

[0002] With the continued increase in the global digital economy's share, cloud computing has become the preferred choice for IT construction for government and enterprise customers. According to the China Academy of Information and Communications Technology's "Cloud Computing White Paper (2024)," the Chinese private cloud market reached 150.2 billion yuan in 2023, with a compound annual growth rate of 25.3%; among which, OpenStack technology accounted for 54.7% of the market share, continuing to maintain its absolute mainstream position. Within the OpenStack system, the Glance component serves as the "sole entry point" for virtual machine images: users must first upload the image file to Glance before creating an instance through Nova. However, Glance's native design only provides "storage + metadata" capabilities, without performing any verification on the image content itself, leading to the following common industry pain points: The number of image files has exploded: an official Windows Server 2022 image is 5.8 GB, and after adding enterprise patch packages, it generally exceeds 50 GB; although the official CentOS qcow2 image is only 700 MB, user-customized versions often reach 8–12 GB.

[0003] The upload process is lengthy and fragile: taking a 50 GB file and gigabit bandwidth as an example, the theoretical upload time is approximately 7 minutes, but in reality, it often exceeds 30 minutes due to public network jitter; once it fails, the entire packet must be retransmitted. Format mistransmission is frequent: IDC's "2023 Cloud Operations Report" points out that 37% of operations and maintenance tickets originate from "images cannot be started," of which 61% are rooted in users mistakenly transmitting non-virtualized formats such as .iso, .vfd, and .tar, yet Glance still accepts them all.

[0004] Availability discovery lag: Image integrity can only be exposed during the Nova virtual machine creation phase, with an average troubleshooting time of 2.1 hours, severely impacting business deployment schedules. Cost spillover: Repeated uploads consume 30%–45% of public network bandwidth, and backend object storage generates a large number of zombie files. In 2023, a provincial government cloud wasted 2.87 million yuan in storage fees due to this.

[0005] In summary, how to prevent incorrect formats before uploading and verify availability immediately after uploading has become a key technical gap for reducing costs and increasing efficiency in private cloud operations and maintenance.

[0006] The current inspection mechanism has several limitations: First, it requires waiting for the image to be completely written to disk before inspection can begin, significantly extending the waiting time for large images. Second, the inspection can only detect superficial issues such as cluster table corruption and header information errors, failing to verify whether the kernel can boot normally, creating a functional blind spot. Furthermore, for images in Raw format without metadata, the lack of verification criteria necessitates a zero-scan approach, which is inefficient as its time increases linearly with file size. Additionally, the inspection process completely consumes local disk I / O, severely impacting concurrent upload performance. Finally, there is no automatic re-upload mechanism after an image is marked as killed, requiring users to manually re-upload, which is not only cumbersome but also inevitably leads to duplicate traffic.

[0007] In view of this, the present invention is hereby proposed. Summary of the Invention

[0008] The purpose of this invention is to overcome the shortcomings of the prior art and provide an OpenStack image integrity pre-inspection system and method based on sandbox verification.

[0009] To achieve the above objectives, the present invention provides the following technical solution: According to a first aspect of the present invention, an OpenStack image integrity pre-inspection system based on sandbox verification is provided. The system is integrated into the Glance service of the OpenStack platform and includes: a Glance checking module, deployed within the glance-api service or as an extension component, used to perform integrity pre-inspection during the image upload process; the Glance checking module includes two core sub-modules: a check format sub-module and a SandboxValidator sub-module; the CheckFormat sub-module is used to determine the format validity at the initial stage of image data stream transmission; the SandboxValidator sub-module is asynchronously triggered after the image file is stored and its status becomes active, and is responsible for functional verification of the image's startup availability.

[0010] In one possible embodiment, the CheckFormat submodule includes: Stream capture unit: After receiving the mirrored data stream from glance-api and before writing it to the backend storage, capture the header bytes at the very beginning of the transmission stream in real time; Feature library: Pre-sets unique identifiers or feature signatures in the header of various standard virtual machine image formats, including at least Qcow2, VHD, VMDK, and Raw formats; Format Decision Unit: Compares the captured header bytes with the feature code library and outputs the judgment result within 2 seconds; Flow control interface: If the result indicates that the format is not supported, an interrupt command is sent to glance-api to terminate the data stream transmission and return an error message; if the format is valid, the data stream is allowed to continue the subsequent storage process.

[0011] In one possible embodiment, the SandboxValidator submodule includes: Trigger unit: Monitors changes in the Glance image status. When the image status changes from uploading to active, it automatically starts the sandbox verification process. Isolation environment building unit: Call the Nova interface to create a minimum-sized temporary virtual machine instance in a predefined sandbox isolation network, wherein the sandbox isolation network has an independent network namespace or VXLAN isolation identifier; Image Replica Management Unit: Generates a fast clone copy of the user image using snapshot or linked cloning technology provided by the storage backend, and uses this copy as the root disk of the temporary virtual machine to ensure that the original image file is not modified; Startup monitoring unit: continuously obtains the console output and status information of the virtual machine through the Nova interface, monitors the virtual machine startup process, and verifies the success of the virtual machine when it successfully loads the kernel in the image and completes initialization, that is, reaches the stage where it can receive startup parameters. Resource recycling unit: Regardless of whether the verification is successful or not, it automatically calls the Nova and storage backend interface after the verification is completed to destroy temporary virtual machine instances, delete cloned disk copies, and release sandbox network ports to ensure that no verification resources remain; Result Feedback Unit: Writes the verification result to the image metadata. If the verification is successful, it is marked as "verified and available"; if the verification fails, the image status is marked as killed, and the startup error log is collected and returned to the user.

[0012] According to a second aspect of the present invention, a sandbox-based OpenStack image integrity pre-inspection method is proposed, employing the aforementioned sandbox-based OpenStack image integrity pre-inspection system, comprising the following steps: Step 1: User initiates upload request Users initiate image upload requests to the Glance service via the Horizon dashboard or CLI client, and these requests are received by the glance-api interface.

[0013] Step 2: Format Pre-check After the image data stream begins transmission but before it is officially stored in the backend storage, glance-api calls the CheckFormat submodule. This module does not wait for the entire image file to be uploaded, but instead parses the header bytes at the very beginning of the transmission stream in real time. The module has pre-set unique identifiers or signature features in the header of standard virtual machine image formats (including Qcow2, VHD, VMDK, and Raw). By comparing the header bytes with the signature library, the CheckFormat module can determine whether the image format is valid within 2 seconds.

[0014] If the format is not supported, immediately interrupt the upload process and return an error message to the user; If the format is valid, allow the data stream to proceed and continue the normal Glance upload process.

[0015] Step 3: Sandbox Startup Verification Once the image file becomes active in Glance, the sandbox verification process is triggered: Resource isolation creation: The system automatically creates a minimum-sized temporary virtual machine instance in a predefined Sandbox-Net (sandbox isolation network); Image copy startup: This temporary virtual machine starts using a fast clone copy of the user-uploaded image to avoid potential damage to the original file; Kernel boot status monitoring: The system monitors the boot process of the virtual machine through the Nova interface. The success criterion is whether the virtual machine can successfully load the kernel in the image and complete the initialization, that is, reach the stage where it can receive boot parameters. Automatic resource cleanup: Regardless of whether the verification is successful or not, the system will automatically destroy the temporary virtual machine, its associated virtual disk copy, and the sandbox network port after the verification is completed, ensuring that there are no remnants.

[0016] Step 4: Results Feedback If the virtual machine starts successfully, the image is marked as "verified available"; If startup fails, the image status will be marked as killed, and the specific startup error log will be returned to the user, suggesting that the user re-upload the corrected image.

[0017] Compared with the prior art, the technical solution provided by the present invention has the following beneficial effects: Real-time format filtering: By identifying the format before the data stream is written, invalid data is not written to disk, effectively saving storage resources and network bandwidth; Functional boot verification: By actually booting a copy of the image, the integrity of the image is verified from a functional perspective to prevent images that are "valid in format but unusable" from entering the production environment; Security isolation mechanism: The verification process is carried out using a read-only copy in an isolated network, and the original image file is not affected in any way, eliminating security risks; Automated resource cleanup: After verification, all temporary resources are automatically reclaimed without any residue, reducing the burden of operation and maintenance; Precise error feedback: Returns detailed startup failure logs to users, making it easier for them to quickly locate and correct image problems. Attached Figure Description

[0018] The accompanying drawings are incorporated in and form part of this specification, and together with the description serve to explain the principles of the invention.

[0019] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a schematic diagram of the OpenStack image integrity pre-inspection system based on sandbox verification according to the present invention; Figure 2 This is a flowchart of the CheckFormat submodule of the present invention; Figure 3 This is a flowchart of the SandboxValidator submodule of the present invention. Detailed Implementation

[0021] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Rather, they are merely examples consistent with some aspects of the invention as detailed in the appended claims.

[0022] To enable those skilled in the art to better understand the technical solutions of the present invention, the present invention will be further described in detail below with reference to the accompanying drawings and embodiments.

[0023] The overall technical solution of this application is achieved by integrating a check module called "glance check" into the OpenStack Glance image upload process, such as... Figure 1 As shown.

[0024] This module consists of two core sub-modules: CheckFormat (static format recognition module) and SandboxValidator (sandbox validation service). Its implementation process is as follows, combined with... Figures 2 to 3 Explanation: User-initiated upload request: The user initiates an image upload request to the Glance service through the Horizon dashboard or CLI client. This request is received by the glance-api interface.

[0025] Format pre-check (CheckFormat submodule): such as Figure 3 As shown, after the mirrored data stream begins transmission but before it is actually stored in the backend storage, glance-api calls the CheckFormat submodule.

[0026] Real-time parsing: This module does not wait for the entire image file to be uploaded, but parses the header bytes at the very beginning of the transport stream in real time (usually 512 bytes to several KB).

[0027] Signature matching: The module has pre-set unique identifiers (magic numbers) or signatures in the header of various standard virtual machine image formats (such as Qcow2, VHD, VMDK, Raw, etc.). For example, the first 8 bytes of the Qcow2 format are 51 46 49 fb (ASCII is "QFI" followed by a version byte).

[0028] Rapid decision-making: By comparing the header bytes with the signature database, the CheckFormat module can determine whether the image format is valid within seconds (≤2 seconds). If the format is not supported (e.g., an .iso or .tar file was mistakenly transmitted), the upload process is immediately interrupted, and a clear error message is returned to the user to prevent invalid data from continuing to be transmitted. If the format is valid, the data stream is allowed to proceed, and the normal Glance upload process continues.

[0029] Sandbox-based validation (SandboxValidator submodule): such as Figure 3 As shown, the sandbox verification process is triggered when the image file becomes active in Glance (i.e., it has been completely written to disk).

[0030] Resource isolation creation: The system automatically creates a temporary virtual machine instance of minimum specifications (e.g., m1.tiny: 1 vCPU / 512MB RAM) within a predefined Sandbox-Net (sandbox isolation network, such as VXLAN ID5000). This network is completely isolated from the user's production environment, ensuring the security of the verification process.

[0031] Image copy startup: This temporary virtual machine is not started using the original image file uploaded by the user, but rather by a quickly cloned copy, avoiding any potential damage to the original file.

[0032] Kernel boot status monitoring: The system monitors the virtual machine's boot process through the Nova interface. The success criterion is not entering the operating system, but rather monitoring whether the virtual machine can successfully load the kernel from the image and complete initialization, i.e., reach the stage where it can receive boot parameters (such as the GRUB menu). This process usually takes less than 90 seconds to determine.

[0033] Automatic resource cleanup: Regardless of whether the verification is successful or not, the system will automatically and thoroughly destroy all resources, including temporary virtual machines, their associated virtual disk copies, and sandbox network ports, after the verification is completed, ensuring no residue remains.

[0034] Feedback Results: If the virtual machine starts successfully, the image is marked as "verified and usable"; if the startup fails, the image status is marked as "killed", and the specific startup error log (such as "Kernel Panic", "boot device not found", etc.) is returned to the user, and the user is advised to re-upload the corrected image.

[0035] Example 1: Intercepting Mistransmitted ISO Disc Image Files Use Case: An administrator at a company needs to upload a customized CentOS 7 virtual machine image to an OpenStack private cloud. The image is actually in Qcow2 format, but the administrator mistakenly named its file extension centos7.iso.

[0036] Implementation process: The administrator executes the command `openstack image create --file centos7.iso --disk-format qcow2 CentOS7-Custom` via CLI.

[0037] Once data transmission begins, the CheckFormat module immediately reads the first 1024 bytes of the file stream.

[0038] The module analysis revealed that the header signature of the data stream (such as 43 44 30 30 31, corresponding to the "CD001" identifier of the ISO9660 file system) did not match the declared qcow2 format, but was completely consistent with the signature of the iso format.

[0039] The upload process was immediately interrupted (total time < 1 second), and the Glance API returned the following error to the administrator: "Error: The actual image format detected is 'iso', which does not match the declared 'qcow2' format. Please check the image file and re-upload." Technical effect: With minimal network bandwidth and server I / O consumption, the upload of incorrectly formatted images is blocked at the beginning of the transmission, avoiding the huge delays and resource waste that occur in traditional solutions where the problem is only discovered when creating a virtual machine after waiting for tens of minutes for the complete upload.

[0040] Example 2: Detection of a Qcow2 image that cannot start due to a packaging error. Use case: A developer used the virt-sysprep tool to process an Ubuntu 22.04 image, but due to an operational error, the image's boot partition configuration was corrupted. He then uploaded this 8GB image to a cloud platform.

[0041] Implementation process: The image passed the format check by the CheckFormat module (because it is indeed a valid Qcow2 format) and was successfully uploaded to Glance, and its status changed to active.

[0042] The SandboxValidator service is automatically triggered the moment the upload is completed.

[0043] The service quickly clones the image in the sandbox network and creates a temporary virtual machine of size m1.tiny to attempt to start it.

[0044] During the startup process, the temporary virtual machine encountered a boot configuration corruption issue, displaying a "No bootable device" error and stalling. The Nova monitoring interface detected this failure.

[0045] SandboxValidator determines boot failure within 90 seconds (timeout mechanism), automatically cleans up sandbox resources, updates the image status to "killed," and returns an error log to the user: "Validation failed: The virtual machine could not boot from the image. Error message: 'No bootable device'. It is recommended to check the image's bootloader (such as GRUB) configuration."

[0046] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention.

[0047] It should be understood that the present invention is not limited to the content already described above, and various modifications and changes can be made without departing from its scope. The scope of the present invention is limited only by the appended claims.

Claims

1. An OpenStack image integrity pre-inspection system based on sandbox verification, characterized in that, The system is integrated into the Glance service of the OpenStack platform and includes: a Glance inspection module, deployed within the glance-api service or as its extended component, used to perform integrity pre-checks during the image upload process; the Glance inspection module includes the following two core sub-modules: a check format sub-module and a SandboxValidator sub-module; wherein the CheckFormat sub-module is used to determine the format validity at the initial stage of image data stream transmission; the SandboxValidator sub-module is asynchronously triggered after the image file is stored and its status becomes active, and is responsible for performing functional verification of the image's startup availability.

2. The OpenStack image integrity pre-inspection system based on sandbox verification according to claim 1, characterized in that, The CheckFormat submodule includes: The stream capture unit is used to capture the header bytes at the very beginning of the transport stream in real time after the glance-api receives the mirrored data stream and before it is written to the backend storage. The signature library contains pre-set unique identifiers or signature features in the header of various standard virtual machine image formats. The format decision unit is used to compare the captured header bytes with the feature code library and output the judgment result; The flow control interface is used to send data flow interruption or release commands to glance-api based on the judgment result.

3. The OpenStack image integrity pre-inspection system based on sandbox verification according to claim 2, characterized in that, The signature library includes at least unique identifiers or signature features in the header of the file in Qcow2, VHD, VMDK, and Raw formats.

4. The OpenStack image integrity pre-inspection system based on sandbox verification according to claim 2, characterized in that, The time for the format decision unit to complete the determination is no more than 2 seconds.

5. The OpenStack image integrity pre-inspection system based on sandbox verification according to claim 1, characterized in that, The SandboxValidator submodule includes: The trigger unit is used to monitor changes in the Glance image status and automatically start the sandbox verification process when the image status becomes active. The isolation environment building block is used to call the Nova interface to create a minimal temporary virtual machine instance in a predefined sandbox isolation network; The image copy management unit is used to generate a fast clone copy of the user image using snapshot or linked cloning technology provided by the storage backend, and to use the copy as the root disk of a temporary virtual machine. The startup monitoring unit is used to obtain the console output and status information of the virtual machine through the Nova interface and monitor the virtual machine startup process. The resource recycling unit is used to automatically destroy temporary virtual machine instances, delete cloned disk copies, and release sandbox network ports after verification. The result feedback unit is used to write the verification results to the image metadata and return the error log.

6. A sandbox-based OpenStack image integrity pre-inspection method, employing the sandbox-based OpenStack image integrity pre-inspection system described in any one of claims 1-5, characterized in that, Includes the following steps: Users initiate image upload requests to the Glance service via the Horizon dashboard or CLI client, and these requests are received by the glance-api interface. After the image data stream starts transmitting but before it is officially stored in the backend storage, glance-api calls the CheckFormat submodule to parse the header bytes at the very beginning of the transmission stream in real time. By comparing the header bytes with the feature code library of the pre-set standard virtual machine image format, it determines whether the image format is valid. If the format is not supported, the upload process will be immediately interrupted and an error message will be returned to the user. If the format is valid, allow the data stream to proceed and continue the normal Glance upload process; When the image file becomes active in Glance, the sandbox verification process is triggered: the system automatically creates a minimum-sized temporary virtual machine instance in a predefined sandbox isolation network. This temporary virtual machine is started using a fast clone copy of the user-uploaded image, and the startup process of the virtual machine is monitored through the Nova interface. The success criterion is whether the virtual machine can successfully load the kernel in the image and complete the initialization, that is, reach the stage where it can receive startup parameters. Regardless of whether the verification is successful or not, the system will automatically destroy the temporary virtual machine, its associated virtual disk copy, and the sandbox network port after the verification is completed. If the virtual machine starts successfully, the image is marked as "verified available"; If startup fails, the image status will be marked as killed, and the specific startup error log will be returned to the user.

7. The OpenStack image integrity pre-inspection method based on sandbox verification according to claim 6, characterized in that, The CheckFormat submodule performs real-time parsing during the image data stream transmission process, without waiting for the entire image file to be uploaded.

8. The OpenStack image integrity pre-inspection method based on sandbox verification according to claim 6, characterized in that, The sandbox isolation network is a pre-configured independent network with an isolated VXLAN ID.

9. The OpenStack image integrity pre-inspection method based on sandbox verification according to claim 6, characterized in that, The fast cloned copy is generated using snapshot or linked cloning technology provided by the storage backend, ensuring read-only protection of the original image file.

10. The OpenStack image integrity pre-inspection method based on sandbox verification according to claim 6, characterized in that, The standard for a successful virtual machine startup is when the virtual machine loads the kernel and completes initialization to the point where it can receive startup parameters, rather than entering the full operating system user mode.

Images