Backup virtual machine operating system detection system

Abstract

The application relates to the technical field of operating system environment detection, and provides an operating system detection system of a backup virtual machine, which can detect the operating system of the backup virtual machine without starting the backup virtual machine and directly exposing the host environment. A simulator management module maps the backup virtual machine disk to a disk access interface to construct a root file system of the detection virtual machine; a kernel of the detection virtual machine constructs a directory tree of the detection virtual machine according to the root file system; and a main process of the detection virtual machine mounts the root file systems of multiple partitions in the disk of the backup virtual machine to different mounting points in the directory tree through the disk access interface, determines a candidate root file system in the root file systems under the different mounting points, analyzes a file pointed to by a preset file path in the candidate root file system, and obtains an operating system detection result according to the analysis result.

Description

Technical Field

[0001] This application relates to the field of operating system environment detection technology, and in particular to an operating system detection system for backup virtual machines. Background Technology

[0002] In enterprise-level backup and recovery systems, virtual machine backups are typically stored in the form of snapshot backup disks, image files, or read-only backup disks. For file-level recovery, system compliance checks, asset identification, disaster recovery orchestration, or cross-platform recovery, the backup system needs to identify the operating system information within the backup virtual machine. Traditional methods usually require starting the backup virtual machine or directly mounting the backup virtual machine's disk on the host machine and parsing the files using scripts. Starting the backup virtual machine requires significant CPU, memory, and startup time, and may also trigger business system auto-start, disk writes, network conflicts, authorization failures, or security risks. While directly mounting and parsing on the host machine is lighter, it lacks sufficient security isolation. Summary of the Invention

[0003] Therefore, it is necessary to provide an operating system detection system, an emulator management module, an emulator process, and a virtual machine detection system to address the above-mentioned technical problems.

[0004] This application provides an operating system detection system for backing up virtual machines, the system comprising:

[0005] The emulator management module of the host machine is used to map the disk of the backup virtual machine to the disk access interface after receiving a request to detect the operating system of the backup virtual machine.

[0006] The emulator management module is used to build the root file system of the operating system of the virtual machine and start the emulator process;

[0007] The emulator process is used to trigger the kernel of the detection virtual machine to build the directory tree of the detection virtual machine according to the root file system of the operating system of the detection virtual machine and start the main process of the detection virtual machine.

[0008] The main process is used to mount the root file system of multiple partitions in the disk of the backup virtual machine to different mount points in the directory tree through the disk access interface.

[0009] The main process is used to determine the root file system of the operating system belonging to the backup virtual machine in the root file system under different mount points based on the characteristic files or directories of the operating system, and obtain candidate root file systems.

[0010] The main process is used to determine a preset file path, parse the operating system information of the file pointed to by the preset file path in the candidate root file system, and obtain the operating system detection result based on the parsing result; the preset file path is a preset path for a file used to store operating system information.

[0011] This application provides a simulator management module, which is the simulator management module in the operating system detection system described in any of the above embodiments.

[0012] This application provides an emulator process, which is the emulator process in the operating system detection system described in any of the above embodiments.

[0013] This application provides a detection virtual machine, which is the detection virtual machine in the operating system detection system described in any of the above embodiments.

[0014] In the solution provided in this application, after receiving a request to detect the operating system of the backup virtual machine, the emulator management module of the host machine maps the disk of the backup virtual machine to the disk access interface; the emulator management module constructs the root file system of the operating system of the detection virtual machine and starts the emulator process; the emulator process triggers the kernel of the detection virtual machine to construct the directory tree of the detection virtual machine based on the root file system of the operating system of the detection virtual machine and starts the main process of the detection virtual machine; the main process mounts the root file systems of multiple partitions in the disk of the backup virtual machine to different mount points in the directory tree through the disk access interface, and determines the root file system of the operating system of the backup virtual machine based on the characteristic files or directories of the operating system in the root file systems under different mount points, thus obtaining candidate root file systems; the main process determines a preset file path, performs operating system information parsing on the files pointed to by the preset file path in the candidate root file systems, and obtains the operating system detection result based on the parsing result; the preset file path is a preset path for storing operating system information. The solution provided in this application can detect the operating system of the backup virtual machine without starting the backup virtual machine and without directly exposing the host machine environment, which can reduce detection resource consumption, improve security isolation, and reduce the risk of abnormal file systems or malicious content affecting the host machine. Attached Figure Description

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

[0016] Figure 1This is a schematic diagram of the operating system detection system for backing up virtual machines in one embodiment;

[0017] Figure 2 This is a schematic diagram of the operating system detection process in one embodiment;

[0018] Figure 3 This is a schematic diagram of the Windows Registry processing flow in one embodiment;

[0019] Figure 4 This is a schematic diagram of the timing interaction process for backing up the virtual machine operating system detection in one embodiment. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0021] It should be noted that the terms "first," "second," etc., used in this application can be used to describe various objects, but these objects are not limited by these terms. These terms are only used to distinguish the first object from the second object. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the solutions, or any combination of multiple solutions.

[0022] The following describes the technical terms used in this application:

[0023] 1. QEMU: An open-source virtualization and hardware emulation tool. In this solution, it is used to launch a lightweight test virtual machine, rather than a full business client (i.e., a backup virtual machine).

[0024] 2. tinyvm: The lightweight detection virtual machine in this solution, running a minimal rootfs, init script and HTTP / JSON-RPC service, used to mount and detect backup disks.

[0025] 3. chroot environment: A runtime environment that switches the process root directory to a specified directory. The chroot-type detection environment in this solution uses the client's root directory on the backup disk as the logical root directory and completes the necessary pseudo-filesystem and runtime directory.

[0026] 4. rootfs: Root file system. This solution includes tinyvm's own minimal rootfs, as well as the root file system of the client system being monitored on the backup disk.

[0027] 5. Snapshot backup disk: A copy of the virtual machine disk generated or saved by the backup system at a certain point in time, which can be used for offline mounting, browsing, detection and recovery.

[0028] 6. Read-only backup disk: A backup disk or disk file provided to the detection process in read-only mode. The detection process cannot directly change its original contents.

[0029] 7. VSOCK: A socket communication mechanism between the virtual machine and the host machine, which can be used for communication between the host machine and the HTTP service within tinyvm.

[0030] 8. JSON-RPC: A JSON-based remote procedure call protocol. In this solution, it is used by the host machine to call the OS detection, command execution, file status, and Hive operation interfaces within tinyvm.

[0031] 9. Hive: The Windows registry's storage file on disk, such as SOFTWARE, SYSTEM, etc.

[0032] 10. hivex: A library for offline reading and modification of Hive files in the Windows registry.

[0033] 11. ControlSet: A set of keys in the Windows SYSTEM registry hive that stores system control configurations, such as ControlSet001. The currently used ControlSet can be determined via Select\Current.

[0034] 12. MountedDevices: A key in the Windows registry that records the correspondence between drive letters and disk partitions. It can be used to map drive letters such as C: and D: to specific partitions.

[0035] 13. fstab: The file system mount configuration file in Unix / Linux systems, usually located at / etc / fstab.

[0036] 14. LVM: Logical Volume Manager, Linux logical volume manager. Virtual machine disks may use LVM to manage root partitions and data partitions.

[0037] 15. Btrfs Subvolume: A subvolume structure within the Btrfs file system. On some Linux systems, the root file system may reside in a designated subvolume.

[0038] like Figure 1 As shown, the operating system detection system for backup virtual machines provided in this application includes an emulator management module, an emulator process, and a detection virtual machine.

[0039] The simulator management module runs in the host operating system's user space, serving as the control plane for the entire detection system. It is responsible for managing the virtual machine instance lifecycle (including creation, startup, and destruction), executing backup disk mount policies (mapping snapshot volumes or image files to a unified disk access interface), and reclaiming temporary resources on the host side after detection (such as unmounting mount points and releasing block device mappings). This module completes the aforementioned storage access actions by calling the host kernel's system interfaces (such as LVM drivers, NBD modules, and file system mounts).

[0040] The emulator process (such as the QEMU emulator process) is started by the emulator management module via the fork() and execve() system calls. It is an independent user-mode process on the host machine, possessing a process identifier (PID) assigned by the host operating system. This process is responsible for providing a complete virtual hardware environment, including a virtual CPU, memory, interrupt controller, bus, and disk controller. It simulates the disk access interface (block device node or disk image file path) prepared by the emulator management module as the root disk for detecting the virtual machine using the -drive parameter. The process itself runs on the host CPU and is scheduled by the host kernel.

[0041] The detection virtual machine is not a process within the host operating system, but rather a logical execution context running on the virtual hardware provided by the emulator process. It contains an independent kernel and processes, whose scheduling and memory management are confined to the virtual address space allocated by the emulator process. The host kernel is unaware of its internal process identifiers or page table structures. The detection virtual machine communicates with the host machine through virtual devices (such as virtio-blk and vsock) simulated by the emulator process, performing operations such as mounting backup disk partitions, parsing characteristic files, and executing chroot probe commands. The probe results are then returned to the emulator management module via JSON-RPC.

[0042] The relationship among the three in the host environment is as follows: the emulator management module and the emulator process both run directly in the host operating system and are host user-mode processes; while the detection virtual machine is logically isolated from the host, its internal state is not visible to the host operating system, and it exists only as a virtualized execution context maintained by the emulator process. The emulator management module is responsible for driver initiation and cleanup, the emulator process is the hardware simulation carrier, and the detection virtual machine is the isolated workload that actually performs OS detection tasks.

[0043] The host machine's emulator management module is used to map the backup virtual machine's disk to the disk access interface after receiving a request to detect the operating system of the backup virtual machine.

[0044] Specifically, the disk used to back up virtual machines refers to the offline backup data to be tested. Its physical form may be a snapshot volume in distributed storage, an image file in object storage, or an incremental chain in a deduplication storage pool. Mapping refers to the emulator management module calling the underlying storage driver (such as LVM activation, NBD export, or file download) to convert the above non-standard backup format into a standard storage object that can be recognized by the host kernel. The disk access interface is the product of the mapping action, specifically a block device node (such as / dev / mapper / snap_vm) or a disk image file path (such as / cache / disk.qcow2). This interface shields the differences in the physical form of the underlying backup storage, enabling the emulator process to load the disk with a unified -drive file= parameter and provide the root disk device for the virtual machine being tested. This mapping action is the step of converting backup data from an offline archive state into online storage resources that can be directly accessed by the virtualization layer.

[0045] The emulator management module is used to build the root file system of the operating system of the virtual machine and start the emulator process.

[0046] The emulator management module can build the root file system of the operating system of the detection virtual machine. This root file system is built to be the minimum root file system required to realize the lightweight running environment of the detection virtual machine. The building process is not just about creating a few empty directories, but about organizing the directory skeleton, the host machine's controlled resources, the detection virtual machine startup script, the pseudo file system mount point and service dependencies into an isolated running environment that can be started, execute detection commands and access the backup disk.

[0047] The construction process includes:

[0048] 1. Create the directory skeleton of the root file system, including / bin, / dev, / etc, / lib, / lib64, / mnt, / opt, / proc, / run, / sys, / tmp, / usr, / var, etc. This step reserves fixed locations for subsequent mounting of proc, sysfs, tmpfs, device directories, backup disk root directories and service dependency directories, so that the detection environment has a stable directory topology;

[0049] 2. Map read-only or controlled base directories (such as / etc, / lib, / lib64, / opt, / usr) on the host machine to the root file system of the virtual machine under test using bind mount. This allows the virtual machine under test to reuse necessary library files, configurations and service components on the host machine. This step is equivalent to assembling a set of controlled runtime dependencies for the virtual machine under test, rather than exposing the complete host machine to the system under test.

[0050] 3. Place the busybox executable file in / bin / busybox as a lightweight toolset for detecting the virtual machine's init scripts and basic command execution;

[0051] 4. Place the init script for the virtual machine in the root directory of the virtual machine's root file system. This script is executed by the kernel after the virtual machine's kernel starts. It is responsible for assembling the runtime environment, including: mounting proc to / proc, mounting sysfs to / sys, mounting tmpfs to / run and / tmp, initializing the basic device nodes under / dev, and starting mdev or similar device management logic so that block devices, partition devices and necessary character devices can be recognized by the detection service.

[0052] 5. Start services such as HTTP / JSON-RPC, device management, and process management, so that the host machine can use VSOCK to detect the OS probing, file access, command execution, and Hive operation capabilities inside the virtual machine.

[0053] The aforementioned root file system is not used to run the operating system of the backup virtual machine under test, but to build a lightweight runtime environment dedicated to testing. Its core function is to provide a sufficiently small, fast-starting, and controllable isolated testing environment that can execute testing commands and access the mounted backup disk, rather than restoring or starting the operating system of the backup virtual machine itself.

[0054] After completing the above root file system construction, the emulator management module calls the fork and execve system calls to start the emulator process. This process runs in the host operating system user space, has an independent process identifier, is responsible for providing a virtual hardware environment, and simulates the aforementioned disk access interface as the root disk device of the virtual machine through the -drive parameter, so that the virtual machine can boot from this root file system.

[0055] The emulator process is used to trigger the kernel of the virtual machine to build the directory tree of the virtual machine based on the root file system of the operating system of the virtual machine and start the main process of the virtual machine.

[0056] The emulator process is an independent process running in the user space of the host operating system. It loads the kernel image of the virtual machine and the root filesystem of the operating system during startup, enabling the CPU in the virtual hardware environment to execute the kernel boot code. During the boot phase, the kernel mounts the root filesystem as the root directory ( / ) of the Virtual File System (VFS), thus constructing the initial directory tree for the virtual machine. This initial directory tree contains the pre-defined directory skeletons in the root filesystem, such as / bin, / dev, / etc, / lib, / mnt, / proc, / sys, / tmp, and / run, as well as the busybox executable file placed in / bin and the init script located in the root directory / . After the kernel completes the mounting, it executes the / init program in this root directory tree, starting the main process of the virtual machine. The main process uses the root directory of the aforementioned root file system as its logical root directory, inheriting the root directory pointer already set by the kernel. After startup, it executes the runtime assembly process defined in the init script (including mounting pseudo file systems and temporary file systems such as / proc, / sys, / dev, / run, and / tmp, starting device management logic and HTTP / JSON-RPC services), putting the detection virtual machine into a ready state, waiting to receive operating system detection commands from the emulator management module. During this process, the emulator process, as the hardware emulation carrier, is responsible for providing the CPU instruction execution environment and virtual devices, and does not directly participate in the mounting or process creation operations during the kernel boot phase. All directory tree construction and main process startup are completed independently by the detection virtual machine kernel.

[0057] The main process is used to mount the root file systems of multiple partitions on the disk of the backup virtual machine to different mount points in the directory tree through the disk access interface.

[0058] The disk access interface, when inspecting the virtual machine, can be presented as a virtual block device (e.g., / dev / vda). The main process reads the partition table (MBR or GPT) of this block device to obtain the starting sector and size information of each partition, and generates corresponding partition block device nodes (e.g., / dev / vda1, / dev / vda2) in the / dev directory. Subsequently, the main process attempts to mount each partition block device, mounting its root file system to different pre-created mount points in the directory tree (e.g., / mnt / guest-root, / mnt / step1, / mnt / step2), so that the top-level root directory of each partition appears under the corresponding mount point path. After mounting is complete, the main process traverses each mount point, performing existence checks based on predefined operating system characteristic files or directories (e.g., / bin / sh or / etc / os-release for Linux, / Windows / System32 / config / SOFTWARE for Windows), and selecting the root file system belonging to the backup virtual machine's operating system from multiple mounted file systems as candidate root directories for subsequent execution of operating system detection commands or offline parsing. This process is performed by the main process after detecting that the virtual machine is ready to boot. Its purpose is to convert the offline backup data into a directory tree view that can be directly accessed by the detection logic, providing a unified file system entry point for subsequent feature parsing.

[0059] The main process is used to determine the root file system of the operating system belonging to the backup virtual machine in the root file systems under different mount points, based on the characteristic files or directories of the operating system.

[0060] This step is executed after the main process mounts the file systems of each partition in the backup virtual machine disk to different mount points in the directory tree.

[0061] Different operating systems follow fixed and mutually exclusive path conventions for storing identifier files and kernel / user-mode entry points in the root file system. For example, Windows fixes the system directory as Windows / System32 and stores the registry configuration unit in Windows / System32 / config. Linux uses / bin / sh and / etc / os-release as core entry points to distinguish distributions, while BSD and DOS series also have their own unique top-level identifier files or directories. Therefore, the main process probes based on the above-mentioned preset paths (i.e., the operating system's characteristic files or directories) to accurately locate the root file system of the operating system hosting the backup virtual machine from among multiple mounted root file systems.

[0062] In the specific determination, the main process traverses the root file systems that have been mounted to different mount points, and performs feature path existence checks on each mount point in a predefined priority order:

[0063] First, the process checks if a Windows system characteristic file or directory exists (Windows / System32 / cmd.exe or Windows / System32 / config / SOFTWARE). If found, it is marked as Windows, and further checks on that mount point cease. If not found, the process continues to check for Linux / Unix system characteristic files or directories. If found, it is marked as Linux / Unix. If still not found, the process expands to FreeBSD, NetBSD, OpenBSD, and DOS system characteristic files or directories in that order. Once a characteristic file or directory of a particular operating system is found, the main process identifies the root file system corresponding to that mount point as a candidate root file system and records its operating system type. For mount points where no characteristic path is found, they are marked as non-system partitions and skipped, not proceeding to the next step.

[0064] The main process is used to determine the preset file path, parse the operating system information of the files pointed to by the preset file path in the candidate root file system, and obtain the operating system detection result based on the parsing result; the preset file path is the preset path of the file used to store the operating system information.

[0065] Other information about the operating system besides the operating system type (such as distribution, version, hostname, CPU architecture, package management method, etc.) is usually stored in several file paths in the root file system, following the conventions of each operating system. For example, Linux stores the distribution identifier and version information in / etc / os-release, the hostname in / etc / hostname, and the file system mount table in / etc / fstab; Windows stores system version, registry configuration, drive letter mapping, and other information in binary hive files such as SOFTWARE and SYSTEM under the Windows / System32 / config directory; and the BSD series stores system version and distribution information in corresponding characteristic files under etc / .

[0066] The default file paths are the default paths used to store operating system information. These default file paths include, but are not limited to: Linux's etc / os-release, etc / hostname, and etc / fstab; Windows' Windows / System32 / config / SOFTWARE and Windows / System32 / config / SYSTEM; and FreeBSD / NetBSD / OpenBSD's etc / rc.conf, etc / freebsd-update.conf, etc / netbsd, and etc / openbsd, etc.

[0067] The main process performs the following operations on the candidate root file system: concatenates the mount point path of the candidate root file system with the preset file path to obtain the absolute access path; for text files (such as os-release, hostname), it calls the standard file reading interface (open+read) to read the file content based on the absolute access path, and parses it according to the corresponding format (such as parsing os-release by the KEY=VALUE line, and directly reading the first line of hostname), extracting fields such as operating system name, version number, and hostname; for binary hive files (Windows' SOFTWARE and SYSTEM), it calls the preset registry parser based on the absolute access path, reads the hive file structure offline, traverses the registry, and extracts version information according to the preset key path (such as SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductName and BuildNumber).

[0068] After completing the parsing of operating system information, the parsing results can be encapsulated into a structured JSON object to obtain the operating system detection results. The operating system detection results can include operating system type, distribution name, version number, hostname, architecture information, and package management method, etc., which can be directly received by the simulator management module and returned to the upper-level backup system for decision input in subsequent file-level recovery, system compliance check, asset identification, or cross-platform recovery scenarios.

[0069] In the above scheme, after receiving a request to detect the operating system of the backup virtual machine, the emulator management module of the host machine maps the disk of the backup virtual machine to the disk access interface; the emulator management module constructs the root file system of the operating system of the detection virtual machine and starts the emulator process; the emulator process triggers the kernel of the detection virtual machine to construct the directory tree of the detection virtual machine based on the root file system of the operating system of the detection virtual machine and starts the main process of the detection virtual machine; the main process mounts the root file systems of multiple partitions in the disk of the backup virtual machine to different mount points in the directory tree through the disk access interface, and determines the root file system of the operating system of the backup virtual machine based on the characteristic files or directories of the operating system in the root file systems under different mount points, thus obtaining candidate root file systems; the main process determines a preset file path, performs operating system information parsing on the files pointed to by the preset file path in the candidate root file systems, and obtains the operating system detection result based on the parsing result; the preset file path is a preset path for storing operating system information. The scheme provided in this application can detect the operating system of the backup virtual machine without starting the backup virtual machine and without directly exposing the host machine environment, which can reduce detection resource consumption, improve security isolation, and reduce the risk of abnormal file systems or malicious content affecting the host machine.

[0070] In an exemplary embodiment, when the main process determines the root file system belonging to the operating system of the backup virtual machine in the root file systems under different mount points based on the characteristic files or directories of the operating system, it is specifically used to: determine the characteristic files or directories of various operating systems; when the root file system under one mount point has a characteristic file or directory, determine that the root file system under the mount point belongs to the root file system of the backup virtual machine's operating system; the main process is also used to determine the operating system type corresponding to the characteristic files or directories existing in the root file system under the mount point, and determine the operating system type as the type of the backup virtual machine's operating system; the main process is also used to obtain the operating system information of the backup virtual machine based on the operating system type to which the backup virtual machine's operating system belongs.

[0071] Characteristic files or directories for various operating systems can be predefined. For example, characteristic files or directories for Windows systems include Windows / System32 / cmd.exe and Windows / System32 / config / SOFTWARE; characteristic files or directories for Linux / Unix systems include bin / sh and etc / os-release or etc / fstab; characteristic files or directories for FreeBSD / NetBSD / OpenBSD systems include etc / rc.conf and the corresponding system kernel file; and characteristic files or directories for DOS systems include COMMAND.COM.

[0072] When the main process traverses mount points, it checks them sequentially according to priority. If a file or directory matching the characteristics of a certain type of operating system exists in the root file system under a mount point, then the root file system under that mount point is determined to belong to the operating system root file system of the backup virtual machine, and the matching operating system type is recorded. If the current mount point does not match any operating system's characteristic files or directories, it is marked as a non-system partition and subsequent processing is skipped.

[0073] In an exemplary embodiment, the main process is further configured to, after determining the operating system type to which the operating system of the backup virtual machine belongs, determine a preset file path corresponding to the operating system type, and perform operating system information parsing on the files pointed to by the preset file path corresponding to the operating system type in the candidate root file system.

[0074] Different operating systems follow their own independent path conventions when storing metadata such as distribution identifiers, version numbers, hostnames, architecture information, and package management methods in the root file system. For example, Linux stores the distribution identifier and version information in `etc / os-release`, and the hostname in `etc / hostname`; Windows stores version information and configuration data in `Windows / System32 / config / SOFTWARE` and the `SYSTEM` binary hive file; while BSD systems record version information in `etc / rc.conf` and the corresponding system name file. After determining the operating system type, the main process can determine the default file paths corresponding to that type to parse the operating system information, thus avoiding invalid reads and parsing errors.

[0075] Specifically, when the operating system type is determined to be Linux / Unix, the main process retrieves the default file paths corresponding to that type. These default file paths include, but are not limited to, etc / os-release, etc / hostname, etc / fstab, etc / *-release, etc / lsb-release, proc / version, proc / cpuinfo, and the package management database path (such as var / lib / rpm / Packages or var / lib / dpkg / status). When the operating system type is determined to be Windows, the main process retrieves the corresponding default file paths, including, but not limited to, Windows / System32 / config / SOFTWARE, Windows / System32 / config / SYSTEM, Windows / System32 / cmd.exe, and Windows / System32 / kernel32.dll. When the operating system type is determined to be BSD, the main process retrieves the corresponding default file path table, including, but not limited to, etc / rc.conf, etc / freebsd-update.conf, etc / netbsd, etc / openbsd, and bin / sh.

[0076] The main process can determine the file pointed to by the preset file path corresponding to the operating system type in the candidate root file system, and parse the operating system information of the file to obtain the parsing result.

[0077] In an exemplary embodiment, when the operating system type of the backup virtual machine is the same as the operating system type of the detection virtual machine, the main process, upon receiving the operating system detection command, assembles the runtime environment required for the child process to execute the operating system detection command at the target mount point; the target mount point is the mount point of the root file system of the operating system of the backup virtual machine.

[0078] As an example, when both the operating system of the backup virtual machine and the operating system of the detection virtual machine are Linux / Unix, operating system information can also be obtained by executing commands. The emulator management module can send operating system detection commands to the main process. When the main process receives the operating system detection command, it can take the mount point of the root file system of the operating system of the backup virtual machine as the target mount point, and assemble the runtime environment required for the child process to execute the operating system detection command under the target mount point. This runtime environment is not used to start the operating system of the backup virtual machine, but to ensure that the operating system detection commands executed after chroot (such as cat / etc / os-release, uname -m, rpm-qa, dpkg-query, etc.) can normally access the kernel interfaces and temporary storage space such as / proc, / sys, dev, / run, and / tmp, avoiding command execution failure or incomplete information return due to missing pseudo file systems or runtime directories.

[0079] The child process is used to switch its own logical root directory to the target mount point, so that the child process can execute operating system detection commands from the perspective of the backup virtual machine's operating system and obtain the command execution results.

[0080] The main process can start child processes. After starting, the child process can call the chroot system call to point its own root directory pointer (fs->root) to the target mount point (i.e., the root filesystem mount point of the backup virtual machine's operating system), and call chdir(" / ") to synchronously switch the current working directory to the new root directory, thus completing the migration of the execution context. After the switch, the / seen by the child process is the root filesystem content of the backup virtual machine, while paths such as / proc, / sys, / dev, / run, and / tmp are automatically mapped to the kernel interfaces and temporary filesystems pre-bound to the main process through the mount view inherited from the parent process.

[0081] The operating system detection command to be executed by the child process is itself a binary executable file stored in the root file system of the backup virtual machine. After switching the root directory, the child process calls the execve system call, passing in the path of the command (such as / bin / sh, / usr / bin / cat, etc.). The kernel resolves the path based on the child process's current root directory pointer (which already points to the target mount point), locates the corresponding binary file in the root file system of the backup virtual machine, and loads it into the child process's memory space for execution.

[0082] Throughout the execution process, the child process focuses on the root file system of the backup virtual machine. All dependent binary files, library files, and configuration files originate from the backup virtual machine's disk, rather than examining the virtual machine's own root file system. Simultaneously, because the main process has pre-mounted runtime interfaces such as / proc, / sys, / dev, / run, and / tmp for the child process, these binary files can access kernel information and temporary storage during execution, ensuring that commands run smoothly and output results. After executing the command, the child process returns the command execution result to the main process via a pipe.

[0083] When the main process obtains the operating system detection result based on the parsing result, it specifically verifies the operating system information in the command execution result with the operating system information in the parsing result to obtain the operating system detection result.

[0084] The aforementioned parsing of the file pointed to by the preset file path is a static file parsing method. The parsing result obtained by the main process through the static file parsing method includes operating system information; the command execution result obtained by executing the operating system detection command also includes operating system information.

[0085] The main process can compare the operating system information in the parsed results with the operating system information in the command execution results item by item according to the same field name (such as distribution name, version number, hostname, architecture). If a field is completely consistent in both the parsed and command execution results, the field is marked as "verified successfully" and a high-confidence label is set for that field. If a conflict exists (for example, the version number in the parsed result is 22.04, while the version number in the command execution result is 20.04), the main process can output both results for that field simultaneously and set a conflict label for that field. If a field is obtained only from static parsing or only from command execution, a "single-source acquisition" label can be set for that field, and no verification is performed. This verification mechanism effectively eliminates the risk of misjudgment of the feature library due to file corruption, backup remnants, or non-standard distributions through multi-source cross-validation, improving the accuracy and anti-interference ability of the detection results.

[0086] In one exemplary embodiment, the main process is further configured to:

[0087] Create a first-class directory and a second-class directory under the target mount point. Mount the pre-assembled pseudo-filesystem to the first-class directory through binding. Mount a temporary filesystem for the second-class directory to assemble the runtime environment required for the child process to execute operating system detection commands under the target mount point. The first-class directory is the directory used to mount the pseudo-filesystem, and the second-class directory is the runtime directory.

[0088] The main process creates two types of directories under the target mount point: first-class directories (directories for mounting pseudo-filesystems, such as proc / , sys / , dev / ) and second-class directories (directories for mounting runtime directories, such as run / , tmp / ). The purpose is to pre-build a complete directory view under the target mount point (i.e., the location of the backup virtual machine operating system's root filesystem) before the child process executes chroot to switch the root directory. If these directories are missing, the detection commands executed by the child process after chrooting (such as cat / etc / os-release, uname -m) will fail because paths like / proc, / sys, / dev, / run, and / tmp do not exist. This is because standard system commands typically rely on these paths to obtain kernel information, access device nodes, or create temporary files during execution. Therefore, the main process creates these directories under the target mount point before performing the mount operation.

[0089] The main process uses `mount--bind` to map the pre-installed ` / proc`, ` / sys`, and ` / dev` resources of the virtual machine to the first type of directory. This allows child processes, after chrooting, to obtain process and kernel information (such as ` / proc / cpuinfo` and ` / proc / mounts`) through ` / proc`, device and bus topology information (such as ` / sys / block`) through ` / sys`, and access necessary device nodes (such as ` / dev / null` and ` / dev / zero`) through ` / dev`. Simultaneously, the main process mounts independent `tmpfs` temporary filesystems for the second type of directories (` / run` and ` / tmp`), providing readable and writable temporary storage space for child processes. This allows commands to write to temporary files (such as the cache files of `lsb_release`) or create runtime state files (such as the ` / run / systemd` directory required by systemd-related tools). After the above resource installation is complete, the directory view under the target mount point contains all the necessary paths after the child process executes chroot, and these paths have correct runtime semantics (the pseudo-filesystem points to the kernel interface, and the runtime directory points to the memory filesystem). After assembly is complete, the main process spawns a child process. The child process inherits the mount view via fork() and directly uses these paths after switching the root directory using chroot, without needing to perform any additional mount operations. This assembly process ensures that the child process can execute commands normally in an isolated testing environment, from a perspective close to that inside the backup virtual machine operating system, avoiding command execution failures due to missing directories or unavailable paths.

[0090] In an exemplary embodiment, when the main process receives an operating system detection command, it assembles the runtime environment required for the child process to execute the operating system detection command at the target mount point, specifically for the following purposes:

[0091] Upon receiving the operating system detection command, determine whether the operating system detection command is in the preset whitelist of commands; if so, assemble the runtime environment required for the child process to execute the operating system detection command under the target mount point.

[0092] After receiving an operating system detection command, the main process can perform a security check on the command to determine if it is in a preset whitelist. The preset whitelist can be a pre-configured set of read-only query commands.

[0093] If the operating system detection command is not in the preset whitelist, the main process can refuse to execute the command and return an error response. If the operating system detection command is in the preset whitelist, it means that the command is safe to execute, and the main process can assemble the runtime environment required for the child process to execute the operating system detection command at the target mount point.

[0094] In an exemplary embodiment, when mapping the disk of the backup virtual machine to the disk access interface, the simulator management module is specifically used for:

[0095] Based on the backup type of the backup virtual machine, determine the target mount strategy, and process the disk of the backup virtual machine according to the target mount strategy to map the disk to the disk access interface.

[0096] Backup types include snapshot backup disks, read-only backup disks, and disk image files, each with its own mounting strategy. The emulator management module obtains the backup type by parsing the backup object identifier (including backup task identifier, backup set identifier, snapshot time point identifier, disk identifier, etc.) and determines the target mounting strategy based on a preset strategy mapping table.

[0097] When the backup type is a snapshot backup disk, the emulator management module determines the target mount policy to be a snapshot mount policy. Under this policy, the emulator management module calls the underlying storage driver to activate the snapshot volume corresponding to the backup disk, maps it to a block device that the host kernel can recognize (such as / dev / mapper / snap_xxx), and returns the block device node path as the disk access interface after the mapping is completed.

[0098] When the backup type is a read-only backup disk, the emulator management module determines the target mount policy to be a read-only file mount policy. Under this policy, the emulator management module locates the disk image file in the backup storage based on the backup object identifier and selects the access method based on the file format: for raw format files, the file path is directly returned as the disk access interface; for non-raw format files, they can be exported as block devices (such as / dev / nbd0) through the NBD (Network Block Device) protocol, or directly accessed by QEMU natively via the -drive parameter.

[0099] When the backup type is a disk image file, the emulator management module determines the target mount policy to be a direct file access policy. Under this policy, the emulator management module directly returns the absolute path of the image file as the disk access interface.

[0100] When the backup type is other scalable sources, the simulator management module supports adding mounting strategies through a plugin mechanism. Plugins follow a unified mounting strategy interface. They only need to complete the conversion of backup data to block device nodes or file paths at the implementation layer and return standardized output to seamlessly integrate into the detection process.

[0101] After completing the above processing, the simulator management module returns the generated block device node path or file path as a unified disk access interface. This disk access interface masks the physical differences in the underlying backup storage (snapshot volumes, object storage image files, local files, etc.), enabling subsequent simulator processes to load the disk using this unified interface and providing the root disk device for virtual machine detection. If an error occurs during the mapping process (such as snapshot activation timeout, file non-existence, or NBD export failure), the simulator management module records the error log and returns a clear error code, terminating the detection process and preventing invalid disk interfaces from being passed to subsequent steps.

[0102] To better understand the above solution, the following details an application example of the operating system detection system for backing up virtual machines in this application.

[0103] The solution provided in this embodiment relates to the fields of virtualization, data protection, backup and recovery, offline disk parsing, and operating system environment detection. It can detect information such as Unix / Linux operating system type, hostname, system architecture, distribution version, and partition mount relationships in the backup virtual machine disk based on the QEMU lightweight virtualization environment and chroot-like root file system environment without starting the full business virtual machine (i.e., backup virtual machine). It can also perform offline registry hive-assisted identification for Windows systems.

[0104] To perform file-level recovery, system compliance checks, asset identification, disaster recovery orchestration, or cross-platform recovery, the backup system needs to identify the operating system information inside the backup virtual machine. For example, it needs to know the operating system type of the backup disk, such as Linux, Windows, FreeBSD, NetBSD, OpenBSD, or DOS, and further identify its distribution, version number, hostname, CPU architecture, package management method, Windows system directory, Windows registry hive path, and drive letter mappings.

[0105] Traditional methods typically require starting a full backup virtual machine or mounting the disk directly on the host machine and parsing the files using a script.

[0106] Starting a full backup virtual machine: The backup system restores or mounts the backup disk as a bootable virtual machine. After starting the guest operating system (the guest machine is also the backup virtual machine), commands are executed and configuration files or the registry are read to obtain information such as hostname, version, and architecture. Starting a full backup virtual machine requires significant CPU, memory, and startup time, and may also trigger business system auto-start, disk writes, network conflicts, authorization failures, or security risks.

[0107] Static file resolution is performed after directly mounting the backup disk on the host machine. This method typically uses loop, qemu-nbd, nbd, guestmount, or storage snapshot mounting to mount the partitions on the backup disk to the host machine directory. Then, the host machine program reads files such as / etc / os-release, / etc / hostname, and registry hive files under Windows system32 / config. While direct mounting and resolution on the host machine is lightweight, it is easily limited by the host machine environment when dealing with LVM, Btrfs subvolumes, multiple partitions, multiple file systems, Windows NTFS, registry hive, case-insensitive paths, symbolic links, and differences in configuration files across different Unix systems. Furthermore, the resolution logic is scattered, and security isolation is insufficient.

[0108] Utilizing general-purpose virtual machine disk access tools like libguestfs: These tools access virtual machine disks through an appliance, providing capabilities such as file reading, system identification, and registry reading. However, they typically exist as general-purpose libraries or command-line tools, requiring callers to perform secondary encapsulation around their capabilities. They don't necessarily possess deep integration with business processes such as backup system snapshot sources, instance lifecycles, communication channels, batch detection, and registry modification interfaces. Furthermore, their OS identification capabilities rely on the rules and version updates maintained by the tool itself, potentially leading to identification lag or failure to identify domestic operating systems, emerging distributions, and enterprise-customized distributions. This solution can address some offline access issues, but it still has shortcomings in cross-system detection, isolated execution environment construction, pseudo-filesystem completion, offline Windows registry read / write, multi-source access to backup disks, and unification with upper-layer backup and recovery processes. In particular, the operating system identification rules of general-purpose offline detection tools usually rely on their own version updates; when emerging Linux distributions, domestic operating systems, or enterprise-customized operating systems appear, they may fail to accurately identify them due to outdated feature libraries.

[0109] It is evident that the relevant technologies have the following problems:

[0110] 1. Fully starting a virtual machine consumes a lot of resources. Starting a full guest machine requires allocating a significant amount of CPU, memory, disk, and network resources, resulting in a long startup time. This makes it unsuitable for rapid testing of a large number of backup points in a backup system.

[0111] 2. A full startup of a virtual machine can easily alter the state of the backup disk. After the guest system starts, it may perform actions such as log replay, service auto-start, system updates, and temporary file writing, which can disturb the original state of the backup copy and reduce the controllability of the detection process.

[0112] 3. Insufficient isolation due to direct resolution on the host machine. Mounting client file systems from unknown sources directly on the host machine exposes it to issues such as abnormal file systems, malicious files, symbolic link jumps, and path case differences, resulting in unclear security boundaries.

[0113] 4. Static analysis lacks a runtime context close to the client machine. Many detection commands or system tools rely on runtime directories such as / proc, / sys, / dev, and / run. When simply reading files, these directories either do not exist or have incomplete semantics, leading to a large number of special cases being required for the detection logic.

[0114] 5. Poor compatibility with multiple operating systems. The system directory structure, hostname configuration, version files, startup configuration, registry or mount table format of systems such as Linux, Windows, FreeBSD, NetBSD, and OpenBSD are quite different, making it difficult for a single script to reliably cover them.

[0115] 6. General tools lag behind in adapting to new systems. Taking the libguestfs tool as an example, its OS detection rules are usually updated with each tool release. When the target is a domestic operating system, an emerging Linux distribution, an industry-customized system, or a system whose distribution identification file has changed, problems such as being identified as "unknown," missing version numbers, or misjudging the distribution may occur.

[0116] 7. Offline processing of the Windows Registry is complex. A large amount of Windows system information is stored in Hive instances such as SOFTWARE and SYSTEM, and drive letter mappings may also involve binary values ​​such as GPT / MBR identifiers and MountedDevices. Simple file reading cannot reliably parse and modify this structured data.

[0117] 8. Inconsistent backup source access. Snapshot backup disks, read-only backup disks, and disk images use different mounting methods. If the detection process is coupled with the mounting strategy, it can lead to difficulties in expansion.

[0118] Based on this, this embodiment provides a solution that employs a lightweight QEMU detection framework for backup virtual machine disks. A minimal runtime environment is built within QEMU, and the backup disk is mounted within this environment. For Unix / Linux systems, candidate root directories are assembled into a chrootable detection root environment, where controlled read-only probe commands are executed and combined with file parsing to obtain OS information. For Windows systems, chroot execution is not forcibly used; instead, it is treated as an offline hive and system directory identification branch, thus obtaining relatively complete OS information without starting the full guest system (i.e., the operating system of the backup virtual machine). Therefore, this solution can build a sufficiently realistic, lightweight, and controllable isolated operating system detection environment for backup virtual machine disks without starting the full backup virtual machine, directly exposing the host environment, or relying entirely on direct host parsing. This allows detection of Unix / Linux systems to be completed using the guest root directory, guest toolchain, and completed runtime directories, while enabling Windows systems to complete auxiliary detection within the same QEMU isolated environment through offline registry and system directory identification. This approach constructs a minimal root environment within a controlled QEMU tinyvm, mounts the backup disk as the object to be detected into the isolated environment, and then triggers OS detection and hive operations through the VSOCK channel.

[0119] Specifically, for backup virtual machine disks, a minimalized version of tinyvm is first launched using QEMU (an emulator) as a controlled detection vehicle. Within tinyvm, the backup disk partitions, LVM, root file system, and necessary runtime directories are organized into a chroot-like detection environment. This allows Unix / Linux detection programs to read system files, resolve symbolic links, and identify file structures with the guest machine's root directory as the logical root directory. Under whitelisting and read-only constraints, they can invoke probe commands within the guest machine's root directory, such as reading release files, querying package management databases, executing hostnames, reading fstab, or calling the distribution's built-in version lookup tools. For Windows systems, offline identification is performed within the same isolated environment using system directory characteristics and hive files such as SOFTWARE and SYSTEM, without packaging Windows detection as meaningless chroot execution. Simultaneously, VSOCK connects the host machine to the HTTP / JSON-RPC service within tinyvm, enabling unified scheduling of backup disk mounting, OS information detection, file access, and registry read / write. This solution transforms "fully launching the client machine" into "launching a lightweight detection virtual machine and constructing the client machine root environment," and can flexibly expand the identification rules according to the characteristics of new distributions or domestic systems, achieving a good balance between resource consumption, isolation, cross-system compatibility, and automated detection capabilities.

[0120] The solution involves the following components:

[0121] 1. Backup Disk Access Module: Used to access snapshot backup disks, read-only backup disks, disk image files or other backup disk sources, and provide backup disk files or block devices to the subsequent QEMU detection environment.

[0122] 2. Mounting Strategy Module: Selects the corresponding mounting strategy based on the backup source, such as snapshot backup disk mounting strategy, read-only backup disk mounting strategy, image file mounting strategy, etc., so that the upper-layer detection process does not care about the differences in the underlying backup source.

[0123] 3. QEMU Instance Management Module: Responsible for creating, reusing, and destroying lightweight QEMU tinyvm instances, and maintaining instance status such as PENDING, CREATING, MOUNTING, CREATED, FAILED, etc.

[0124] 4. tinyvm rootfs build module: Responsible for building the minimal root file system, creating directories such as / bin, / dev, / etc, / lib, / lib64, / mnt, / opt, / proc, / run, / sys, / tmp, / usr, and / var, and placing busybox, init scripts, and necessary service configurations inside.

[0125] 5. Isolation Root Environment Construction Module: Mount pseudo file systems and device directories such as proc, sysfs, tmpfs, and dev in tinyvm, mount the target root partition in the backup disk as the detection root directory, and form a chroot-like detection environment that can be actually entered by Unix / Linux detection commands.

[0126] 6. Communication Module: The host machine connects to the HTTP service inside tinyvm through VSOCK and initiates OS probing, file access, and registry operation requests through this channel.

[0127] 7. OS Detection Module: Performs operating system detection on the specified root directory within tinyvm, identifying systems such as Linux, Windows, FreeBSD, NetBSD, OpenBSD, and DOS, and extracting system information.

[0128] 8. Windows Registry Hive Operation Module: Based on the HiveX library, it opens, reads, modifies, and commits Windows Registry Hive files, and supports offline processing of SOFTWARE, SYSTEM, and other Hive applications.

[0129] 9. Cleanup and Lifecycle Module: Performs periodic cleanup of idle tinyvm, residual QEMU processes, and mount points to prevent resource leaks.

[0130] The overall flow of this embodiment is as follows: Figure 2 As shown in the diagram, this illustrates the module hierarchy and call relationships of the backup virtual machine operating system detection system. The Console / Backup console calls the Agent / QEMU Manager module via JSON-RPC. The Agent / QEMU Manager is responsible for QEMU instance lifecycle management and connects to various backup disk sources, such as snapshots, read-only backup disks, and image files, through mount policies. The Agent / QEMU Manager communicates with QEMUTinyVM via HTTP / JSON-RPC. TinyVM first mounts the backup disk partition and activates LVM, then performs feature detection to determine the operating system type, and assigns it to the corresponding branch accordingly: the Linux / Unix system branch prioritizes static file parsing, and builds a chroot environment and executes read-only commands as needed when supplementary information is required; the Windows system branch directly parses SOFTWARE and SYSTEM hive offline to obtain the version, hostname, and drive letter mapping. The detection results from each branch are summarized and returned to the upper layer.

[0131] Regarding backup disk access and mounting: When the upper layer needs to detect a specific backup virtual machine disk, the QEMU instance management module can generate or find the corresponding tinyvm instance based on the backup object identifier. The backup object can be uniquely identified by information such as the backup task identifier, backup set identifier, snapshot time point identifier, and disk identifier.

[0132] The mount strategy module performs different processing based on the backup type: for snapshot backup disks, it calls the snapshot backup disk mount strategy to mount the disk to the host machine or provide it to tinyvm in a controllable manner; for read-only backup disks, it calls the read-only backup disk mount strategy to obtain the backup disk file or block device in read-only mode, avoiding changes to the backup data during the detection process; for other scalable sources, mount strategies can be added, as long as the ultimately accessible disk file or block device is provided to QEMU.

[0133] The purpose of the mounting strategy is to decouple the "difference in backup sources" from the "OS detection process," so that the OS detection module only faces a unified disk access interface.

[0134] TinyVM minimal OOTFS (detecting the root filesystem of the virtual machine's operating system):

[0135] Before starting QEMU, a minimal rootfs can be built. This rootfs is not used to boot the operating system of the backup virtual machine, but rather as a lightweight runtime environment for testing. Its focus is not merely on creating several empty directories, but on organizing the directory skeleton, host-controlled resources, tinyvm startup scripts, pseudo-filesystem mount points, and service dependencies into a bootable, executable testing command environment with access to the backup disk. The minimal rootfs building process includes:

[0136] 1. Create the rootfs directory skeleton, including / bin, / dev, / etc, / lib, / lib64, / mnt, / opt, / proc, / run, / sys, / tmp, / usr, / var, etc. This step reserves fixed locations for subsequent mounting of proc, sysfs, tmpfs, device directories, backup disk root directories, and service dependency directories, ensuring a stable directory topology for the testing environment.

[0137] 2. Map read-only or controlled base directories on the host machine, such as / etc, / lib, / lib64, / opt, and / usr, to the tinyvm rootfs using bind mount. This allows tinyvm to reuse necessary library files, configurations, and internal service components. This step is equivalent to assembling a controlled set of runtime dependencies for tinyvm, rather than exposing the entire host machine to the system under test (i.e., the operating system of the backup virtual machine).

[0138] 3. Place busybox in bin / busybox as a lightweight toolset for the tinyvm init script (tinyvm startup script) and basic command execution.

[0139] 4. Place the tinyvm init script, which will perform runtime assembly after tinyvm starts: mount proc to / proc, mount sysfs to / sys, mount tmpfs to runtime directories such as / run and / tmp, initialize the basic device nodes under / dev, and start mdev or similar device management logic to enable block devices, partition devices and necessary character devices to be recognized by the detection service.

[0140] 5. Start services such as HTTP / JSON-RPC, device management, and process management, enabling the host machine to call tinyvm's internal OS detection, file access, command execution, and Hive operation capabilities through VSOCK.

[0141] The core function of this minimal rootfs is to provide a sufficiently small, fast-starting, and controllable environment for detecting the virtual machine's operating system, rather than restoring or starting the backup virtual machine's own operating system.

[0142] chroot class detection environment setup:

[0143] After tinyvm starts, it mounts the backup disk partitions into tinyvm and identifies the partitions, LVM volumes, root file system, and subvolumes within it. For paths identified as potential system root directories, it builds a chroot-like detection environment.

[0144] A chroot-based detection environment refers to using the guest system's root directory on the backup disk as the logical root directory. Resources already configured in tinyvm, such as proc, sysfs, device directories, and runtime directories, are mounted or bound to this logical root directory as needed. This allows the detection process to read files and execute controlled detection commands from a perspective close to that of the guest system. The purpose of supplementing the runtime directory is not to boot the guest operating system, but to provide the OS (operating system) detection commands executed in chroot with the system context upon which they depend for proper operation. For example, executing chroot... <guest-root> / usr / bin / rpm-qf / etc / os-release、chroot <guest-root> / usr / bin / dpkg-query-S / etc / os-release、chroot <guest-root> / bin / hostname、chroot <guest-root>When using ` / usr / bin / lsb_release -a` or the version lookup tool included with the distribution, related programs may access paths such as ` / proc`, ` / sys`, ` / dev`, ` / run`, ` / tmp`, the dynamic linker, NSS configuration, and package management database. If these directories are just empty directories, or if they are not given runtime semantics through methods such as `mount`, `bind mount`, `tmpfs`, or device node initialization, the command may still fail to execute, return incomplete information, or misjudge the system status.

[0145] 1. Guest root file system, such as / in Linux, / Windows or / WINNT directory in Windows system partition, BSD system root directory, etc.

[0146] 2. / proc: Used to provide runtime views of processes, kernel, mounts, CPU, memory, etc., to OS detection commands within chroot. Some system identification commands, package management commands, or scripts read information from / proc / mounts, / proc / cpuinfo, / proc / filesystems, etc.

[0147] 3. / sys: Used to provide sysfs information such as devices, block devices, file systems, and buses, enabling the detection logic to identify disk, partition, block device attributes, and some system capabilities exposed by the kernel.

[0148] 4. / dev: Used to provide entry points for basic device nodes and block devices, such as disk partition devices, LVM devices, null, zero, random, etc. Some detection commands or libraries check or access these device nodes during startup.

[0149] 5. / run: Used to provide runtime status directories. Some newer Linux distributions and systemd-related tools access the runtime path under / run by default, and may rely on this directory even when querying system information.

[0150] 6. / tmp: Used to provide a temporary file directory. Some detection commands, scripts, or dynamic library loading processes may require the creation of temporary files.

[0151] 7. Path resolution capabilities, including symbolic link resolution, case-insensitive path lookup, and relative path restoration, to adapt to the differences between Linux / Unix and Windows file systems.

[0152] Its working logic can be represented by the following:

[0153] TinyVM rootfs

[0154] /

[0155] |-- bin

[0156] `-- busybox

[0157] |-- dev <- device nodes initialized by mdev

[0158] |-- etc <- bind-mounted controlled configuration

[0159] |-- lib / lib64 <- bind-mounted runtime libraries

[0160] |-- opt / usr / var <- bind-mounted service dependencies

[0161] |-- proc <- proc filesystem mounted at boot

[0162] |-- run <- tmpfs runtime filesystem

[0163] |-- sys <- sysfs mounted at boot

[0164] |-- tmp <- tmpfs temporary workspace

[0165] `-- mnt

[0166] `-- guest-root <- mount point for backing up the root filesystem of the virtual machine itself

[0167] |-- proc <- proc bind / mount view for chroot commands

[0168] |-- sys <- sysfs bind / mount view for chroot commands

[0169] |-- dev <- device bind / mount view for chroot commands

[0170] |-- run <- tmpfs runtime view for chroot commands

[0171] |-- tmp <- tmpfs workspace for chroot commands

[0172] |-- etc

[0173] | |-- os-release

[0174] | |-- fstab

[0175] | `-- hostname

[0176] |--: Indicates that the current line is a sub-item (directory or file) under the parent directory, and there are sibling items following it. `--: Indicates that the current line is the last sub-item under the parent directory, and there are no more sibling items following it. <-: Comment separator. The English sentence to the right of the arrow is a technical comment on the path or file to the left of the arrow (explaining its origin, mounting method, or initialization method).

[0177] / : Detects the global root directory of the TinyVM virtual machine. bin: Short for Binary, the directory containing user-space executable programs. busybox: A single executable file that integrates hundreds of standard Unix commands such as sh, ls, cat, and mount, serving as the basic command toolkit for TinyVM. dev: Short for Device, the directory for device files. mdev is the device management tool in BusyBox, responsible for scanning the kernel at startup and creating nodes such as / dev / null and / dev / vda in this directory. etc: Et Cetera (derived from Unix convention), the directory containing system configuration files. Here, controlled configurations are injected from the host machine via bind-mounting. lib / lib64: Short for Library, the directory containing dynamic link libraries (such as libc.so). Mapped from the host machine via bind-mounting, allowing TinyVM to reuse the host machine's C runtime libraries. opt: Short for Optional, usually used to store third-party applications; here, it's used to store TinyVM's service dependencies. usr: Unix System Resources (early meaning), the directory containing system tools, libraries, and services. Here, the host machine is mapped via binding mount. `var`: Short for Variable, stores runtime data (such as logs and cache). Service dependencies are mapped from the host machine via binding mount. `proc`: Short for Process Information Pseudo-filesystem; the procfs interface mounted by the kernel at startup, providing process lists, memory statistics, and kernel parameters. `run`: Directory storing runtime data (such as PID files and Unix sockets), mounted as tmpfs (memory file system), data is lost after reboot. `sys`: Short for System Filesystem, i.e., sysfs; mounted by the kernel at startup, providing an interface for device, driver, and bus topology information. `tmp`: Short for Temporary, directory storing temporary files, mounted as tmpfs, automatically cleared upon reboot. `mnt`: Short for Mount, standard parent directory used for temporarily mounting external file systems (such as mounting backup disk partitions).

[0178] TinyVM's operating system root filesystem corresponds to ` / ` (the top-level root node of the tree) and all top-level directories and files under it except for the content mounted to ` / mnt / guest-root`. Specifically, it includes the following parts:

[0179] / bin (including busybox)

[0180] / dev (device node)

[0181] / etc (configuration for binding mounts)

[0182] / lib, / lib64 (runtime libraries)

[0183] / opt, / usr, / var (service dependencies)

[0184] / proc, / sys (kernel pseudo-filesystem mount points)

[0185] / run, / tmp (tmpfs temporary file system)

[0186] / mnt (Note: This specifically refers to the empty directory / mnt itself, which is TinyVM's own skeleton directory)

[0187] When TinyVM's own operating system's root file system is built, / mnt is just an empty skeleton directory used as the parent mount point for subsequently mounting backup disks. Only after the main process mounts the backup disk partition to / mnt / guest-root does the content under that path become the data of the backup virtual machine. At this point, it is still mounted in TinyVM's directory tree, but in terms of storage ownership, it has been classified as "external load" rather than TinyVM's own runtime dependency.

[0188] guest-root: Short for Guest Root. It is the mount point for the backup virtual machine's root file system in TinyVM. This path contains the root file system of a single partition on the backup disk. guest-root / proc (bind mount): Here, proc is not a directory inherent to the backup disk, but rather a view image mapped here by TinyVM using `mount --bind / proc`, used to provide process information interfaces for chrooted inspection commands. guest-root / sys (bind mount): TinyVM's / sys directory is bound to this location, providing device and kernel interfaces for chrooted inspection commands. guest-root / dev (bind mount): TinyVM's / dev directory is bound to this location, providing basic device nodes (such as / dev / null) for chrooted inspection commands. guest-root / run (tmpfs mount): A newly mounted, independent tmpfs in memory, providing an independent temporary runtime space for chrooted inspection commands, isolated from TinyVM's own / run. `guest-root / tmp` (tmpfs mount): A newly mounted, independent tmpfs in memory, providing a writable temporary workspace for commands after chrooting. `guest-root / etc` (no arrow marker): This is the actual ` / etc` directory carried by the backup disk itself; it's not a bound mount. It stores configuration files generated during the guest operating system installation. `os-release`: Operating System Release file, a text file used by Linux systems to store distribution information such as ID and VERSION_ID. `fstab`: File System Table file, recording the mapping relationship between guest system partitions, UUIDs, and mount points (such as / , / boot). `hostname`: Hostname configuration file, a plain text file storing the hostnames set internally by the guest.

[0189] The proc, sys, and dev directories under guest-root are image copies prepared by child processes (executing chroot) of the TinyVM main process. By using mount --bind to point to the top-level directory with the same name, it is ensured that the commands in the backup disk can obtain the runtime context through the TinyVM kernel.

[0190] The files etc, os-release, fstab, and hostname under guest-root are the actual files on the backup disk itself and are the core targets that the OS detection module needs to read.

[0191] Based on the above tree structure, the detection program does not need to start the guest kernel on the backup disk, nor does it need to directly execute programs in the unknown system on the host machine. Instead, it reads and parses the root directory of the backup system in the isolated space of tinyvm. When it is necessary to use the guest's own toolchain, it only executes read-only query commands within the preset whitelist in the chroot class environment, and sets timeout, environment variables, PATH, read-only mount, and output length limits.

[0192] Unix system detection process:

[0193] For Unix-like systems such as Linux, FreeBSD, NetBSD, and OpenBSD, the OS detection module primarily relies on static file parsing. This means it prioritizes reading configuration files in candidate root file systems (such as / etc / os-release, / etc / lsb-release, release files specific to each distribution, / etc / hostname, and / etc / fstab) and the ELF headers of executable files (without needing to execute them) to determine the operating system type, distribution, version, architecture, hostname, and file system mount relationships. Read-only query commands executed within chroot serve as an optional cross-validation or supplementary method. This is used when the static parsing results are incomplete or require verification, by executing commands such as cat, lsb_release, rpm, and dpkg-query on the client machine to obtain information or verify the static results.

[0194] For Linux systems, the following steps can be used to perform the test:

[0195] 1. Read ` / etc / os-release` from the candidate root file system, prioritizing the parsing of fields such as ID (distribution type identifier), `PRETTY_NAME`, `VERSION_ID`, and `BUILD_ID`. If the file is complete (i.e., the distribution is parsed and the product name is not empty), the identification process ends here. The fallback parsing of ` / etc / lsb-release` and each distribution's specific release file is not performed; the distribution and version are directly determined based on this, and then the process proceeds to obtaining other information such as architecture, hostname, and `fstab`.

[0196] 2. If / etc / os-release is incomplete or does not exist, continue parsing / etc / lsb-release to extract fields such as DISTRIB_ID, DISTRIB_RELEASE, DISTRIB_CODENAME, and DISTRIB_DESCRIPTION. If the file is still incomplete and / usr / bin / lsb_release exists in the candidate root file system, you can choose to execute lsb_release -a in chroot as a supplement to extract fields such as Distributor ID, Description, Release, and Codename for verification or completion of the file parsing results.

[0197] 3. Perform fallback checks on specific release files for different distributions, such as Red Hat, CentOS, Rocky, Oracle Linux, Fedora, Debian, Ubuntu, SUSE, OpenSUSE, Alpine, Arch, Gentoo, OpenEuler, OpenCloudOS, TencentOS, Kylin, etc. If both / etc / os-release and / etc / lsb-release are incomplete, then check the distribution-specific files (such as / etc / redhat-release, / etc / debian_version, / etc / SuSE-release, etc.) for fallback checks.

[0198] 4. Extract hostnames from files such as / etc / hostname, / etc / HOSTNAME, and / etc / sysconfig / network. If / bin / hostname or / usr / bin / hostname exists in the candidate root file system, you can choose to execute hostname in chroot as a verification to validate the static file resolution results.

[0199] 5. The system architecture is determined by reading the ELF headers and dynamic linker paths of client executables such as / bin / bash, / bin / ls, / bin / sh, / usr / bin / rpm, and / usr / bin / dpkg-query. This operation only reads the file content and does not execute the program. For further verification, commands such as uname -m can be executed in chroot to corroborate the results with the ELF header parsing.

[0200] 6. Parse ` / etc / fstab` to obtain the client file system mount relationships, and read ` / proc / mounts` (if mounted), ` / dev / disk / by-uuid` (if accessible), LVM device paths, and Btrfs subvolume information. Restore the UUID, LABEL, device name, and subvolume parameters from `fstab` to the actual partitions or volumes recognized by tinyvm. This step relies on static file reading and does not require executing client commands.

[0201] 7. Infer the package format and package manager based on the distribution and version, such as RPM, DEB, APK, PACMAN, DNF, YUM, APT, ZYPPER, etc. If unclear information remains after static parsing, and the whitelist, read-only, and timeout conditions are met, you can enter chroot and execute the package manager's query command (such as rpm-qf, dpkg-query -W) to read the distribution package name and version information from the local package database as a verification or supplement to the static parsing results. This operation only executes query commands and does not perform operations that modify the system, such as installation, uninstallation, upgrades, or script triggers.

[0202] For BSD systems, the system type, version, and hostname can be identified through a combination of files such as / etc / freebsd-update.conf, / etc / fstab, / netbsd, / bsd, / etc / release, / etc / motd, and / etc / rc.conf.

[0203] The overall execution sequence of this process is as follows: static file parsing of the main path ( / etc / os-release → / etc / lsb-release → distribution-specific files) → static ELF header reading (architecture) → static file parsing (hostname, fstab) → output results; read-only command execution within chroot serves as an optional cross-validation or supplementary method, triggered when the static parsing results are incomplete or require verification, used to verify the static results or compensate for insufficient static information. This design, which prioritizes static parsing and supplements it with command execution, minimizes dependence on the client environment and potential risks while ensuring recognition accuracy.

[0204] Windows system detection process (Hive branch):

[0205] For Windows systems, the detection module does not use the Unix chroot command execution method because tinyvm typically uses a Linux operating system, and if the backup set disk is a Windows system, tinyvm cannot execute Windows system commands. Therefore, for Windows systems, offline file system and registry Hive parsing can be performed on the mounted Windows partition within the tinyvm isolated environment. The detection module first searches for common system directories in the candidate root directories, such as / windows, / winnt, / win32, / win, and / reactos. If not found, it can also parse the system directories recorded in boot.ini.

[0206] To determine whether a directory is the root directory of the Windows system, you can check the following conditions:

[0207] 1. The directory contains system32.

[0208] 2. The directory contains system32 / config.

[0209] 3. The directory contains system32 / cmd.exe.

[0210] After confirming the Windows system root directory, perform the following checks:

[0211] 1. Determine the Windows system architecture by examining the file format of system32 / cmd.exe.

[0212] 2. Open system32 / config / SOFTWAREhive and read the values ​​of ProductName, CurrentMajorVersionNumber, CurrentMinorVersionNumber, CurrentVersion, InstallationType, and CurrentBuildNumber under Microsoft\WindowsNT\CurrentVersion to obtain the product name, version, installation type, and build number.

[0213] 3. Open system32 / config / SYSTEMhive, read Select\Current, and determine the current ControlSet, for example, ControlSet001.

[0214] 4. Read Services\Tcpip\Parameters\Hostname under the current ControlSet to obtain the Windows hostname.

[0215] 5. Read the values ​​of \DosDevices\C: under MountedDevices, and combine them with the GPT partition GUID or MBR signature and the partition start offset to map the Windows drive letter to the block device partition path recognized by tinyvm.

[0216] Windows Registry processing flow as follows: Figure 3 As shown.

[0217] Through the hivex library, the registry hive can be opened, traversed, read, subkeys added, deleted, values ​​set, and committed offline. This can be used for detecting OS information and can also be extended to scenarios such as registry repair before and after recovery, driver configuration adjustment, and network configuration modification. This Windows branch embodies "offline parsing of Windows system directories and hive in a QEMU isolated environment," rather than relying on chroot to execute Windows programs; therefore, it is parallel to the Unix / Linux chroot command detection branch, and both are uniformly scheduled by tinyvm's mounting, isolation, communication, and lifecycle mechanisms.

[0218] Start an HTTP / JSON-RPC service within tinyvm and register multiple functional interfaces, for example:

[0219] 1. OS Information Detection Interface: This interface receives one or more root directories to be detected and returns the OS information corresponding to each directory.

[0220] 2. Command execution interface, used for controlled execution of shell commands within tinyvm.

[0221] 3. File status interface, used to read file metadata.

[0222] 4. Btrfs subvolume interface, used to list subvolumes and retrieve the default subvolume.

[0223] 5. Hive operation interface, used for registry Hive operations such as open, close, root, get_child, add_child, delete_child, values, commit, etc.

[0224] On the host machine side, VSOCK is used to connect to the HTTP / JSON-RPC service within tinyvm, sending detection requests and receiving structured results via a lightweight communication channel. The communication details do not affect the OS detection logic; the core of the detection still lies in the construction of the isolated root environment within tinyvm and the parsing of cross-system information.

[0225] The calling process is as follows Figure 4 As shown in the diagram, this illustrates the timing interaction process of operating system detection in a backup virtual machine, involving five modules: the front-end / backup system, the Agent, the QEMU Manager, the TinyVM HTTP service, and the OS Inspector (OS detection module). The Agent, QEMU Manager, and front-end / backup system all run directly within the host operating system, belonging to the host's user-space processes. The TinyVM HTTP service and OS Inspector run inside the detection virtual machine (TinyVM), logically isolated from the host, and communicate in a controlled manner with the Agent and QEMU Manager on the host side through virtual devices emulated by QEMU (such as VSOCK).

[0226] 1. Creating TinyVM: The front-end / backup system sends an operating system detection request to the Agent. The Agent calls QEMUManager to create a TinyVM instance. QEMU Manager builds the root file system of TinyVM based on the backup object identifier, starts the QEMU emulator process, loads the TinyVM kernel and root file system, and puts the TinyVM into running state.

[0227] 2. Mounting the backup disk and waiting for HTTP to be ready: QEMU Manager executes the corresponding mount policy based on the backup type (snapshot backup disk, read-only backup disk, or image file), mapping the backup virtual machine disk to a QEMU-recognizable disk access interface (block device node or disk image file path), and passes it to TinyVM via the -drive parameter. After TinyVM starts, its internal Linux kernel mounts the root filesystem as / , and the main process (PID 1) executes the init script to complete runtime assembly (mounting / proc, / sys, / dev, etc.), then starts the HTTP / JSON-RPC service and enters the ready state. QEMUManager waits for the TinyVM HTTP service to be ready (confirmed by VSOCK probing or port listening), and after confirmation, proceeds to the next step.

[0228] 3. Calling os.info: The Agent sends an os.info request to the TinyVM HTTP service via VSOCK or a network channel. The request parameters contain a list of mount point paths to be detected (such as / mnt / guest-root, etc.). This request instructs TinyVM to begin the operating system detection process.

[0229] 4. Parsing Linux / Unix files or Windows Hive: After receiving a request, the TinyVM HTTP service distributes the task to the OS Inspector module. The OS Inspector determines the operating system type based on characteristic files or directories in the candidate root file system, and then calls the corresponding parsing branch according to the determined operating system type:

[0230] For Linux / Unix systems, static file parsing is the primary method (reading / etc / os-release, / etc / hostname, / etc / fstab, and release files specific to each distribution, and reading ELF headers to determine the architecture). When necessary, read-only commands (such as cat, lsb_release, rpm, dpkg-query, etc.) are executed in the chroot environment as a cross-validation or supplementary means to obtain information such as distribution, version, hostname, CPU architecture, package format, and fstab mount information.

[0231] For Windows systems, the system extracts product name, version number, and build number from SOFTWARE\Microsoft\Windows NT\CurrentVersion by parsing registry hive files (SOFTWARE and SYSTEM) offline, extracts hostname from SYSTEM\ControlSet001\Control\ComputerName\ActiveComputerName, and resolves the mapping relationship between drive letters and partition devices from SYSTEM\MountedDevices. At the same time, the system scans the Windows\System32 directory to determine the system bitness.

[0232] 5. JSON Result Return to Agent: The OS Inspector encapsulates the parsed fields (operating system type, distribution, version number, hostname, CPU architecture, etc.) into a structured JSON object and returns it to the Agent via the TinyVM HTTP service. The Agent forwards the result to the frontend / backup system, completing the detection process. Subsequently, QEMU Manager destroys the TinyVM instance and reclaims host-side resources.

[0233] This solution can output structured OS information, categorized by applicable system type as follows:

[0234] I. General Fields (Applicable to all supported operating system types):

[0235] Operating system types: Linux, Windows, FreeBSD, NetBSD, OpenBSD, DOS, unknown, etc.

[0236] Distributions or product types: Ubuntu, Debian, CentOS, RHEL, Rocky, SLES, OpenEuler, Windows, etc.

[0237] Product name, version number, and build number (for Linux / Unix, the build number corresponds to BUILD_ID; for Windows, the build number corresponds to BuildNumber).

[0238] Hostname;

[0239] CPU architecture.

[0240] II. Unix / Linux-specific fields (applicable to Linux and BSD systems):

[0241] fstab mount information (file system mount table, which records the mapping relationship between partitions and mount points);

[0242] Package formats and package managers.

[0243] III. Windows-specific fields (Windows systems only):

[0244] Installation type;

[0245] The Windows system root directory (i.e., the path of the Windows partition under the mount point, such as / mnt / guest-root / Windows).

[0246] WindowsSOFTWAREhive and SYSTEMhive paths (absolute paths of registry hive files under mount points);

[0247] The current Windows ControlSet (e.g., ControlSet001, used to locate the system startup configuration);

[0248] Mapping relationship between Windows drive letters and partition devices.

[0249] The execution process of this embodiment is as follows:

[0250] 1. Receive an operating system detection request for a backup virtual machine disk. The request includes the backup object identifier (including backup task identifier, backup set identifier, snapshot time point identifier, disk identifier, etc.).

[0251] 2. The emulator management module calls the corresponding mount policy according to the backup type (snapshot backup disk, read-only backup disk, disk image file or other scalable source) to map the backup virtual machine disk to a disk access interface (block device node or disk image file path) that QEMU can recognize.

[0252] 3. The emulator management module constructs the minimal root file system for the detection virtual machine (TinyVM), including creating a directory skeleton ( / bin, / dev, / etc, / lib, / mnt, / proc, / sys, / tmp, / run, etc.), binding and mounting reuses the host machine's base directories ( / etc, / lib, / lib64, / opt, / usr), placing the busybox executable file and init startup script, starting the QEMU emulator process, loading the TinyVM kernel and root file system, and putting the detection virtual machine into running state.

[0253] 4. During the boot phase, the TinyVM kernel mounts the root filesystem as the root directory of the VFS ( / ), establishing an initial directory tree. The kernel executes the / init program in this directory tree, starting the main process (PID 1) for detecting the virtual machine. The main process executes the init script to complete runtime assembly: mounting proc to / proc, mounting sysfs to / sys, mounting tmpfs to / run and / tmp, initializing the basic device nodes under / dev through mdev, and starting the HTTP / JSON-RPC service, putting the virtual machine into a ready state.

[0254] 5. After receiving the operating system detection command, the main process mounts the partitions (or LVM logical volumes, Btrfs subvolumes) of the backup virtual machine disk to different mount points in its own directory tree (such as / mnt / guest-root, / mnt / step1, etc.), making the file system of each partition visible in the directory tree.

[0255] 6. The main process traverses each mount point and performs existence checks on predefined operating system characteristic files or directories (such as / bin / sh and / etc / os-release for Linux, and / Windows / System32 / config / SOFTWARE for Windows). It then selects candidate root file systems belonging to the backup virtual machine operating system from multiple mount points and records their operating system type labels.

[0256] 7. The main process executes the corresponding detection branch based on the operating system type label:

[0257] For Linux / Unix-like systems, the main process creates an empty directory under the mount point of the candidate root file system for mounting pseudo file systems and runtime directories. It binds and maps its pre-assembled / proc, / sys, and / dev to the corresponding directories, and mounts independent tmpfs for / run and / tmp to assemble the runtime environment required for child processes to execute detection commands. Then, it generates child processes, which use the chroot system call to switch their logical root directory to the mount point of the candidate root file system, execute read-only detection commands from the whitelist (such as cat / etc / os-release, uname -m, rpm -qa, etc.), and return the command output to the main process through a pipe. The main process cross-verifies the command execution results with the static file parsing results ( / etc / os-release, / etc / hostname, / etc / fstab, ELF header information, etc.) to obtain the operating system type, distribution, version number, hostname, CPU architecture, package format, and fstab mount information.

[0258] For Windows systems, the main process offline parses the registry hive files (SOFTWARE and SYSTEM) under the candidate root file system. It extracts the product name, version number, and build number from SOFTWARE\Microsoft\Windows NT\CurrentVersion, extracts the hostname from SYSTEM\ControlSet001\Control\ComputerName\ActiveComputerName, parses the mapping relationship between drive letters and partition devices from SYSTEM\MountedDevices, and scans the Windows\System32 directory to determine the system bitness, thus obtaining the Windows system root directory, registry hive path, current ControlSet, and drive letter mapping relationship.

[0259] 8. The main process encapsulates the detection results (including fields such as operating system type, distribution, version number, hostname, and CPU architecture) into a structured JSON object and returns it to the emulator management module on the host machine via HTTP / JSON-RPC service. The emulator management module then forwards it to the upper-layer backup system.

[0260] 9. After the detection task is completed, the simulator management module terminates the QEMU simulator process, unmounts the mounted backup disk partition, destroys the detection virtual machine instance, and reclaims the temporary mount points, block device mappings, and process resources on the host side to ensure that no residual resources are occupied.

[0261] This embodiment reduces detection resource consumption by eliminating the need to boot a full client operating system; instead, it uses a minimal TinyVM, reducing CPU, memory, and startup time consumption, making it suitable for batch backup point scanning. Furthermore, it reduces the risk of backup copies being altered, as the detection process primarily reads backup disk files and the Hive registry, avoiding uncontrollable writes such as service auto-start, log writing, and system updates during the full client startup process.

[0262] This embodiment can also improve security isolation. The unknown client file system and parsing process are executed in QEMUtinyvm, and the host machine does not directly expose the client system content, reducing the risk of abnormal file systems or malicious content affecting the host machine.

[0263] This embodiment can also improve detection accuracy by supplementing necessary directories such as / proc, / sys, / dev, and / run through the chroot root environment. This allows Unix / Linux detection to actually use commands, dynamic linkers, package management databases, and configuration files in the guest root directory to complete read-only queries and cross-verify with static file parsing, making it closer to the real system environment than simply reading static files.

[0264] This embodiment can also improve cross-platform compatibility, uniformly supporting multiple systems such as Linux, Windows, FreeBSD, NetBSD, OpenBSD, and DOS, and can identify different distributions, different version files, and different registry structures.

[0265] This embodiment can also improve Windows detection capabilities. By using Hivex to offline parse SOFTWARE and SYSTEMhive, information that is difficult to obtain through ordinary file parsing can be obtained, such as Windows product name, version, build number, hostname, current ControlSet, and drive letter mapping.

[0266] This embodiment also enhances scalability. Mounting strategies, OS detectors, and Hive operation interfaces can all be modularly expanded, facilitating the integration of new backup sources, new file systems, and new operating system types.

[0267] This embodiment can also improve project controllability. Mechanisms such as QEMU instance management, lifecycle management, timeout cleanup, and residual process cleanup enable the detection process to be stably integrated into the backup and recovery system.

[0268] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0269] In one exemplary embodiment, a simulator management module is provided, which is the simulator management module in the operating system detection system described in any of the above embodiments.

[0270] In one exemplary embodiment, an emulator process is provided, which is the emulator process in the operating system detection system described in any of the above embodiments.

[0271] In one exemplary embodiment, a detection virtual machine is provided, which is the detection virtual machine in the operating system detection system described in any of the above embodiments.

[0272] In one exemplary embodiment, a computer device is provided, including a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the steps in the various embodiments described above.

[0273] In one exemplary embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps described in the various embodiments above.

[0274] In one exemplary embodiment, a computer program product is provided having a computer program stored thereon, the computer program being executed by a processor of the steps described in the various embodiments above.

[0275] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0276] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments described above. Any references to memory, database, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described; however, any combination of these technical features that does not contradict each other should be considered within the scope of this application.

[0277] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. An operating system detection system for backup virtual machines, characterized in that, The system includes: The emulator management module of the host machine is used to map the disk of the backup virtual machine to the disk access interface after receiving a request to detect the operating system of the backup virtual machine. The emulator management module is used to build the root file system of the operating system of the virtual machine and start the emulator process; The emulator process is used to trigger the kernel of the detection virtual machine to build the directory tree of the detection virtual machine according to the root file system of the operating system of the detection virtual machine and start the main process of the detection virtual machine. The main process is used to mount the root file system of multiple partitions in the disk of the backup virtual machine to different mount points in the directory tree through the disk access interface. The main process is used to determine the root file system of the operating system belonging to the backup virtual machine in the root file system under different mount points based on the characteristic files or directories of the operating system, and obtain candidate root file systems. The main process is used to determine a preset file path, parse the operating system information of the files pointed to by the preset file path in the candidate root file system, and obtain the operating system detection result based on the parsing result; the preset file path is a preset path for a file used to store operating system information.

2. The system according to claim 1, characterized in that, When the main process determines the root file system of the backup virtual machine's operating system in the root file systems under different mount points based on the characteristic files or directories of the operating system, it is specifically used to: determine the characteristic files or directories of various operating systems; when the root file system under one mount point has characteristic files or directories, determine that the root file system under the mount point belongs to the root file system of the backup virtual machine's operating system. The main process is also used to determine the operating system type corresponding to the characteristic files or directories existing in the root file system under the mount point, and to determine the operating system type as the type of the operating system of the backup virtual machine. The main process is also used to obtain the operating system information of the backup virtual machine based on the operating system type of the backup virtual machine's operating system.

3. The system according to claim 2, characterized in that, The main process is also used to determine the operating system type to which the operating system of the backup virtual machine belongs, determine the preset file path corresponding to the operating system type, and parse the operating system information of the files pointed to by the preset file path corresponding to the operating system type in the candidate root file system.

4. The system according to claim 1, characterized in that, When the operating system type of the backup virtual machine is the same as the operating system type of the detection virtual machine, the main process is used to assemble the runtime environment required for the child process to execute the operating system detection command at the target mount point when it receives the operating system detection command; the target mount point is the mount point of the root file system of the operating system of the backup virtual machine. The subprocess is used to switch its own logical root directory to the target mount point, so that the subprocess can execute the operating system detection command from the perspective of the operating system of the backup virtual machine and obtain the command execution result; When the main process obtains the operating system detection result based on the parsing result, it specifically verifies the operating system information in the command execution result with the operating system information in the parsing result to obtain the operating system detection result.

5. The system according to claim 4, characterized in that, The main process is also used for: Create a first type of directory and a second type of directory under the target mount point. Mount the pseudo file system that has been assembled to the first type of directory through binding. Mount a temporary file system for the second type of directory to assemble the runtime environment required for the child process to execute the operating system detection command under the target mount point. The first type of directory is the directory used to mount the pseudo file system, and the second type of directory is the runtime directory.

6. The system according to claim 4, characterized in that, When the main process receives an operating system detection command, it assembles the runtime environment required for the child process to execute the operating system detection command at the target mount point, specifically for: Upon receiving the operating system detection command, determine whether the operating system detection command is in the preset whitelist of commands; If so, then assemble the runtime environment required for the child process to execute operating system detection commands at the target mount point.

7. The system according to claim 1, characterized in that, When the simulator management module maps the disk of the backup virtual machine to the disk access interface, it is specifically used for: Based on the backup type corresponding to the backup virtual machine, determine the target mount strategy, and process the disk of the backup virtual machine according to the target mount strategy to map the disk to the disk access interface.

8. A simulator management module, characterized in that, The simulator management module is the simulator management module in the operating system detection system according to any one of claims 1 to 7.

9. An emulator process, characterized in that, The simulator process is the simulator process in the operating system detection system according to any one of claims 1 to 7.

10. A method for detecting virtual machines, characterized in that, The detection virtual machine is the detection virtual machine in the operating system detection system according to any one of claims 1 to 7.

Images