Method and system for detecting Guest OS starting exception

Abstract

The embodiment of the invention provides a Guest OS starting exception detection method and system, and the method comprises the steps: recording the starting moment of a virtual machine instance in response to a detected starting event of the virtual machine instance; under the condition that the virtual machine instance is in the running state, determining whether the virtual machine instance successfully responds to a detection request sent by a host machine where the virtual machine instance is located or not; if it is confirmed that the predefined starting exception judgment condition is met, it is judged that starting of a guest operating system Guest OS on the virtual machine instance is abnormal; wherein the startup exception judgment condition comprises that the virtual machine instance does not successfully respond to the detection request within a preset duration after the startup moment.

Description

Technical Field

[0001] This specification relates to one or more embodiments in the field of cloud service technology, and in particular to a method and system for detecting Guest OS startup anomalies. Background Technology

[0002] Virtualization technology plays a crucial role in cloud service provider scenarios, allowing cloud service providers to run multiple independent virtual machine instances or container instances on the same physical device, thereby improving resource utilization, reducing costs, and enhancing service flexibility.

[0003] Virtual machine instances utilize full virtualization technology, simulating a complete hardware environment so that each virtual machine instance can independently run its own operating system and applications. Container instances, on the other hand, employ a more lightweight virtualization technology. Based on operating system-level virtualization, they share the host machine's operating system kernel and only encapsulate the application and its dependencies. Therefore, for scenarios requiring rapid deployment, high-density deployment, and microservice architectures, such as DevOps processes and continuous integration / continuous delivery, container instances are more suitable. However, for scenarios requiring high isolation and compatibility, such as development and testing environments and multi-tenant applications in production environments, virtual machine instances are more suitable. Since the host machine and virtual machine instances need to run their own independent operating systems, for ease of distinction, the operating system on the host machine is usually called the host operating system (Host OS), and the operating system on the virtual machine instance is called the guest operating system (Guest OS).

[0004] Cloud service providers can offer services based on virtual machine instances or container instances according to users' actual needs. For virtual machine instances: In related technologies, cloud service providers or their affiliated operations and maintenance (O&M) service providers' personnel can only know the status of the virtual machine instance itself, but not the status of the Guest OS. This means that if the virtual machine instance is running but the Guest OS is malfunctioning, O&M personnel cannot promptly detect and handle the situation. Users must independently discover the anomaly and report a Guest OS anomaly ticket before O&M personnel can handle the subsequent processing.

[0005] However, on the one hand, this process relies heavily on manual handling by users and maintenance personnel, which is not only time-consuming and labor-intensive but also prone to oversight. On the other hand, users often cannot determine at which stage the Guest OS malfunctions, making it difficult for maintenance personnel to quickly identify the appropriate troubleshooting approach and prolonging the troubleshooting time. Summary of the Invention

[0006] In view of the above, one or more embodiments of this specification provide the following technical solutions:

[0007] According to a first aspect of one or more embodiments of this specification, a method for detecting Guest OS boot anomalies is provided, the method comprising:

[0008] In response to the detection of a virtual machine instance startup event, the startup time of the virtual machine instance is recorded;

[0009] If the virtual machine instance is running, determine whether the virtual machine instance successfully responded to the probe request issued by its host machine;

[0010] If the predefined startup exception determination conditions are confirmed to be met, then the guest operating system on the virtual machine instance is determined to have a startup exception; wherein, the startup exception determination conditions include: the virtual machine instance has not successfully responded to the probe request within a preset time after the startup time, and the preset time is longer than the predefined guest OS startup time.

[0011] According to a second aspect of one or more embodiments of this specification, a detection system for Guest OS boot anomalies is provided, the system comprising:

[0012] The host machine, which runs virtual machine instances;

[0013] The detection node, in response to detecting a startup event of a virtual machine instance, records the startup time of the virtual machine instance; and, if the virtual machine instance is in a running state and it is confirmed that a predefined startup exception determination condition has been met, determines that the guest operating system instance on the virtual machine instance has a startup exception; wherein, the startup exception determination condition includes: the virtual machine instance has not successfully responded to the probe request issued by the host machine within a preset time after the startup time, and the preset time is longer than the predefined guest OS startup time.

[0014] According to a third aspect of one or more embodiments of this specification, an electronic device is provided, comprising: a processor; a memory for storing processor-executable instructions; wherein the processor performs the steps of the method as described in the first aspect by executing the executable instructions.

[0015] According to a fourth aspect of one or more embodiments of this specification, a computer-readable storage medium is provided that stores computer instructions thereon, which, when executed by a processor, implement the steps of the method as described in the first aspect.

[0016] According to a fifth aspect of one or more embodiments of this specification, a computer program product is provided, comprising a computer program / instructions that, when executed by a processor, implement the steps of the method as described in the first aspect.

[0017] As can be seen from the above embodiments, this specification allows the host machine to issue a probe request to the virtual machine instance that is running on it. Based on whether the virtual machine instance successfully responds to the probe request, it can automatically and accurately identify whether the Guest OS on the virtual machine is malfunctioning. This eliminates the need for users to manually check whether the virtual machine instance is functioning correctly, and also eliminates the need for users to submit work orders or for maintenance personnel to process them. This simplifies the operation for both users and maintenance personnel, and allows for more timely detection of Guest OS malfunctions, avoiding serious consequences caused by negligence or delayed detection. Furthermore, by automatically detecting the startup event of the virtual machine instance and recording its startup time, when a Guest OS malfunction occurs on the virtual machine instance, the relationship between the time of the malfunction and the startup time of the virtual machine instance can be used to automatically identify whether the Guest OS malfunction occurred during the startup phase. This allows maintenance personnel to quickly determine the appropriate troubleshooting approach and helps to promptly eliminate the Guest OS malfunction. Attached Figure Description

[0018] Figure 1 This is a schematic diagram of the architecture of a Guest OS startup exception detection system provided in an exemplary embodiment.

[0019] Figure 2 This is a flowchart of a method for detecting Guest OS startup anomalies, provided in an exemplary embodiment.

[0020] Figure 3 This is a schematic diagram illustrating an exemplary embodiment of sending a probe request to a virtual machine instance.

[0021] Figure 4 This is an exemplary embodiment of a diagram illustrating another method for sending a probe request to a virtual machine instance.

[0022] Figure 5 This is a schematic diagram illustrating a boot anomaly detection and root cause analysis of a Guest OS provided in an exemplary embodiment.

[0023] Figure 6 This is a schematic diagram of a serial port diagnostic provided in an exemplary embodiment.

[0024] Figure 7 This is a schematic diagram of a screenshot diagnosis provided in an exemplary embodiment.

[0025] Figure 8 This is a schematic structural diagram of a device provided in an exemplary embodiment.

[0026] Figure 9 This is a block diagram of a Guest OS startup anomaly detection device provided in an exemplary embodiment.

[0027] Figure 10 This is a schematic structural diagram of an electronic device provided in an exemplary embodiment. Detailed Implementation

[0028] 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 manual are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or refuse.

[0029] Figure 1 This is a schematic diagram of the architecture of a Guest OS startup exception detection system provided in an exemplary embodiment. Figure 1 As shown, a virtual machine instance 110 can be created on host machine 10, and a Guest OS runs on virtual machine instance 110. Virtual machine instance 110 can be created on host machine 10 based on virtualization technology, and it can occupy some or all of the resources on a single host machine 10. Of course, in other embodiments, a virtual machine instance can also occupy resources on multiple physical devices simultaneously, in which case these multiple physical devices can simultaneously serve as hosts for the virtual machine instance. The Guest OS running on virtual machine instance 110 is independent of the Host OS running on host machine 10; both can be the same or different types of operating systems. This specification does not limit the specific type of Guest OS. Since a Guest OS needs to be run, the virtual machine instance (such as virtual machine instance 110) and its running Guest OS can also be considered as a whole, collectively referred to as a Guest OS instance.

[0030] The detection node can work together to perform the aforementioned startup anomaly detection operations. This detection node can be deployed in locations such as... Figure 1 The detection node is located on a physical host 20 as shown. In other embodiments, the detection node may also be deployed in a virtual machine environment, and this specification does not limit this to that.

[0031] A detection node can inspect one or more virtual machine instances within the network to determine if their GuestOS is experiencing startup issues. The inspection process for each virtual machine instance follows the same logic. Multiple detection nodes can exist simultaneously in the network, each capable of inspecting different virtual machine instances, thus distributing the workload across all nodes.

[0032] The process of the detection node detecting virtual machine instances will be explained below in conjunction with... Figure 2 A detailed introduction will be provided. Figure 2 This is a flowchart illustrating a method for detecting Guest OS startup anomalies, provided in an exemplary embodiment. Figure 2 As shown, the method may include:

[0033] Step 202: In response to the detection of a virtual machine instance startup event, record the startup time of the virtual machine instance.

[0034] Each virtual machine instance in the network can serve as a virtual machine instance in step 202, and the technical solutions in this specification can be used to detect whether the Guest OS on it has a startup error. In practical scenarios, different virtual machine instances can also be distinguished so that some virtual machine instances can serve as virtual machine instances here, while others cannot. For example, the Guest OS startup error detection scheme based on this specification can be used as an additional function. If a virtual machine instance has permission to use this additional function, then that virtual machine instance can serve as a virtual machine instance here; if it does not have permission to use this additional function, then that virtual machine instance cannot serve as a virtual machine instance here. Of course, other methods can also be used to distinguish different virtual machine instances, which will not be elaborated here.

[0035] If a startup event of a virtual machine instance is detected, it indicates that the virtual machine instance has begun its lifecycle. A startup event can be represented by a startup message or a file containing startup messages; however, this specification does not impose any limitations on this. The content of the startup event, i.e., the content of the aforementioned startup message, can include the startup time of the corresponding virtual machine instance. Of course, this specification does not limit the method of obtaining or determining the startup time; for example, the moment the startup event is detected can also be used as the aforementioned startup time.

[0036] Step 204: If the virtual machine instance is running, determine whether the virtual machine instance successfully responded to the probe request issued by its host machine.

[0037] During the lifecycle of a virtual machine instance, there are several possible states. For example, the "running" state indicates that the virtual machine instance is running normally, while the "stopped" state indicates that the virtual machine instance has stopped running. Of course, different cloud service providers may have different definitions for the same state of a virtual machine instance, but this does not affect the essence. Typically, the management system at the cloud service provider can obtain the status of each virtual machine instance. This management system may, for example, run on the monitoring node mentioned above. Alternatively, the management system may also run on other nodes, and the monitoring node can obtain the status of the virtual machine instances from those other nodes.

[0038] Virtual machine instances may crash for various reasons. When a virtual machine instance crashes, its status on the management system will change from "running" (as mentioned above) to "stopped" or other statuses; in short, it will be visible on the management system. However, even when the virtual machine instance's status on the management system is "running," meaning it is in a running state, it may still fail to respond to requests normally. This can be called a system crash, which is usually caused by an anomaly in the Guest OS running on the virtual machine instance.

[0039] As can be seen, for virtual machine instances experiencing crashes, the management system cannot accurately reflect the true status of the virtual machine instance based on its current state. However, the technical solution in this specification can accurately detect this. Specifically, by sending a probe request to a running virtual machine instance, if the virtual machine instance is not experiencing a crash, it can return a response message to the probe request, indicating a successful response. Conversely, if the virtual machine instance is experiencing a crash, it cannot return a response message to the probe request, indicating a failed response. Therefore, it is possible to detect whether an anomaly has occurred in the Guest OS on the virtual machine instance.

[0040] As one example, the probe request includes an arp_ping (Packet Internet Groper) request based on ARP (Address Resolution Protocol). When sending an arp_ping request to a virtual machine instance, the virtual machine instance's IP address needs to be included in the arp_ping request, which is equivalent to asking it, "Is this your IP address?". Accordingly, if the virtual machine instance determines that its own IP address is included in the arp_ping request, it returns an ARP reply message: the ARP reply will contain the virtual machine instance's MAC address.

[0041] As another embodiment, the probe request includes an ICMP Echo Request based on ICMP (Internet Control Message Protocol), used to test network connectivity. Upon receiving an ICMP Echo Request, the virtual machine instance returns an ICMP Echo Reply message.

[0042] Of course, this specification does not limit the type of protocol used for probe requests and response messages. In fact, as long as it is ensured that after a probe request is sent to the virtual machine instance, the virtual machine instance will return a response message when the Guest OS is running normally, and will not return a response message when the Guest OS is malfunctioning, the corresponding communication protocol can be used for the technical solutions in this specification.

[0043] Since virtual machine instances are created on the host machine based on virtualization technology, the host machine always needs to send a probe request to the virtual machine instance and receive the response message returned by the virtual machine instance. Of course, although the host machine ultimately performs the action of "sending a probe request to the virtual machine instance," there are several possible ways to trigger this action.

[0044] In one embodiment, the detection node can send a probe command to the virtual machine instance to instruct the host machine to initiate the probe request to the virtual machine instance; and receive a feedback message from the host machine, the feedback message indicating whether the virtual machine instance successfully responded to the probe request. For example Figure 3As shown, assuming the virtual machine instance is deployed on a host machine, the detection node can send a probe command to the host machine in step ①. The host machine does not need to be configured with logic for autonomously probing the virtual machine instance. It only needs to send a probe request to the virtual machine instance in step ② according to the probe command's instructions, and receive the response message returned by the virtual machine instance in step ③. Of course, if the Guest OS on the virtual machine instance is abnormal, it may not be able to receive the response message returned by the virtual machine instance. If the host machine receives the response message, it can directly return the response message to the detection node as the aforementioned feedback message in step ④; alternatively, the host machine can also use the response message as the payload of the feedback message, i.e., carry the response message in the feedback message; or, the host machine can also indicate in the feedback message that the virtual machine instance has successfully responded to the probe request in other ways, such as setting the value of a preset field in the feedback message to a predefined first value (e.g., "1"), thereby reducing the data volume of the feedback message and helping to improve transmission speed. If the host machine does not receive a response message, it can return a feedback message to the detection node in step ④. This feedback message is used to indicate to the detection node that the virtual machine instance failed to respond to the probe request. For example, the value of the above-mentioned preset field in the feedback message can be set to a predefined second value (such as "0"), or other methods can be used to represent it. This specification does not limit this.

[0045] In another embodiment, the detection node can receive probe results sent by the host machine where the virtual machine instance resides. These probe results are generated by the host machine actively initiating a probe request to the virtual machine instance, and are used to indicate whether the virtual machine instance successfully responded to the probe request. For example... Figure 4 As shown, the host machine can proactively send a probe request to the virtual machine instance in step ①'. Therefore, compared to the aforementioned scheme, where the detection node sends a probe command to the host machine to instruct it to initiate a probe request to the virtual machine instance, this embodiment requires pre-configuration of autonomous probe processing logic on the host machine, enabling the host machine to proactively send probe requests to the virtual machine instance without the detection node sending a probe command. Correspondingly, if the host machine receives a response message from the virtual machine instance in step ②', it further feeds back the probe result to the detection node in step ③' to indicate that the virtual machine instance successfully responded to the probe request; correspondingly, with... Figure 3Similar to the illustrated embodiment, the host machine can directly use the received response message as the probe result, add the received response message as the payload of the probe result, or set the value of a preset field in the probe result to a first value (such as "1"), or other feasible methods. If the host machine does not receive a response message from the virtual machine instance in step ②', it will send the probe result back to the detection node in step ③' to indicate that the virtual machine instance did not successfully respond to the probe request; correspondingly, it will still use... Figure 3 Similar to the embodiments shown, the host machine may set the value of the preset field of the probe request to a predefined second value (such as "0"), or use other methods to represent it, and this specification does not limit this.

[0046] Whether the detection node instructs the host to initiate a detection request via a detection command, or the host actively sends the aforementioned detection request based on its autonomous detection processing logic, the timing of sending the detection request can include: sending a detection request to the virtual machine instance in response to the detection of a startup event; in other words, starting to send the detection request immediately after detecting the startup event to detect any startup anomalies in the Guest OS as early as possible; or, sending a detection request to the virtual machine instance after waiting for a predefined Guest OS startup time in response to the detection of a startup event; in other words, not starting to send the detection request immediately after detecting the startup event, because the Guest OS startup itself also takes a certain amount of time, and the virtual machine instance will inevitably be unable to provide a response message before the Guest OS startup is complete. Therefore, the detection request can be sent to the virtual machine instance only after waiting for the predefined Guest OS startup time, thereby avoiding or reducing meaningless sending of detection requests during a stage when the virtual machine instance will inevitably be unable to respond.

[0047] Of course, regarding the aforementioned Figure 3 and Figure 4 The two different scenarios shown require the detection node and the host machine to control the timing respectively. For example, for Figure 3 In the illustrated embodiment, the detection node can send a probe command to the host machine where the virtual machine instance resides in response to the detection of a virtual machine instance startup event, or the detection node can send a probe command to the host machine where the virtual machine instance resides after waiting for a predefined Guest OS startup time, and the host machine only needs to initiate a probe request in response to the received probe command. For example, for... Figure 4In the embodiment shown, the host needs to detect the startup event of the virtual machine instance and, in response to detecting the startup event of the virtual machine instance, send a probe request to the virtual machine instance. Alternatively, the host can, in response to detecting the startup event of the virtual machine instance, send a probe request to the virtual machine instance after waiting for a predefined Guest OS startup time.

[0048] The Guest OS startup time can be a predefined duration t. This duration t can be determined based on an estimate of the Guest OS startup time. For example, the average historical Guest OS startup time can be calculated from historical data and set as t. This historical data can be the entire historical dataset, or it can be divided into different scenarios based on virtual machine resource configuration information, Guest OS operating system type, etc., and the average Guest OS startup time for each scenario can be calculated separately. In this case, the aforementioned duration t can be the Guest OS startup time defined for the scenario corresponding to the detected virtual machine instance. Of course, the Guest OS startup time can also be set in other ways, and this manual does not impose any restrictions on this.

[0049] by Figure 5 Taking the abnormal startup detection phase shown as an example, and in conjunction with... Figure 4 The illustrated embodiment is described by way of example. It is assumed that the host machine detects a virtual machine instance startup event at time T0. In one embodiment, the host machine can send a probe request① to the Guest OS instance at time T1, which corresponds to... Figure 5 The "probe 1" in the context refers to the time difference between T1 and T0, which can be the Guest OS startup time mentioned above, and is set to t, where t > 0. If the Guest OS on the virtual machine instance starts normally enough to receive probe request ①, it will return a response message accordingly. After receiving this response message, the host machine will not continue to send probe requests. If the host machine does not receive a response message within the predefined response time, it determines that the virtual machine instance has not successfully responded to probe request ①, and continues to send probe request ② to the virtual machine instance at time T2. This operation corresponds to... Figure 5 The "probe 2" in the context of the virtual machine instance. If the Guest OS on the virtual machine instance boots normally enough to receive probe request ②, it will return a response message accordingly. Once the host machine receives this response message, it will not continue sending probe requests. If the host machine does not receive a response message within the predefined response time, it determines that the virtual machine instance has not successfully responded to probe request ②, and continues to send probe request ③ to the virtual machine instance at time T3. This operation corresponds to... Figure 5 The "probe 3" in the text. And so on, assuming a preset number of attempts is 5, then the host machine might continue to... Figure 5At subsequent times (not shown), probe requests ④ and ⑤ are sent respectively. If the host machine does not receive a response message, it will stop sending probe requests and report a "virtual machine instance failed to respond to probe request" status to the detection node. The detection node can then determine that the virtual machine instance has experienced a crash. Of course, if the host machine receives a response message at some point, it will report a "virtual machine instance successfully responded to probe request" status to the detection node, and the detection node can then determine that the Guest OS on the virtual machine instance has started normally.

[0050] When a virtual machine instance experiences a crash event, the detection node needs to further determine whether the crash event was caused by a Guest OS startup anomaly. If it wasn't caused by a Guest OS startup anomaly, but rather by an anomaly occurring during operation after successful startup, the troubleshooting approach required by the operations and maintenance personnel would be drastically different. For example, step 206 below can be used to confirm whether a Guest OS startup anomaly occurred.

[0051] Step 206: If it is confirmed that the predefined startup exception determination conditions have been met, then the guest operating system on the virtual machine instance is determined to have a startup exception; wherein, the startup exception determination conditions include: the virtual machine instance has not successfully responded to the probe request within a preset time after the startup time, and the preset time is longer than the predefined guest OS startup time.

[0052] In one embodiment, the startup exception determination condition may only include: condition (1) the virtual machine instance fails to respond to the probe request within a preset time after the startup time, and the preset time is longer than the predefined GuestOS startup time.

[0053] In other words, starting from the aforementioned startup time, the host machine will send one or more probe requests to the virtual machine instance. If no response message is received from the virtual machine instance, it indicates that the Guest OS has failed to show any signs of normal startup and operation since the virtual machine instance started normally. Therefore, it can be considered that the Guest OS has failed to start normally, i.e., the Guest OS startup on the virtual machine instance is abnormal. The preset duration should be greater than the predefined Guest OS startup time to avoid the situation where "no successful response to probe requests" is due to the Guest OS not yet having completed startup, thus preventing misjudgment. The specific difference between the preset duration and the predefined Guest OS startup time can be set according to actual conditions, and this manual does not impose any restrictions on it. In particular, if the host machine needs to wait for the predefined Guest OS startup time after startup before sending a probe request, it should at least ensure that the host machine can complete one probe request sending operation and has sufficient time to determine that the virtual machine instance has indeed failed to return a response message.

[0054] For example, in conjunction with the above Figure 5 In this example, the predefined startup time of the Guest OS is t, the time to complete the sending of a probe request is t1, and the time for the virtual machine instance to return a response message under normal circumstances is t2. Then the above-mentioned preset duration tt should satisfy: tt≥t+t1+t2.

[0055] Specifically, assuming the predefined Guest OS startup time is t = 20s, the above-mentioned preset duration is tt = 60s. After the host machine detects the virtual machine instance startup event at time T0, it can wait for t = 20s, and then send probe requests to the virtual machine instance at a period of, for example, 10s, i.e., T1 = T0 + 20s, T2 = T1 + 10s, T3 = T2 + 10s, and so on. Then, if the host machine receives a response message before T3 after sending a probe request at, for example, time T2, it can determine that the Guest OS has started normally and does not need to continue sending probe requests; otherwise, it will continue to send probe requests at time T3. If, at Tx = T0 + 60s, all probe requests sent by the host machine have failed to receive corresponding response messages, the host machine can consider that the above condition (1) has been met, and thus determine that the Guest OS on the virtual machine instance has failed to start.

[0056] In another embodiment, in addition to the above-mentioned condition (1), the startup exception determination condition may further include: condition (2) no heartbeat message is received from the guest agent within a preset time after the startup time.

[0057] The client agent can be configured by the user on the Guest OS as an extended function according to actual needs. In the technical solution of this specification, the client agent can be used to periodically send heartbeat messages when the Guest OS is booting normally; correspondingly, the detection node will receive the heartbeat messages. Of course, the client agent can also be used to implement other functions, and this specification does not limit this.

[0058] It is evident that if the Guest OS fails to start normally, the client agent cannot operate normally and therefore cannot send heartbeat messages. However, if the detection node receives a heartbeat message, it can determine that the client agent is running normally, and the Guest OS must have started normally. Therefore, the detection node can cross-judge whether the Guest OS has started abnormally based on the above conditions (1) and (2) to avoid misjudgment. In other words, the detection node can determine that the Guest OS has started abnormally if the virtual machine instance has not successfully responded to the probe request within a preset time after startup and has not received a heartbeat message from the client agent within the preset time after startup. When judging whether conditions (1) and (2) are met, the detection node can first judge any one of the conditions. If the condition is met, it can further judge the other condition, or it can independently judge the two conditions in parallel and summarize the judgment results. This specification does not limit this.

[0059] This manual does not impose any restrictions on the heartbeat message sending and receiving mechanism. In summary, the client agent configured within the Guest OS defines the logic for periodically sending heartbeat messages, enabling the client agent to implement this. The heartbeat message sending cycle can be set according to actual needs, such as sending a heartbeat message every 5 seconds or other intervals; this manual does not impose any restrictions on this.

[0060] During the transmission of heartbeat messages, the host machine typically acts as an intermediary between the client agent and the detection node. For example, upon receiving a heartbeat message from a client agent configured on the Guest OS, the host machine can forward the heartbeat message to the detection node. The forwarding logic for the heartbeat message can be configured on the host machine. For instance, a host agent can run on the host machine, and the aforementioned heartbeat message forwarding logic can be configured within this host agent, enabling it to specifically receive the heartbeat message sent by the client agent and then forward it to the detection node.

[0061] If a startup exception is determined to occur in the Guest OS on a virtual machine instance, root cause analysis (RCA) can be performed to determine the cause of the Guest OS startup exception. To do this, the detection node can acquire diagnostic-related data and perform root cause analysis on the Guest OS startup exception based on this data. The diagnostic-related data can include any data that can be used to perform root cause analysis on the Guest OS startup exception; this specification does not impose any limitations on this.

[0062] Root cause analysis, as a problem-solving method, involves analyzing diagnostic data and employing logical reasoning and data analysis techniques to explore the possible causes of problems. In particular, it identifies the core cause from among numerous possibilities, which is usually the initial factor leading to a series of anomalies—the "root cause," or fundamental reason. In the technical solution of this specification, the aim is to analyze and determine the root cause of the Guest OS's abnormal startup. By investigating this root cause, we can resolve the current situation of the virtual machine instance crashing and propose subsequent optimization solutions to prevent similar anomalies from recurring in the long term.

[0063] There can be many sources for diagnostic data. For example... Figure 5 The root cause identification phase illustrated includes serial port diagnostics and screenshot diagnostics, each with different data sources. Of course, other sources not detailed in this manual can also be used, and root cause diagnosis can be achieved based on other diagnostic methods; this manual does not impose any restrictions on this.

[0064] For serial port diagnostics, specifically, when the detection node determines that a startup exception has occurred in the Guest OS on the virtual machine instance, it can obtain the system log generated by that virtual machine instance. This system log records diagnostic-related data, which can be used to perform root cause diagnosis of the startup exception of the corresponding Guest OS. For example... Figure 6 As shown, it is called serial port diagnosis mainly because the host machine reads the above system log from the virtual machine instance through a preset virtual serial port. Therefore, this system log can also be called serial port log.

[0065] After obtaining system logs, the host machine can directly send them to the detection nodes. However, this means the detection nodes need to establish a direct communication connection with the host machine. If there are many host machines in the network, the number of communication connections that the detection nodes need to establish and maintain will also be large. Therefore, as an alternative, the host machine can establish a connection with the log storage system and then store the obtained system logs in the log storage system. Correspondingly, the detection nodes can establish a connection with the log storage system and read system logs from it. It is evident that regardless of the number of host machines, the detection nodes only need to connect to the log storage system, and will not need to establish and maintain more communication connections due to an increase in the number of host machines, greatly reducing the overhead incurred by the detection nodes.

[0066] For example, an exemplary log format is as follows:

[0067] [timestamp][severity level][source]:[message]

[0068] Here, "[timestamp]" is the timestamp of the event, "[severity level]" indicates the severity of the event, "[source]" refers to the message source that generated the log, and "[message]" is the specific error or information message.

[0069] Based on the above log format, for example, the following log entries may be generated when the Guest OS boots abnormally:

[0070] 2023-04-01T12:00:00Z[ERROR][SeaBIOS]:Booting from Hard Disk failed with error'unknown filesystem'.

[0071] 2023-04-01T12:00:05Z[INFO][SeaBIOS]: Entering rescue mode.

[0072] In the first line, the value of [timestamp] is "2023-04-01T12:00:00Z", the value of [severitylevel] is "ERROR", the value of [source] is "SeaBIOS", and the value of [message] is "Booting from Hard Disk failed with error 'unknown filesystem'".

[0073] In the second line, the corresponding value for [timestamp] is "2023-04-01T12:00:05Z", the corresponding value for [severitylevel] is "INFO", the corresponding value for [source] is "SeaBIOS", and the corresponding value for [message] is "Entering rescue mode".

[0074] In summary, the log entries above reflect that the Guest OS failed to boot properly during the startup process because it could not recognize the file system on the hard drive, and thus entered rescue mode.

[0075] For screenshot diagnosis, specifically, when a detection node determines that the Guest OS on the virtual machine instance has a startup abnormality, it connects to the host machine where the virtual machine instance resides, accesses the screen content of the virtual machine instance through the virtual machine manager on the host machine, and captures the screen content to obtain a screenshot image. Then, it performs text recognition on the screenshot image to obtain diagnostic-related data contained in the screen content of the virtual machine instance, which is then used to perform root cause diagnosis of the startup abnormality of the Guest OS on the virtual machine instance. For example... Figure 7 As shown, the detection node can remotely connect to the host machine via methods such as VNC (Virtual Network Console), RPD (Remote Desktop Protocol), or others. The host machine can run virtual machine managers such as VMware Workstation or VirtualBox, allowing the detection node to select the aforementioned virtual machine instance, access its screen content, and capture the screenshot using the virtual machine manager's screenshot function. By using OCR (Optical Character Recognition) technology to perform text recognition on the screenshot, the text of the screen content can be obtained, which will contain the aforementioned diagnostic data.

[0076] For example, exemplary screen content may include:

[0077] SeaBIOS (version 449e491) / / Represents the SeaBIOS version number

[0078] Machine UUID 05cf67a3-eec5-4a7d-a746-24f56644f9d8 / / Represents a unique identifier for the virtual machine instance.

[0079] Booting

[0080] r from Hard Disk.. / / This indicates that the operating system is attempting to boot from the hard drive.

[0081] Error: Unknown filesystem. / / Error message indicating that the system cannot recognize the file system on the hard drive.

[0082] Entering

[0083] rescue mode...

[0084] grub rescue> / / This indicates entering rescue mode

[0085] In summary, the above screen content reflects that the Guest OS on the virtual machine instance failed to boot normally during the startup process because it could not recognize the file system on the hard drive, and entered the rescue mode of GRUB (GRand Unified Bootloader).

[0086] The detection node can acquire only system logs or screenshots, or both. Similarly, it can acquire other data sources if they exist. For the acquired diagnostic data, the detection node can input it into a pre-built rule engine and obtain the root cause diagnosis results output by that rule engine, such as... Figures 6-7 As shown.

[0087] The core concept of a rule engine is a set of rules, which consist of a series of conditions and actions. For example, in this embodiment, when diagnostic data meets the conditions defined in the rules, the rule engine outputs the corresponding root cause diagnosis result. For instance, in a scenario of root cause diagnosis of Guest OS startup anomalies, the conditions in the rules can include predefined keywords, with different keywords corresponding to different root cause diagnosis results. Therefore, after inputting diagnostic data into the rule engine, the content of the diagnostic data can be matched with the aforementioned predefined keywords: if a matching keyword exists, the root cause diagnosis result corresponding to that keyword can be determined and output as the root cause diagnosis result corresponding to the input diagnostic data.

[0088] For example, exemplary rules may include:

[0089] The rule `StartVmFailedAtGrubRescue"GrubRescue."salience 128: / / ` indicates that the rule is named "StartVmFailedAtGrubRescue" and described as "GrubRescue". The `salience` value of 128 indicates that this rule has high importance.

[0090] when: / / indicates that the following are conditions (specific up to "Then").

[0091] VncContent.OsType == "linux": / / indicates that the Guest OS's operating system type is Linux.

[0092] (VncContent.Value.MatchString("grub>")||VncContent.Value.MatchString("grubrescue>")||VncContent.Value.MatchString("rescuemode")||VncContent.Value.MatchString("GNUGRUB")): / / indicates whether the Value field of VncContent contains "grub>", "grubrescue>", "rescuemode", or "GNUGRUB", which are all flags for GRUB rescue mode.

[0093] Then: / / indicates that the results are below.

[0094] Result.Code = "GuestOS.ScreenShot.GrubRescue"; / / This means setting the result code to "GuestOS.ScreenShot.GrubRescue", which confirms that the Guest OS has entered rescue mode via screenshot.

[0095] Result.CodeID = "1662001143"; / / This sets the result code ID to "1662001143"

[0096] Result.Reason = "Linux system GRUB boot failure"; / / indicates that the exception reason is described as "Linux system GRUB boot failure".

[0097] Result.Url = "Possible causes: missing or corrupted GRUB bootloader, unrecognized system partition, abnormal shutdown, etc. It is recommended to manually try booting and then reinstalling GRUB; if manual booting fails, the system is corrupted, and it is recommended to reset the system disk."; : / / indicates a link to the error details, providing possible causes and suggested solutions.

[0098] Complete(); / / indicates the end

[0099] In summary, this code provides a rule named StartVmFailedAtGrubRescue, which describes the root cause analysis logic when the Guest OS encounters GRUB rescue mode during startup. For example, by inputting the aforementioned exemplary screen content into the rule engine and processing it using this exemplary rule, the rule engine is expected to output the aforementioned result code, result code ID, exception cause description, and exception details link, as the root cause diagnosis result.

[0100] This specification does not restrict the method of creating rules used by the rule engine. For example, rules can be summarized and written by operations personnel or other experts based on experience. Alternatively, an artificial intelligence model can learn from historical data related to the Guest OS engine and then summarize and generate usable rules.

[0101] It should be noted that after determining that a boot failure has occurred in the Guest OS, the detection node is not necessarily required to independently acquire diagnostic data and perform root cause diagnosis. For example, the detection node can inform another node, such as the diagnostic node, of the Guest OS boot failure, and the diagnostic node can then independently acquire diagnostic data and perform root cause diagnosis. Alternatively, the detection node can acquire diagnostic data and provide it to the diagnostic node after determining that a boot failure has occurred, and the diagnostic node can then perform root cause diagnosis based on this data.

[0102] In addition, in such Figure 5 Following the root cause identification stage, there may be subsequent processing at the application layer, such as further fault cause analysis and fault impact range analysis based on the root cause diagnosis results, finding suitable solutions, and generating analysis reports for users. These can be achieved using application layer tools in related technologies, which will not be elaborated here.

[0103] In summary, this manual describes a method where the host machine issues a probe request to a running virtual machine instance. Based on whether the virtual machine instance successfully responds to the probe request, it automatically and accurately identifies whether the Guest OS on that virtual machine is experiencing anomalies. This eliminates the need for manual checks of the virtual machine instance's functionality, as well as the need for users to submit work orders or for maintenance personnel to process them. This simplifies operations for both users and maintenance personnel and allows for more timely detection of Guest OS anomalies, preventing serious consequences from oversight or delayed detection. Furthermore, by automatically detecting and recording the startup events of the virtual machine instance, when an anomaly occurs on the Guest OS, the relationship between the time of the anomaly and the startup time of the virtual machine instance can be used to automatically identify whether the anomaly occurred during the startup phase. This allows maintenance personnel to quickly determine the appropriate troubleshooting approach and helps to promptly resolve the Guest OS anomaly.

[0104] Figure 8 This is a schematic structural diagram of a device provided in an exemplary embodiment. Please refer to... Figure 8 At the hardware level, the device includes a processor 802, an internal bus 804, a network interface 806, memory 808, and non-volatile memory 810, and may also include other hardware required for its functions. One or more embodiments of this specification can be implemented in software, for example, the processor 802 reads the corresponding computer program from the non-volatile memory 810 into memory 808 and then runs it. Of course, besides software implementation, one or more embodiments of this specification do not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. That is to say, the execution entity of the following processing flow is not limited to individual logic units, but can also be hardware or logic devices.

[0105] Please refer to Figure 9 The detection device for Guest OS instance startup anomalies can be applied to, for example... Figure 8 The device shown may include:

[0106] The startup time recording unit 901 records the startup time of the virtual machine instance in response to detecting a startup event of the virtual machine instance;

[0107] The response status determination unit 902 determines whether the virtual machine instance has successfully responded to the probe request issued by its host machine when the virtual machine instance is in a running state.

[0108] If the startup exception determination unit 903 confirms that the predefined startup exception determination conditions have been met, it determines that the guest operating system on the virtual machine instance has a startup exception; wherein, the startup exception determination conditions include: the virtual machine instance has not successfully responded to the probe request within a preset time after the startup time, and the preset time is longer than the predefined guest OS startup time.

[0109] Optionally, the response determination unit 902 is specifically used for:

[0110] Send a probe command to the host machine where the virtual machine instance resides, instructing the host machine to initiate the probe request to the virtual machine instance; and receive a feedback message from the host machine, the feedback message indicating whether the virtual machine instance successfully responded to the probe request; or,

[0111] The system receives a probe result sent by the host machine where the virtual machine instance resides. The probe result is generated by the host machine actively initiating the probe request to the virtual machine instance, and the probe result is used to indicate whether the virtual machine instance successfully responded to the probe request.

[0112] Optionally, sending a probe command to the host machine where the virtual machine instance resides includes:

[0113] In response to detecting the startup event of the virtual machine instance, the probe command is sent to the host machine where the virtual machine instance resides; or,

[0114] In response to the detection of the startup event of the virtual machine instance, after waiting for the predefined Guest OS startup time, the probe command is sent to the host machine where the virtual machine instance is located.

[0115] Optionally, a client agent is configured on the Guest OS, which is used to periodically send heartbeat messages when the Guest OS starts normally.

[0116] The startup anomaly determination condition also includes: no heartbeat message is received from the client agent within a preset time after the startup time;

[0117] The startup anomaly determination unit 903 is specifically used to determine that the Guest OS startup is abnormal if the virtual machine instance fails to respond to the probe request within a preset time after the startup time and does not receive a heartbeat message from the client agent within the preset time after the startup time.

[0118] Optionally, the device further includes:

[0119] Log acquisition unit 904, when it is determined that the Guest OS on the virtual machine instance is abnormally started, acquires the system log generated by the virtual machine instance, and the system log records diagnostic-related data;

[0120] The first root cause diagnosis unit 905 performs root cause diagnosis on the startup anomaly of the Guest OS on the virtual machine instance based on the diagnosis-related data.

[0121] Optionally, the log acquisition unit 904 is specifically used for:

[0122] Establish a connection with the log storage system and read the system logs from the log storage system;

[0123] The system log is read from the virtual machine instance by the host machine of the virtual machine instance through a preset virtual serial port and then stored in the log storage system.

[0124] Optionally, the device further includes:

[0125] The connection establishment unit 906 connects to the host machine of the virtual machine instance if it determines that the Guest OS on the virtual machine instance is abnormal during startup.

[0126] The screenshot and recognition unit 907 accesses the screen content of the virtual machine instance through the virtual machine manager on the host machine, and captures the screen content of the virtual machine instance to obtain a corresponding screenshot image; and performs text recognition on the screenshot image to obtain diagnostic-related data contained in the screen content of the virtual machine instance.

[0127] The second root cause diagnosis unit 908 performs root cause diagnosis on the startup anomaly of the Guest OS on the virtual machine instance based on the diagnosis-related data.

[0128] Based on the same concept as the methods described above, this specification also provides an electronic device. For example, Figure 10 This is a schematic structural diagram of an electronic device provided in an exemplary embodiment. For example... Figure 10 As shown, the electronic device includes: a processor 1001; and a memory 1002 for storing executable instructions of the processor 1001; wherein the processor 1001 implements the steps of the method as described in any of the above embodiments by executing the executable instructions. For example, the electronic device can be as follows: Figure 1The physical host 20 is shown. Based on the executable instructions stored in the memory 1002, the processor 1001 can be implemented as a detection node as described above by running the executable instructions to determine whether the Guest OS on the virtual machine has experienced a startup abnormality, as well as other related functions as described above. For details, please refer to the various embodiments described above, which will not be repeated here.

[0129] Based on the same concept as the methods described above, this specification also provides a computer-readable storage medium having computer instructions stored thereon that, when executed by a processor, implement the steps of the methods as described in any of the above embodiments.

[0130] Based on the same concept as the methods described above, this specification also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the methods as described in any of the above embodiments.

Claims

1. A method for detecting Guest OS boot anomalies, characterized in that, The method includes: In response to the detection of a virtual machine instance startup event, the startup time of the virtual machine instance is recorded; If the virtual machine instance is running, determine whether the virtual machine instance successfully responded to the probe request issued by its host machine; If the predefined startup exception determination conditions are confirmed to be met, then the guest operating system on the virtual machine instance is determined to have a startup exception; wherein, the startup exception determination conditions include: the virtual machine instance has not successfully responded to the probe request within a preset time after the startup time, and the preset time is longer than the predefined guest OS startup time.

2. The method according to claim 1, characterized in that, Determining whether the virtual machine instance successfully responded to the probe request issued by its host machine includes: Send a probe command to the host machine where the virtual machine instance resides, instructing the host machine to initiate the probe request to the virtual machine instance; and receive a feedback message from the host machine, the feedback message indicating whether the virtual machine instance successfully responded to the probe request; or, The system receives a probe result sent by the host machine where the virtual machine instance resides. The probe result is generated by the host machine actively initiating the probe request to the virtual machine instance, and the probe result is used to indicate whether the virtual machine instance successfully responded to the probe request.

3. The method according to claim 2, characterized in that, Sending a probe command to the host machine where the virtual machine instance resides includes: In response to detecting the startup event of the virtual machine instance, the probe command is sent to the host machine where the virtual machine instance resides; or, In response to the detection of the startup event of the virtual machine instance, after waiting for the predefined Guest OS startup time, the probe command is sent to the host machine where the virtual machine instance is located.

4. The method according to any one of claims 1-3, characterized in that, The Guest OS is configured with a client agent, which is used to periodically send heartbeat messages when the Guest OS starts normally. The startup anomaly determination condition also includes: no heartbeat message is received from the client agent within a preset time after the startup time; If the predefined startup exception determination conditions are confirmed to be met, then the Guest OS on the virtual machine instance is determined to have a startup exception, including: If the virtual machine instance fails to respond to the probe request within a preset time after the startup time, and does not receive a heartbeat message from the client agent within the preset time after the startup time, the Guest OS startup is determined to be abnormal.

5. The method according to any one of claims 1-3, characterized in that, The method further includes: If the Guest OS on the virtual machine instance is found to be abnormal during startup, the system log generated by the virtual machine instance is obtained, and the system log contains diagnostic-related data. Based on the diagnostic data, a root cause diagnosis was performed on the Guest OS startup anomaly on the virtual machine instance.

6. The method according to claim 5, characterized in that, The process of obtaining the system logs generated by the Guest OS instance includes: Establish a connection with the log storage system and read the system logs from the log storage system; The system log is read from the virtual machine instance by the host machine of the virtual machine instance through a preset virtual serial port and then stored in the log storage system.

7. The method according to any one of claims 1-3, characterized in that, The method further includes: If the Guest OS on the virtual machine instance is found to be booting abnormally, connect to the host machine of the virtual machine instance; Access the screen content of the virtual machine instance through the virtual machine manager on the host machine, and capture the screen content of the virtual machine instance to obtain the corresponding screenshot image. Perform text recognition on the screenshot to obtain diagnostic-related data contained in the screen content of the virtual machine instance; Based on the diagnostic data, a root cause diagnosis was performed on the Guest OS startup anomaly on the virtual machine instance.

8. A detection system for Guest OS startup anomalies, characterized in that, The system includes: The host machine, which runs virtual machine instances; The detection node, in response to detecting a startup event of a virtual machine instance, records the startup time of the virtual machine instance; and, if the virtual machine instance is in a running state and it is confirmed that a predefined startup exception determination condition has been met, determines that the guest operating system instance on the virtual machine instance has a startup exception; wherein, the startup exception determination condition includes: the virtual machine instance has not successfully responded to the probe request issued by the host machine within a preset time after the startup time, and the preset time is longer than the predefined guest OS startup time.

9. The system according to claim 8, characterized in that, The host machine is used for: In response to the probe command sent by the detection node, the probe request is initiated to the virtual machine instance; a feedback message is returned to the detection node, the feedback message indicating whether the virtual machine instance has successfully responded to the probe request; or, The probe request is actively initiated to the virtual machine instance, and the probe result is sent to the detection node. The probe result is used to indicate whether the virtual machine instance has successfully responded to the probe request.

10. The system according to claim 9, characterized in that, The host machine is also used to: detect the startup event of the virtual machine instance; The active initiation of the probe request to the virtual machine instance includes: In response to detecting the startup event of the virtual machine instance, the probe request is actively initiated to the virtual machine instance; or, In response to the detection of the startup event of the virtual machine instance, after waiting for the predefined Guest OS startup time, the probe request is actively initiated to the virtual machine instance.

11. The system according to any one of claims 8-10, characterized in that, The host machine is further configured to: forward the heartbeat message to the detection node upon receiving a heartbeat message sent by the client agent configured on the Guest OS; wherein the client agent is configured to: periodically send heartbeat messages when the Guest OS is started normally; The startup anomaly determination condition also includes: no heartbeat message is received from the client agent within a preset time after the startup time; If the predefined startup exception determination conditions are confirmed to be met, the Guest OS startup exception on the virtual machine instance is determined to be abnormal, including: if the virtual machine instance fails to respond to the probe request within a preset time after the startup time, and does not receive a heartbeat message from the client agent within the preset time after the startup time, the Guest OS startup exception is determined to be abnormal.

12. An electronic device, characterized in that, include: processor; A memory for storing processor-executable instructions; wherein the processor implements the steps of the method as described in any one of claims 1-7 by executing the executable instructions.

13. A computer-readable storage medium, characterized in that, It stores computer instructions that, when executed by a processor, implement the steps of the method as described in any one of claims 1-7.

14. A computer program product, characterized in that, Includes a computer program / instructions that, when executed by a processor, implement the steps of the method as described in any one of claims 1 to 7.

Images