Method and device for detecting running state of virtual machine, equipment and storage medium

Abstract

Embodiments of the present application disclose a method for detecting a running state of a virtual machine, comprising: obtaining prediction data for a target virtual machine and feedback data of a target object for the target virtual machine in a preset historical time period; performing random sample generation processing on the prediction data and the feedback data to obtain augmented samples; training a virtual machine running state detection model using the prediction data, the feedback data and the augmented samples as sample data to obtain a trained virtual machine running state detection model; and detecting a running state of a to-be-detected virtual machine using the trained virtual machine running state detection model to obtain the running state of the to-be-detected virtual machine. Embodiments of the present application also provide a device for detecting a running state of a virtual machine, equipment and a storage medium.

Description

Technical Field

[0001] This application relates to the field of electronic equipment technology, and relates to, but is not limited to, methods, apparatuses, devices, and storage media for detecting the running status of virtual machines. Background Technology

[0002] During enterprise digital transformation, it's necessary to migrate business operations and data from local computers to cloud platforms. In large-scale cloud platform applications, determining the running status of virtual machines (VMs) involves using supervised models to automatically identify their operational status. For example, supervised models such as Support Vector Machines (SVM), Logistic Regression (LR), and Regression Trees can be used for detection. Before using a supervised model, it needs to be trained. During training, the VM's running status is scored by a target object to determine the desired running status, which is then used as a label for the VM's running status. Training samples are obtained based on these labels and the VM's operational data, and the supervised model is trained using these samples.

[0003] The above methods require a large number of training samples during the training of supervised models. A large number of training samples necessitates the identification of numerous labels by virtual machine management experts, resulting in high manpower and time costs. Consequently, the model update frequency is low, making it difficult to quickly support the needs of different business scenarios. Summary of the Invention

[0004] This application provides a method, apparatus, device, and storage medium for detecting the running status of a virtual machine.

[0005] The technical solution of this application embodiment is implemented as follows:

[0006] This application provides a method for detecting the running status of a virtual machine. The method includes: acquiring predicted data for a target virtual machine and feedback data from a target object for the target virtual machine within a preset historical time period; performing random sample generation processing on the predicted data and the feedback data to obtain expanded samples; training a virtual machine running status detection model using the predicted data, the feedback data, and the expanded samples as sample data to obtain a trained virtual machine running status detection model; and using the trained virtual machine running status detection model to detect the running status of the virtual machine to be detected, thereby obtaining the running status of the virtual machine to be detected.

[0007] This application provides a device for detecting the running status of a virtual machine. The device includes: an acquisition module for acquiring predicted data for a target virtual machine and feedback data from a target object for the target virtual machine within a preset historical time period; a processing module for performing random sample generation processing on the predicted data and the feedback data to obtain expanded samples; a training module for training a virtual machine running status detection model using the predicted data, the feedback data, and the expanded samples as sample data to obtain a trained virtual machine running status detection model; and a detection module for using the trained virtual machine running status detection model to detect the running status of the virtual machine to be detected, thereby obtaining the running status of the virtual machine to be detected.

[0008] This application provides a device for detecting the running status of a virtual machine. The device includes: a database component for storing prediction data for a target virtual machine and feedback data from a target object for the target virtual machine within a preset historical time period; a virtual machine running status detection component for obtaining the prediction data for the target virtual machine and the feedback data from the target object for the target virtual machine within the preset historical time period from the database component; performing random sample generation processing on the prediction data and the feedback data to obtain expanded samples; training a virtual machine running status detection model using the prediction data, the feedback data, and the expanded samples as sample data to obtain a trained virtual machine running status detection model; and using the trained virtual machine running status detection model to detect the running status of the virtual machine to be detected, thereby obtaining the running status of the virtual machine to be detected.

[0009] This application provides an electronic device, including a memory and a processor. The memory stores a computer program that can run on the processor, and the processor executes the program to implement the steps in the above-described method.

[0010] This application provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps in the above-described method.

[0011] The beneficial effects of the technical solutions provided in this application include at least the following:

[0012] In this embodiment, predicted data for a target virtual machine and feedback data from a target object for the target virtual machine are acquired within a preset historical time period. Random sample generation processing is performed on the predicted data and the feedback data to obtain expanded samples. Using the predicted data, the feedback data, and the expanded samples as sample data, the virtual machine runtime state detection model is trained to obtain the trained virtual machine runtime state detection model. This approach has several advantages. First, expanding the predicted data with feedback data generates a large number of expanded samples, increasing the sample data available for training the virtual machine runtime state detection model and reducing the manpower and time costs of acquiring large amounts of sample data. Second, the expanded samples obtained based on the feedback data conform to the actual runtime state of the virtual machine, allowing the classification hyperplane of the virtual machine runtime state detection model to be quickly adjusted to a position that aligns with user judgment. This means the model can quickly correct prediction results, achieving automatic adaptation to different user scenarios. Third, feedback learning using feedback data enhances the influence of feedback data on the virtual machine runtime state detection model; automated training of the virtual machine runtime state detection model improves its robustness. Attached Figure Description

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

[0014] Figure 1A This application provides an optional architecture diagram of a method for detecting the running status of a virtual machine;

[0015] Figure 1B This application provides a flowchart illustrating a method for detecting the running status of a virtual machine.

[0016] Figure 2A This application provides a data flow diagram of a method for detecting the running status of a virtual machine.

[0017] Figure 2B This application provides a flowchart illustrating a method for detecting the running status of a virtual machine.

[0018] Figure 2C This application provides a performance diagram illustrating a virtual machine runtime status detection model.

[0019] Figure 2D This application provides a flowchart illustrating a method for detecting the running status of a virtual machine.

[0020] Figure 2E This application provides a flowchart illustrating a method for detecting the running status of a virtual machine.

[0021] Figure 2F This application provides an illustration of an application scenario where a virtual machine malfunctions.

[0022] Figure 3 This is a schematic diagram illustrating an application scenario for a method for detecting the running status of a virtual machine, as provided in this application embodiment.

[0023] Figure 4 This application provides a schematic diagram of the composition structure of a virtual machine running status detection device.

[0024] Figure 5 This application provides a schematic diagram of the composition structure of a virtual machine running status detection device.

[0025] Figure 6 This is a schematic diagram of the hardware entity of an electronic device provided in an embodiment of this application. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. The following embodiments are used to illustrate this application, but are not intended to limit the scope of this application. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0027] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0028] It should be noted that the terms "first, second, and third" used in the embodiments of this application are merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first, second, and third" can be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0029] It will be understood by those skilled in the art that, unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which the embodiments of this application pertain. It should also be understood that terms such as those defined in general dictionaries should be understood to have a meaning consistent with their meaning in the context of the prior art, and should not be interpreted in an idealized or overly formal sense unless specifically defined as herein.

[0030] During enterprise digital transformation, it's necessary to migrate business operations and data from local computers to cloud platforms. This necessitates virtual machine resources that can meet the enterprise's business needs. Managing virtual machine resources requires a series of optimization measures to balance operating costs and efficiency, minimizing waste and improving operational efficiency. Determining the operational status of each virtual machine requires expert management to synthesize data such as its configuration, resource consumption by business processes, and virtual machine behavior, consuming significant human and time resources.

[0031] Another method for determining the running status of a virtual machine is to have a running status monitoring program monitor the virtual machine's running data based on pre-set thresholds and rules by virtual machine management experts, and then determine whether the virtual machine's resources need to be optimized based on the monitoring results. However, the pre-set thresholds and rules do not take into account the business status, so they are prone to misjudgment, making it difficult to accurately identify the running status of the virtual machine and increasing the cost of secondary maintenance.

[0032] In large-scale cloud platform applications, determining the running status of virtual machines (VMs) involves using supervised models to automatically identify their operational status. For example, supervised models such as Support Vector Machines (SVM), Logistic Regression (LR), and Regression Trees can be employed. Before using a supervised model, it needs to be trained. During training, a target object, such as a VM management expert, scores the VM's running status based on its operational data, determining the desired running status and using this desired status as a label. Training samples are then obtained based on these labels and the VM's operational data, and the supervised model is trained using these samples.

[0033] The methods described above require a large number of training samples during the training of supervised models. On one hand, a large number of training samples necessitate the identification of numerous labels by virtual machine management experts, resulting in high manpower and time costs and a low model update frequency, making it difficult to quickly support the needs of different business scenarios. On the other hand, a large number of training samples require standardized operational data. However, many vendors use supervised models, and the operational data used by different vendors includes complex metrics. For example, these may include virtual machine monitoring data, network traffic volume, active process lists, user behavior statistics, SSH connection counts, etc. With such complex operational data and metrics, determining the labels for virtual machine operating status is difficult, making it hard to establish fixed and unified standards and reducing the effectiveness of the training samples.

[0034] To help understand the technical solutions of the embodiments of this application, the concepts involved in the embodiments of this application are introduced below:

[0035] A hyperplane is a subspace with a dimension smaller than that of the environment space. When the environment space is 3-dimensional, the hyperplane is a 2-dimensional plane; when the environment space is 2-dimensional, the hyperplane is a 1-dimensional line. The hyperplane represents the geometric meaning of a generalized function and is used to represent a problem to be optimized. The optimal solution to the problem can be found by calculating the gradient of the hyperplane. The faster the hyperplane is adjusted to the position of the optimal solution during the gradient calculation, the shorter the time to find the optimal solution. When a hyperplane is used to solve a classification problem, it is called a classification hyperplane.

[0036] This application provides a method for detecting the running status of a virtual machine, the method being based on a microservice architecture. Figure 1A This is a schematic diagram of an optional architecture for a virtual machine runtime status detection method provided in an embodiment of this application, as shown below. Figure 1A As shown, the microservice architecture 100 includes: a proxy 11, a frontend 12, a time-series database (TSDB) 13, a virtual machine runtime status detection component 14, and a MongoDB database 15. These components can be physically separate or integrated. When these components are located on the same electronic device, the virtual machine runtime status detection component 14 interacts directly with TSDB 13 and MongoDB 15. Each component handles a specific type of business logic, and there is no coupling between the components. If a single virtual machine runtime status component 14 cannot meet the high-efficiency business requirements, multiple virtual machine runtime status detection components can be deployed in the microservice architecture 100, flexibly increasing the number of virtual machines to be detected at a time and improving the efficiency of virtual machine runtime status detection.

[0037] exist Figure 1AUnder the microservice architecture shown, this application embodiment provides a method for detecting the running status of a virtual machine. Figure 1B This is a flowchart illustrating a method for detecting the running status of a virtual machine provided in an embodiment of this application. Figure 1B As shown, the method includes at least the following steps:

[0038] Step S101: Obtain the prediction data for the target virtual machine and the feedback data of the target object for the target virtual machine within a preset historical time period.

[0039] Here, the predicted data is the virtual machine's operating state predicted based on the operating data of the target virtual machine within a preset historical time period. The operating data of the target virtual machine refers to data generated during the virtual machine's operation that reflects the operating state of various components of the virtual machine. For example, such as... Figure 3 As shown, the virtual machine running data may include: the virtual machine's CPU utilization 31, memory utilization 32, and running location 33.

[0040] Here, the target object can be a user using a virtual machine.

[0041] Here, the feedback data refers to the feedback from the virtual machine user regarding the accuracy of the virtual machine's predicted operating state at a given moment, based on the actual operating state of the target virtual machine at that moment. This feedback data serves as data for the system's automatic model optimization, enabling model training and optimization. For example, if the predicted operating state is idle, the virtual machine user, based on the virtual machine's CPU utilization, determines that the virtual machine is in a busy state, corrects the predicted idle state to a busy state, and uses the busy state as the feedback data.

[0042] In one possible implementation, step S101, obtaining prediction data for the target virtual machine within a preset historical time period, includes: obtaining a list of virtual machines to be detected; obtaining the running data of each virtual machine in the virtual machine list within the preset historical time period; wherein the running data is collected by the host machine running each virtual machine; and determining the prediction data for the target virtual machine based on the running data of each virtual machine.

[0043] Here, as Figure 1A As shown, the Agent11 process collects configuration data from the virtual machines and saves the collected configuration data to MongoDB15. The virtual machine runtime status detection component 14 obtains a list of virtual machines to be detected from MongoDB15. Here, the list of virtual machines to be detected includes the number and configuration information of the virtual machines to be detected.

[0044] Here, considering that the data within virtual machines in a managed cloud environment belongs to user data, and for security reasons, user consent is required before installing an agent within the virtual machine to collect runtime data. This limits the types of data that can be used to assess the virtual machine's runtime status. In this situation, the method used by Site Reliability Engineers (SREs) to analyze virtual machine runtime status requires first observing the virtual machine's resource usage to determine if it is idle. However, by collecting runtime data from the host machine running each virtual machine, the security of user data can be improved, and the complexity of virtual machine runtime status analysis can be reduced.

[0045] Here, the agent that obtains virtual machine running data is installed on the host machine running the virtual machine. It collects running data such as CPU utilization, memory utilization, disk utilization, and running location of the virtual machine from the Qemu layer (CPU virtualization layer) on the host machine.

[0046] In one feasible approach, after the user authorizes the virtual machine to install the Agent, the Agent installed in the virtual machine can further collect runtime data such as the virtual machine's boot time and keyboard and mouse operation time, as shown in Table 1, to help predict the virtual machine's running status.

[0047] In the above implementation process, the running data is collected by the host machine running each virtual machine. This makes it applicable to scenarios where data collection is done without virtual machine intrusion. By adopting a host machine monitoring strategy, all virtual machine status information is collected from its host machine without intrusion into the virtual machine, which improves the security of the virtual machine and enhances the usability of the virtual machine running status detection method.

[0048] In one possible implementation, determining the predicted data of the target virtual machine based on the runtime data of each of the virtual machines includes: determining the runtime data of the target virtual machine from the runtime data of at least one virtual machine; performing feature extraction on the runtime data of the target virtual machine to obtain the central tendency statistics and volatility characteristics of the runtime data; and determining the predicted data of the target virtual machine based on the central tendency statistics and volatility characteristics.

[0049] Here, the feature extraction process may include performing mathematical and statistical feature analysis on historical operating data, constructing effective features for training the model through feature analysis, so as to improve the prediction accuracy of the trained model.

[0050] Here, feature extraction can expand the information of business data such as operational data, enhance the information expression ability of operational data, and enable the virtual machine operation status detection model to better fit the distribution of data in high-dimensional space.

[0051] Here, feature extraction may include, but is not limited to, variance filtering, joint hypothesis testing, F-test, mutual information verification, and analysis combined with business scenarios for runtime data. Through feature extraction, commonly used features for time-series indicators in machine learning can be screened and verified to obtain stable and effective features in the scenario of identifying virtual machine runtime states. Here, stable and effective features may include calculating the indicators in Table 3 for runtime data to obtain the central tendency statistics and volatility characteristics of the runtime data.

[0052] In one possible implementation, the predicted data for the target virtual machine is determined based on the central tendency statistics and volatility characteristics, including: using the features obtained based on the feature extraction methods listed in Table 3, and combining them with the labels determined for the target object to form the predicted data for the virtual machine, the expression for the predicted data being as shown in formula (2-1):

[0053]

[0054] in, This represents the predicted data. a, β, γ, and δ represent any one of the following characteristics: CPU utilization variance, maximum memory utilization, minimum memory utilization, and minimum disk utilization, respectively. `idle` indicates the virtual machine is in an idle state, and `busy` indicates the virtual machine is in a running state.

[0055] In the above implementation process, the prediction data of the target virtual machine is determined based on the central tendency statistics and volatility characteristics. In this way, the classification hyperplane of the virtual machine running state detection model is not affected by irrelevant features, which improves the effectiveness of model training, reduces the noise of the training model, and the resulting virtual machine running state detection model has a faster prediction speed and higher prediction accuracy.

[0056] In one possible implementation, before determining the predicted data of the target virtual machine based on the running data of each virtual machine, the method further includes: determining an abnormal running time period for the virtual machines based on the running data of each virtual machine; wherein, during the abnormal running time period, the proportion of virtual machines with abnormal running data is greater than a preset proportion threshold; and determining the running data that is not in the abnormal running time period as the running data of each virtual machine.

[0057] Here, when anomalies occur in the virtual machine's runtime data, the virtual machine's operating environment may experience issues such as system upgrades, power outages, or restarts. These problems are difficult to detect during operation, and fluctuations caused by missing data can lead to deviations in prediction results. Therefore, it is necessary to handle anomalies in the runtime data during the data preprocessing stage to improve the accuracy of the runtime data. Handling anomalies in runtime data may include: statistically analyzing the similarity of data missing time points in the virtual machine to be tested, determining whether the similarity ratio exceeds a certain threshold, and if it exceeds the threshold, grouping adjacent data missing time points into an abnormal time period, identifying and automatically skipping possible abnormal time periods in the environment. For example, as shown... Figure 2F As shown, virtual machines 32, 33, and 35 have missing data between time tx and ty (EmptyDataRangex-y), and the calculated support ratio for SR-1 (abnormal time period 1) is 0.6; device d has missing data between time node to and tp (EmptyDataRangeo-p), and the calculated support ratio for SR-2 (abnormal time period 2) is 0.2. The expressions for the judgment conditions include:

[0058] If:Support(EmptyDataRange x-y )>=threshold

[0059] then→DataSequence=DataSequence[:x]=DataSequence[y:]

[0060] Among them, it is determined whether the support of the time period when the data is empty is greater than the threshold. If it is greater, it indicates that most virtual machines in the environment are missing data at that time, which is an environmental problem. The running data in the abnormal time period is skipped for detection.

[0061] For example, with a threshold of 0.5, meaning more than 50% of devices in the environment have missing data within the same SR (abnormal time period), the running data within the abnormal time period is skipped. This means that virtual machines 32, 33, and 35 will not use data within the tx to ty time period when making predictions. However, virtual machine 34 has a device support ratio of less than 0.2, therefore, without skipping data within the abnormal time period, virtual machine 34 can use data within the to to tp time period when making predictions.

[0062] In the above implementation process, based on the operating data of each virtual machine, an abnormal operating period is determined; wherein, within the abnormal operating period, the proportion of virtual machines with abnormal operating data is greater than a preset proportion threshold; the operating data not within the abnormal operating period is determined as the operating data of each virtual machine. In this way, the impact of operating data fluctuations caused by virtual machine online upgrades, power outages, and other scenarios on prediction accuracy can be automatically detected and reduced.

[0063] Step S102: Perform random sample generation processing on the predicted data and the feedback data to obtain expanded samples.

[0064] Here, the process of determining the augmented samples can be implemented through unsupervised or semi-supervised learning. The augmented samples can quickly correct model biases and optimize the model. However, since the amount of feedback data is limited, using it for model training is insufficient to directly change the model's bias; therefore, the feedback samples need to be expanded to the target order of magnitude. Semi-supervised or unsupervised models can be used to randomly generate augmented samples based on the feedback data. For example, as... Figure 2E As shown, the predicted data is clustered to obtain at least one category c1(27), c2(28), and c3(29); the boundary points e1(30) and e2(31) of category 27, 28, and 29 of the feedback data t1(26) are determined, that is, the range of expanded samples of category 27 is generated by t1(26). The sample points n1 to n5 within the range are expanded samples, and the category of the expanded samples is 27.

[0065] In one possible implementation, step S102, which involves performing random sample generation processing on the predicted data and the feedback data to obtain expanded samples, includes: clustering the predicted data to obtain at least one cluster; determining the distance between the feedback data and the cluster center of each cluster to obtain the cluster center with the shortest distance; iteratively executing: determining the center point between the feedback data and the cluster center with the shortest distance, identifying the center point as an expanded sample, and updating the center point to the cluster center with the shortest distance; until a target number of expanded samples are obtained. For example, as shown in the following code snippet, a clustering algorithm is used to divide the predicted data into k classes (to ensure the accuracy of the generated expanded samples, it is recommended to set k to a minimum of 10); initializing the generated sample set Set(); and sequentially calculating the feedback data. With existing cluster centers Find the distance and locate the cluster center vector corresponding to the shortest distance. As a variable and feedback sample vector as variables Set the target number N for expanding the sample size; the larger N is, the greater the magnitude of model change. Here, N defaults to 1% of the existing sample size. Iteratively use the dichotomy algorithm to calculate the center point of the feedback data and cluster centers, add them to the generated sample set, and set this center point as a new variable. Continue until N is zero; return the generated expanded sample set.

[0066]

[0067] In the above implementation process, the expansion samples are determined based on feedback data and prediction data. On the one hand, this increases the amount of prediction data used for training when the amount of running data is limited; on the other hand, in an online environment, after the baseline model is deployed, the prediction data is expanded using user feedback data. This allows the model to quickly correct prediction results, achieving the goal of automatically adapting to different user scenarios.

[0068] Step S103: Using the predicted data, the feedback data, and the expanded samples as sample data, train the virtual machine running status detection model to obtain the trained virtual machine running status detection model.

[0069] Here, the virtual machine running status detection model can be a highly scalable model that can classify features under multiple different scales, predict unstandardized features, add or delete new features, and classify the results as probabilities, so as to adapt to different feature and running data scenarios.

[0070] In one possible implementation, the virtual machine runtime status detection model is a random forest model. Exemplarily, machine learning modeling can use a random forest model. Exemplarily, the added features may include: 1) user-added metrics; for example, added network traffic metrics; 2) added methods for extracting features from Table 3, for example, discovering features with expressive meaning.

[0071] In the above implementation process, the virtual machine running status detection model is a random forest model. This model can simultaneously accommodate features of multiple different scales for classification without requiring feature standardization. It is suitable for scenarios that consider different numbers of virtual machine indicators and behavioral data. Furthermore, using a random forest model also facilitates the addition or removal of new features, improving the model's scalability when data collection capabilities vary across different cloud platforms.

[0072] Step S104: Using the trained virtual machine running status detection model, the running status of the virtual machine to be detected is detected to obtain the running status of the virtual machine to be detected.

[0073] In one possible implementation, the running state of the virtual machine to be detected is the idle probability of the virtual machine to be detected. For example, as... Figure 2D As shown, the running data of the virtual machine to be tested is input into the random forest model. The decision stumps 23 in the random forest model are classified according to the running data to obtain multiple classification results 24. The running status of the virtual machine to be tested is predicted according to the algorithm 25 for determining the idle probability.

[0074] In the above embodiment, the running state of the virtual machine to be detected is the idle probability of the virtual machine to be detected. In this way, the model outputs not a "yes / no" question, but a "virtual machine idle probability". By adjusting the sensitivity to the "idle probability", it can be applied to different business models of different users, thereby reducing the false alarm rate of idleness.

[0075] In this embodiment, predicted data for a target virtual machine and feedback data from a target object for the target virtual machine are acquired within a preset historical time period. Random sample generation processing is performed on the predicted data and the feedback data to obtain expanded samples. Using the predicted data, the feedback data, and the expanded samples as sample data, the virtual machine runtime state detection model is trained to obtain the trained virtual machine runtime state detection model. This approach has several advantages. First, expanding the predicted data with feedback data generates a large number of expanded samples, increasing the sample data available for training the virtual machine runtime state detection model and reducing the manpower and time costs of acquiring large amounts of sample data. Second, the expanded samples obtained based on the feedback data conform to the actual runtime state of the virtual machine, allowing the classification hyperplane of the virtual machine runtime state detection model to be quickly adjusted to a position that aligns with user judgment. This means the model can quickly correct prediction results, achieving automatic adaptation to different user scenarios. Third, feedback learning using feedback data enhances the influence of feedback data on the virtual machine runtime state detection model; automated training of the virtual machine runtime state detection model improves its robustness.

[0076] exist Figure 1A In the microservice architecture shown, the steps for data exchange between components are as follows: Figure 2A As shown, it includes:

[0077] Step S201: Save the virtual machine running data.

[0078] Here, the agent process collects virtual machine runtime data and saves the collected runtime data to TSDB13. Here, as... Figure 3 As shown, the virtual machine running data may include: the virtual machine's CPU utilization 31, memory utilization 32, and running location 33.

[0079] In one feasible approach, after the user authorizes the virtual machine to install the Agent, the Agent installed in the virtual machine can further collect runtime data such as the virtual machine's boot time and keyboard and mouse operation time, as shown in Table 1, to help predict the virtual machine's running status.

[0080] Table 1 Virtual Machine Running Data

[0081]

[0082] Step S202: Save the virtual machine configuration data.

[0083] Here, as Figure 3 As shown, the virtual machine configuration data may include: load status 34, virtual machine ID 35, user name 36, virtual machine name 37, number of CPU cores 38, memory size 39, and operating system 40. Here, the agent process collects the virtual machine configuration data and saves the collected configuration data to MongoDB.

[0084] Step S203: The virtual machine running status detection component obtains a list of virtual machines to be detected from MongoDB.

[0085] Step S204: The virtual machine running status detection component acquires the running data of the virtual machine to be detected.

[0086] Here, the virtual machine runtime status detection component retrieves historical runtime data from the TSDB in the order of the virtual machines in the list.

[0087] Step S205: The virtual machine running status detection component predicts the running status of the virtual machine.

[0088] Here, the virtual machine runtime status detection component performs online prediction based on periodically retrieved virtual machine runtime data to obtain the prediction result, i.e., the virtual machine runtime status. The virtual machine detection component includes a virtual machine runtime status detection model. Using a trained virtual machine runtime status detection model, the runtime status of the virtual machine to be detected is detected, and the runtime status of the virtual machine to be detected is predicted. The methods for training the virtual machine runtime status detection model and predicting the virtual machine runtime status are as follows: Figure 2B As shown, the method includes the following steps S2051 to S2058.

[0089] Step S2051: Collect historical running data of the virtual machine.

[0090] Here, collecting historical running data of virtual machines requires the cloud platform where the virtual machine resides to have the function of collecting virtual machine running data.

[0091] In step S2052, the target object determines the label of the virtual machine's running status based on the running data, and obtains the predicted data.

[0092] Here, the target audience can include virtual machine management experts and users. In determining the labels, 100 basic samples of virtual machines in different usage scenarios are needed to meet the training and sample expansion requirements of the virtual machine runtime status detection model.

[0093] Step S2053: Extract features from historical operating data.

[0094] Table 2 Comparison of Feature Processing in Supervised Learning Models:

[0095]

[0096]

[0097] As shown in Table 2, among the related technologies, in the absence of virtual machine sample datasets, using machine learning models and selectively choosing features with high expressive power in idle virtual machine detection scenarios can achieve a relatively optimal balance between learning speed, interpretability, and accuracy. Performance comparisons for different dimensions are as follows: Figure 2C As shown, deep network model 21 has stronger generalization ability than machine learning model 22, but lower extraction efficiency. Here, stable and effective features can include calculating the indicators in Table 3 on the running data to obtain the central tendency statistics and volatility features of the running data.

[0098] Table 3 Features to be extracted

[0099]

[0100]

[0101] The statistical characteristics listed in Table 3 can describe the volatility and central tendency of time-series running data relatively completely, reflecting the activity level of the virtual machine over a period of time.

[0102] Here, based on the indicators listed in Table 3, feature extraction can be performed on each of the virtual machine's runtime data, such as CPU utilization and memory utilization, to obtain multiple features (a, β, γ, δ...) as shown in Formula (2-1). The predicted data composed of these multiple features is then used as one type of sample data for training the virtual machine runtime status detection model. In this way, the classification hyperplane of the training virtual machine runtime status detection model is not affected by irrelevant features, improving the effectiveness of model training, reducing noise in the training model, and resulting in a faster prediction speed and higher prediction accuracy. For example, using the same random forest model, feature extraction based on the indicators listed in Table 3, compared to the commonly used extraction of full statistical features from time-series data, reduces the time spent by the model processing the runtime data of the virtual machine to be predicted and providing the prediction result of its runtime status by more than 65% after targeted feature optimization, and increases the prediction accuracy from 90% to 95%.

[0103] Step S2054, machine learning modeling.

[0104] Here, the machine learning model is a virtual machine runtime status detection model. This model can be a highly scalable machine learning model capable of classifying features under multiple different scales, predicting unstandardized features, adding or deleting new features, and providing probabilistic classification results, thus adapting to scenarios with different features and runtime data.

[0105] Step S2055: Obtain the running data of the virtual machine to be detected, and extract features from the running data.

[0106] Here, the trained machine learning model can be deployed on a cloud platform system. After obtaining the running data of the virtual machine to be tested, the machine learning model deployed on the cloud platform system can extract features from the running data.

[0107] Step S2056: Determine the running status of the virtual machine to be detected and obtain the predicted idle probability of the virtual machine.

[0108] In one possible implementation, after obtaining the running status of the virtual machine, the method further includes: providing disposal suggestions for the virtual machine based on its idle status. Table 4 is a table of virtual machine disposal suggestions. As shown in Table 4, for virtual machines with a predicted idle probability of less than 20%, the virtual machine is determined to be in an active state; for virtual machines with a predicted idle probability of less than 50% but more than 20%, the virtual machine is determined to be in an occasionally active state, and appropriate downsizing can be implemented; for virtual machines with a predicted idle probability of less than 80% but more than 50%, the virtual machine is determined to be in an inactive state; and for virtual machines with a predicted idle probability of more than 80%, the virtual machine is determined to be in an inactive state.

[0109] Table 4 Recommendations for Virtual Machine Handling

[0110]

[0111] Here, based on the virtual machine handling suggestions in Table 4, the executable operations can be output to the user, reducing the cost for the user to understand the model output and improving the convenience of user use.

[0112] In one feasible approach, in addition to the aforementioned handling suggestions, a virtual machine blacklist / whitelist mechanism can be established. When a virtual machine is used to run critical business processes, regardless of resource usage, it should not be shut down or have its resources reclaimed by the platform. Through a time-dependent blacklist / whitelist mechanism that marks specific virtual machines, no predictions or reclamation suggestions will be made for that virtual machine within a certain period. This mechanism is easily deployed across different cloud platforms, allowing users to decide whether to predict virtual machine usage based on specific business needs. Users can obtain feedback on whether a virtual machine that should not be reclaimed is running a critical process. This helps the model uncover the data relationship between virtual machine resource usage and the running of critical processes, enabling automatic identification of critical processes and providing more granular handling suggestions and actions, offering users a reference for handling.

[0113] Step S2057: Obtain feedback data on the running status.

[0114] Here, the cloud platform system can collect user feedback data on the virtual machine's runtime status predicted by the virtual machine runtime status detection model.

[0115] Step S2058: Based on the feedback data and prediction data, determine the expanded sample to correct the virtual machine running status detection model, and use the corrected virtual machine running status detection model to predict the running status of the virtual machine.

[0116] In one possible implementation, after obtaining the expanded samples, the method further includes: using the predicted data, the feedback data, and the expanded samples as sample data to train the virtual machine running state detection model, thereby obtaining the trained virtual machine running state detection model.

[0117] In the above implementation process, the expanded samples are determined based on feedback data and prediction data. On the one hand, this increases the amount of prediction data used for training when there is limited running data; on the other hand, in an online environment, after the baseline model is deployed, the prediction data is expanded using user feedback data. This allows the model's classification hyperplane to be quickly adjusted to a position that matches the user's judgment, meaning the model can quickly correct its prediction results and automatically adapt to different user scenarios.

[0118] In the above implementation process, steps S2051 to S2054 are the offline training process of the model, and steps S2055 to S2058 are the online prediction process of the model.

[0119] Step S206: Save the running state of the virtual machine.

[0120] Here, the predicted virtual machine running status is saved to the intermediate cache database TSDB, awaiting invocation by the frontend service. The virtual machine running status detection component is completely decoupled from the running data and the frontend, eliminating the need to maintain service status. Increasing the number of virtual machine running status detection components allows for flexible scaling of the number of virtual machines processed at a time, improving detection efficiency in a microservice architecture.

[0121] Step S207: Obtain the virtual machine's running data and running status.

[0122] Here, the front-end retrieves the virtual machine's runtime data and status from the TSDB database and displays them to the user. In one possible implementation, the virtual machine runtime status detection component obtains data based on the virtual machine's runtime data, such as... Figure 3 The analytical conclusions shown include, for example, the reclaimable resource sensitivity of virtual machines 41, the idle trend graph 42, the idle rate 43, and the total number of idle virtual machines 44.

[0123] Step S208: Save the user's feedback data on the running status of the virtual machine.

[0124] Step S209: Obtain feedback data.

[0125] Here, the virtual machine runtime status detection component periodically receives feedback data and re-optimizes the virtual machine runtime status detection model in the component based on the feedback data.

[0126] In the above embodiments, by acquiring the runtime data of the target virtual machine, predictive data is determined based on the runtime data. Random sample generation processing is performed on the predictive data and the feedback data from the target object regarding the target virtual machine to obtain expanded samples. Using the predictive data, feedback data, and the expanded samples as sample data, the virtual machine runtime status detection model is trained to obtain the trained virtual machine runtime status detection model. Using the virtual machine runtime status detection model, the runtime status of the virtual machine to be detected is determined, and the predicted idle probability of the virtual machine is obtained. In this way, expanded samples can be generated through feedback data, achieving automatic model optimization while reducing manual costs, and improving the convergence speed and prediction accuracy of the trained model.

[0127] Based on the foregoing embodiments, this application further provides a device for detecting the running status of a virtual machine. The control device includes all the modules included, which can be implemented by a processor in an electronic device; of course, it can also be implemented by specific logic circuits. In the implementation process, the processor can be a central processing unit (CPU), a microprocessor (MPU), a digital signal processor (DSP), or a field programmable gate array (FPGA), etc.

[0128] Figure 4 This is a schematic diagram of the composition structure of a virtual machine running status detection device provided in an embodiment of this application, as shown below. Figure 4 As shown, the device 400 includes an acquisition module 401, a processing module 402, a training module 403, and a detection module 404, wherein:

[0129] The acquisition module 401 is used to acquire prediction data for the target virtual machine and feedback data from the target object for the target virtual machine within a preset historical time period; the processing module 402 is used to perform random sample generation processing on the prediction data and the feedback data to obtain expanded samples; the training module 403 is used to train the virtual machine running status detection model using the prediction data, the feedback data and the expanded samples as sample data to obtain the trained virtual machine running status detection model; the detection module 404 is used to use the trained virtual machine running status detection model to detect the running status of the virtual machine to be detected to obtain the running status of the virtual machine to be detected.

[0130] In some possible embodiments, the processing module 402 is further configured to: cluster the predicted data to obtain at least one cluster; determine the distance between the feedback data and the cluster center of each cluster to obtain the cluster center with the shortest distance; iteratively execute: determine the center point between the feedback data and the cluster center with the shortest distance, determine the center point as an expanded sample, and update the center point as the cluster center with the shortest distance; until a target number of expanded samples are obtained.

[0131] In some possible embodiments, the acquisition module 401 is further configured to: acquire a list of virtual machines to be detected; acquire the running data of each virtual machine in the list of virtual machines within the preset historical time period; wherein the running data is collected by the host machine running each virtual machine; and determine the predicted data of the target virtual machine based on the running data of each virtual machine.

[0132] In some possible embodiments, the acquisition module 401 is further configured to: determine the running data of a target virtual machine from the running data of at least one virtual machine; perform feature extraction on the running data of the target virtual machine to obtain the central tendency statistics and volatility characteristics of the running data; and determine the predicted data of the target virtual machine based on the central tendency statistics and volatility characteristics.

[0133] In some possible embodiments, the device 400 further includes a determining module, configured to: determine a virtual machine abnormal operation period based on the operation data of each virtual machine; wherein, during the virtual machine abnormal operation period, the proportion of virtual machines with abnormal operation data is greater than a preset proportion threshold; and determine the operation data that is not in the virtual machine abnormal operation period as the operation data of each virtual machine.

[0134] In some possible embodiments, the virtual machine running status detection model is a random forest model, and the running status of the virtual machine to be detected is the idle probability of the virtual machine to be detected.

[0135] It should be noted that the descriptions of the above device embodiments are similar to those of the above method embodiments, and have similar beneficial effects. For technical details not disclosed in the device embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0136] It should be noted that, in the embodiments of this application, if the above methods are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiments of this application, or the part that contributes to the related technology, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause an electronic device (which may be a smartphone, tablet computer, etc. with a camera) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, mobile hard drives, read-only memory (ROM), magnetic disks, or optical disks. Thus, the embodiments of this application are not limited to any specific hardware and software combination.

[0137] Correspondingly, embodiments of this application provide a computer-readable storage medium storing a computer program thereon. When executed by a processor, the computer program implements the steps in any of the virtual machine running state detection methods described in the above embodiments. Correspondingly, embodiments of this application provide a chip including programmable logic circuits and / or program instructions. When the chip is executed, it is used to implement the steps in any of the virtual machine running state detection methods described in the above embodiments. Correspondingly, embodiments of this application provide a computer program product. When executed by a processor of an electronic device, the computer program product is used to implement the steps in any of the virtual machine running state detection methods described in the above embodiments.

[0138] Based on the same technical concept, this application provides a device for detecting the running status of a virtual machine, used to implement the method for detecting the running status of a virtual machine as described in the above method embodiments. Figure 5 This is a schematic diagram of the composition structure of a virtual machine running status detection device provided in an embodiment of this application, as shown below. Figure 5 As shown, the electronic device 500 includes: a database component 501 and a virtual machine running status detection component 502, wherein: the database component 501 is used to store prediction data for the target virtual machine and feedback data from the target object for the target virtual machine within a preset historical time period;

[0139] The virtual machine runtime status detection component 502 is used to obtain prediction data for the target virtual machine and feedback data from the target object for the target virtual machine within a preset historical time period from the database component; perform random sample generation processing on the prediction data and the feedback data to obtain expanded samples; use the prediction data, the feedback data, and the expanded samples as sample data to train the virtual machine runtime status detection model to obtain the trained virtual machine runtime status detection model; and use the trained virtual machine runtime status detection model to detect the runtime status of the virtual machine to be detected to obtain the runtime status of the virtual machine to be detected.

[0140] In the above embodiments, the virtual machine running status detection component obtains the predicted data for the target virtual machine and the feedback data of the target object for the target virtual machine within a preset historical time period from the database component. This allows the virtual machine running status detection component to interact with components such as the database without needing to interact with a server that has a database. In this way, the functions provided by microservices can be deployed as plug-ins on a single terminal device. When it is necessary to expand the functions, the processing efficiency and resource allocation efficiency of the service can be improved by deploying multiple plug-ins at the same time, thereby improving the accuracy and discrimination efficiency of idle detection in actual online hosted cloud scenarios.

[0141] Based on the same technical concept, this application provides an electronic device for implementing the virtual machine running status detection method described in the above method embodiments. Figure 6 This is a schematic diagram of the hardware entity of an electronic device provided in an embodiment of this application, such as... Figure 6 As shown, the electronic device 600 includes a memory 610 and a processor 620. The memory 610 stores a computer program that can run on the processor 620. When the processor 620 executes the program, it implements the steps in any of the methods described in the embodiments of this application.

[0142] Memory 610 is configured to store instructions and applications executable by processor 620, and may also cache data to be processed or already processed by processor 620 and various modules in the electronic device (e.g., image data, audio data, voice communication data, and video communication data). It can be implemented using flash memory or random access memory (RAM). When processor 620 executes a program, it implements the steps of any of the above methods. Processor 620 typically controls the overall operation of electronic device 600.

[0143] The aforementioned processor can be at least one of the following: Application Specific Integrated Circuit (ASIC), Digital Signal Processor (DSP), Digital Signal Processing Device (DSPD), Programmable Logic Device (PLD), Field Programmable Gate Array (FPGA), Central Processing Unit (CPU), Controller, Microcontroller, and Microprocessor. It is understood that other electronic devices can also implement the functions of the aforementioned processor, and this application does not specifically limit the specific implementation.

[0144] The aforementioned computer storage media / memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic random access memory (FRAM), flash memory, magnetic surface memory, optical disc, or compact disc read-only memory (CD-ROM), etc.; or it can be various electronic devices that include one or any combination of the above-mentioned memories, such as mobile phones, computers, tablet devices, personal digital assistants, etc.

[0145] It should be noted that the descriptions of the storage medium and device embodiments above are similar to the descriptions of the method embodiments above, and have similar beneficial effects. For technical details not disclosed in the storage medium and device embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0146] It should be understood that the phrase "one embodiment" or "an embodiment" throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that in the various embodiments of this application, the sequence numbers of the above-described processes do not imply a sequential order of execution; the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. The sequence numbers of the above-described embodiments are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0147] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0148] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces, and the indirect coupling or communication connection between devices or units can be electrical, mechanical, or other forms.

[0149] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units. They may be located in one place or distributed across multiple network units. Some or all of the units may be selected to achieve the purpose of the embodiments of this application, depending on actual needs.

[0150] In addition, each functional unit in the various embodiments of this application can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit; the integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0151] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to related technologies, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause the device automatic test line to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROMs, magnetic disks, or optical disks.

[0152] The methods disclosed in the several method embodiments provided in this application can be arbitrarily combined without conflict to obtain new method embodiments.

[0153] The features disclosed in the several method or device embodiments provided in this application can be arbitrarily combined without conflict to obtain new method or device embodiments.

[0154] The above description is merely an embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for detecting the running status of a virtual machine, characterized in that, The method includes: Obtain prediction data for the target virtual machine and feedback data from the target object for the target virtual machine within a preset historical time period; The predicted data is clustered to obtain at least one cluster; the distance between the feedback data and the cluster center of each cluster is determined to obtain the cluster center with the shortest distance; iterative execution: determining the center point between the feedback data and the cluster center with the shortest distance, determining the center point as an expanded sample, and updating the center point as the cluster center with the shortest distance; until the target number of expanded samples is obtained; the expanded samples are samples that conform to the actual running state of the virtual machine; Using the predicted data, the feedback data, and the expanded samples as sample data, the virtual machine running status detection model is trained to obtain the trained virtual machine running status detection model. The trained virtual machine running status detection model is used to detect the running status of the virtual machine to be detected, thereby obtaining the running status of the virtual machine to be detected.

2. The method as described in claim 1, characterized in that, The acquisition of prediction data for the target virtual machine within a preset historical time period includes: Get the list of virtual machines to be tested; Obtain the running data of each virtual machine in the virtual machine list within the preset historical time period; wherein, the running data is collected by the host machine running each virtual machine; Based on the runtime data of each virtual machine, the predicted data for the target virtual machine is determined.

3. The method as described in claim 2, characterized in that, The step of determining the predicted data for the target virtual machine based on the runtime data of each virtual machine includes: Determine the runtime data of the target virtual machine from the runtime data of at least one virtual machine; Feature extraction is performed on the runtime data of the target virtual machine to obtain the central tendency statistics and volatility characteristics of the runtime data; Based on the central tendency statistics and volatility characteristics, the predicted data for the target virtual machine are determined.

4. The method as described in claim 2, characterized in that, Before determining the predicted data for the target virtual machine based on the runtime data of each of the virtual machines, the method further includes: Based on the running data of each virtual machine, a time period of abnormal virtual machine operation is determined; wherein, during the time period of abnormal virtual machine operation, the proportion of virtual machines with abnormal running data is greater than a preset proportion threshold. The running data that is not within the abnormal running time period of the virtual machine is determined as the running data of each virtual machine.

5. The method according to any one of claims 1 to 4, characterized in that, The virtual machine running status detection model is a random forest model, and the running status of the virtual machine to be detected is the idle probability of the virtual machine to be detected.

6. A device for detecting the running status of a virtual machine, characterized in that, The device includes: A database component is used to store prediction data for the target virtual machine and feedback data from the target object to the target virtual machine within a preset historical time period. A virtual machine runtime status detection component is used to obtain predicted data for a target virtual machine and feedback data from a target object for the target virtual machine within a preset historical time period from the database component; cluster the predicted data to obtain at least one cluster; determine the distance between the feedback data and the cluster center of each cluster to obtain the cluster center with the shortest distance; iteratively execute: determine the center point between the feedback data and the cluster center with the shortest distance, determine the center point as an expanded sample, and update the center point to the cluster center with the shortest distance; until a target number of expanded samples are obtained; the expanded samples are samples that conform to the actual runtime status of the virtual machine; use the predicted data, the feedback data, and the expanded samples as sample data to train the virtual machine runtime status detection model to obtain a trained virtual machine runtime status detection model; use the trained virtual machine runtime status detection model to detect the runtime status of the virtual machine to be detected, and obtain the runtime status of the virtual machine to be detected.

7. A device for detecting the running status of a virtual machine, characterized in that, The device includes: The acquisition module is used to acquire prediction data for the target virtual machine and feedback data from the target object for the target virtual machine within a preset historical time period. The processing module is used to cluster the predicted data to obtain at least one cluster; determine the distance between the feedback data and the cluster center of each cluster to obtain the cluster center with the shortest distance; iteratively execute: determine the center point between the feedback data and the cluster center with the shortest distance, determine the center point as an expanded sample, and update the center point as the cluster center with the shortest distance; until a target number of expanded samples are obtained; the expanded samples are samples that conform to the actual running state of the virtual machine; The training module is used to train the virtual machine running status detection model using the predicted data, the feedback data, and the expanded samples as sample data, so as to obtain the trained virtual machine running status detection model. The detection module is used to perform runtime status detection on the virtual machine to be detected using the trained virtual machine runtime status detection model, and obtain the runtime status of the virtual machine to be detected.

8. An electronic device comprising a memory and a processor, the memory storing a computer program executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the method according to any one of claims 1 to 5.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method of any one of claims 1 to 5.

Images