Virtual machine monitoring system and method

Abstract

The invention discloses a virtual machine monitoring system and method, and the system comprises a security measurement assembly which is used for monitoring at least one piece of state information of a currently running virtual machine: an abnormal state of task running, an abnormal state of interruption processing, heartbeat information or business state information; the monitoring control component is used for acquiring the state information reported by the security measurement component, and judging whether the currently running virtual machine needs to be switched according to the state information and a preset exception handling strategy; and the resource allocation component is used for allocating hardware equipment resources to the to-be-started virtual machine when the monitoring control component judges that the virtual machine needs to be switched. According to the technical scheme, the system failure time can be shortened, the available time and reliability of the system are improved, the timeliness and accuracy of switching of the main virtual machine and the standby virtual machine are improved, and the hardware cost of a user can be reduced.

Description

Technical Field

[0001] This application relates to the field of virtual machine monitor technology, specifically to a virtual machine monitoring system and method. Background Technology

[0002] A hypervisor is an intermediary software layer that runs between a physical computer system and the operating system software, allowing multiple operating systems and applications to share a single set of underlying physical hardware. A hypervisor can be viewed as a "meta" operating system within a virtual environment, coordinating and allocating access to all physical devices on the physical computer system for each virtual machine, including processors, memory, storage, and network devices.

[0003] Common high-availability system architectures primarily target cloud services and cluster services. A single node often integrates multiple virtual machines running business systems (such as database services, internet application services, and storage services) to provide a complete service. Nodes are typically located on different physical machines, or even in different locations, to avoid common-cause failures such as power outages and natural disasters. Monitoring channels are also usually configured as network channels with multiple routes to maintain communication redundancy.

[0004] Currently, high-availability system construction methods, when applied to critical business scenarios on the edge side such as automotive control, aircraft control, and industrial robots, have the following problems: 1. There is no time-constrained design; node service switching time varies with the configuration of cluster services, making it unsuitable for systems requiring time determinism; 2. There is no multi-layered monitoring design for the operating system and applications running on GVM, relying entirely on node heartbeat monitoring, resulting in coarse-grained monitoring; 3. The set of controllable devices for each virtual machine is basically the same, while the edge side does not have so many redundant devices, and the devices lack flexible partitioning and reuse configurations, making it difficult to guarantee smooth and uninterrupted critical business operations with simple master-slave switching methods; 4. The monitoring channel is only the network, and in a single Hypervisor scenario, no monitoring channel with lower latency is provided; 5. The monitoring and management modules are based on complex operating systems such as Windows and Linux, making it difficult to pass strict functional safety standard certifications. Summary of the Invention

[0005] In view of the above problems, this application is made in order to provide a virtual machine monitoring system and method that overcomes or at least partially solves the above problems.

[0006] According to one aspect of this application, a virtual machine monitoring system is provided, the virtual machine monitoring system comprising:

[0007] The security measurement component is used to monitor at least one of the following status information of the currently running virtual machine: abnormal status of task execution, abnormal status of interrupt handling, heartbeat information or business status information;

[0008] The monitoring and control component is used to obtain the status information reported by the security measurement component, and determine whether it is necessary to switch the currently running virtual machine based on the status information and the preset anomaly handling strategy.

[0009] The resource allocation component is used to allocate hardware resources to the standby virtual machine to be started when the monitoring and control component determines that a virtual machine needs to be switched.

[0010] In some implementations, the components within the security measurement component or the security measurement component communicate with the monitoring and control component via a shared memory channel.

[0011] In some implementations, the abnormal operational status of the task monitored by the security metric component includes at least one of the following:

[0012] Does the task scheduling delay exceed the threshold?

[0013] Whether the percentage of tasks completed within the preset period has reached the threshold;

[0014] Did the task exit abnormally?

[0015] The abnormal states of interrupt handling monitored by the security metric component include at least one of the following:

[0016] Does the operating system's interrupt handling delay exceed a threshold?

[0017] Does the interrupt handler's processing time exceed the threshold?

[0018] Has the number of interrupts processed within the preset period reached the threshold?

[0019] In some implementations, the logic monitored by the security metric component includes:

[0020] Configure a task list, threshold, and / or preset period in the virtual machine's configuration file, and register hook functions within the virtual machine's operating system; when the virtual machine is running, determine the abnormal state based on the call status of hook functions for different tasks in each functional module of the operating system, the threshold, and / or the preset period.

[0021] In some implementations, the processing steps for determining whether the task scheduling delay is less than a threshold include: when the hook function of an enabled task is detected to be called, determining whether the enabled task is a monitoring task; if so, recording the task enable time td1 in the monitoring task list; when the task switching hook function is called, determining whether the target task of the switch is a monitoring task; if so, recording the task scheduling time td2 and calculating the scheduling delay time td2-td1; determining whether the scheduling delay time is greater than a threshold; if it is greater than the threshold, reporting the scheduling delay timeout exception information to the monitoring and control component; if it is not greater than the threshold, not reporting.

[0022] The steps for determining whether the running share of a task within a preset period has reached the threshold include: starting a timer with a preset interval and recording the running time ts1 of each monitored task; when the timer expires, obtaining the running time slice ts2 of each monitored task again, and calculating the running share of each task within the period = ts2 - ts1; determining whether the running share of each task is less than the threshold; if it is less than the threshold, reporting the abnormal information of insufficient running share of the task to the monitoring and control component.

[0023] The steps for handling whether a task has exited abnormally include: when the task exit hook function is detected to be called, determine whether the exiting task is a critical task; if so, report the status information of the critical task's abnormal exit to the monitoring and control component.

[0024] In some implementations, the steps for determining whether the interrupt handling delay of the operating system exceeds a threshold include: when the interrupt shutdown hook function of the operating system interrupt shutdown function is called, recording the start time ti1; when the interrupt enable hook function of the operating system interrupt enable function is called, recording the end time ti2; calculating the interrupt shutdown time ti2-ti1; determining whether the interrupt shutdown time exceeds a threshold; and if it exceeds a threshold, reporting the interrupt delay timeout status information to the monitoring and control component.

[0025] The steps for determining whether the interrupt handler's processing time exceeds the threshold include: when the interrupt handler's entry hook function is called, determining whether to monitor the interrupt; if so, recording the interrupt handling start time tc1 in the monitored interrupt list; when the interrupt handler's exit hook function is called, determining whether to monitor the interrupt; if so, recording the interrupt handling end time tc2, and calculating the interrupt handling time = tc2 - tc1; determining whether the interrupt handling time is greater than the threshold; if so, reporting the interrupt handling timeout exception information to the monitoring and control component.

[0026] The steps for determining whether the number of interrupts processed within a preset period has reached the threshold include: starting a timer with a preset interval and recording the current count c1 of each monitored interrupt; when the timer expires, obtaining the current count c2 of each monitored interrupt and calculating the number of interrupts processed within the period = c2 - c1; determining whether the number of interrupts processed is less than the threshold, and if so, reporting an abnormal message that the number of critical interrupts processed within the preset period is insufficient to the monitoring and control component.

[0027] In some implementations, the pre-defined anomaly handling strategy in the monitoring and control component includes at least one of the following:

[0028] If task scheduling delay exceeds the threshold X times consecutively, switch virtual machines.

[0029] If any critical task exits abnormally, switch virtual machines;

[0030] If the critical interrupt handling time exceeds the threshold for Y consecutive times, switch virtual machines.

[0031] If the interrupt delay time exceeds the threshold for Z consecutive times, switch virtual machines.

[0032] Where X, Y, and Z are preset integer values.

[0033] In some implementations, the virtual machine includes a primary virtual machine and a standby virtual machine. When the primary virtual machine and the standby virtual machine are in a symmetrical mode and have the same device resources and capabilities, the processing steps of the monitoring and control component include:

[0034] S1, start the heartbeat timer;

[0035] S2, wait for the security measurement component to report status information and obtain heartbeat timer information;

[0036] S3, determine if there is a case of virtual machine heartbeat loss. If yes, proceed to S5; otherwise, proceed to S4.

[0037] S4, determine if any virtual machine security measurement component has reported abnormal information. If not, return to S2; otherwise, proceed to S5.

[0038] S5, determine whether a switch is needed based on the preset exception handling strategy; if not, record and report the exception information and return to S2; if yes, proceed to S6.

[0039] S6, determine whether the currently abnormal virtual machine is the primary virtual machine;

[0040] S7. Otherwise, the primary virtual machine continues to take over the business, restarts the standby virtual machine, and then records and reports the restart information; if yes, the standby virtual machine is made the primary virtual machine and takes over the business, while the original primary virtual machine is changed to the standby virtual machine and restarted, and then the restart information is recorded and reported.

[0041] In some implementations, the virtual machine includes a primary virtual machine and a standby virtual machine. When the primary virtual machine and the standby virtual machine are in an asymmetric mode, and the standby virtual machine receives fewer device resources and capabilities relative to the primary virtual machine, the processing steps of the monitoring and control component include:

[0042] S1, start the heartbeat timer;

[0043] S2, wait for the security measurement component to report status information and obtain heartbeat timer information;

[0044] S3, determine if there is a case of virtual machine heartbeat loss. If yes, proceed to S6; otherwise, proceed to the next step.

[0045] S4, determine if any virtual machine security measurement component has reported abnormal information. If not, return to S2; otherwise, proceed to S5.

[0046] S5, determine whether a switch is needed based on the preset exception handling strategy; otherwise, record and report the exception information and return to S2; otherwise, proceed to S6.

[0047] S6, determine if the currently abnormal virtual machine is the primary one; if not, the primary virtual machine continues to take over the business, restart the standby virtual machine, and record and report the restart information; if so, proceed to S7;

[0048] S7, the standby virtual machine takes over the service, restarts the primary virtual machine, and records and reports the restart information;

[0049] S8 determines whether the primary virtual machine has restarted successfully. If the restart is successful, the primary virtual machine will take over the business again and enter the next loop. If the restart is unsuccessful, return to S5.

[0050] According to another aspect of this application, a virtual machine monitoring method is provided, the virtual machine monitoring method comprising:

[0051] Monitor at least one of the following status information of the currently running virtual machine: abnormal status of task execution, abnormal status of interrupt handling, heartbeat information or business status information;

[0052] Obtain the status information, and determine whether to switch the currently running virtual machine based on the status information and the preset exception handling strategy;

[0053] When it is determined that a virtual machine needs to be switched, hardware resources are allocated to the virtual machine to be started, and the virtual machine takes over the tasks.

[0054] As can be seen from the above, the virtual machine monitoring system disclosed in this application can reduce system failure time, improve system availability and reliability, improve the timeliness and accuracy of primary and backup virtual machine switching, and also reduce users' hardware costs.

[0055] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0056] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0057] Figure 1 A schematic diagram of the structure of a virtual machine monitoring system according to some embodiments of this application is shown;

[0058] Figure 2 This invention illustrates a schematic diagram of the execution architecture of a virtual machine monitoring system according to some embodiments of this application;

[0059] Figure 3 A flowchart illustrating the monitoring of critical task scheduling delays according to some embodiments of this application is shown;

[0060] Figure 4 A flowchart illustrating the monitoring of the operational share of critical tasks within a preset period according to some embodiments of this application is shown.

[0061] Figure 5 A flowchart illustrating the abnormal exit of monitoring for a critical task according to some embodiments of this application is shown;

[0062] Figure 6 A schematic flowchart of monitoring interruption delay processing according to some embodiments of this application is shown;

[0063] Figure 7 A schematic flowchart illustrating timeout handling for monitoring critical interrupts according to some embodiments of this application is shown.

[0064] Figure 8 A flowchart illustrating the statistics of the number of critical interrupt processing within a preset period according to some embodiments of this application is shown;

[0065] Figure 9 A flowchart illustrating a process for determining whether to switch virtual machines using an exception handling strategy according to some embodiments of this application is shown.

[0066] Figure 10 A flowchart illustrating a process for determining whether to switch virtual machines using an exception handling strategy according to other embodiments of this application is shown.

[0067] Figure 11 A flowchart illustrating a virtual machine monitoring method according to some embodiments of this application is shown. Detailed Implementation

[0068] Exemplary embodiments of the present application will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present application are shown in the drawings, it should be understood that the present application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this application will be thorough and complete, and will fully convey the scope of the present application to those skilled in the art.

[0069] This application addresses the shortcomings of existing high-availability multi-virtual machine systems based on virtual machine monitors in critical business scenarios on the end side. It provides a high-availability virtual machine monitoring solution suitable for critical business scenarios. This virtual machine monitoring solution is based on a hypervisor that conforms to functional safety standards and provides monitoring and control components, resource allocation components, and at least some security measurement components running in virtual machines. It can build various high-availability software systems in different critical business scenarios, provide multiple master-slave failover modes, meet the time response latency requirements of critical businesses, reduce business downtime, and improve the reliability level of the system.

[0070] Figure 1 A schematic diagram of a virtual machine monitoring system according to an embodiment of this application is shown. The system includes:

[0071] The security measurement component 110 is used to monitor at least one of the following status information of the currently running virtual machine: abnormal status of task execution, abnormal status of interrupt handling, heartbeat information or business status information; it should be noted that the virtual machine generally includes a primary virtual machine and one or more standby virtual machines.

[0072] The monitoring and control component 120 is used to obtain the status information reported by the security measurement component, and determine whether it is necessary to switch the currently running virtual machine based on the status information and the preset anomaly handling strategy.

[0073] Resource allocation component 130 is used to allocate hardware resources to the standby virtual machine to be started when the monitoring and control component determines that the virtual machine needs to be switched.

[0074] In some alternative implementations, combined with Figure 2 The architecture diagram shown indicates that the security measurement component 110 can be set up inside a virtual machine; or it can be divided into multiple sub-components, set up inside the virtual machine and the monitor respectively; while the monitoring and control component and the resource allocation component are software components running in the monitor (Hypervisor).

[0075] In some embodiments, the components within the security measurement component communicate with each other, or the security measurement component communicates with the monitoring and control component, via a shared memory channel. Optionally, the shared memory channel needs to be modified and hardened to meet communication requirements.

[0076] According to the above embodiments, this application can achieve the following beneficial effects: by running at least part of the security measurement component within the virtual machine, the internal business status of the virtual machine can be monitored more timely, the risk of system failure can be reduced, and the system's secure availability time can be increased.

[0077] The monitoring content of the security measurement component is a general function of the operating system, which can be easily adapted to various types of operating systems without the need to specify the operating system, thus improving the convenience and versatility of this application.

[0078] This application uses a shared memory channel to replace the conventional Ethernet channel, ensuring the time determinism of monitoring, making it applicable to systems requiring real-time control, such as automotive control, aircraft control, and industrial robots.

[0079] The monitoring and control component of this application runs in a hypervisor that meets functional safety requirements and provides an anomaly policy customization mechanism. It can not only ensure that it meets functional safety requirements, but also be easily applied to control systems of different businesses, thereby improving the application scenarios with high availability.

[0080] In some embodiments, combined with Figure 2 As shown, in the overall high-availability virtual machine monitoring system architecture, the functions of each component include:

[0081] The resource allocation component in the monitor assigns devices to different virtual machines based on user configuration. Users can allocate appropriate sets of devices to primary and backup virtual machines through suitable configurations, ensuring that both virtual machines have sufficient devices to complete business operations. Device configuration information is passed to the virtual machine operating system in ways supported by the virtual machine operating system, such as virtual firmware and DTS flat device tree files. Simultaneously, the resource allocation component uses hardware features such as two-level address mapping to ensure the isolation of virtual machine access to devices; that is, a virtual machine can only use the devices assigned to it and cannot access devices that do not belong to it.

[0082] The monitoring and control component is responsible for monitoring the abnormal status of the primary virtual machine through the security measurement component. When the current virtual machine status is found to be abnormal and the switching threshold is reached, a switch is initiated, and other virtual machines are used to take over the business. At the same time, the abnormal virtual machine can also be restarted to test its availability and ensure that it can work smoothly when it is required to take over the business.

[0083] In some embodiments, the security measurement component is a software component running on a virtual machine, responsible for monitoring the operating system status of the virtual machine, and mainly includes:

[0084] The user can configure a list of critical tasks (including system tasks and application tasks) to be monitored, and the monitored task statuses include:

[0085] Is the task scheduling delay less than a preset threshold?

[0086] Within a preset period, whether the task's execution share reaches a preset threshold.

[0087] Monitor whether critical tasks exit abnormally.

[0088] The processing status of critical interrupts can be monitored. Users can configure a list of interrupts that need to be monitored. The processing status of the interrupts that can be monitored includes:

[0089] Whether the operating system's interrupt handling delay will fall below the set threshold can be indirectly monitored by monitoring the operating system's interrupt shutdown time.

[0090] Whether the interrupt handler for a critical interrupt has timed out.

[0091] Within the preset period, has the number of critical interrupts processed reached the set value?

[0092] Furthermore, it also includes using a shared memory channel to send information to the monitoring and control components of the Hypervisor. The messages sent include: heartbeat messages; status anomaly messages for monitored critical tasks or critical interruptions; and business status synchronization information.

[0093] It should be noted that the security measurement component runs at least partially on the user's virtual machine, and is responsible for monitoring the running status of the user's virtual machine's critical tasks and critical interrupts. At the same time, it reports heartbeat messages and abnormal statuses to the monitoring and control component in the Hypervisor. Business applications can also report business status information through the security measurement component's channel.

[0094] Compared to regular heartbeats, the Hypervisor, through its security metrics component, can more promptly grasp the operational status of critical tasks and critical interrupts, initiate error handling processes more quickly, reduce system downtime, and improve the overall availability of the system.

[0095] In some specific implementations, the security measurement component's processing flow for monitoring critical tasks includes:

[0096] The process for monitoring whether the scheduling delay of critical tasks is less than the threshold is as follows: Figure 3 As shown, the specific steps include: when the hook function of the enabled task is called, it is determined whether the enabled task is a monitoring task; if so, the task enable time td1 is recorded in the monitoring task list; when the task switching hook function is called, it is determined whether the target task of the switch is a monitoring task; if so, the task scheduling time td2 is recorded, and the scheduling delay time td2-td1 is calculated; it is determined whether the scheduling delay time is greater than the threshold. If it is greater than the threshold, the scheduling delay timeout exception information is reported to the monitoring and control component; if it is not greater than the threshold, no report is made.

[0097] There is no direct sequential call relationship between the task enable hook function and the task scheduling hook function; they have a logical dependency relationship. Figure 3 (This relationship is represented by dashed lines). That is, after a task enable hook function is called, it's not guaranteed that another task enable hook function will be called in the same context; the task enable hook function may be called in different contexts. However, for the same monitored task, the task enable hook function needs to be called first to record the time point td1 when the task is enabled (i.e., the task is set to runnable state, added to the scheduling queue, and waiting for the CPU). Then, the task scheduling hook function is called to record the time point td2 when the monitored task is scheduled to receive CPU time, thereby calculating the scheduling latency.

[0098] Combination Figure 4 As shown, the process of scheduling the share of critical monitoring tasks within a preset period includes the following steps: start a timer with a preset interval and record the running time ts1 of each monitoring task; when the timer expires, obtain the running time slice ts2 of each monitoring task again and calculate the running share of each task within the period = ts2 - ts1; determine whether the running share of each task is less than the threshold; if it is less than the threshold, report the abnormal information of insufficient task running share to the monitoring and control component.

[0099] It should be noted that the timer function and task execution time can be obtained from the virtual machine operating system.

[0100] The process for handling whether a critical task exits abnormally is as follows: Figure 5As shown, the steps include: when the task exit hook function is detected to be called, determine whether the exiting task is a critical task; if so, report the status information of the critical task's abnormal exit to the monitoring and control component.

[0101] It should be noted that, according to Figures 3-5 To enable the aforementioned monitoring functions during system runtime, it is necessary to pre-configure information such as critical tasks, thresholds, and preset cycles in the configuration file, and to pre-register or attach hook functions within the operating system. After the virtual machine starts, it reads the critical tasks, preset cycles, and thresholds from the configuration file and starts the monitoring function of the security measurement component.

[0102] It's important to note that after the operating system registers the task exit hook function, this hook function is not called within the context of the monitored task. Instead, it is called only when a task exits during system operation. Figure 5 This is indicated by a dashed line.

[0103] Other embodiments of this application also illustrate the processing flow of the security measurement component monitoring interruption latency:

[0104] The security metrics component monitors the interruption latency handling process as follows: Figure 6 As shown, the specific steps for determining whether the interrupt handling delay exceeds the threshold include: when the interrupt shutdown hook function of the operating system interrupt shutdown function is called, record the start time ti1; when the interrupt enable hook function of the operating system interrupt enable function is called, record the end time ti2, calculate the interrupt shutdown time ti2-ti1; determine whether the interrupt shutdown time exceeds the threshold, and if it exceeds the threshold, report the interrupt delay timeout status information to the monitoring and control component.

[0105] Among them, the hook function for interrupt enabling and disabling may have existing interfaces in open-source operating systems. If not, it can be added by modifying the source code. For closed-source operating systems, if no relevant interfaces are provided, we can check whether the closed-source operating system provides corresponding interrupt disabling time statistics or interrupt delay monitoring functions. If neither is provided, then interrupt delay monitoring of the operating system cannot be performed. From the perspective of time determinism in functional safety, the closed-source operating system is not very suitable for carrying critical business.

[0106] Figure 6 This is a processing flow based on the operating system's ability to hook functions for enabling and disabling interrupts. When interrupt delay monitoring is enabled, the program will not directly execute until the interrupt disabling hook function is called. Instead, it may be called in different contexts, triggered by other tasks, as the system runs; therefore, it is represented by dashed lines in the diagram.

[0107] Monitoring process for critical interrupt handling time, such as Figure 7 As shown, the steps for determining whether the interrupt handler's processing time exceeds the threshold include: when the interrupt handling entry hook function is called, determining whether to monitor the interrupt; if so, recording the interrupt handling start time tc1 in the monitored interrupt list; when the interrupt handling exit hook function is called, determining whether to monitor the interrupt; if so, recording the interrupt handling end time tc2, and calculating the interrupt handling time = tc2 - tc1; determining whether the interrupt handling time is greater than the threshold; if so, reporting the interrupt handling timeout exception information to the monitoring and control component.

[0108] Based on the operating system's ability to provide hooks for interrupt handling entry and exit points, open-source operating systems typically have readily available interfaces; if not, they can be added by modifying the source code. However, when interrupt timeout monitoring is enabled, the program will not directly execute the interrupt handling entry hook function. Instead, it will be called within the operating system's interrupt handling process as the system runs. Figure 7 The middle part is represented by a dashed line.

[0109] The process for handling the number of critical interrupts within the monitoring period is as follows: Figure 8 As shown, the processing steps for determining whether the number of interrupts processed within a preset period reaches the threshold include: starting a timer with a preset interval and recording the current count c1 of each monitored interrupt; when the timer expires, obtaining the current count c2 of each monitored interrupt and calculating the number of interrupts processed within the period = c2 - c1; determining whether the number of interrupts processed is less than the threshold, and if so, reporting an abnormal message that the number of critical interrupts processed within the preset period is insufficient to the monitoring and control component.

[0110] The timer function and interrupt count acquisition function shown in the process are provided by most operating systems.

[0111] According to other embodiments of this application, a processing flow for the monitoring and control component is also provided, see details below. Figure 9 and Figure 10 As shown. Among them, Figure 9 This approach is primarily suitable for situations where the primary and backup virtual machines have the same amount of device resources. Therefore, when one virtual machine malfunctions and needs to be switched over, the other virtual machine becomes the primary one and takes over the business without requiring manual switching back to the original virtual machine. Of course, this mode can also be applied to situations where device resources differ. Figure 10 This is generally applicable when the device resources of the primary virtual machine and the standby virtual machine are not equal. Once the primary virtual machine is restarted, the service needs to be switched back to the primary virtual machine, otherwise overload may occur.

[0112] Specific combination Figure 9 As shown, when the primary and backup virtual machines are in symmetric mode, the processing steps of the monitoring and control component include:

[0113] S1, start the heartbeat timer;

[0114] S2, wait for the security measurement component to report status information and obtain heartbeat timer information;

[0115] S3, determine if there is a case of virtual machine heartbeat loss. If yes, proceed to S5; otherwise, proceed to S4.

[0116] S4, determine if any virtual machine security measurement component has reported abnormal information. If not, return to S2; otherwise, proceed to S5.

[0117] S5, determine whether a switch is needed based on the preset exception handling strategy; if not, record and report the exception information and return to S2; if yes, proceed to S6.

[0118] S6, determine whether the currently abnormal virtual machine is the primary virtual machine;

[0119] S7. If not, the primary virtual machine takes over the service, restart the standby virtual machine, and then record and report the restart information; if yes, the standby virtual machine becomes the primary virtual machine and takes over the service, while the original primary virtual machine is changed to the standby virtual machine and restarted, and then the restart information is recorded and reported.

[0120] It should be noted that when the Hypervisor starts, it will start the primary and standby virtual machines according to the user configuration (the device resources of each virtual machine are configured in the virtual machine configuration file, and the device resource management component provides the function, which is also a basic function of all Hypervisors and a common industry technology). The monitoring and control component will use a high-speed shared memory channel (a high-speed shared memory channel between the Hypervisor and the virtual machine, and between virtual machines, is a function provided by most Hypervisors and is a common industry technology, which is not involved in the key technology points of this application, so this application will not describe it in detail) to establish a connection with the security measurement component in the virtual machine, monitor the status of the virtual machine, and when the status of the primary virtual machine is abnormal, it will perform error handling operations such as alarm, reporting, and switching to standby according to the user-configured policy.

[0121] Figure 9 In this context, exception handling strategies are primarily configured by end users based on business requirements. The following are some configurable exception strategies for reference:

[0122] If the critical task scheduling delay exceeds the threshold X times consecutively, the virtual machine needs to be restarted.

[0123] If any critical task exits abnormally, the virtual machine must be restarted.

[0124] If critical interrupt handling time exceeds the threshold for Y consecutive times, the virtual machine needs to be restarted.

[0125] If the interruption delay time exceeds the threshold for Z consecutive times, the virtual machine needs to be restarted.

[0126] exist Figure 9 In Mode 1, both the primary and standby virtual machines have the same device resource configurations and can execute identical business logic. The disadvantages are high system cost and high power consumption.

[0127] In other embodiments, the monitoring and control component also provides another control module in which the standby virtual machine is configured with fewer device resources to temporarily provide degraded services. Once the primary virtual machine recovers, it resumes providing services, and the standby virtual machine switches back to standby mode. Combined with... Figure 10 As shown, when the primary and backup virtual machines are in asymmetric mode, the processing steps of the monitoring and control component include:

[0128] S1, start the heartbeat timer;

[0129] S2, wait for the security measurement component to report status information and obtain heartbeat timer information;

[0130] S3, determine if there is a case of virtual machine heartbeat loss. If yes, proceed to S6; otherwise, proceed to the next step.

[0131] S4, determine if any virtual machine security measurement component has reported abnormal information. If not, return to S2; otherwise, proceed to S5.

[0132] S5, determine whether a switch is needed based on the preset exception handling strategy; otherwise, record and report the exception information and return to S2; otherwise, proceed to S6.

[0133] S6, determine if the currently abnormal virtual machine is the primary one; if not, the primary virtual machine takes over the service, restarts the standby virtual machine, and records and reports the restart information; if it is, proceed to S7.

[0134] S7, the standby virtual machine takes over the service, restarts the primary virtual machine, and records and reports the restart information;

[0135] S8 determines whether the primary virtual machine has restarted successfully. If the restart is successful, the primary virtual machine will take over the business again and enter the next loop. If the restart is unsuccessful, return to S5.

[0136] exist Figure 10 In this context, exception handling strategies are primarily configured by end users based on business requirements. Figure 9 The pattern is similar, and the configurable exception handling strategies are as follows:

[0137] If the critical task scheduling delay exceeds the threshold X times consecutively, the virtual machine needs to be restarted.

[0138] If any critical task exits abnormally, the virtual machine must be restarted.

[0139] If critical interrupt handling time exceeds the threshold for Y consecutive times, the virtual machine needs to be restarted.

[0140] If the interruption delay time exceeds the threshold for Z consecutive times, the virtual machine needs to be restarted.

[0141] Where X, Y, and Z take positive integer values.

[0142] Compared to Figure 9 The pattern Figure 10 Systems built using this model require lower costs and are more economical.

[0143] See Figure 11 As shown, this application also provides a virtual machine monitoring method, including the following steps:

[0144] Step S110: Monitor at least one of the following status information of the currently running virtual machine: abnormal status of task execution, abnormal status of interrupt handling, heartbeat information or business status information;

[0145] Step S120: Obtain the status information, and determine whether it is necessary to switch the currently running virtual machine based on the status information and the preset exception handling strategy;

[0146] Step S130: When it is determined that a virtual machine needs to be switched, hardware resources are allocated to the virtual machine to be started, and the standby virtual machine takes over the task.

[0147] According to the embodiments of this method, system failure time can be reduced, system availability and reliability can be improved, the timeliness and accuracy of primary and backup virtual machine switching can be improved, and the user's hardware costs can also be reduced.

[0148] It should be noted that the specific implementation methods of the above-described method embodiments can be referred to the specific implementation methods of the corresponding system embodiments described above, and will not be repeated here.

[0149] In summary, the embodiments of this application achieve the following features or beneficial effects:

[0150] Reduce system downtime and increase system uptime. For example, a typical Linux-based automotive intelligent driving system requires 3-10 seconds to return to normal operation after a hot reboot. However, the high-availability system built using this application can complete a master-slave hot switch in milliseconds, reducing system downtime from seconds to milliseconds.

[0151] Improve system reliability. The high-availability system constructed according to this application is equivalent to adding parallel nodes to the original functional chain. Assuming the failure probability of a single system is 0.01, after connecting two single systems in parallel to form a high-availability system, the failure probability of the high-availability system is 0.0001, and the system reliability is improved by 100 times.

[0152] Improve the timeliness and accuracy of master-slave failover. Conventionally, hypervisor-based high-availability systems use heartbeats for monitoring. When the hypervisor detects a lost heartbeat, the service in the virtual machine system has already been down for some time; conversely, the heartbeat may not be lost, but the service has already failed. The security measurement component provided in this application can monitor service failures more accurately and promptly, triggering master-slave failover in a timely manner and reducing the downtime of the high-availability system.

[0153] Improve system cost-effectiveness. Conventional methods typically require multiple physical machines, while the solution provided in this application allows for the construction of a highly available system on a single physical machine based on a hypervisor, reducing hardware costs for users.

[0154] It should be noted that:

[0155] The algorithms and displays provided herein are not inherently related to any particular computer, virtual device, or other equipment. Various general-purpose devices can also be used in conjunction with the teachings herein. The required structure for constructing such devices is apparent from the above description. Furthermore, this application is not directed to any particular programming language. It should be understood that the content of this application described herein can be implemented using various programming languages, and the above description of specific languages ​​is for the purpose of disclosing the best mode of implementation of this application.

[0156] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of this application may be practiced without these specific details. In some instances, well-known methods, structures, and techniques have not been shown in detail so as not to obscure the understanding of this specification.

[0157] Similarly, it should be understood that, in order to simplify this application and aid in understanding one or more aspects of the application, various features of this application are sometimes grouped together in a single embodiment, figure, or description thereof in the above description of exemplary embodiments of this application. However, this disclosure method should not be construed as reflecting an intention that the claimed application requires more features than are expressly recited in each claim.

[0158] Those skilled in the art will understand that modules in the device of the embodiments can be adaptively changed and placed in one or more devices different from that embodiment. Modules, units, or components in the embodiments can be combined into a single module, unit, or component, and further, they can be divided into multiple sub-modules, sub-units, or sub-components. Except where at least some of such features and / or processes or units are mutually exclusive, any combination can be used to combine all features disclosed in this specification (including the accompanying claims, abstract, and drawings) and all processes or units of any method or device so disclosed. Unless expressly stated otherwise, each feature disclosed in this specification (including the accompanying claims, abstract, and drawings) may be replaced by an alternative feature that serves the same, equivalent, or similar purpose.

[0159] Furthermore, those skilled in the art will understand that although some embodiments described herein include certain features included in other embodiments but not others, combinations of features from different embodiments are meant to be within the scope of this application and form different embodiments.

[0160] The various component embodiments of this application can be implemented in hardware, or as software modules running on one or more processors, or a combination thereof. Those skilled in the art will understand that microprocessors or digital signal processors (DSPs) can be used in practice to implement some or all of the functions of some or all of the components in the grid map building apparatus according to embodiments of this application. This application can also be implemented as a device or apparatus program (e.g., a computer program and computer program product) for performing part or all of the methods described herein. Such an implementation of this application can be stored on a computer-readable medium, or can be in the form of one or more signals. Such signals can be downloaded from an Internet website, provided on a carrier signal, or provided in any other form.

[0161] This application also provides a non-volatile computer storage medium storing at least one executable instruction that can execute the virtual machine monitoring method in any of the above method embodiments.

[0162] It should be noted that the above embodiments are illustrative of this application and not restrictive, and that those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. This application can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In the unit claims enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names.

Claims

1. A virtual machine monitoring system, characterized in that, The virtual machine monitoring system includes: The security measurement component is used to monitor at least one of the following status information of the currently running virtual machine: abnormal status of task execution, abnormal status of interrupt handling, heartbeat information or business status information; The monitoring and control component is used to obtain the status information reported by the security measurement component, and determine whether it is necessary to switch the currently running virtual machine based on the status information and the preset anomaly handling strategy. The resource allocation component is used to allocate hardware resources to the virtual machine to be started when the monitoring and control component determines that the virtual machine needs to be switched.

2. The virtual machine monitoring system according to claim 1, characterized in that, The components within the security measurement component communicate with each other or with the monitoring and control component via a shared memory channel.

3. The virtual machine monitoring system according to claim 1, characterized in that, The abnormal running status of the task monitored by the security metric component includes at least one of the following: Does the task scheduling delay exceed the threshold? Whether the percentage of tasks completed within the preset period has reached the threshold; Did the task exit abnormally? The abnormal states of interrupt handling monitored by the security metric component include at least one of the following: Does the operating system's interrupt handling delay exceed a threshold? Does the interrupt handler's processing time exceed the threshold? Has the number of interrupts processed within the preset period reached the threshold? 4. The virtual machine monitoring system according to claim 3, characterized in that, The security metric component monitors the following logic: Configure a task list, threshold, and / or preset period in the virtual machine's configuration file, and register hook functions within the virtual machine's operating system; when the virtual machine is running, determine the abnormal state based on the call status of hook functions for different tasks in each functional module of the operating system, the threshold, and / or the preset period.

5. The virtual machine monitoring system according to claim 3 or 4, characterized in that, The steps for determining whether the task scheduling delay is less than the threshold include: when the hook function of an enabled task is called, determine whether the enabled task is a monitoring task; if so, record the task enable time td1 in the monitoring task list; when the task switching hook function is called, determine whether the target task of the switch is a monitoring task; if so, record the task scheduling time td2 and calculate the scheduling delay time td2-td1; determine whether the scheduling delay time is greater than the threshold; if it is greater than the threshold, report the scheduling delay timeout exception information to the monitoring and control component; if it is not greater than the threshold, do not report it. The steps for determining whether the running share of a task within a preset period has reached the threshold include: starting a timer with a preset interval and recording the running time ts1 of each monitored task; when the timer expires, obtaining the running time slice ts2 of each monitored task again, and calculating the running share of each task within the period = ts2 - ts1; determining whether the running share of each task is less than the threshold; if it is less than the threshold, reporting the abnormal information of insufficient running share of the task to the monitoring and control component. The steps for handling whether a task has exited abnormally include: when the task exit hook function is detected to be called, determine whether the exiting task is a critical task; if so, report the status information of the critical task's abnormal exit to the monitoring and control component.

6. The virtual machine monitoring system according to claim 3 or 4, characterized in that, The steps for determining whether the interrupt handling delay of the operating system exceeds the threshold include: when the interrupt shutdown hook function of the operating system interrupt shutdown function is called, record the start time ti1; when the interrupt enable hook function of the operating system interrupt enable function is called, record the end time ti2, calculate the interrupt shutdown time ti2-ti1; determine whether the interrupt shutdown time exceeds the threshold, and if it exceeds the threshold, report the interrupt delay timeout status information to the monitoring and control component. The steps for determining whether the interrupt handler's processing time exceeds the threshold include: when the interrupt handler's entry hook function is called, determining whether to monitor the interrupt; if so, recording the interrupt handling start time tc1 in the monitored interrupt list; when the interrupt handler's exit hook function is called, determining whether to monitor the interrupt; if so, recording the interrupt handling end time tc2, and calculating the interrupt handling time = tc2 - tc1; determining whether the interrupt handling time is greater than the threshold; if so, reporting the interrupt handling timeout exception information to the monitoring and control component. The steps for determining whether the number of interrupts processed within a preset period has reached the threshold include: starting a timer with a preset interval and recording the current count c1 of each monitored interrupt; when the timer expires, obtaining the current count c2 of each monitored interrupt and calculating the number of interrupts processed within the period = c2 - c1; determining whether the number of interrupts processed is less than the threshold, and if so, reporting an abnormal message that the number of critical interrupts processed within the preset period is insufficient to the monitoring and control component.

7. The virtual machine monitoring system according to any one of claims 1-4, characterized in that, The pre-defined anomaly handling strategies in the monitoring and control components include at least one of the following: If task scheduling delay exceeds the threshold X times consecutively, switch virtual machines. If any critical task exits abnormally, switch virtual machines; If the critical interrupt handling time exceeds the threshold for Y consecutive times, switch virtual machines. If the interrupt delay time exceeds the threshold for Z consecutive times, switch virtual machines. Where X, Y, and Z are preset integer values.

8. The virtual machine monitoring system according to any one of claims 1-4, characterized in that, The virtual machines include a primary virtual machine and a standby virtual machine. When the primary virtual machine and the standby virtual machine are in symmetrical mode and have the same device resources and capabilities, the processing steps of the monitoring and control component include: S1, start the heartbeat timer; S2, wait for the security measurement component to report status information and obtain heartbeat timer information; S3, determine if there is a case of virtual machine heartbeat loss. If yes, proceed to S5; otherwise, proceed to S4. S4, determine if any virtual machine security measurement component has reported abnormal information. If not, return to S2; otherwise, proceed to S5. S5, determine whether a switch is needed based on the preset exception handling strategy; if not, record and report the exception information and return to S2; if yes, proceed to S6. S6, determine whether the currently abnormal virtual machine is the primary virtual machine; S7. Otherwise, the primary virtual machine continues to take over the business, restarts the standby virtual machine, and then records and reports the restart information; if so, the standby virtual machine is made into the primary virtual machine and takes over the business, while the original primary virtual machine is changed to the standby virtual machine and restarted, and then the restart information is recorded and reported.

9. The virtual machine monitoring system according to any one of claims 1-4, characterized in that, The virtual machines include a primary virtual machine and a standby virtual machine. When the primary virtual machine and the standby virtual machine are in an asymmetric mode, and the standby virtual machine receives fewer device resources and capabilities compared to the primary virtual machine, the processing steps of the monitoring and control component include: S1, start the heartbeat timer; S2, wait for the security measurement component to report status information and obtain heartbeat timer information; S3, determine if there is a case of virtual machine heartbeat loss. If yes, proceed to S6; otherwise, proceed to the next step. S4, determine if any virtual machine security measurement component has reported abnormal information. If not, return to S2; otherwise, proceed to S5. S5, determine whether a switch is needed based on the preset exception handling strategy; otherwise, record and report the exception information and return to S2; otherwise, proceed to S6. S6, determine if the currently abnormal virtual machine is the primary one; if not, the primary virtual machine continues to take over the business, restart the standby virtual machine, and record and report the restart information; if it is, proceed to S7. S7, the standby virtual machine takes over the service, restarts the primary virtual machine, and records and reports the restart information; S8 determines whether the primary virtual machine has restarted successfully. If the restart is successful, the primary virtual machine will take over the business again and enter the next loop. If the restart is unsuccessful, return to S5.

10. A virtual machine monitoring method, characterized in that, The virtual machine monitoring method includes: Monitor at least one of the following status information of the currently running virtual machine: abnormal status of task execution, abnormal status of interrupt handling, heartbeat information or business status information; Obtain the status information, and determine whether to switch the currently running virtual machine based on the status information and the preset exception handling strategy; When it is determined that a virtual machine needs to be switched, hardware resources are allocated to the virtual machine to be started, and the virtual machine takes over the tasks.

Images