Log implementation method in hypervisor / virtualization environment
By dynamically switching hardware ownership between the Hypervisor and SOS, and using full virtualization technology to intercept early UOS operations, combined with shared memory and kernel driver agents, efficient, real-time, and conflict-free unified collection and management of logs in the virtualization environment is achieved, solving the problems of incomplete and unreliable log recording during the virtual machine startup phase.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- NINGBO QIANCHUAN TECH CO LTD
- Filing Date
- 2026-02-27
- Publication Date
- 2026-05-29
AI Technical Summary
In existing virtualization environments, the dynamic complexity of the system startup phase and conflicts in physical debugging hardware resources lead to incomplete and unreliable log recording, making it difficult to collect and manage them in a unified manner.
During the Hypervisor startup phase, the Hypervisor acts as the initial owner of the physical debugging hardware and outputs logs. When the SOS starts, it transfers ownership of the hardware to the SOS. It intercepts early UOS console operations through full virtualization technology and builds a cross-level transparent transmission chain by combining shared memory and kernel driver agents to achieve efficient and real-time log aggregation.
It solves the problems of integrity and reliability of virtual machine lifecycle logging, realizes conflict-free log output and low-overhead real-time unified management, and ensures that logs are not lost during critical stages.
Smart Images
Figure CN122111731A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of operating system virtualization technology, and in particular to a method for implementing Log in a Hypervisor / virtualization environment. Background Technology
[0002] Currently, in virtualization environments, log management primarily employs a technology system centered on post-event identification and proactive collection. Regarding log identification, the host machine or management node assigns a unique software identifier, such as a MAC address, to each virtual machine and embeds it into the logs generated by the virtual machine, thereby enabling traceability of the log's source. In the log collection phase, when a virtual machine enters the late stages of its lifecycle, especially before it is deleted, log files are typically actively retrieved and transferred to an external storage server by deploying collection scripts and remotely logging into the virtual machine node, thus preserving the virtual machine's operational records. These processes, from identification to collection, constitute the standard technical framework for traditional virtualization log management.
[0003] The aforementioned and existing related technologies often suffer from the following shortcomings: Currently, traditional log management technologies neglect the dynamic and complex nature of the virtualization system startup phase. During the successive startup of the hypervisor and multiple virtual machines, log output paths are difficult to establish due to incomplete hardware resources and unloaded drivers. Simultaneously, there is a lack of effective coordination and management mechanisms regarding ownership disputes and access conflicts between different virtual machines and the hypervisor over physical debugging hardware such as UART. Furthermore, existing technologies cannot achieve low-overhead transparent collection and real-time unified aggregation of logs across hypervisor and virtual machine levels, making it difficult to efficiently integrate logs generated at different levels. From a reliability perspective, traditional methods are severely inadequate in capturing critical logs during the early initialization phase of virtual machines, especially before the operating system kernel driver model is loaded, failing to reliably preserve these early logs and creating reliability blind spots.
[0004] Publication No. CN105488086A discloses a logging method and system in a virtualization environment. It solves the problem of the host machine's inability to distinguish log sources when multiple virtual machines coexist by assigning and associating a unique MAC address to each newly created virtual machine and embedding this address when the virtual machine generates logs. However, this method is entirely based on a static scenario where the virtual machines have already been created and are running stably. It does not address the fundamental dynamic issues of how logs are output in the early stages of virtual machine startup and how to coordinate ownership and access conflicts of the physical debugging hardware UART. Log collection may still be scattered and delayed.
[0005] Publication No. CN107977385A discloses a method and apparatus for collecting runtime logs of elastic nodes in a virtualization environment. This method solves the problem of permanent loss of runtime logs caused by the deletion of virtual machines and their disks by actively scheduling and deploying collection scripts before the virtual machine is deleted, remotely logging in, and pulling log files from the node for centralized storage. However, this technology involves high-overhead, periodic active file collection and does not address how to build a low-overhead, real-time transparent streaming channel for logs between the hypervisor and the virtual machine. Furthermore, it cannot access or capture critical logs generated by the virtual machine in the early stages of startup initialization, before the collection scripts are deployed. Summary of the Invention
[0006] The technical problem this invention aims to solve is that existing virtualization environments suffer from incomplete, unreliable, and difficult-to-collect and manage virtual machine lifecycle logs due to the dynamic complexity of the system startup phase, conflicts in physical debugging hardware resources, and inefficient log transmission mechanisms. To address this, we propose a Log implementation method for Hypervisor / virtualization environments.
[0007] To achieve the above objectives, this application adopts the following technical solution: a logging implementation method in a Hypervisor / virtualization environment, comprising the following steps:
[0008] S1, during the Hypervisor startup phase, the Hypervisor, as the initial owner of the physical debugging hardware, directly operates the physical debugging hardware to output logs. When the Hypervisor is ready to start the server operating system virtual machine SOS, it shuts down the Hypervisor's hardware driver and temporarily stores the subsequently generated logs in a buffer maintained by the Hypervisor kernel. During the SOS startup phase, ownership of the physical debugging hardware is transferred to SOS.
[0009] S2 loads a dedicated driver in the SOS kernel, which accesses the memory area shared with the Hypervisor to read and output log data temporarily stored in the Hypervisor kernel buffer. Through the user-space interface exported by the SOS kernel, it provides log reading functionality to upper-layer services.
[0010] S3, in the early console stage of the kernel of the client operating system virtual machine UOS, the Hypervisor performs full virtualization interception on the operation of UOS accessing the physical debug hardware registers, and writes the intercepted log data into the Hypervisor kernel buffer.
[0011] After the early console phase of the UOS kernel ends, S4 switches the UOS log output channel to a semi-virtualized communication mode. The virtual console front-end driver running inside UOS sends log data to the back-end service process running in the SOS user space through a virtual queue.
[0012] Preferably, step S1 includes:
[0013] S11, in the initial stage of system startup, the Hypervisor directly operates the physical debugging hardware to output its own log information.
[0014] S12, when the Hypervisor completes its own initialization and is ready to start SOS, it actively closes the device driver corresponding to the physical debugging hardware inside it, so as to stop directly outputting logs through the physical debugging hardware, and temporarily stores the log data generated during the subsequent operation in the Hypervisor kernel buffer.
[0015] S13, in the subsequent SOS startup phase, complete ownership and control of the physical debugging hardware are transferred to SOS through hardware pass-through technology.
[0016] Furthermore, the Hypervisor, as the initial owner of the physical debugging hardware, operates the hardware to output logs, specifically by performing the following operations:
[0017] The hypervisor sends specific query commands to the underlying firmware or hardware abstraction layer of the system hardware to request and obtain the mapping start address information of the physical debugging hardware device in the system's physical memory address space. Based on the address information, the hypervisor completes the initialization of the device driver corresponding to the physical debugging hardware and puts the driver into an enabled state, thereby establishing a channel for direct log output through the hardware. If the query command sent to the underlying layer fails to return valid memory mapping start address information, the hypervisor adopts a default strategy to disable the output function logic corresponding to the physical debugging hardware. In this case, the hypervisor's logs will not be output through the physical hardware device.
[0018] Furthermore, the timing of the operation to shut down the Hypervisor's hardware drivers when the Hypervisor is preparing to start the SOS virtual machine is precisely controlled by the internal system process. This triggering logic is embedded in the Hypervisor's startup sequence. Specifically, it must ensure that the Hypervisor itself has completed the initialization of the core kernel, including the normal readiness of memory management, CPU scheduling framework, and key virtualization facilities. At the same time, the Hypervisor must complete the startup of its basic system services. These services are the minimum set of functions necessary to maintain its own operation and subsequent virtual machine management. Only when both of the above conditions are met is the system state determined to be ready to start SOS. In this state, the operation to shut down the hardware drivers is executed immediately, and this operation is set to be completed before the specific startup process or function used by the Hypervisor to start the SOS virtual machine is formally called and executed.
[0019] Preferably, step S2 includes:
[0020] S21, after SOS successfully boots and loads its kernel, loads a dedicated log forwarding driver in the SOS kernel space.
[0021] S22, the dedicated log forwarding driver accesses the shared memory area jointly maintained by the Hypervisor and SOS kernel, and continuously reads log data temporarily stored in the Hypervisor kernel buffer.
[0022] S23, the dedicated log forwarding driver calls the standard logging interface provided by the SOS kernel to format and output the log data from the Hypervisor as part of the SOS kernel's own log stream.
[0023] S24 creates and exports a data access interface for user space in the SOS kernel layer, providing log reading functionality for upper-layer log collection and management services running in the SOS user space.
[0024] Furthermore, the user-space data access interface exported by the kernel is specifically implemented as a buffer device node with a circular queue structure:
[0025] This device node is configured to follow specific data consumption semantics, meaning that once the log data stored in its circular buffer is successfully read by any user-space service or process, the read log data changes from an accessible state to a consumed state and cannot be read again, thus ensuring the timeliness and integrity of log records.
[0026] The upper-layer log collection service running in the SOS user space of the server operating system virtual machine can obtain the complete log stream by continuously monitoring and reading the device node, and persistently store the obtained log data in a pre-defined directory in the file system.
[0027] Preferably, step S3 includes:
[0028] S31, in the early console output phase of the UOS kernel, the Hypervisor intercepts and simulates UOS's attempts to access the registers of physical debug hardware devices based on full virtualization technology.
[0029] When the Hypervisor captures a write operation to the hardware register by the UOS kernel, its internal simulator module parses the data content carried by the operation.
[0030] S33, the parsed valid information is appended as a log entry to the Hypervisor kernel buffer.
[0031] Furthermore, the underlying implementation mechanism of the Hypervisor's full virtualization technology interception and simulation of UOS access to physical debugging hardware registers is as follows:
[0032] The Hypervisor leverages hardware virtualization features to set memory access trap permissions for the virtual physical debugging hardware address space seen by UOS. When the UOS kernel performs a data write operation to this protected virtual hardware address space during its early boot phase, it immediately triggers the Hypervisor's preset trap handler. The Hypervisor's trap handler transfers control to its internal simulator module, which parses the specific data content carried by this write operation, organizes the parsed character data into a structured log entry according to a predefined format, and stores the entry in a specified location.
[0033] Preferably, step S4 includes:
[0034] S41, after the early console phase of the UOS kernel ends, switches the UOS log output path from the fully virtualized interception simulation mode to the semi-virtualized standard communication transmission mode.
[0035] S42, driven by a virtual console front-end driver running within UOS, follows a semi-virtualized communication protocol and uses a shared memory queue mechanism provided by virtualization technology to send runtime log data generated by the UOS kernel to the back-end service process running in the SOS user space.
[0036] Furthermore, the final output behavior of the semi-virtualized channel supports dynamic control based on configuration: during the startup initialization phase, the backend service process running in the SOS user space reads its external configuration file information to obtain control parameters. If a specific control option in the configuration information is set to off or disabled, the backend service process will not output the log data received from the client operating system virtual machine UOS from the virtual queue to the standard error output device of the SOS user space during operation, thereby allowing the administrator to flexibly control the final presentation of the logs according to their needs.
[0037] The technical effects and advantages of this invention are as follows:
[0038] 1. This invention establishes a dynamic hardware ownership switching and phased log output control mechanism based on the system startup sequence from Hypervisor to server operating system virtual machine SOS and then to client operating system virtual machine UOS. This enables conflict-free and continuous use of physical debugging hardware throughout the entire virtual machine startup process, and solves the problem of log output interruption and hardware access conflict caused by the inability of the static allocation model to adapt to the dynamic startup process in the existing technology.
[0039] 2. This invention achieves efficient, real-time, and automatic aggregation of Hypervisor kernel logs to SOS by constructing a cross-level transparent transmission chain based on shared memory and kernel driver agent. This solves the problems of high system overhead, high latency, and difficulty in real-time unified management caused by the use of active pull and file transfer modes in existing log collection methods.
[0040] 3. This invention employs a switchless forced capture mechanism based on full virtualization technology to intercept and convert all hardware accesses to the early UOS console, achieving reliable and unloss-free logging of the logs before the operating system driver is loaded in the earliest stage of virtual machine startup. This completely solves the problems of blank logging and reliability blind spots in existing technologies at this critical stage.
[0041] 4. This invention uses UOS internal events as intelligent switching points and combines a hybrid output strategy of full virtualization capture and semi-virtualization transmission to achieve the goal of ensuring the integrity of UOS's full lifecycle logs while optimizing performance and resource consumption according to the running stage. This solves the contradiction that a single virtualization technology cannot simultaneously guarantee high reliability during startup and high-efficiency transmission during runtime. Attached Figure Description
[0042] The disclosure of this invention is illustrated with reference to the accompanying drawings. It should be understood that the drawings are for illustrative purposes only and are not intended to limit the scope of protection of this invention. In the drawings, the same reference numerals are used to refer to the same parts:
[0043] Figure 1This is a flowchart of the program of the present invention;
[0044] Figure 2 This invention provides an architecture diagram of a log output system in a virtualized environment.
[0045] Figure 3 This is a schematic diagram of the UART hardware control and log output process from the Hypervisor startup phase to the initial SOS startup phase in an embodiment of the present invention.
[0046] Figure 4 This is a schematic diagram of the UOS startup phase log capture and runtime log semi-virtualization output process in an embodiment of the present invention. Detailed Implementation
[0047] It is readily understood that, based on the technical solution of this invention, those skilled in the art can propose various interchangeable structural methods and implementations without altering the essential spirit of the invention. Therefore, the following detailed embodiments and accompanying drawings are merely illustrative examples of the technical solution of this invention and should not be considered as the entirety of the invention or as limitations or restrictions on the technical solution of this invention.
[0048] As attached Figure 1 , Figure 2 As shown, this embodiment runs on a system architecture that includes a Hypervisor, a server operating system virtual machine (SOS), and one or more client operating system virtual machines (UOS). The owner of the physical debugging hardware is dynamically configured during the startup phase, thereby establishing different log output paths and ultimately achieving unified aggregation of all logs to the SOS. This embodiment uses a Universal Asynchronous Receiver / Transmitter (UART) as an example of physical debugging hardware.
[0049] S1: Hypervisor Startup and Log Output
[0050] Figure 3 As shown, after the system is powered on, the Hypervisor starts first. In this initial stage, the Hypervisor is the sole owner of the physical debugging hardware. The Hypervisor sends a query command to the underlying hardware platform on which it runs, requesting to obtain the starting address of the physical memory mapping of the UART hardware. If the query is successful, the Hypervisor initializes and enables its internal UART device driver based on this address, thereby directly outputting its own operation log to the terminal device connected to the UART hardware. If the query fails and no valid address information is obtained, the Hypervisor disables its UART output function by default.
[0051] When the Hypervisor completes the initialization of its kernel and basic services and is about to start the SOS virtual machine, it performs a crucial operation: actively disabling its UART device driver. From this point onward, logs generated by the Hypervisor runtime are no longer output to the physical serial port, but are temporarily stored in a dedicated log buffer maintained by its kernel.
[0052] S2: SOS Startup and Log Takeover
[0053] Subsequently, the Hypervisor starts the SOS virtual machine. During the SOS startup process, the aforementioned physical UART hardware is completely transferred to SOS via pass-through technology. Therefore, SOS has native, direct access to this hardware from the moment it starts, and its operating system kernel and application logs can be output directly via UART just like on the physical machine.
[0054] To collect Hypervisor logs, this embodiment loads a dedicated driver into the SOS kernel. This driver module reads log data temporarily stored in the Hypervisor kernel buffer by accessing a shared memory region pre-mapped by the Hypervisor and SOS. After reading, the driver immediately calls the SOS kernel's standard logging interface to format and output the Hypervisor logs as part of the SOS kernel's own log stream. Thus, the Hypervisor logs are output by the SOS kernel on its behalf.
[0055] Simultaneously, the driver creates and exports a special character device node at the SOS kernel layer for user space access. At its core is a circular queue buffer whose data follows a one-time consumption semantic; once log data is successfully read by a user-space service, it is removed from the accessible state and cannot be read again, thus ensuring the integrity and timeliness of log records. A dedicated log collection service running in SOS user space monitors and reads this device node, persistently saving the Hypervisor logs to a specified directory in the file system for developers to review.
[0056] S3: UOS Startup and Early Log Capture
[0057] like Figure 4 As shown, after SOS boots up, the UOS virtual machine can be started. Since the physical UART is already occupied by SOS, UOS cannot directly access this hardware. During the early console phase of the UOS kernel, attempts by the kernel to directly write to the UART registers are intercepted by the Hypervisor using full virtualization technology.
[0058] Specifically, the Hypervisor sets access traps for the virtual UART hardware address space seen by the UOS. When the UOS performs a write operation, a CPU exception is triggered and caught by the Hypervisor's trap handler. The emulator module inside the Hypervisor parses the data carried by this write operation and formats the parsed character information into a log record, which is then appended to the Hypervisor kernel buffer via the Hypervisor's internal log interface. This capture mechanism is designed to be forcibly enabled without a software control switch. Therefore, all early console output generated by the UOS before the driver model is loaded is reliably captured and subsequently output via the SOS agent through the shared memory channel described in the second phase.
[0059] S4: Paravirtualized output of UOS normal operation logs
[0060] like Figure 4 As shown, after the UOS kernel completes its early initialization and its early console phase ends, it loads the virtual console frontend driver based on the Virtio standard. From this point onward, the UOS log output mechanism changes.
[0061] The UOS kernel sends logs to the Virtio-console frontend driver. This driver, conforming to the Virtio protocol, sends log packets to the backend service via a semi-virtualized channel established by the virtualization layer. This backend service is a process running in the SOS user space.
[0062] The backend process in this SOS user space receives the log data stream. Its final output behavior is determined by the configuration file read when the SOS virtual machine starts: for example, if the option named dump_console in the configuration file is set to false, this backend process will not output the received UOS logs to the SOS standard error output device. This approach places the output management of UOS runtime logs in SOS user space and provides runtime configurable flexibility.
[0063] The technical scope of this invention is not limited to the content described above. Those skilled in the art can make various modifications and variations to the above embodiments without departing from the technical concept of this invention, and all such modifications and variations should fall within the protection scope of this invention.
Claims
1. A method for implementing Log in a Hypervisor / virtualization environment, characterized in that, Includes the following steps: S1. Start the Hypervisor virtual machine manager, which will then operate the physical debugging hardware to output logs. S2, Start the server operating system virtual machine SOS, transfer ownership of the physical debugging hardware to SOS, load a dedicated driver in the SOS kernel to read and output the logs temporarily stored by the Hypervisor, and provide log reading function to the upper layer service; S3, start the client operating system virtual machine UOS, and the Hypervisor intercepts UOS's access to physical debug hardware registers in the early console stage and writes the intercepted log data to the Hypervisor kernel buffer; After the early console phase of UOS ends, S4 sends the UOS logs to the backend service process in the SOS user space via a semi-virtualized channel.
2. The logging implementation method in a Hypervisor / virtualization environment according to claim 1, characterized in that, Step S1 includes: S11, in the initial stage of system startup, the Hypervisor directly operates the physical debugging hardware to output its own log information; S12, when the Hypervisor completes its own initialization and is ready to start SOS, it actively closes the device driver corresponding to the physical debugging hardware inside it, so as to stop the direct output of logs through the physical debugging hardware, and temporarily stores the log data generated during the subsequent operation in the Hypervisor kernel buffer. S13, in the subsequent SOS startup phase, complete ownership and control of the physical debugging hardware are transferred to SOS through hardware pass-through technology.
3. The Log implementation method in a Hypervisor / virtualization environment according to claim 2, characterized in that, The Hypervisor, as the initial owner of the physical debugging hardware, operates the hardware to output logs, specifically performing the following operations: The hypervisor sends specific query commands to the underlying firmware or hardware abstraction layer of the system hardware to request and obtain the mapping start address information of the physical debugging hardware device in the system's physical memory address space. Based on the address information, the hypervisor completes the initialization of the device driver corresponding to the physical debugging hardware and puts the driver into an enabled state. If the query command sent to the underlying layer fails to return valid memory mapping start address information, the hypervisor adopts a default strategy to disable the output function logic corresponding to the physical debugging hardware. In this case, the hypervisor's logs will not be output through the physical hardware device.
4. The Log implementation method in a Hypervisor virtualization environment according to claim 2, characterized in that, The timing of the operation to shut down the Hypervisor's hardware drivers when the Hypervisor is preparing to start the SOS virtual machine is precisely controlled by internal system processes. This triggering logic is embedded in the Hypervisor's startup sequence. Specifically, it requires that the Hypervisor itself has completed kernel initialization and that its basic system services have started. Only when both conditions are met is the system state determined to be ready to start SOS. In this state, the operation to shut down the hardware drivers is executed immediately, and this operation is scheduled to be completed before the specific startup process or function used to start the SOS virtual machine within the Hypervisor is formally called and executed.
5. The logging implementation method in a Hypervisor / virtualization environment according to claim 1, characterized in that, Step S2 includes: S21, after SOS successfully boots and loads its kernel, loads a dedicated log forwarding driver in the SOS kernel space; S22, the dedicated log forwarding driver accesses the shared memory area jointly maintained by the Hypervisor and SOS kernels, and continuously reads the log data temporarily stored in the Hypervisor kernel buffer; S23, the dedicated log forwarding driver calls the standard logging interface provided by the SOS kernel to format and output the log data from the Hypervisor as part of the SOS kernel's own log stream; S24 creates and exports a data access interface for user space in the SOS kernel layer, providing log reading functionality for upper-layer log collection and management services running in the SOS user space.
6. The Log implementation method in a Hypervisor / virtualization environment according to claim 5, characterized in that, The kernel-exported user-space data access interface is specifically implemented as a buffer device node with a circular queue structure: This device node is configured to follow specific data consumption semantics, that is, once the log data stored in its circular buffer is successfully read by any user-space service or process, the read log data changes from an accessible state to a consumed state and cannot be read again to ensure the timeliness and integrity of log records. The upper-layer log collection service running in the SOS user space of the server operating system virtual machine can obtain the complete log stream by continuously monitoring and reading the device node, and persistently store the obtained log data in a pre-defined directory in the file system.
7. The logging implementation method in a Hypervisor / virtualization environment according to claim 1, characterized in that, Step S3 includes: S31, In the early console output phase of the UOS kernel, the Hypervisor intercepts and simulates UOS's attempts to access physical debug hardware device registers based on full virtualization technology; When the Hypervisor captures a write operation to the hardware register by the UOS kernel, its internal simulator module parses the data content carried by the operation. S33, the parsed valid information is appended as a log entry to the Hypervisor kernel buffer.
8. A Log implementation method in a Hypervisor / virtualization environment according to claim 7, characterized in that, The underlying mechanism for intercepting and simulating the UOS's access to the physical debugging hardware registers using full virtualization technology by the Hypervisor is as follows: The Hypervisor leverages hardware virtualization features to set memory access trap permissions for the virtual physical debugging hardware address space seen by UOS. When the UOS kernel performs a data write operation to this protected virtual hardware address space during its early boot phase, it immediately triggers the Hypervisor's preset trap handler. The Hypervisor's trap handler transfers control to its internal simulator module, which parses the specific data content carried by this write operation, organizes the parsed character data into a structured log entry according to a predefined format, and stores the entry in a specified location.
9. The logging implementation method in a Hypervisor / virtualization environment according to claim 1, characterized in that, Step S4 includes: S41, after the early console phase of the UOS kernel ends, switch the UOS log output path from the interception simulation mode based on full virtualization to the communication transmission mode based on the semi-virtualization standard. S42, driven by a virtual console front-end driver running within UOS, follows a semi-virtualized communication protocol and uses a shared memory queue mechanism provided by virtualization technology to send runtime log data generated by the UOS kernel to the back-end service process running in the SOS user space.
10. A Log implementation method in a Hypervisor / virtualization environment according to claim 9, characterized in that, The final output behavior of the semi-virtualized channel supports configuration-based dynamic control: During the startup initialization phase, the backend service process running in SOS user space reads its external configuration file information to obtain control parameters. If a specific control option in the configuration information is set to off or disabled, the backend service process will not output log data received from the client operating system virtual machine UOS from the virtual queue to the standard error output device of SOS user space during operation.