Method and apparatus for virtualization platform lifecycle monitoring

Abstract

The application provides a virtualization platform life cycle monitoring method and device, the virtualization platform includes a virtual machine, the life cycle state of the virtual machine is acquired, and a state conversion process between the life cycle states is acquired, the state conversion process includes one of starting state conversion to a running state, running state conversion to an exit state, exit state conversion to a starting state, conversion between the running state and a hibernation state, and fault state conversion to the exit state. Then, the virtual machine is monitored according to the state conversion process and a test library. The method solves the problems of state conversion exceptions, state conversion failures and initial configuration errors in the whole life cycle, can make up for the lack of effective monitoring of unexpected state conversion of the Hypervisor of the ASILD level meeting the functional safety, can improve the diagnosis rate of random hardware failure and the robustness of state migration in the life cycle state conversion, and greatly reduces the dependence on hardware safety.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of virtualization, and in particular to a virtualization platform life cycle monitoring method and device. BACKGROUND

[0002] To meet the scene fusion requirements of the increasingly centralized automotive E / E architecture computing platform, the computing platform is designed with virtualization capabilities for safety, reliability, high performance, and low loss, and the software and hardware (CPU, memory, storage devices, etc.) resources are isolated and flexibly arranged and shared for scene applications, which improves resource utilization and operating efficiency while supporting the coexistence of multiple scene application ecologies.

[0003] In view of this, the Hypervisor (virtualization) adopts a high reliability and security framework design to provide functional safety capability support for virtualization ecological software, which can guarantee the functional safety of the vehicle.

[0004] Virtual Machine (VM) life cycle management is the most basic function of virtualization, and its function itself runs through the entire virtualization life cycle. Therefore, on the basis of meeting the basic functions, it is necessary to develop a configuration and monitoring function with high safety and high robustness. SUMMARY

[0005] The present application provides a virtualization platform life cycle monitoring method and device to monitor the life cycle of the function state of the virtual machine.

[0006] In a first aspect, the present application provides a virtualization platform life cycle monitoring method, the virtualization platform comprising a virtual machine, the method comprising:

[0007] obtaining a life cycle state of the virtual machine, the life cycle state comprising a start state of the virtual machine, a running state of the virtual machine, a quit state of the virtual machine, and a hibernation state of the virtual machine and a fault state of the virtual machine;

[0008] obtaining a state transition process between the life cycle states, the state transition process comprising one of the start state transitioning to the running state, the running state transitioning to the quit state, the quit state transitioning to the start state, the running state and the hibernation state transitioning, and the fault state transitioning to the quit state;

[0009] monitoring the life cycle of the virtual machine according to the state transition process and a test library, the test library comprising fault injection testing and online testing.

[0010] In a possible design, if the state transition process is the transition from the starting state to the running state, the lifecycle monitoring of the virtual machine according to the state transition process and the test library comprises the following steps.

[0011] configuring the virtual machine according to the configuration instruction, and obtaining a first time point, which is a configuration start time point;

[0012] powering on the self-check of the virtual machine after the configuration, and obtaining state data after the self-check according to the self-check item of the virtual machine;

[0013] if it is determined that the self-check of the virtual machine is passed according to the state data, making the virtual machine enter the starting state in response to a starting instruction, and obtaining a second time point and a third time point, wherein the second time point and the third time point are respectively an end time point of the self-check and a start time point of the starting state;

[0014] performing the fault injection test and the online test on the virtual machine in the starting state, and making the virtual machine enter the fault state when the virtual machine detects an exception;

[0015] if it is determined that the transition of the virtual machine from the starting state to the running state meets a first transition condition, making the virtual machine enter the running state in response to a first transition instruction, and obtaining a fourth time point, which is an end time point of the starting state;

[0016] monitoring the lifecycle of the virtual machine according to the first time point, the second time point, the third time point and the fourth time point.

[0017] In a possible design, the lifecycle monitoring of the virtual machine according to the third time point and the fourth time point comprises the following steps.

[0018] if it is determined that a time difference between the fourth time point and the third time point is less than or equal to a second preset time length, ending the lifecycle monitoring of the virtual machine from the starting state to the running state.

[0019] In a possible design, if it is determined that the time difference between the fourth time point and the third time point is greater than the second preset time length, the virtual machine is controlled to enter the fault state.

[0020] In a possible design, the method further comprises the following steps.

[0021] if it is determined that a time difference between the second time point and the first time point is less than or equal to a first preset time length, ending the lifecycle monitoring of the virtual machine in the configuration stage;

[0022] If it is determined that the time difference between the second time and the first time is greater than the first preset time length, the virtual machine is controlled to enter a safe state.

[0023] In a possible design, if the state transition process is from the running state to the exit state, the lifecycle monitoring of the virtual machine according to the state transition process and the test library comprises:

[0024] obtaining a start time of the virtual machine entering the running state;

[0025] performing the fault injection test and the online test on the virtual machine entering the running state, and entering the fault state when the virtual machine detects an exception;

[0026] If it is determined that the virtual machine that has entered the fault state meets a second transition condition when transitioning from the running state to the exit state, the virtual machine is caused to enter the exit state in response to a second transition instruction, and an end time of the running state is obtained.

[0027] If it is determined that the time difference between the end time of the running state and the start time of the running state is less than or equal to a third preset time length, the lifecycle monitoring of the virtual machine transitioning from the running state to the exit state is ended.

[0028] In a possible design, if it is determined that the time difference between the end time of the running state and the start time of the running state is greater than the third preset time length, the virtual machine is controlled to enter the fault state.

[0029] In a possible design, if the state transition process is from the exit state to the start state, the lifecycle monitoring of the virtual machine according to the state transition process and the test library comprises:

[0030] obtaining a start time of the virtual machine entering the exit state;

[0031] performing the fault injection test and the online test on the virtual machine entering the exit state, and entering the fault state when the virtual machine detects an exception;

[0032] If it is determined that the virtual machine that has entered the fault state meets a third transition condition when transitioning from the exit state to the start state, the virtual machine is caused to enter the start state in response to a third transition instruction, and an end time of the exit state is obtained.

[0033] If it is determined that a time difference between an ending moment of the exiting state and a starting moment of the exiting state is less than or equal to a fourth preset time length, the life cycle monitoring of the virtual machine from the exiting state to the starting state is ended.

[0034] In a possible design, if it is determined that the time difference between the ending moment of the exiting state and the starting moment of the exiting state is greater than the fourth preset time length, the virtual machine is controlled to enter the fault state.

[0035] In a possible design, if the state transition process is from the running state to the hibernation state, the life cycle monitoring of the virtual machine according to the state transition process and the test library comprises:

[0036] an ending moment of the running state is obtained;

[0037] the fault injection test and the online test are performed on the virtual machine in the running state, and the virtual machine enters the fault state when detecting an exception;

[0038] If it is determined that the virtual machine in the fault state is transitioned from the running state to the hibernation state and satisfies a fourth transition condition, the virtual machine is caused to enter the hibernation state in response to a fourth transition instruction, and an ending moment of the running state is obtained.

[0039] If it is determined that a time difference between the ending moment of the running state and the starting moment of the running state is less than or equal to a fifth preset time length, the life cycle monitoring of the virtual machine from the running state to the hibernation state is ended.

[0040] In a possible design, if it is determined that the time difference between the ending moment of the running state and the starting moment of the running state is greater than the fifth preset time length, the virtual machine is controlled to enter the fault state.

[0041] In a possible design, if the state transition process is from the hibernation state to the running state, the life cycle monitoring of the virtual machine according to the state transition process and the test library comprises:

[0042] an ending moment of the hibernation state is obtained;

[0043] the fault injection test and the online test are performed on the virtual machine in the hibernation state, and the virtual machine enters the fault state when detecting an exception;

[0044] if it is determined that the virtual machine that has entered the fault state is converted from the hibernation state to the running state meets a fifth conversion condition, making the virtual machine enter the running state in response to a fifth conversion instruction, and obtaining an ending time of the hibernation state;

[0045] if it is determined that a time difference between the ending time of the hibernation state and a starting time of the hibernation state is less than or equal to a sixth preset time length, ending the life cycle monitoring of the virtual machine converted from the hibernation state to the running state.

[0046] In a possible design, if it is determined that the time difference between the ending time of the hibernation state and the starting time of the hibernation state is greater than the sixth preset time length, the virtual machine is controlled to enter the fault state.

[0047] In a possible design, if the state conversion process is the conversion of the fault state to the exit state, the life cycle monitoring of the virtual machine according to the state conversion process and the test library comprises:

[0048] obtaining a starting time of the virtual machine entering the fault state;

[0049] performing the fault injection test and the online test on the virtual machine entering the fault state, to trigger the virtual machine to reset external hardware;

[0050] if it is determined that the virtual machine that has reset the external hardware is converted from the fault state to the exit state meets a sixth conversion condition, making the virtual machine enter the exit state in response to a sixth conversion instruction, and obtaining an ending time of the fault state;

[0051] if it is determined that a time difference between the ending time of the fault state and a starting time of the fault state is less than or equal to a seventh preset time length, ending the life cycle monitoring of the virtual machine converted from the fault state to the exit state.

[0052] In a possible design, if it is determined that the time difference between the ending time of the fault state and the starting time of the fault state is greater than the seventh preset time length, the virtual machine is controlled to enter the fault state.

[0053] In a possible design, the method further comprises: arbitrating to monitor the life cycle of the virtual machine.

[0054] In a possible design, the arbitrating to monitor the life cycle of the virtual machine comprises:

[0055] acquire a previous lifecycle state and a next lifecycle state of a current lifecycle state of the virtual machine and a historical transition condition, the historical transition condition being a transition condition when the previous lifecycle state transitions to the next lifecycle state;

[0056] if it is determined that the historical transition condition is correct and that the program does not exist in a dead loop running, determine whether the program exists in a program running failure, the program running failure including an abnormal interruption phenomenon or an abnormal exit phenomenon;

[0057] if no, and it is determined that the previous lifecycle state is normally ended and the next lifecycle state is normally started, end the lifecycle monitoring of the virtual machine when the program running fails.

[0058] In a possible design, if it is determined that one of the historical transition condition is incorrect, the program exists in a dead loop running, the program exists in the program running failure, the previous lifecycle state is not normally ended, or the next lifecycle state is not normally started, a fault instruction is generated, and the virtual machine enters the fault state in response to the fault instruction.

[0059] In a possible design, the method further includes:

[0060] acquire a fault source of the virtual machine entering the fault state after detecting an exception;

[0061] restart the external hardware according to the fault source, so that the virtual machine enters a safe working state according to an application scenario.

[0062] In a second aspect, the present application provides a virtualization platform lifecycle monitoring apparatus, the virtualization platform including a virtual machine, and the apparatus including:

[0063] a first acquiring module configured to acquire a lifecycle state of the virtual machine, the lifecycle state including a starting state of the virtual machine, a running state of the virtual machine, an exiting state of the virtual machine, a hibernating state of the virtual machine, and a fault state of the virtual machine;

[0064] a second acquiring module configured to acquire a state transition process between the lifecycle states, the state transition process including one of the starting state transitioning to the running state, the running state transitioning to the exiting state, the exiting state transitioning to the starting state, the running state and the hibernating state transitioning, and the fault state transitioning to the exiting state;

[0065] a monitoring module configured to perform lifecycle monitoring on the virtual machine according to the state transition process and a test library, the test library including fault injection testing and online testing.

[0066] In a possible design, if the state transition process is the transition from the starting state to the running state, the monitoring module is specifically configured to:

[0067] configure the virtual machine in response to a configuration instruction, and obtain a first time point, which is a time point when the configuration starts;

[0068] power on the virtual machine that has completed the configuration, and obtain state data after self-checking according to a self-checking item of the virtual machine;

[0069] if it is determined that the self-checking of the virtual machine is passed according to the state data, make the virtual machine enter the starting state in response to a starting instruction, and obtain a second time point and a third time point, the second time point and the third time point are respectively an end time point of the self-checking and a start time point of the starting state;

[0070] perform the fault injection test and the online test on the virtual machine that enters the starting state, and make the virtual machine enter the fault state when the virtual machine detects an exception;

[0071] if it is determined that the transition of the virtual machine that has entered the fault state from the starting state to the running state meets a first transition condition, make the virtual machine enter the running state in response to a first transition instruction, and obtain a fourth time point, which is an end time point of the starting state;

[0072] perform life cycle monitoring on the virtual machine according to the first time point, the second time point, the third time point and the fourth time point.

[0073] In a possible design, the monitoring module is further configured to:

[0074] if it is determined that a time difference between the fourth time point and the third time point is less than or equal to a second preset time length, end the life cycle monitoring on the transition of the virtual machine from the starting state to the running state.

[0075] In a possible design, if it is determined that the time difference between the fourth time point and the third time point is greater than the second preset time length, the monitoring module is further configured to: control the virtual machine to enter the fault state.

[0076] In a possible design, the monitoring module is further configured to:

[0077] if it is determined that a time difference between the second time point and the first time point is less than or equal to a first preset time length, end the life cycle monitoring on the configuration phase of the virtual machine;

[0078] If it is determined that a time difference between the second time and the first time is greater than the first preset time length, the virtual machine is controlled to enter a safe state.

[0079] In a possible design, if the state transition process is from the running state to the exit state, the monitoring module is specifically configured to:

[0080] obtain a start time of the virtual machine entering the running state;

[0081] perform the fault injection test and the online test on the virtual machine entering the running state, and enter the fault state when the virtual machine detects an exception;

[0082] If it is determined that the virtual machine that has entered the fault state meets a second transition condition when transitioning from the running state to the exit state, the virtual machine is caused to enter the exit state in response to a second transition instruction, and an end time of the running state is obtained.

[0083] If it is determined that a time difference between the end time of the running state and the start time of the running state is less than or equal to a third preset time length, the lifecycle monitoring of the virtual machine transitioning from the running state to the exit state is ended.

[0084] In a possible design, if it is determined that the time difference between the end time of the running state and the start time of the running state is greater than the third preset time length, the monitoring module is further configured to control the virtual machine to enter the fault state.

[0085] In a possible design, if the state transition process is from the exit state to the start state, the monitoring module is specifically configured to:

[0086] obtain a start time of the virtual machine entering the exit state;

[0087] perform the fault injection test and the online test on the virtual machine entering the exit state, and enter the fault state when the virtual machine detects an exception;

[0088] If it is determined that the virtual machine that has entered the fault state meets a third transition condition when transitioning from the exit state to the start state, the virtual machine is caused to enter the start state in response to a third transition instruction, and an end time of the exit state is obtained.

[0089] If it is determined that a time difference between the end time of the exit state and the start time of the exit state is less than or equal to a fourth preset time length, the lifecycle monitoring of the virtual machine transitioning from the exit state to the start state is ended.

[0090] In a possible design, if it is determined that a time difference between the end moment of the exiting state and the start moment of the exiting state is greater than a fourth preset time length, the monitoring module is further configured to control the virtual machine to enter the fault state.

[0091] In a possible design, if the state transition process is from the running state to the hibernation state, the monitoring module is specifically configured to:

[0092] obtain a start moment of the virtual machine entering the running state;

[0093] perform the fault injection test and the online test on the virtual machine entering the running state, and enter the fault state when the virtual machine detects an exception;

[0094] if it is determined that the virtual machine that has entered the fault state meets a fourth transition condition when transitioning from the running state to the hibernation state, make the virtual machine enter the hibernation state in response to a fourth transition instruction, and obtain an end moment of the running state;

[0095] if it is determined that a time difference between the end moment of the running state and the start moment of the running state is less than or equal to a fifth preset time length, end the life cycle monitoring of the virtual machine transitioning from the running state to the hibernation state.

[0096] In a possible design, if it is determined that a time difference between the end moment of the running state and the start moment of the running state is greater than a fifth preset time length, the monitoring apparatus is further configured to control the virtual machine to enter the fault state.

[0097] In a possible design, if the state transition process is from the hibernation state to the running state, the monitoring apparatus is further configured to:

[0098] obtain a start moment of the virtual machine entering the hibernation state;

[0099] perform the fault injection test and the online test on the virtual machine entering the hibernation state, and enter the fault state when the virtual machine detects an exception;

[0100] if it is determined that the virtual machine that has entered the fault state meets a fifth transition condition when transitioning from the hibernation state to the running state, make the virtual machine enter the running state in response to a fifth transition instruction, and obtain an end moment of the hibernation state;

[0101] If it is determined that a time difference between the end time of the hibernation state and the start time of the hibernation state is less than or equal to a sixth preset time length, the life cycle monitoring of the transition of the virtual machine from the hibernation state to the running state is ended.

[0102] In a possible design, if it is determined that a time difference between the end time of the hibernation state and the start time of the hibernation state is greater than the sixth preset time length, the monitoring apparatus is further configured to: control the virtual machine to enter the fault state.

[0103] In a possible design, if the state transition process is the transition from the fault state to the exit state, the monitoring module is further configured to:

[0104] obtain a start time when the virtual machine enters the fault state;

[0105] perform the fault injection test and the online test on the virtual machine in the fault state, so as to trigger the virtual machine to reset the external hardware;

[0106] If it is determined that the transition of the virtual machine from the fault state to the exit state, in which the external hardware has been reset, satisfies a sixth transition condition, the virtual machine is caused to enter the exit state in response to a sixth transition instruction, and an end time of the fault state is obtained.

[0107] If it is determined that a time difference between the end time of the fault state and the start time of the fault state is less than or equal to a seventh preset time length, the life cycle monitoring of the transition of the virtual machine from the fault state to the exit state is ended.

[0108] In a possible design, if it is determined that a time difference between the end time of the fault state and the start time of the fault state is greater than the seventh preset time length, the monitoring module is further configured to: control the virtual machine to enter the fault state.

[0109] In a possible design, if the virtual machine program fails to run, the apparatus further includes:

[0110] an arbitration module configured to: arbitrate and determine the life cycle monitoring of the virtual machine.

[0111] In a possible design, the arbitration module is specifically configured to:

[0112] obtain a previous life cycle state and a next life cycle state of a current life cycle state of the virtual machine, and a historical transition condition, the historical transition condition being a transition condition when the previous life cycle state is transitioned to the next life cycle state;

[0113] If it is determined that the historical transition condition is correct and that the program does not exist in a dead loop running, it is determined whether the program exists in a program running failure, the program running failure including an abnormal interruption phenomenon or an abnormal exit phenomenon;

[0114] If no, and it is determined that the previous life cycle state is normally ended and the next life cycle state is normally started, the life cycle monitoring of the virtual machine in the program running failure is ended.

[0115] In a possible design, if it is determined that one of the historical transition condition is incorrect, the program exists in a dead loop running, the program exists in the program running failure, the previous life cycle state is not normally ended or the next life cycle state is not normally started, the arbitration module is further configured to:

[0116] generate a failure instruction, and make the virtual machine enter the failure state in response to the failure instruction.

[0117] In a possible design, the apparatus further includes a restart module, and the restart module is configured to:

[0118] acquire a failure source when the virtual machine enters the failure state after detecting an exception;

[0119] restart the external hardware according to the failure source, so that the virtual machine enters a safe working state according to an application scenario.

[0120] In a third aspect, the present application provides an electronic device, including a processor and a memory connected with the processor in communication;

[0121] The memory stores computer execution instructions.

[0122] The processor executes the computer execution instructions stored in the memory, so as to realize any one of the possible virtualization platform life cycle monitoring methods provided in the first aspect.

[0123] In a fourth aspect, the present application provides a computer readable storage medium, and the computer readable storage medium stores computer execution instructions, the computer execution instructions are executed by a processor to realize any one of the possible virtualization platform life cycle monitoring methods provided in the first aspect.

[0124] In a fifth aspect, the present application provides a computer program product, including computer execution instructions, the computer execution instructions are executed by a processor to realize any one of the possible virtualization platform life cycle monitoring methods provided in the first aspect.

[0125] The application provides a virtualization platform life cycle monitoring method and device, which comprises a virtual machine. Firstly, a life cycle state of the virtual machine is acquired, and the life cycle state comprises a start state of the virtual machine, a running state of the virtual machine, an exit state of the virtual machine, a hibernation state of the virtual machine and a fault state of the virtual machine. Then, a state transition process between the life cycle states is acquired, wherein the state transition process comprises one of the start state transitioning to the running state, the running state transitioning to the exit state, the exit state transitioning to the start state, the running state and the hibernation state transitioning, and the fault state transitioning to the exit state. The virtual machine is monitored according to the state transition process and a test library, and the test library comprises fault injection testing and online testing. The function state management in the life cycle of the virtual machine can be monitored, the state transition abnormality, the state transition failure and the initial configuration error problem in the whole life cycle can be solved, the present situation that the effective life cycle state unexpected transition monitoring is lacked by the Hypervisor meeting the ASILD level of the function safety can be made up, in addition, the diagnosis rate of the random hardware failure existing in the life cycle state transition and the robustness of the state migration can be improved, and the dependence on the hardware safety can be greatly reduced compared with the related art. BRIEF DESCRIPTION OF DRAWINGS

[0126] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the drawings needed to be used in the embodiments or the prior art description will be briefly introduced. Obviously, the drawings in the following description are some embodiments of the present application, and other drawings can be obtained by those skilled in the art without any creative labor.

[0127] Figure 1 An application scenario schematic diagram provided for the embodiments of the present application;

[0128] Figure 2 A flowchart of a virtualization platform life cycle monitoring method provided for the embodiments of the present application;

[0129] Figure 3 A state transition process schematic diagram of a life cycle state provided for the embodiments of the present application;

[0130] Figure 4 A flowchart of another virtualization platform life cycle monitoring method provided for the embodiments of the present application;

[0131] Figure 5 A flowchart of still another virtualization platform life cycle monitoring method provided for the embodiments of the present application;

[0132] Figure 6A flowchart of another virtualization platform lifecycle monitoring method provided by an embodiment of the present application is shown in FIG. 6;

[0133] Figure 7 A flowchart of another virtualization platform lifecycle monitoring method provided by an embodiment of the present application is shown in FIG. 6;

[0134] Figure 8 A flowchart of another virtualization platform lifecycle monitoring method provided by an embodiment of the present application is shown in FIG. 6;

[0135] Figure 9 A flowchart of another virtualization platform lifecycle monitoring method provided by an embodiment of the present application is shown in FIG. 6;

[0136] Figure 10 A flowchart of another virtualization platform lifecycle monitoring method provided by an embodiment of the present application is shown in FIG. 6;

[0137] Figure 11 A flowchart of another virtualization platform lifecycle monitoring method provided by an embodiment of the present application is shown in FIG. 6;

[0138] Figure 12 A flowchart of another virtualization platform lifecycle monitoring method provided by an embodiment of the present application is shown in FIG. 6;

[0139] Figure 13 A flowchart of another virtualization platform lifecycle monitoring method provided by an embodiment of the present application is shown in FIG. 6;

[0140] Figure 14 A flowchart of another virtualization platform lifecycle monitoring method provided by an embodiment of the present application is shown in FIG. 6;

[0141] Figure 15 A flowchart of another virtualization platform lifecycle monitoring method provided by an embodiment of the present application is shown in FIG. 6; DETAILED DESCRIPTION

[0142] The exemplary embodiments will be described in detail herein below with reference to the drawings. In the following description, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments are not meant to represent all embodiments consistent with the present application. Rather, they are merely examples of methods and apparatuses consistent with some aspects of the present application as detailed in the appended claims.

[0143] The terms "first", "second", "third", "fourth" etc. (if any) in the description and claims of this application and the above figures are used for distinguishing between similar objects, not necessarily for describing a particular sequential or chronological order. It is to be understood that the use of such terms, if any, are not to be construed to limit corresponding generic objects to the corresponding ordinal position, other than where a particular ordinal position is explicitly called for in order to avoid ambiguity in the description. Further, the terms "comprise", "comprising", "comprises", and "comprising" and any variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of steps or units does not necessarily comprise only those steps or units but can include other not expressly listed steps or units. Steps or units can be added to or removed from a process or method, and a process or method can consist of more than one step or unit.

[0144] Currently, the Hypervisor can adopt a high reliability and security framework design to provide functional safety capability support of the virtualization ecological software, thereby guaranteeing the functional safety of the vehicle. As the most basic function of virtualization, the virtual machine (VM) life cycle management is throughout the entire virtualization life cycle. Therefore, on the basis of meeting the basic function, it is necessary to develop a configuration and monitoring function with high security and high robustness.

[0145] In view of the above problems existing in the prior art, the present application provides a virtualization platform life cycle monitoring method and device. The inventive concept of the virtualization platform life cycle monitoring method provided by the present application is that the state conversion of the virtualization platform life cycle state and the program running failure and timeout are monitored, and the power-on self-test, online self-test and fault injection are performed by using the test library, so as to effectively cover the random hardware failure, thereby providing an effective monitoring scheme for the virtualization platform life cycle management as a whole.

[0146] Figure 1 An application scenario diagram provided by an embodiment of the present application is shown in FIG. 1. As shown in FIG. 1, a virtualization platform is configured in a vehicle 100, thereby providing functional safety capability support of the virtualization ecological software, which can guarantee the functional safety of the vehicle 100. The virtualization platform includes a virtual machine. An electronic device 200 is configured to perform the virtualization platform life cycle monitoring method provided by the present application, which can monitor the function state management in the virtual machine life cycle, can not only solve the problems of state conversion abnormality, state conversion failure and initial configuration error in the whole life cycle, but also make up for the current situation that the Hypervisor of the ASILD level in line with the functional safety lacks effective monitoring of the unexpected conversion of the life cycle state, in addition, can improve the diagnosis rate of random hardware failure and the robustness of state migration in the life cycle state conversion, and can greatly reduce the dependence on hardware security. Figure 1 The virtualization platform life cycle monitoring method provided by the present application can monitor the function state management in the virtual machine life cycle, can not only solve the problems of state conversion abnormality, state conversion failure and initial configuration error in the whole life cycle, but also make up for the current situation that the Hypervisor of the ASILD level in line with the functional safety lacks effective monitoring of the unexpected conversion of the life cycle state, in addition, can improve the diagnosis rate of random hardware failure and the robustness of state migration in the life cycle state conversion, and can greatly reduce the dependence on hardware security.

[0147] The electronic device 200 may, for example, be an Electronic Control Unit (ECU), a Micro Controller Unit (MCU), or the like, configured in the vehicle 100, and the embodiments of the present application do not limit the type of the electronic device 200, Figure 1 The ECU is taken as an example.

[0148] It should be noted that the above application scenario diagram is only for illustration, and the virtualization platform lifecycle monitoring method and device provided by the embodiments of the present application include but are not limited to the above application scenario.

[0149] Figure 2 A flowchart of a virtualization platform lifecycle monitoring method provided by the embodiments of the present application is shown in Figure 2 The virtualization platform lifecycle monitoring method provided by the embodiments of the present application includes:

[0150] S101: Obtain a lifecycle state of a virtual machine.

[0151] Obtaining the lifecycle state of the virtual machine is to obtain the current state of the virtual machine. Referring to Figure 3 The entire lifecycle state of the virtual machine can include a startup state of the virtual machine (as shown in S0 in Figure 3 ), a running state of the virtual machine (as shown in S1 in Figure 3 ), an exit state of the virtual machine (as shown in S2 in Figure 3 ), a hibernation state of the virtual machine (as shown in S3 in Figure 3 ), and a fault state of the virtual machine (as shown in S4 in Figure 3 ). Among them, S0-S3 are basic states for implementing the lifecycle of the virtual machine, and through the conversion between these states, the basic conversion of the lifecycle of the virtual machine can be realized. The S4 state can realize a safe monitoring closed loop of the entire lifecycle, and can finally enter a safe working state with the help of an external independent safety device.

[0152] S102: Obtain a state conversion process between the lifecycle states.

[0153] Continuing to refer to Figure 3 The state conversion process between the lifecycle states can include conversion from the startup state of the virtual machine to the running state of the virtual machine (S0→S1), conversion from the running state of the virtual machine to the exit state of the virtual machine (S1→S2), conversion from the exit state of the virtual machine to the startup state of the virtual machine (S2→S0), conversion between the running state of the virtual machine and the hibernation state of the virtual machine One of the state transition from the fault state to the exit state (S4→S2). The state transition process between the life cycle states is the state transition process in which the virtual machine is currently located.

[0154] For each state S0 to S3, the monitoring of the transition conditions in each state of the virtual machine and the state transition process can be implemented, and further, the arbitration can be used to make corresponding processing strategy decisions from the aspects of each dimension of software system failure, time timeout, sleep wake-up exception, and the like.

[0155] It should be noted that the state transition process between the life cycle states includes but is not limited to the above enumeration, and can also include the running state transition to the fault state (S1→S4), the fault state transition to the exit state (S4→S2), the sleep state transition to the fault state (S3→S4), and the self transition of each life cycle state, as shown in FIG. 1. Figure 3 The life cycle state transition process is determined by the actual working condition, and the embodiments of the present application are not limited thereto. The life cycle monitoring process of the life cycle state transition process is similar to the life cycle state transition process that has been listed, and will not be described herein.

[0156] S103: Life cycle monitoring of the virtual machine is performed according to the state transition process and the test library.

[0157] The test library can include fault injection testing and online testing. In some embodiments, the fault injection testing can be a specific stage single test, such as error correcting code (ECC) gizmos injection, clock frequency fault injection, memory fault injection, and interrupt fault injection. The online testing can be an online loop test, such as a dual-core lockstep test, a memory build-in-self test (MBIST), and an online register mirror test. In the actual working condition, the specific test strategy can be configured according to the actual application scenario. The configuration method includes but is not limited to adding a specific fault injection test, performing power-on or initialization testing when the system is powered on and powered off, and performing periodic testing during system running. Various combinations can be used to ensure system resources while effectively covering hardware random failures.

[0158] On the basis of obtaining the life cycle transition path of the virtual machine, the full life cycle of the virtual machine is monitored in combination with the corresponding test strategy designed in the test library.

[0159] The unexpected state transition or transition failure of the life cycle state caused by program running failure can be monitored to determine the transition condition, determine the program dead loop, determine the abnormal interruption and abnormal exit, determine the abnormal end of the previous state, determine the abnormal start of the subsequent state, determine the abnormal sleep, and determine the abnormal wake-up. In addition, through effective collection of the previous and subsequent states, post-check of the transition condition, comprehensive coverage of the software systematic failure mode, and reasonable design in the whole life cycle, the diagnostic coverage of the program running failure can be maximized, and the program running failure caused by systematic failure can be avoided.

[0160] In addition, the life cycle state transition failure caused by state transition timeout can be effectively avoided by starting and ending time in the whole life cycle state transition process. In combination with the preset timeout time, the static configuration of different applications and different life cycle state transition stages can be supported. In addition, the introduction of the test library can identify the single-point failure and latent failure of the hardware, and effectively improve the overall security of the virtualization platform.

[0161] The virtualization platform life cycle monitoring method provided by the embodiment of the application includes the following steps: obtaining the life cycle state of a virtual machine, the life cycle state including the start state, the running state, the exit state, the sleep state and the failure state of the virtual machine; obtaining the state transition process between the life cycle states, the state transition process including one of the start state to the running state, the running state to the exit state, the exit state to the start state, the running state to the sleep state, and the failure state to the exit state; and performing life cycle monitoring on the virtual machine according to the state transition process and a test library, the test library including fault injection testing and online testing. The function state management in the life cycle of the virtual machine can be monitored, the state transition abnormality, the state transition failure and the initial configuration error in the whole life cycle can be solved, the effective monitoring of the unexpected state transition of the life cycle state can be supplemented for the Hypervisor of the ASILD level that meets the functional safety, the diagnostic rate of the random hardware failure in the life cycle state transition and the robustness of the state migration can be improved, and the dependence on the hardware security can be greatly reduced compared with the related art.

[0162] In a possible design, if the state transition process is the start state to the running state (S0→S1), the possible implementation of step S103 is as shown in Figure 4 . Figure 4 Another flowchart of the virtualization platform life cycle monitoring method provided by the embodiment of the application is as shown in Figure 4 . The embodiment of the application includes the following steps:

[0163] S201: configuring the virtual machine in response to the configuration instruction and obtaining a first time.

[0164] The first time is a configuration start time.

[0165] The virtual machine is configured in response to the configuration instruction, and the first time is the time T11 at the configuration start time.

[0166] S202: power-on self-test of the configured virtual machine, and obtaining state data after self-test according to the power-on self-test items of the virtual machine.

[0167] The virtual machine after configuration is subjected to power-on self-test, and the state after each power-on self-test is obtained, and the state data after self-test is represented. In some embodiments, different self-test items can be selected according to different requirements for system startup time, for example, but not limited to: validity of virtual machine ID, validity of parameter type in virtual machine configuration data structure, validity of parameter range, etc. Hardware self-test can also be included, such as various fault injection tests, memory tests, lockstep tests, register tests, etc.

[0168] S203: determining whether the power-on self-test passes according to the state data.

[0169] According to the state data corresponding to the power-on self-test item, it is determined whether the power-on self-test passes, if it passes, then the next step S204 is entered, if it fails, then it is reconfigured, i.e. step S201 is performed. In some embodiments, whether the power-on self-test passes can be determined according to the content of the power-on self-test item, which is not limited by the embodiments of the present application.

[0170] S204: making the virtual machine enter a startup state in response to a startup instruction, and obtaining a second time and a third time.

[0171] After the power-on self-test passes, the virtual machine is controlled to enter a startup state in response to a startup instruction, and the end time of the power-on self-test, i.e. the second time T12, and the start time of the startup state, i.e. the third time T13, are recorded.

[0172] S205: performing fault injection test and online test on the virtual machine in the startup state, and entering a fault state when the virtual machine detects an exception.

[0173] The virtual machine in the startup state is subjected to fault injection test, which can be configured according to the requirements of fault injection test, and then enters the fault state of the virtual machine (S4) when an exception is detected.

[0174] The virtual machine in the startup state is subjected to online test, which can be configured according to the requirements of online test, and then enters the fault state of the virtual machine (S4) when an exception is detected.

[0175] S206: Determine whether the virtual machine that has entered the fault state is converted from the start state to the running state to meet the first conversion condition.

[0176] Determine whether the conversion condition of the virtual machine from the start state to the running state meets the corresponding first conversion condition. If yes, execute step S207a, and if no, execute step S207b, i.e., maintain the current state.

[0177] In some embodiments, the first conversion condition includes, but is not limited to, one or more of whether the virtual machine ID number is correct, whether the physical CPU bitmap used by the virtual machine is used by the current virtual machine, virtual machine configuration information type validity, and virtual machine configuration information range validity.

[0178] S207a: In response to the first conversion instruction, make the virtual machine enter the running state, and obtain the fourth time.

[0179] If the first conversion condition is met, in response to the generated first conversion instruction, control the virtual machine to enter the running state, and record the end time of the start state, i.e., the fourth time T14.

[0180] In some embodiments, after obtaining the fourth time, the virtual machine is further tested online, and detected to be abnormal to enter the virtual machine fault state (S4).

[0181] S207b: Keep the start state of the virtual machine.

[0182] S208: Perform life cycle monitoring on the virtual machine according to the third time and the fourth time.

[0183] After step S207a, further perform life cycle monitoring on the virtual machine from the start state to the running state according to the obtained third time T13 and fourth time T14.

[0184] In a possible design, a possible implementation manner of step S208 is as shown in Figure 5 . Figure 5 Another flowchart of a virtualization platform life cycle monitoring method provided by an embodiment of the present application is shown in Figure 5 . The embodiment of the present application includes:

[0185] S2081: Determine whether the time difference between the fourth time and the third time is less than or equal to the second preset time length.

[0186] determining whether T14-T13 is less than or equal to the second preset time length, if it is determined that T14-T13 is less than or equal to the second preset time length, the timeout monitoring of the state transition phase S0→S1 is ended, i.e., step S2082 is executed; if it is determined that T14-T13 is greater than the second preset time length, it indicates that the state transition from the starting state to the running state is timed out, and the virtual machine is controlled to enter the fault state, i.e., step S2083 is executed.

[0187] S2082: the life cycle monitoring of the virtual machine from the starting state to the running state is ended.

[0188] S2083: the virtual machine is controlled to enter the fault state.

[0189] In addition, after the first time T11 and the second time T12 are acquired, the life cycle monitoring of the virtual machine configuration phase by the first time and the second time is further included, and the implementation manner is as shown in Figure 6 . Figure 6 A flowchart of still another virtualization platform life cycle monitoring method provided by the embodiment of the present application is shown in Figure 6 , and the embodiment of the present application includes:

[0190] S301: determining whether the time difference between the second time and the first time is less than or equal to the first preset time length;

[0191] S302: the life cycle monitoring of the virtual machine configuration phase is ended.

[0192] S303: the virtual machine is controlled to enter the safe state.

[0193] determining whether T12-T11 is less than or equal to the first preset time length, if it is determined that T12-T11 is less than or equal to the first preset time length, the timeout monitoring of the configuration phase is ended, i.e., step S302 is executed, and then Figure 4 the life cycle monitoring of the virtual machine from the starting state to the running state is performed by the embodiment; if it is determined that T12-T11 is greater than the first preset time length, it indicates that the virtual machine configuration phase is timed out, and the virtual machine is controlled to enter the safe state, i.e., step S303 is executed, at this time, the safe state is in the virtual machine preparation state, and cannot enter the starting state of the virtual machine. The configuration phase is used to complete the power-on self-test.

[0194] It should be noted that the first and second preset durations can be customized and configured to meet the requirements of the maximum allowable time for system fault handling while allowing for a certain margin. The maximum allowable time for system fault handling is not a fixed value. It needs to be determined based on the overall consideration of potential hazards, fault triggering conditions, fault detection, and security status according to the upper-layer application scenario and business requirements. The diagnostic test interval and fault response time are determined accordingly. The specific values ​​of the first and second preset durations are not limited in this embodiment.

[0195] The virtualization platform lifecycle monitoring method provided in this application, through power-on self-test (POST), test injection using a designed test library, and timeout monitoring from the startup state to the running state, effectively avoids unexpected transitions or failures from the startup state to the running state caused by virtualization platform configuration errors. This is achieved through the start and end times of the transition process and the use of the test library, as well as through configuration validity checks during power-on self-test and configurable fault injection tests. Self-testing and fault injection tests can identify single points of failure and latent faults in the hardware, effectively improving the overall security of the virtualization platform. Furthermore, by combining configurable timeout settings, such as a first preset duration and a second preset duration, static configurations for different applications and different lifecycle transition stages can be supported.

[0196] In one possible design, if the state transition process is from the running state to the exit state (S1→S2), the possible implementation of step S103 is as follows: Figure 7 As shown. Figure 7 This is a flowchart illustrating another virtualization platform lifecycle monitoring method provided in an embodiment of this application. Figure 7 As shown, the embodiments of this application include:

[0197] S401: Get the start time when the virtual machine enters the running state.

[0198] The virtual machine enters the running state, and the start time T21 of the running state is recorded.

[0199] S402: Perform fault injection testing and online testing on the virtual machine that has entered the running state. When the virtual machine detects an anomaly, it enters the fault state.

[0200] For running virtual machines, fault injection testing can be performed. The specific configuration can be determined according to the needs of the fault injection test. Once an anomaly is detected, the virtual machine enters a fault state (S4).

[0201] Online testing of running virtual machines can be configured according to online testing requirements. Once an anomaly is detected, the virtual machine enters a fault state (S4).

[0202] S403: determining whether the virtual machine that has entered the fault state is converted from the running state to the exit state satisfying a second conversion condition.

[0203] determining whether the conversion condition of the virtual machine from the running state to the exit state satisfies the corresponding second conversion condition, if yes, executing step S404a, if no, executing step S404b, i.e. maintaining the previous state.

[0204] In some embodiments, the second conversion condition includes, but is not limited to, virtual machine data structure pointer type validity or virtual machine data structure pointer range validity.

[0205] S404a: responding to the second conversion instruction to make the virtual machine enter the exit state, and obtaining the end time of the running state.

[0206] If the second conversion condition is satisfied, responding to the generated second conversion instruction to control the virtual machine to enter the exit state, and recording the end time of the running state, i.e. T22.

[0207] In some embodiments, after obtaining the end time of the running state, i.e. T22, the virtual machine is further tested online, and the abnormality is detected to enter the virtual machine fault state (S4).

[0208] S404b: maintaining the running state of the virtual machine.

[0209] S405: determining whether the time difference between the end time of the running state and the start time of the running state is less than or equal to a third preset time length.

[0210] determining whether T22-T21 is less than or equal to the third preset time length. If it is determined that T22-T21 is less than or equal to the third preset time length, the timeout monitoring of the state conversion phase of S1→S2 is ended, i.e. step S306 is executed; if it is determined that T22-T21 is greater than the third preset time length, it indicates that the state conversion from the running state to the exit state is timed out, and the virtual machine is controlled to enter the fault state, i.e. step S407 is executed.

[0211] S406: ending the life cycle monitoring of the virtual machine from the running state to the exit state.

[0212] S407: controlling the virtual machine to enter the fault state.

[0213] The virtualization platform life cycle monitoring method provided by the embodiments of the present application can effectively avoid the unexpected conversion or conversion failure of the running state to the exit state caused by the configuration error of the virtualization platform through the start time, the end time and the test library in the conversion process of the phase. Moreover, combined with the configurable timeout time, e.g. the third preset time length, the static configuration of different applications and different life cycle conversion phases can be supported.

[0214] In a possible design, if the state transition process is from the exit state to the start state (S2→S0), a possible implementation manner of step S103 is as shown in Figure 8 . Figure 8 Another flowchart of a virtualization platform lifecycle monitoring method provided by an embodiment of the present application is shown in Figure 8 . An embodiment of the present application includes the following steps:

[0215] S501: obtaining a start time of entering and exiting a state of a virtual machine.

[0216] The virtual machine enters and exits a state, and a start time T31 of exiting the state is recorded.

[0217] S502: performing fault injection testing and online testing on the virtual machine entering and exiting the state, and entering a fault state when the virtual machine detects an exception.

[0218] The fault injection testing is performed on the virtual machine exiting the state, and the fault injection testing can be configured according to the requirements of the fault injection testing, and then an exception is detected to enter the fault state (S4) of the virtual machine.

[0219] The online testing is performed on the virtual machine exiting the state, and the online testing can be configured according to the requirements of the online testing, and then an exception is detected to enter the fault state (S4) of the virtual machine.

[0220] S503: determining whether the virtual machine entering the fault state is converted from the exit state to the start state and meets a third conversion condition.

[0221] It is determined whether the conversion condition of the virtual machine converted from the exit state to the start state meets the corresponding third conversion condition, if yes, step S504a is performed, and if no, step S504b is performed, that is, the previous state is maintained.

[0222] In some embodiments, the third conversion condition includes, but is not limited to, whether a virtual machine ID number is correct, whether a virtual machine configuration information type is valid, or whether a virtual machine configuration information range is valid.

[0223] S504a: making the virtual machine enter the start state in response to a third conversion instruction, and obtaining an end time of exiting the state.

[0224] If the third conversion condition is met, the virtual machine enters the start state in response to a generated third conversion instruction, and an end time T32 of exiting the state is recorded.

[0225] In some embodiments, after the end time T32 of exiting the state is obtained, the online testing is further performed on the virtual machine, and an exception is detected to enter the fault state (S4) of the virtual machine.

[0226] S504b: maintaining the exit state of the virtual machine.

[0227] S505: determining whether a time difference between an end time of the exit state and a start time of the exit state is less than or equal to a fourth preset time length.

[0228] It is determined whether T32-T31 is less than or equal to the fourth preset time length. If it is determined that T32-T31 is less than or equal to the fourth preset time length, the timeout monitoring of the state transition phase of S2→S0 is ended, that is, step S406 is performed; if it is determined that T32-T31 is greater than the fourth preset time length, it indicates that the state transition from the exit state to the start state is timed out, and the virtual machine is controlled to enter a fault state, that is, step S407 is performed.

[0229] S506: ending the life cycle monitoring of the virtual machine from the exit state to the start state.

[0230] S507: controlling the virtual machine to enter a fault state.

[0231] The virtualization platform life cycle monitoring method provided by the embodiments of the present application can effectively avoid the unexpected transition or transition failure from the exit state to the start state caused by the configuration error of the virtualization platform, by using the start time, the end time and the test library in the transition process of the phase. In combination with the configurable timeout time, such as the fourth preset time length, the static configuration of different applications and different life cycle transition phases can be supported.

[0232] In a possible design, if the state transition process is the running state to the hibernation state (S1→S3), the possible implementation manner of step S103 is as shown in Figure 9 . Figure 9 Another flowchart of the virtualization platform life cycle monitoring method provided by the embodiments of the present application is shown in Figure 9 . The embodiments of the present application include the following steps:

[0233] S601: obtaining a start time of the virtual machine entering a running state.

[0234] The virtual machine enters the running state, and the start time T41 of the running state is recorded.

[0235] S602: performing fault injection testing and online testing on the virtual machine entering the running state, and entering a fault state when the virtual machine detects an exception.

[0236] The fault injection testing is performed on the virtual machine in the running state, and the fault injection testing can be configured according to the requirements of the fault injection testing, and then the exception is detected to enter the fault state (S4) of the virtual machine.

[0237] The online test of the running state of the virtual machine can be configured according to the online test requirement, and the abnormality detected is the entering of the virtual machine into the fault state (S4).

[0238] S603: Determine whether the virtual machine that has entered the fault state is converted from the running state to the hibernation state to meet the fourth conversion condition.

[0239] Determine whether the conversion condition of the virtual machine converted from the running state to the hibernation state meets the corresponding fourth conversion condition. If yes, execute step S604a, and if no, execute step S604b, that is, maintain the previous state.

[0240] In some embodiments, the fourth conversion condition includes, but is not limited to, virtual machine data structure pointer type validity or virtual machine data structure pointer range validity.

[0241] S604a: In response to the fourth conversion instruction, make the virtual machine enter the hibernation state, and obtain the end time of the running state.

[0242] If the fourth conversion condition is met, in response to the generated fourth conversion instruction, control the virtual machine to enter the hibernation state, and record the end time of the running state, that is, T42.

[0243] In some embodiments, after obtaining the end time of the running state, that is, T42, the virtual machine is further subjected to online test, and the abnormality detected enters the virtual machine into the fault state (S4).

[0244] S604b: Keep the running state of the virtual machine.

[0245] S605: Determine whether the time difference between the end time of the running state and the start time of the running state is less than or equal to the fifth preset time length.

[0246] Determine whether T42-T41 is less than or equal to the fifth preset time length. If it is determined that T42-T41 is less than or equal to the fifth preset time length, end the timeout monitoring of the state conversion phase of S1→S3, that is, execute step S606; if it is determined that T42-T41 is greater than the fifth preset time length, it indicates that the state conversion from the running state to the hibernation state is timed out, and the virtual machine is controlled to enter the fault state, that is, execute step S607.

[0247] S606: End the life cycle monitoring of the virtual machine converted from the running state to the hibernation state.

[0248] S607: Control the virtual machine to enter the fault state.

[0249] The virtualization platform lifecycle monitoring method provided by the embodiments of the present application can effectively avoid the unexpected conversion or conversion failure from the running state to the hibernation state caused by the configuration error of the virtualization platform. Moreover, in combination with the configurable timeout time (for example, the fifth preset time length), the static configuration of different applications and different lifecycle conversion stages can be supported.

[0250] In a possible design, if the state conversion process is from the hibernation state to the running state (S3→S1), the possible implementation manner of step S103 can be as shown in Figure 10 Figure 10 This is a flowchart of another virtualization platform lifecycle monitoring method provided by the embodiments of the present application. As shown in Figure 10

[0251] S701: Obtain the start time of the virtual machine entering the hibernation state.

[0252] The virtual machine enters the hibernation state, and the start time T51 of the hibernation state is recorded.

[0253] S702: Perform the fault injection test and the online test on the virtual machine entering the hibernation state, and when the virtual machine detects an exception, the virtual machine enters the fault state.

[0254] The fault injection test is performed on the virtual machine in the hibernation state. The fault injection test can be configured according to the requirements of the fault injection test, and when an exception is detected, the virtual machine enters the fault state (S4).

[0255] The online test is performed on the virtual machine in the hibernation state. The online test can be configured according to the requirements of the online test, and when an exception is detected, the virtual machine enters the fault state (S4).

[0256] S703: Determine whether the virtual machine that has entered the fault state is converted from the hibernation state to the running state and meets the fifth conversion condition.

[0257] It is determined whether the conversion condition of the virtual machine converted from the hibernation state to the running state meets the corresponding fifth conversion condition. If yes, step S704a is performed, and if no, step S704b is performed, that is, the previous state is maintained.

[0258] In some embodiments, the fifth conversion condition includes but is not limited to the validity of the virtual machine data structure pointer type or the validity of the virtual machine data structure pointer range.

[0259] S704a: In response to the fifth conversion instruction, the virtual machine enters the running state, and the end time of the hibernation state is obtained.

[0260] ​​If the fifth conversion condition is met, the generated fifth conversion instruction is used to control the virtual machine to enter the running state, and the end time T52 of the hibernation state is recorded.

[0261] In some embodiments, after the end time T52 of the hibernation state is obtained, the virtual machine is also tested online to detect an exception to enter a virtual machine fault state (S4).

[0262] S704b: The hibernation state of the virtual machine is maintained.

[0263] S705: It is determined whether a time difference between the end time of the hibernation state and the start time of the hibernation state is less than or equal to a sixth preset time length.

[0264] It is determined whether T52-T51 is less than or equal to the sixth preset time length. If it is determined that T52-T51 is less than or equal to the sixth preset time length, the timeout monitoring of the state conversion phase of S3→S1 is ended, that is, step S706 is performed; if it is determined that T52-T51 is greater than the sixth preset time length, it is indicated that the state conversion from the hibernation state to the running state is timed out, and the virtual machine is controlled to enter a fault state, that is, step S707 is performed.

[0265] S706: The life cycle monitoring of the virtual machine from the hibernation state to the running state is ended.

[0266] S707: The virtual machine is controlled to enter a fault state.

[0267] The virtualization platform life cycle monitoring method provided by the embodiments of the present application can effectively avoid the unexpected conversion or conversion failure of the hibernation state to the running state caused by the configuration error of the virtualization platform, by using the start time, the end time and the test library in the conversion process of this phase. In combination with the configurable timeout time, for example, the fifth preset time length, the static configuration of different applications and different life cycle conversion phases can be supported.

[0268] In a possible design, if the state conversion process is the conversion from the fault state to the exit state (S4→S2), a possible implementation manner of step S103 is as shown in Figure 11 . Figure 11 Another flowchart of the virtualization platform life cycle monitoring method provided by the embodiments of the present application is shown in Figure 11 . The embodiments of the present application include the following steps.

[0269] S801: The start time of the virtual machine entering the fault state is obtained.

[0270] The virtual machine enters the fault state, and the start time T61 of the fault state is recorded.

[0271] S802: performing fault injection test and online test on the virtual machine in the fault state to trigger the virtual machine to reset the external hardware.

[0272] The fault injection test is performed on the virtual machine in the fault state, and the fault injection test can be configured according to the requirements of the fault injection test, so as to detect the abnormality and trigger the external hardware reset.

[0273] The online test is performed on the virtual machine in the running state, and the online test can be configured according to the requirements of the online test, so as to detect the abnormality and trigger the external hardware reset.

[0274] S803: determining whether the virtual machine in which the external hardware has been reset is converted from the fault state to the exit state and meets the sixth conversion condition.

[0275] It is determined whether the conversion condition of the virtual machine converted from the fault state to the exit state meets the corresponding sixth conversion condition. If yes, step S804a is performed, and if no, step S804b is performed, that is, the previous state is maintained.

[0276] In some embodiments, the sixth conversion condition includes, but is not limited to, virtual machine data structure pointer type validity, virtual machine data structure pointer range validity, or the fault type is the first time to judge the program running fault and needs to restart the virtual machine.

[0277] S804a: responding to the sixth conversion instruction to make the virtual machine enter the exit state and obtaining the end time of the fault state.

[0278] If the sixth conversion condition is met, the generated sixth conversion instruction is responded to control the virtual machine to enter the exit state, and the end time of the fault state, that is, T62, is recorded.

[0279] In some embodiments, after the end time of the fault state, that is, T62, is obtained, the online test is further performed on the virtual machine, and the abnormality is detected to enter the fault state of the virtual machine (S4).

[0280] S784b: maintaining the fault state of the virtual machine.

[0281] S805: determining whether the time difference between the end time of the fault state and the start time of the fault state is less than or equal to the seventh preset time length.

[0282] It is determined whether T62-T61 is less than or equal to the seventh preset time length. If it is determined that T62-T61 is less than or equal to the seventh preset time length, the timeout monitoring of the state conversion phase of S4→S2 is ended, that is, step S806 is performed; if it is determined that T62-T61 is greater than the seventh preset time length, it indicates that the state conversion from the fault state to the exit state is timed out, and the virtual machine is controlled to enter the fault state, that is, step S807 is performed.

[0283] S806: End the life cycle monitoring of the virtual machine from the fault state to the exit state.

[0284] S807: Control the virtual machine to enter the fault state.

[0285] The virtualization platform life cycle monitoring method provided by the embodiments of the present application can effectively avoid the unexpected conversion or conversion failure of the fault state to the exit state caused by the configuration error of the virtualization platform. In combination with the configurable timeout time, such as the fifth preset time length, the static configuration of different applications and different life cycle conversion stages can be supported.

[0286] In some embodiments, the life cycle monitoring of the virtual machine can also be performed through arbitration judgment. Specifically, the program running failure scenario can be monitored, so that the arbitration judgment can be used to make the final processing strategy decision from various dimensions of software system failure, such as time timeout, hibernation wake-up exception, and the like.

[0287] In a possible design, the possible implementation manner of the life cycle monitoring of the virtual machine through arbitration judgment can be as shown in Figure 12 . Figure 12 Another flowchart of the virtualization platform life cycle monitoring method provided by the embodiments of the present application is shown in Figure 12 . The embodiments of the present application include:

[0288] S901: Obtain the previous life cycle state and the next life cycle state of the current life cycle state of the virtual machine and the historical conversion condition.

[0289] The historical conversion condition is the conversion condition when the previous life cycle state is converted to the next life cycle state.

[0290] The previous life cycle state, the next life cycle state of the current life cycle state of the virtual machine, and the conversion condition between the previous and next life cycle states are obtained.

[0291] S902: Determine whether the historical conversion condition is correct.

[0292] It is determined whether the historical conversion condition is correct. If correct, the next step S803 is further executed to make the next level judgment; otherwise, if the historical conversion condition is incorrect, the fault state is directly output, and the virtual machine fault state is entered according to the arbitration judgment, that is, step S808 is executed. Step S802 is the post-judgment according to the previous and next states and the conversion condition, which can effectively avoid the unexpected conversion of the state.

[0293] S903: Determine whether the program exists in a dead loop running.

[0294] It is judged whether the program has a dead loop running. If the program has a dead loop running, a fault state is directly outputted, and the virtual machine enters a fault state according to the fault state judged by arbitration, that is, step S908 is executed. If not, the next step is entered, that is, step S904 is executed. The dead loop detection of step S903 can effectively avoid state conversion failure and conversion timeout.

[0295] S904: It is judged whether the program has a program running fault.

[0296] The program running fault includes an abnormal interruption phenomenon or an abnormal exit phenomenon.

[0297] It is judged whether the program has an abnormal interruption or an abnormal exit. If the program has an abnormal interruption or an abnormal exit, a fault state is directly outputted, and the virtual machine enters a fault state according to the fault state judged by arbitration, that is, step S908 is executed. If not, the next step is entered, that is, step S905 is executed. The abnormal interruption or abnormal exit can cause program execution abnormality and hinder real-time execution of a normal program. The abnormal interruption and abnormal exit detection can effectively avoid program unexpected execution and program timeout.

[0298] S905: It is judged whether the previous life cycle state is normally ended.

[0299] It is judged whether the previous life cycle state is normally ended. If not, a fault state is directly outputted, and the virtual machine enters a fault state according to the fault state judged by arbitration, that is, step S808 is executed. If yes, the next step is entered, that is, step S806 is executed. The previous life cycle state normally ended detection can effectively avoid an abnormal state in which multiple states exist at the same time.

[0300] S906: It is judged whether the next life cycle state is normally started.

[0301] It is judged whether the next life cycle state is normally started. If not, a fault state is directly outputted, and the virtual machine enters a fault state according to the fault state judged by arbitration, that is, step S908 is executed. If yes, step S907 is executed to end the life cycle monitoring of the virtual machine when the program fails to run. The step S906 for detecting whether the next life cycle state is normally started can effectively avoid an abnormal state in which the previous and next states do not exist.

[0302] S907: The life cycle monitoring of the virtual machine when the program fails to run is ended.

[0303] S908: A fault instruction is generated, and the virtual machine enters a fault state in response to the fault instruction.

[0304] If one of the following conditions is determined, i.e., the historical transition condition is incorrect, the program has a dead loop, the program has a program running fault, the previous life cycle state is not normally ended, or the next life cycle state is not normally started, a fault instruction is generated, and the virtual machine enters a fault state in response to the fault instruction.

[0305] The virtualization platform life cycle monitoring method provided in the embodiments of the present application monitors the life cycle of the virtual machine through arbitration, and can specifically monitor the program running failure scenario, so that the arbitration can be used to make a final processing strategy decision from various dimensions of software system failure, time out, hibernation wake-up exception, and the like.

[0306] In some embodiments, the safe working state is not a unique fixed state, and the most suitable state needs to be considered according to the upper application scenario and business demand. As a bottom layer basic platform, the Hypervisor can finally notify an external independent MCU, a watchdog, and the like through an effective approach to inform the system that it is currently in a serious abnormal state or to inform the external hardware to restart to achieve the implementation. Therefore, the virtualization platform life cycle monitoring method provided in the embodiments of the present application can further include a possible implementation manner of making the virtual machine enter a safe working state from a fault state, as shown in Figure 13 . Figure 13 A flowchart of another virtualization platform life cycle monitoring method provided in the embodiments of the present application is shown in Figure 13 . The embodiments of the present application include the following steps.

[0307] S1001: A fault source of the virtual machine entering a fault state after detecting an exception is acquired.

[0308] S1002: The external hardware is restarted according to the fault source, so that the virtual machine enters a safe working state according to the application scenario.

[0309] As described in the foregoing embodiments, the fault source of the virtual machine entering a fault state (S4) after detecting an exception can include the following approaches: 1, arbitration determines that the virtual machine state is not expected to be converted, the virtual machine state conversion fails, hibernation or wake-up exception, and the like, and a program running fault state trigger enters the life cycle state S4; 2, the start and end time of the state conversion is determined to exceed the set time, and an out-of-time fault state trigger enters the life cycle state S4; 3, according to the fault injection test result, if there is an interruption exception, a memory exception, a clock exception, and the like, a fault injection test fails to pass, and a life cycle state trigger enters S4; 4, according to the online test result, if there is a lock step exception, a memory self-check exception, a register test exception, and the like, an online test fails to pass, and a life cycle state trigger enters S4.

[0310] The fault source of the virtual machine entering the fault state is judged, and then the external hardware is restarted according to the fault source, so that the virtual machine enters a safe working state according to the application scenario.

[0311] For example, if the fault source is that the maximum allowed time of system fault handling is exceeded, the external hardware such as a safety MCU or a watchdog is directly notified that it is in a fault state, and the external hardware can select overall restart or other effective means according to the overall demand of the system, wherein the maximum allowed time of system fault handling includes a first preset time length, a second preset time length, a third preset time length, a fourth preset time length, a fifth preset time length, a sixth preset time length, and a seventh preset time length; if the fault source is that a single fault injection test fails, the external hardware such as a safety MCU or a watchdog is directly notified that it is in a fault state, and the external hardware can select overall restart or other effective means according to the overall demand of the system; if the fault source is that an online test fails, the external hardware such as a safety MCU or a watchdog is notified that it is in a fault state, and subsequent processing is selected by the system level according to the overall business function and scene; if the fault source is a program running fault identified by arbitration judgment, the virtual machine can be restarted first, and it is judged whether the fault can be recovered, if the fault can be recovered, the fault state (S4) is converted to the exit state (S2), and then the conversion of the normal life cycle state of the startup state of the virtual machine and the running state of the virtual machine is entered. Further, if the virtual machine cannot be recovered after being restarted after the fault source is determined, the external hardware such as a safety MCU or a watchdog is directly notified that it is in a fault state, and the external hardware can select overall restart or other effective means according to the overall demand of the system.

[0312] The virtualization platform life cycle monitoring method provided by the embodiment of the application can make the virtual machine enter a safe working state according to specific application scenarios and system requirements with the aid of the external hardware, the independent safety device, after realizing the safe monitoring of the entire life cycle of the virtual machine, thereby improving the practicality of the virtualization platform life cycle monitoring method.

[0313] Figure 14 A virtualization platform life cycle monitoring device structure diagram is provided for the embodiment of the application, wherein the virtualization platform includes a virtual machine. Figure 14 As shown in the figure, the virtualization platform life cycle monitoring device 1000 provided by the embodiment of the application includes:

[0314] The first acquisition module 1001 is configured to acquire the life cycle state of the virtual machine, and the life cycle state includes a startup state of the virtual machine, a running state of the virtual machine, an exit state of the virtual machine, a hibernation state of the virtual machine, and a fault state of the virtual machine.

[0315] The second obtaining module 1002 is configured to obtain a state transition process between life cycle states, the state transition process comprising one of starting state transition to running state, running state transition to exiting state, exiting state transition to starting state, transition between running state and hibernation state, and fault state transition to exiting state.

[0316] The monitoring module 1003 is configured to perform life cycle monitoring on the virtual machine according to the state transition process and a test library, the test library comprising fault injection testing and online testing.

[0317] In a possible design, if the state transition process is starting state transition to running state, the monitoring module 1003 is specifically configured to:

[0318] configure the virtual machine in response to a configuration instruction, and obtain a first time point, the first time point being a configuration start time point;

[0319] perform power-on self-test on the configured virtual machine, and obtain state data after self-test according to a power-on self-test item of the virtual machine;

[0320] if it is determined according to the state data that the power-on self-test of the virtual machine is passed, make the virtual machine enter starting state in response to a starting instruction, and obtain a second time point and a third time point, the second time point and the third time point being an end time point of the power-on self-test and a start time point of the starting state respectively;

[0321] perform fault injection testing and online testing on the virtual machine in the starting state, and make the virtual machine enter fault state when the virtual machine detects an exception;

[0322] if it is determined that the virtual machine in the fault state satisfies a first transition condition when transitioning from the starting state to the running state, make the virtual machine enter the running state in response to a first transition instruction, and obtain a fourth time point, the fourth time point being an end time point of the starting state;

[0323] perform life cycle monitoring on the virtual machine according to the third time point and the fourth time point.

[0324] In a possible design, the monitoring module 1003 is further configured to:

[0325] if it is determined that a time difference between the fourth time point and the third time point is less than or equal to a second preset time length, end the life cycle monitoring on the virtual machine when transitioning from the starting state to the running state.

[0326] In a possible design, if it is determined that the time difference between the fourth time point and the third time point is greater than the second preset time length, the monitoring module 1003 is further configured to: control the virtual machine to enter the fault state.

[0327] In a possible design, the monitoring module 1003 is further configured to:

[0328] If it is determined that the time difference between the second time and the first time is less than or equal to the first preset time length, the life cycle monitoring of the configuration phase of the virtual machine is ended;

[0329] If it is determined that the time difference between the second time and the first time is greater than the first preset time length, the virtual machine is controlled to enter a safe state.

[0330] In a possible design, if the state transition process is from the running state to the exit state, the monitoring module 1003 is specifically configured to:

[0331] obtain a start time of the virtual machine entering the running state;

[0332] perform fault injection testing and online testing on the virtual machine entering the running state, and when the virtual machine detects an exception, the virtual machine enters a fault state;

[0333] If it is determined that the virtual machine that has entered the fault state is transitioned from the running state to the exit state to meet a second transition condition, the virtual machine is caused to enter the exit state in response to a second transition instruction, and an end time of the running state is obtained;

[0334] If it is determined that the time difference between the end time of the running state and the start time of the running state is less than or equal to a third preset time length, the life cycle monitoring of the virtual machine from the running state to the exit state is ended.

[0335] In a possible design, if it is determined that the time difference between the end time of the running state and the start time of the running state is greater than the third preset time length, the monitoring module is further configured to 1003: control the virtual machine to enter the fault state.

[0336] In a possible design, if the state transition process is from the exit state to the start state, the monitoring module 1003 is specifically configured to:

[0337] obtain a start time of the virtual machine entering the exit state;

[0338] perform fault injection testing and online testing on the virtual machine entering the exit state, and when the virtual machine detects an exception, the virtual machine enters a fault state;

[0339] If it is determined that the virtual machine that has entered the fault state is transitioned from the exit state to the start state to meet a third transition condition, the virtual machine is caused to enter the start state in response to a third transition instruction, and an end time of the exit state is obtained;

[0340] If it is determined that the time difference between the end time of the exit state and the start time of the exit state is less than or equal to a fourth preset time length, the life cycle monitoring of the virtual machine from the exit state to the start state is ended.

[0341] In a possible design, if the time difference between the end moment of the exiting state and the start moment of the exiting state is greater than a fourth preset time length, the monitoring module 1003 is further configured to control the virtual machine to enter a fault state.

[0342] In a possible design, if the state transition process is from the running state to the hibernation state, the monitoring module 1003 is specifically configured to:

[0343] obtain a start moment of the virtual machine entering the running state;

[0344] perform fault injection testing and online testing on the virtual machine entering the running state, and when the virtual machine detects an exception, the virtual machine enters a fault state;

[0345] if it is determined that the virtual machine that has entered the fault state is transitioned from the running state to the hibernation state and satisfies a fourth transition condition, the virtual machine enters the hibernation state in response to a fourth transition instruction, and an end moment of the running state is obtained;

[0346] if it is determined that the time difference between the end moment of the running state and the start moment of the running state is less than or equal to a fifth preset time length, the lifecycle monitoring of the virtual machine from the running state to the hibernation state is ended.

[0347] In a possible design, if the time difference between the end moment of the running state and the start moment of the running state is greater than the fifth preset time length, the monitoring apparatus 1003 is further configured to control the virtual machine to enter a fault state.

[0348] In a possible design, if the state transition process is from the hibernation state to the running state, the monitoring apparatus 1003 is further configured to:

[0349] obtain a start moment of the virtual machine entering the hibernation state;

[0350] perform fault injection testing and online testing on the virtual machine entering the hibernation state, and when the virtual machine detects an exception, the virtual machine enters a fault state;

[0351] if it is determined that the virtual machine that has entered the fault state is transitioned from the hibernation state to the running state and satisfies a fifth transition condition, the virtual machine enters the running state in response to a fifth transition instruction, and an end moment of the hibernation state is obtained;

[0352] if it is determined that the time difference between the end moment of the hibernation state and the start moment of the hibernation state is less than or equal to a sixth preset time length, the lifecycle monitoring of the virtual machine from the hibernation state to the running state is ended.

[0353] In a possible design, if it is determined that a time difference between the end moment of the hibernation state and the start moment of the hibernation state is greater than a sixth preset time length, the monitoring device 1003 is further configured to control the virtual machine to enter a fault state.

[0354] In a possible design, if the state transition process is a transition from the fault state to the exit state, the monitoring module 1003 is further configured to:

[0355] obtain a start moment of the virtual machine entering the fault state;

[0356] perform fault injection testing and online testing on the virtual machine in the fault state, to trigger the virtual machine to reset external hardware;

[0357] if it is determined that the virtual machine that has reset the external hardware meets a sixth transition condition when transitioning from the fault state to the exit state, the virtual machine is caused to enter the exit state in response to a sixth transition instruction, and an end moment of the fault state is obtained;

[0358] if it is determined that a time difference between the end moment of the fault state and the start moment of the fault state is less than or equal to a seventh preset time length, the lifecycle monitoring of the virtual machine transitioning from the fault state to the exit state is ended.

[0359] In a possible design, if it is determined that a time difference between the end moment of the fault state and the start moment of the fault state is greater than the seventh preset time length, the monitoring module 1003 is further configured to control the virtual machine to enter the fault state.

[0360] In a possible design, if the virtual machine program fails to run, the virtualization platform lifecycle monitoring device 1000 further includes:

[0361] an arbitration module configured to: perform lifecycle monitoring on the virtual machine by arbitration.

[0362] In a possible design, the arbitration module is specifically configured to:

[0363] obtain a previous lifecycle state and a next lifecycle state of a current lifecycle state of the virtual machine, and a historical transition condition, the historical transition condition being a transition condition when the previous lifecycle state transitions to the next lifecycle state;

[0364] if it is determined that the historical transition condition is correct, and it is determined that the program does not exist in a dead loop, it is determined whether the program exists in a program running fault, the program running fault including an abnormal interruption phenomenon or an abnormal exit phenomenon;

[0365] if no, and it is determined that the previous lifecycle state is normally ended and the next lifecycle state is normally started, the lifecycle monitoring on the virtual machine when the program fails to run is ended.

[0366] In a possible design, if it is determined that one of the following conditions is met: a history conversion condition is incorrect, a program has a dead loop, the program has a program running fault, a previous life cycle state is not normally ended, or a next life cycle state is not normally started, the arbitration module is further configured to:

[0367] generate a fault instruction, and make the virtual machine enter a fault state in response to the fault instruction.

[0368] In a possible design, the virtualization platform life cycle monitoring apparatus 1000 further includes a restart module, configured to:

[0369] obtain a fault source of the virtual machine entering the fault state due to the exception;

[0370] restart external hardware according to the fault source, so that the virtual machine enters a safe working state according to an application scenario.

[0371] The virtualization platform life cycle monitoring apparatus provided in the embodiments of the present application can perform the corresponding steps of the virtualization platform life cycle monitoring method in the method embodiments, and has similar implementation principles and technical effects, which will not be described here again.

[0372] Figure 15 A structural schematic diagram of an electronic device provided in the embodiments of the present application is shown in FIG. 2, which can include a processor 2001 and a memory 2002 connected with the processor 2001. Figure 15

[0373] The memory 2002 is configured to store a program. Specifically, the program can include program code, and the program code includes computer execution instructions.

[0374] The memory 2002 can include a high-speed RAM memory, and can also include a non-volatile memory (NoN-volatile memory), for example, at least one disk memory.

[0375] The processor 2001 is configured to execute the computer execution instructions stored in the memory 2002, so as to implement the virtualization platform life cycle monitoring method provided in each of the embodiments.

[0376] The processor 2001 can be a central processing unit (CPU), or an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present application.

[0377] ​Optionally, the memory 2002 can be independent or integrated with the processor 2001. When the memory 2002 is independent of the processor 2001, the electronic device 2000 can further include:

[0378] A bus 2003 is used to connect the processor 2001 and the memory 2002. The bus can be an industry standard architecture (ISA) bus, a peripheral component (PCI) bus, an extended industry standard architecture (EISA) bus, or the like. The bus can be divided into an address bus, a data bus, a control bus, and the like, but does not mean that there is only one bus or one type of bus.

[0379] Optionally, in a specific implementation, if the memory 2002 and the processor 2001 are integrated on a chip, the memory 2002 and the processor 2001 can communicate through an internal interface.

[0380] The application also provides a computer readable storage medium, which can include a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and various media that can store program codes, and specifically, the computer readable storage medium stores computer execution instructions, and the computer execution instructions are used for each step of the method in the above embodiments.

[0381] The application also provides a computer program product, which includes computer execution instructions, and the computer instructions are executed by the processor to realize each step of the method in the above embodiments.

[0382] Other embodiments of the application will be apparent to those skilled in the art from consideration of the specification and practice of the application disclosed herein. The application is intended to cover any variations, uses or adaptations of the application following, in general, the principles of the application and including such departures from the present disclosure as come within known or customary practice in the art to which the application pertains. The specification and examples are to be regarded as exemplary only, and the true scope and spirit of the application are indicated by the appended claims.

[0383] It should be understood that the application is not limited to the precise construction that has been described and illustrated herein and that various modifications and changes can be made therein without departing from the scope thereof. The scope of the application is indicated by the appended claims.

Claims

1. A method for monitoring the lifecycle of a virtualization platform, characterized in that, The virtualization platform includes virtual machines, and the method includes: Obtain the lifecycle state of the virtual machine, which includes the startup state, running state, exit state, hibernation state, and fault state of the virtual machine. Obtain the state transition process between the lifecycle states, the state transition process including one of the following: transition from the start state to the running state, transition from the running state to the exit state, transition from the exit state to the start state, transition between the running state and the hibernation state, and transition from the fault state to the exit state; The virtual machine is monitored throughout its lifecycle based on the state transition process and a test library, which includes fault injection testing and online testing. If the state transition process involves a transition from the startup state to the running state, the lifecycle monitoring of the virtual machine based on the state transition process and the test library includes: The virtual machine is configured in response to a configuration command, and a first timer is obtained, wherein the first timer is the configuration start time; The virtual machine that has been configured is powered on and performs a self-test, and the status data after the self-test is obtained according to the power-on self-test items of the virtual machine; If the power-on self-test of the virtual machine is determined to be successful based on the status data, a startup command is executed to cause the virtual machine to enter the startup state, and a second timer and a third timer are acquired, wherein the second timer and the third timer are the end time of the power-on self-test and the start time of the startup state, respectively. The virtual machine that has entered the startup state is subjected to the fault injection test and the online test. When the virtual machine detects an anomaly, it enters the fault state. If it is determined that the virtual machine's transition from the startup state to the running state satisfies the first transition condition, the first transition instruction is responded to cause the virtual machine to enter the running state, and a fourth timer is acquired, wherein the fourth timer is the end time of the startup state; The virtual machine's lifecycle is monitored based on the third and fourth timers.

2. The virtualization platform lifecycle monitoring method according to claim 1, characterized in that, The lifecycle monitoring of the virtual machine based on the third and fourth timers includes: If it is determined that the time difference between the fourth timer and the third timer is less than or equal to the second preset duration, the lifecycle monitoring of the virtual machine from the startup state to the running state is terminated.

3. The virtualization platform lifecycle monitoring method according to claim 1, characterized in that, If it is determined that the time difference between the fourth timer and the third timer is greater than the second preset duration, the virtual machine is controlled to enter the fault state.

4. The virtualization platform lifecycle monitoring method according to claim 1, characterized in that, Also includes: If it is determined that the time difference between the second timer and the first timer is less than or equal to the first preset duration, the lifecycle monitoring of the virtual machine configuration phase ends; If it is determined that the time difference between the second timer and the first timer is greater than the first preset duration, the virtual machine is controlled to enter a safe state.

5. The virtualization platform lifecycle monitoring method according to claim 1, characterized in that, If the state transition process involves a transition from the running state to the exit state, the lifecycle monitoring of the virtual machine based on the state transition process and the test library includes: Obtain the start time when the virtual machine enters the running state; The virtual machine that has entered the running state is subjected to the fault injection test and the online test. When the virtual machine detects an anomaly, it enters the fault state. If it is determined that the virtual machine's transition from the running state to the exit state satisfies the second transition condition, the virtual machine is made to enter the exit state in response to the second transition instruction, and the end time of the running state is obtained; If the time difference between the end time of the running state and the start time of the running state is less than or equal to a third preset duration, the lifecycle monitoring of the virtual machine transitioning from the running state to the exit state is terminated.

6. The virtualization platform lifecycle monitoring method according to claim 5, characterized in that, If the time difference between the end time and the start time of the running state is determined to be greater than a third preset duration, the virtual machine is controlled to enter the fault state.

7. The virtualization platform lifecycle monitoring method according to claim 1, characterized in that, If the state transition process involves a transition from the exit state to the startup state, the lifecycle monitoring of the virtual machine based on the state transition process and the test library includes: Obtain the start time when the virtual machine enters the exit state; The virtual machine that has entered the exit state is subjected to the fault injection test and the online test. When the virtual machine detects an anomaly, it enters the fault state. If it is determined that the virtual machine's transition from the exit state to the startup state satisfies the third transition condition, the third transition instruction is responded to cause the virtual machine to enter the startup state, and the end time of the exit state is obtained; If the time difference between the end time of the exit state and the start time of the exit state is less than or equal to a fourth preset duration, the lifecycle monitoring of the virtual machine transitioning from the exit state to the startup state is terminated.

8. The virtualization platform lifecycle monitoring method according to claim 7, characterized in that, If the time difference between the end time and the start time of the exit state is determined to be greater than a fourth preset duration, the virtual machine is controlled to enter the fault state.

9. The virtualization platform lifecycle monitoring method according to claim 1, characterized in that, If the state transition process involves a transition from the running state to the hibernation state, the lifecycle monitoring of the virtual machine based on the state transition process and the test library includes: Obtain the start time when the virtual machine enters the running state; The virtual machine that has entered the running state is subjected to the fault injection test and the online test. When the virtual machine detects an anomaly, it enters the fault state. If it is determined that the virtual machine's transition from the running state to the hibernation state satisfies the fourth transition condition, the virtual machine enters the hibernation state in response to the fourth transition instruction, and the end time of the running state is obtained; If the time difference between the end time of the running state and the start time of the running state is less than or equal to a fifth preset duration, the lifecycle monitoring of the virtual machine transitioning from the running state to the hibernation state is terminated.

10. The virtualization platform lifecycle monitoring method according to claim 9, characterized in that, If the time difference between the end time and the start time of the running state is determined to be greater than a fifth preset duration, the virtual machine is controlled to enter the fault state.

11. The virtualization platform lifecycle monitoring method according to claim 1, characterized in that, If the state transition process involves a transition from the hibernation state to the running state, the lifecycle monitoring of the virtual machine based on the state transition process and the test library includes: Obtain the start time when the virtual machine enters the hibernation state; The virtual machine that has entered the hibernation state is subjected to the fault injection test and the online test. When the virtual machine detects an anomaly, it enters the fault state. If it is determined that the virtual machine's transition from the hibernation state to the running state satisfies the fifth transition condition, the virtual machine is brought into the running state in response to the fifth transition instruction, and the end time of the hibernation state is obtained; If the time difference between the end time of the hibernation state and the start time of the hibernation state is less than or equal to a sixth preset duration, the lifecycle monitoring of the virtual machine transitioning from the hibernation state to the running state is terminated.

12. The virtualization platform lifecycle monitoring method according to claim 11, characterized in that, If the time difference between the end time of the hibernation state and the start time of the hibernation state is determined to be greater than a sixth preset duration, the virtual machine is controlled to enter the fault state.

13. The virtualization platform lifecycle monitoring method according to claim 1, characterized in that, If the state transition process involves a transition from the fault state to the exit state, the lifecycle monitoring of the virtual machine based on the state transition process and the test library includes: Obtain the start time when the virtual machine enters the fault state; The virtual machine that has entered the fault state is subjected to the fault injection test and the online test to trigger the virtual machine to reset the external hardware; If it is determined that the virtual machine that has reset the external hardware satisfies the sixth transition condition for transitioning from the fault state to the exit state, the virtual machine enters the exit state in response to the sixth transition instruction, and the end time of the fault state is obtained. If the time difference between the end time of the fault state and the start time of the fault state is less than or equal to a seventh preset duration, the lifecycle monitoring of the virtual machine transitioning from the fault state to the exit state is terminated.

14. The virtualization platform lifecycle monitoring method according to claim 13, characterized in that, If the time difference between the end time and the start time of the fault state is determined to be greater than a seventh preset duration, the virtual machine is controlled to enter the fault state.

15. The virtualization platform lifecycle monitoring method according to claim 1, characterized in that, Also includes: The virtual machine's lifecycle is monitored through arbitration.

16. The virtualization platform lifecycle monitoring method according to claim 15, characterized in that, The lifecycle monitoring of the virtual machine through arbitration includes: Obtain the previous lifecycle state and the next lifecycle state of the current lifecycle state of the virtual machine, as well as the historical transition conditions. The historical transition conditions are the transition conditions when the previous lifecycle state transitions to the next lifecycle state. If the historical conversion conditions are determined to be correct and the program is determined not to have an infinite loop, then it is determined whether the program has a program execution failure, which includes abnormal interruption or abnormal exit. If not, and it is determined that the previous lifecycle state is a normal end and the next lifecycle state is a normal start, then the lifecycle monitoring of the virtual machine when the program fails to run will end.

17. The virtualization platform lifecycle monitoring method according to claim 16, characterized in that, If it is determined that the historical transition condition is incorrect, the program is running in an infinite loop, the program has a program running failure, the previous life cycle state ends abnormally, or the next life cycle state begins abnormally, a fault instruction is generated, and the virtual machine enters the fault state in response to the fault instruction.

18. The virtualization platform lifecycle monitoring method according to any one of claims 1-12 and 15-17, characterized in that, Also includes: Obtain the fault source after the virtual machine detects an anomaly and enters the fault state; Restarting the external hardware based on the source of the fault allows the virtual machine to enter a safe working state according to the application scenario.

19. A virtualization platform lifecycle monitoring device, characterized in that, The virtualization platform includes virtual machines, and the device includes: The first acquisition module is used to acquire the lifecycle status of the virtual machine, which includes the startup status, running status, exit status, hibernation status, and fault status of the virtual machine. The second acquisition module is used to acquire the state transition process between the life cycle states, the state transition process including one of the following: the start state transitioning to the running state, the running state transitioning to the exit state, the exit state transitioning to the start state, the running state transitioning to the dormant state, and the fault state transitioning to the exit state; The monitoring module is used to monitor the virtual machine's lifecycle based on the state transition process and the test library, which includes fault injection testing and online testing. If the state transition process is from the startup state to the running state, the monitoring module is specifically used to: respond to configuration instructions to configure the virtual machine and obtain a first timer, wherein the first timer is the configuration start time; The virtual machine that has been configured is powered on and performs a self-test, and the status data after the self-test is obtained according to the power-on self-test items of the virtual machine; If the power-on self-test of the virtual machine is determined to be successful based on the status data, a startup command is executed to cause the virtual machine to enter the startup state, and a second timer and a third timer are acquired, wherein the second timer and the third timer are the end time of the power-on self-test and the start time of the startup state, respectively. The virtual machine that has entered the startup state is subjected to the fault injection test and the online test. When the virtual machine detects an anomaly, it enters the fault state. If it is determined that the virtual machine's transition from the startup state to the running state satisfies the first transition condition, the first transition instruction is responded to cause the virtual machine to enter the running state, and a fourth timer is acquired, wherein the fourth timer is the end time of the startup state; The virtual machine's lifecycle is monitored based on the third and fourth timers.

20. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the virtualization platform lifecycle monitoring method as described in any one of claims 1-18.

21. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the virtualization platform lifecycle monitoring method as described in any one of claims 1-18.

22. A computer program product comprising computer-executable instructions, which, when executed by a processor, are used to implement the virtualization platform lifecycle monitoring method as described in any one of claims 1-18.

Images