Virtual machine network detection method and device, equipment, storage medium and program

Abstract

The invention discloses a virtual machine network detection method and device, equipment, a storage medium and a program, and relates to the technical field of cloud platforms, and the method comprises the steps: monitoring a logic router created in a southbound database, and determining a logic switch associated with the logic router; under the condition that a connection relationship is established between the logic router and the logic switch, creating a switching port for detecting the logic of the second-layer gateway for the logic router, and binding the switching port with the detection service node and the virtual machine network; determining a data path binding table and a port binding table corresponding to the target virtual machine according to the binding result under the condition that the target virtual machine in the virtual machine network needs to be detected; and based on the data path binding table and the port binding table, carrying out period detection on a network used by the target virtual machine so as to adjust configuration parameters of the target virtual machine according to a detection result.

Description

Technical Field

[0001] This application relates to the field of cloud platform technology, and more specifically, to a method, apparatus, device, storage medium, and program for detecting virtual machine networks. Background Technology

[0002] In cloud computing environments, the network, as a critical component of infrastructure, is essential for the quality of cloud services due to its stability and connectivity. With the continuous development and widespread adoption of virtualization technology, Network Function Virtualization (NFV) has become a mainstream trend in cloud data centers, aiming to provide flexible and elastic network services. OpenStack, a leading open-source cloud infrastructure management platform, uses its Neutron component to manage network resources, while the Open Virtual Network (OVN), as the backend of Neutron, implements network function virtualization, providing a high-performance network virtualization solution. Although the combination of Neutron and OVN can meet the virtual network management needs of large-scale cloud environments, when facing virtual machine connectivity detection scenarios, related technologies typically rely on OVN-SB (Southbound Database) to share detection results. However, OVN-SB, as a lightweight database, has limited capabilities in handling high concurrency and large amounts of data. Especially in large-scale cluster environments, frequent read and write operations can put enormous pressure on the database, potentially leading to cluster instability.

[0003] Currently, there is no effective solution to the problem that virtual machine network connectivity detection often affects the overall performance of virtual machine services and leads to low efficiency in virtual machine network detection. Summary of the Invention

[0004] This application provides a method, apparatus, device, storage medium, and program for detecting virtual machine networks, in order to at least solve the problem in related technologies that virtual machine network connectivity detection often affects the overall performance of virtual machine services, resulting in low efficiency in detecting virtual machine networks.

[0005] According to one embodiment of this application, a method for detecting a virtual machine network is provided, comprising: monitoring a logical router created in a southbound database and determining the logical switch associated with the logical router; when a connection relationship is established between the logical router and the logical switch, creating a switch port for detecting the Layer 2 gateway logic for the logical router, and binding the switch port to a detection service node and the virtual machine network; when it is determined that a target virtual machine in the virtual machine network needs to be detected, determining a data path binding table and a port binding table corresponding to the target virtual machine based on the binding result; periodically detecting the network used by the target virtual machine based on the data path binding table and the port binding table, so as to adjust the configuration parameters of the target virtual machine according to the detection result.

[0006] According to another embodiment of this application, a virtual machine network detection device is provided, comprising: a first determining module, configured to monitor logical routers created in a southbound database and determine the logical switches associated with the logical routers; a binding module, configured to, when the logical routers and the logical switches establish a connection relationship, create a switching port for detecting Layer 2 gateway logic for the logical routers, and bind the switching port to a detection service node and a virtual machine network; a second determining module, configured to, when it is determined that a target virtual machine in the virtual machine network needs to be detected, determine a data path binding table and a port binding table corresponding to the target virtual machine based on the binding result; and a detection module, configured to periodically detect the network used by the target virtual machine based on the data path binding table and the port binding table, so as to adjust the configuration parameters of the target virtual machine according to the detection results.

[0007] According to yet another embodiment of this application, a computer-readable storage medium is also provided, wherein a computer program is stored therein, and the computer program is configured to perform the steps in any of the above method embodiments when it is run.

[0008] According to yet another embodiment of this application, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0009] According to yet another embodiment of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the steps in any of the above method embodiments.

[0010] This application focuses on monitoring the creation events of logical routers in the southbound database to quickly identify the logical switches associated with those routers. Based on the established connection between the logical router and the logical switch, a Layer 2 gateway logical switch port for network detection is automatically created and bound to the detection service node and the virtual machine network. The target virtual machine to be detected is identified within the virtual machine network, and based on the previous binding results, the data path binding table and port binding table associated with the target virtual machine are accurately determined. Using the data path binding table and port binding table provided by the second determination module, periodic connectivity checks are performed on the network used by the target virtual machine. The detection results are used to adjust the network configuration parameters of the target virtual machine, such as network paths and virtual local area network (VLAN) allocation, to ensure network connectivity. This approach achieves automated detection of virtual machine network connectivity while reducing the impact on cloud platform performance, improving detection accuracy and efficiency, and ensuring high availability of the detection service. It reduces dependence on the southbound database, avoiding cluster instability issues that may be caused by excessive database pressure, and optimizes the resource allocation and management of the detection service node, solving the problem that virtual machine network connectivity detection often affects the overall virtual machine service performance, leading to low detection efficiency. Attached Figure Description

[0011] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the 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.

[0012] Figure 1 This is a hardware structure block diagram of a server device for a virtual machine network detection method according to an embodiment of this application;

[0013] Figure 2 This is a flowchart of a virtual machine network detection method according to an embodiment of this application;

[0014] Figure 3 This is a schematic diagram of the architecture of a virtual machine operation management system according to an embodiment of this application;

[0015] Figure 4 This is a structural block diagram of a virtual machine network detection system according to an embodiment of this application. Detailed Implementation

[0016] 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, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0017] It should be noted that, in the description of this application, 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. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0018] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0019] As an optional implementation, the method embodiments provided in this application can be executed on a server device or a similar computing device. Taking running on a server device as an example, Figure 1 This is a hardware structure block diagram of a server device for a virtual machine network detection method according to an embodiment of this application. Figure 1 As shown, the server device may include one or more ( Figure 1 Only one is shown in the image. Processor 102 (processor 102 may include, but is not limited to, a central processing unit (CPU), microprocessor (MCU), or programmable logic device (FPGA), etc.) and memory 104 for storing data. The server device may also include transmission device 106 for communication functions and input / output device 108. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the server equipment described above. For example, the server equipment may also include components that are more... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0020] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the virtual machine network detection method in this embodiment. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, thus implementing the above-described method. The memory 104 may include high-speed random access memory and non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to server devices via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0021] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by a communication provider for the server device. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module used for wireless communication with the Internet.

[0022] This embodiment provides a method for detecting virtual machine networks. Figure 2 This is a flowchart of a virtual machine network detection method according to an embodiment of this application, such as... Figure 2 As shown, the process includes the following steps:

[0023] Step S202 involves monitoring the logical routers created in the southbound database and determining the logical switches associated with those routers. This step is the starting point of the entire detection process, involving monitoring the southbound database (OVN-SB), which stores the real-time network status of the Open Virtual Network. When the Neutron component detects a new logical router created in the database, it automatically identifies the logical switch associated with that router. This is to establish the foundation for subsequent connections between routers and switches, building the detection network. This ensures that detection can respond promptly to changes in the network architecture, preparing for subsequent connectivity testing.

[0024] Step S204: With the logical router and logical switch connected, a switch port for detecting Layer 2 gateway logic is created on the logical router, and this switch port is bound to the detection service node and the virtual machine network. In other words, once the association between the logical router and logical switch is determined, a Layer 2 Gateway Logical Switch Port for connectivity detection is automatically created on the logical router. These ports are bound to the specific detection service node responsible for detection and connected to the relevant virtual machine network. By creating and binding detection ports, the connectivity of the virtual machine network can be detected in a non-intrusive manner, while avoiding direct operation of the original service node and reducing performance impact.

[0025] Step S206: If it is determined that the target virtual machine in the virtual machine network needs to be detected, the data path binding table and port binding table corresponding to the target virtual machine are determined according to the binding result.

[0026] Understandably, based on the previous binding operations, it's determined which target virtual machines (VMs) require connectivity testing. To perform the testing efficiently, the data path binding table and port binding table related to the target VMs are searched. The data path binding table provides mapping information between VMs and physical network devices, while the port binding table records the association between VM ports and logical network resources. Through these two tables, the testing service can accurately identify the network resources that need to be tested, improving the targeting and efficiency of the testing.

[0027] Step S208: Periodically detect the network used by the target virtual machine based on the data path binding table and the port binding table, and adjust the configuration parameters of the target virtual machine according to the detection results.

[0028] After obtaining the network information of the target virtual machine, the detection service will periodically perform connectivity checks on the virtual machine network. This process is based on data path binding tables and port binding tables, and assesses the network connectivity between virtual machines by sending specific network probe packets or using other detection techniques, such as Ping tests. The detection results will be used to adjust the configuration parameters of the target virtual machine. For example, if a network path interruption is detected, the network path can be automatically reconfigured or VLAN allocation can be adjusted to ensure the connectivity and stability of the virtual machine network.

[0029] By focusing on monitoring the creation events of logical routers in the southbound database (OVN-SB), the system quickly identifies the logical switches associated with each logical router. Once a connection is established between the logical router and the logical switch, a Layer 2 gateway logical switch port for network detection is automatically created and bound to the detection service node and the virtual machine network. The system identifies the target virtual machine to be detected within the virtual machine network and, based on the previous binding results, accurately determines the data path binding table and port binding table associated with the target virtual machine. Using the data path binding table and port binding table provided by the second determination module, periodic connectivity checks are performed on the network used by the target virtual machine. The detection results are used to adjust the network configuration parameters of the target virtual machine, such as network paths and virtual LAN allocation, to ensure network connectivity. This approach achieves automated detection of virtual machine network connectivity while reducing the impact on cloud platform performance, improving detection accuracy and efficiency, and ensuring high availability of the detection service. It reduces the dependence on the OVN-SB database, avoids cluster instability issues that may be caused by excessive database pressure, and optimizes the resource allocation and management of the detection service nodes. It also solves the problem that virtual machine network connectivity detection often affects the overall virtual machine service performance, resulting in low efficiency of virtual machine network detection.

[0030] In one exemplary embodiment, periodic detection of the network used by the target virtual machine based on a data path binding table and a port binding table includes: determining at least three interface types for detecting access to the target virtual machine based on the data path binding table and the port binding table, wherein the at least three interface types include: a first interface type corresponding to the first result of all detection service nodes detecting the target virtual machine after obtaining a first time point; a second interface type corresponding to the second result of detection service nodes detecting the target virtual machine before deleting the second time point in the southbound database; and a third interface type corresponding to the third result of the Internet packet explorer interface detecting the target virtual machine; setting time point parameters for the at least three interface types using historical detection data stored in the southbound database; and controlling the target interfaces corresponding to the at least three interface types to periodically detect the network used by the target virtual machine using the time point parameters.

[0031] Specifically, based on existing data path binding tables and port binding tables, three different detection interface types can be determined to support periodic detection of the network connectivity of the target virtual machine.

[0032] First, a primary interface type is defined, which focuses on the connectivity test results performed by all detection service nodes on the target virtual machine starting from a specific point in time (the first time point). This interface type is designed to allow detection processes or applications to quickly retrieve recent detection records, thereby providing network administrators with up-to-date network status reports. To achieve this, historical detection data is stored in a southbound database. By analyzing this data, a reasonable time point parameter can be set to ensure the freshness and timeliness of the detection results.

[0033] Secondly, the second interface type focuses on clearing expired detection data, that is, detection results that occurred before another specific point in time (the second time point). This design not only improves database performance and avoids read / write latency caused by storing large amounts of historical data, but also ensures that the detection process or application can focus on the current and future network state, rather than past data, thereby improving detection response speed and efficiency.

[0034] Finally, the third interface type, the Internet Packet Explorer interface, is used to periodically check the activity of the target virtual machines, i.e., whether they can respond to external network packets. This activity detection mechanism ensures that the detection process or application can promptly detect network anomalies of the virtual machines, such as disconnections or configuration errors, and thus take timely remedial measures. The timing parameter also plays a crucial role here, controlling the frequency and timing of activity detection to ensure that it neither interferes with the normal operation of the virtual machines too frequently nor misses the fault window due to excessively long detection intervals.

[0035] In summary, by utilizing these interface types and time-point parameters, efficient and dynamic monitoring of the target virtual machine's network connectivity is achieved. Simultaneously, by limiting the depth and scope of database queries, the database load is reduced, ensuring the stability of the detection process or application and the overall performance of the cloud platform. Furthermore, the combination of periodic monitoring and a liveness detection mechanism enables effective management of network resources, ensuring that the virtual machine's network configuration is always in optimal condition, allowing for rapid responses to network topology changes or fluctuations in virtual machine status.

[0036] In an exemplary embodiment, before or after monitoring the logical router created in the southbound database, the method further includes: monitoring the physical host private information table entries in the southbound database, wherein the physical host private information table entries are used to record the network status of virtual machine networks associated with physical hosts; determining whether the target physical host corresponding to the target virtual machine has deployed a detection service based on the external identifier field in the physical host private information table entries, and updating the node information corresponding to the detection service node in the southbound database based on the determination result.

[0037] It should be noted that, in addition to focusing on events related to logical routers, the monitoring and utilization of physical host private information has been further strengthened to enhance the intelligent scheduling and resource management capabilities of the detection service. The physical host private information table entry (Chassis_Private) plays a crucial role, recording the real-time status of the virtual machine network on the physical host, including but not limited to important information such as virtual machine port binding and network connectivity.

[0038] By continuously monitoring changes to the private information entries on physical hosts, the detection process or application can instantly grasp the status of the physical hosts, especially the deployment status of the detection service. Specifically, it searches for specific markers (such as the probe-server attribute) in the external identifier field of the entry to determine whether the target physical host has deployed the detection service. This information is crucial for the efficient utilization of the detection service, as it directly affects the allocation and execution of detection tasks.

[0039] Based on this confirmed result, the node information of the detection service nodes in the southbound database will be dynamically updated to reflect the latest deployment status of the detection services. This includes two scenarios: First, when a new detection service comes online, the information of the service node will be automatically registered and added to the database, which helps to expand the detection coverage and improve the comprehensiveness and accuracy of connectivity detection; second, when a detection service fails or is removed, the relevant node information will be marked as pending obsolescence, so that these unavailable service nodes will not be considered in subsequent detection task allocation, thereby avoiding resource waste and ensuring the high availability of the detection service and the stability of the cluster.

[0040] The design strategy described above not only enhances the flexibility and response speed of the detection service but also ensures that detection tasks can be executed on appropriate service nodes, maintaining high efficiency and accuracy even in cloud environments with complex network architectures and numerous physical hosts. This approach effectively alleviates the excessive reliance on a central database in traditional detection solutions, reducing database pressure. Simultaneously, by updating node information in real time, it improves the robustness of the detection service and overall operational efficiency.

[0041] In an exemplary embodiment, the method further includes updating the node information corresponding to the detection service node in the southbound database based on the determination result: if the determination result indicates that the target physical host has deployed a detection service and the detection service has added a new detection service node, obtaining the first node data corresponding to the new detection service node and using the first node data to update the node information; if the determination result indicates that the target physical host has not deployed a detection service and the detection service has reduced the number of detection service nodes, obtaining the second node data corresponding to the reduced detection service node and using the second node data to update the node information.

[0042] In this embodiment, the strategy for managing detection service node information is further refined, aiming to achieve immediate response to changes in the addition, deletion, and updates of detection services and accurate updates to database information. When a change is detected in the physical host private information table entry (Chassis_Private), and the detection service has been deployed on the target physical host by analyzing the external identifier field, a series of update mechanisms are triggered to ensure that the information related to the service node in the southbound database (such as OVN-SB) remains up-to-date.

[0043] Specifically, when a new service node is added to the detection service, the system automatically acquires first-node data related to the new node, including but not limited to key information such as the node's IP address, port number, and service status. Subsequently, this first-node data is used to update the node information of the corresponding service node in the southbound database, enabling the database to reflect the addition of the new node in a timely manner. This allows the database to take this new resource into account during subsequent detection task allocation, achieving efficient utilization and performance optimization of the detection service.

[0044] Conversely, if the results indicate that the target physical host has not deployed the detection service, and the detection service has reduced its service nodes, a different update strategy will be adopted. In this case, second-node data related to the reduced service nodes is collected, including node identification information, last detection time, status flags, etc., to update or remove the corresponding node information in the database. This mechanism ensures that there are no invalid or outdated service node records in the database, avoiding the allocation of tasks to non-existent or no longer valid nodes during detection task scheduling, thereby improving the efficiency and accuracy of detection task allocation, and also reducing resource waste caused by inaccurate node information.

[0045] Through the aforementioned update mechanism, changes in the detection service nodes can be dynamically adapted. Whether adding or removing nodes, real-time updates of database information and precise scheduling of detection tasks are ensured. This not only enhances the flexibility and responsiveness of the detection service but also further improves the overall efficiency and stability of cloud platform network connectivity detection, providing users with a more robust and reliable virtual machine network environment.

[0046] In an exemplary embodiment, after obtaining the first node data corresponding to the new detection service node, the process includes: if there is already target node information in the node information that is the same as the first node information, the first node data is not used to update the node information for the time being; if there is no target node information in the node information that is the same as the first node information, the first node data is written to the southbound database and the first node data is marked as data to be updated.

[0047] In this embodiment, the processing flow for new detection service node information is carefully designed to avoid duplicate updates and resource conflicts, while ensuring the accuracy and real-time performance of the database information. Upon successfully obtaining the first node data corresponding to the new detection service node, the system first checks if the database contains identical target node information. This check is crucial, as it helps maintain the cleanliness and efficiency of the database, preventing query delays and storage waste caused by unnecessary duplicate data.

[0048] If the same target node information already exists in the database, the strategy of "not updating" will be adopted. This means that the existing information will not be overwritten or modified using the first node data. The reason behind this decision is that duplicate node information updates may interfere with normal detection service scheduling, causing resource allocation chaos and even affecting the accuracy and timeliness of detection. Therefore, subsequent update operations will only be performed if it is confirmed that there is no identical node information in the database.

[0049] Once it is confirmed that no information identical to the first node's data exists in the database, the first node's data will be written to the southbound database and marked as "data to be updated." This marking mechanism provides the foundation for subsequent high-availability strategies for detection service nodes, ensuring that new node information can be correctly identified and utilized. For example, during the health monitoring and failover process of detection service nodes, new node information marked as "data to be updated" will be prioritized for task allocation, ensuring the continuity and high efficiency of the detection service.

[0050] By implementing the above strategies, when introducing new detection service nodes, intelligent judgment and avoidance of information duplication can be achieved, ensuring that the node information in the database is always up-to-date and non-redundant. This provides a solid data foundation for the allocation and execution of detection tasks, improving the overall operational efficiency and user experience of the cloud platform. Simultaneously, this mechanism enhances the high availability of the detection service, maintaining stability and accuracy even in environments with dynamically changing nodes.

[0051] In an exemplary embodiment, after obtaining the second node data corresponding to the reduced detection service node, the method further includes: determining that the node information has been updated if there is no target node information identical to the second node information in the node information; and marking the second node data as data to be discarded if there is target node information identical to the second node information in the node information.

[0052] In this embodiment, when a service node is detected to have been removed and its corresponding second node data is successfully acquired, a rigorous database information check and update process is immediately initiated. If, during the check, it is found that the database node information no longer contains the target node information matching the second node data, this indicates that the database information update has been completed, meaning the previous removal operation has been recorded by the database. At this point, no additional processing is required. This step verifies the real-time performance and integrity of the database, ensuring its reliability as a core resource for scheduling detection tasks.

[0053] However, if the target node information is still found to be consistent with the second node's data, it means that the database has not yet synchronously reflected the fact that this node has been removed. In this case, a "mark as data to be discarded" operation will be performed, that is, the node information will be specially marked in the database to indicate that its status has changed to unusable. This strategy not only avoids the problems that may be caused by directly deleting data, such as accidental data loss or consistency issues, but also provides a basis for subsequent advanced management decisions. For example, based on such marking information, the allocation of detection tasks can be automatically adjusted to ensure that no more detection requests are sent to nodes marked as "to be discarded," avoiding resource waste and potential detection failures.

[0054] Through the dynamic information update and discarding mark mechanism in the above embodiments, it is possible to flexibly respond to the increase or decrease of detection service nodes, maintain the accuracy and timeliness of database information, and at the same time ensure the efficient scheduling and execution of detection tasks.

[0055] In one exemplary embodiment, the network used by the target virtual machine is periodically detected by the target interface corresponding to at least three interface types through time point parameters, including: determining a first detection result based on a first interface type and time point parameters; determining a second detection result based on a second interface type and time point parameters when the first detection result is stored; and determining the memory information to be released in the southbound database based on the second detection result when the virtual machine service corresponding to the southbound database is determined to be running normally through a third interface type.

[0056] In other words, the entire testing process revolves around three interface types, and through clever timing control, the continuity of testing and the timeliness of data are ensured.

[0057] First, the first detection result is determined by using the first interface type and combining it with the set time point parameters (e.g., a specific start time). This stage focuses on collecting and analyzing data from all detection service nodes performing network connectivity checks on the target virtual machine from that time point. Obtaining the first detection result is the starting point of the detection process, providing foundational information for subsequent detection and resource management.

[0058] Following the successful storage of the first detection result, a second detection result will be determined using the second interface type, also based on a time point parameter. This second detection result primarily focuses on cleaning up expired detection data, specifically deleting all detection records prior to a second time point (e.g., a cutoff time). This process not only helps maintain a clean database and avoids the accumulation of redundant data but also ensures that the detection service can quickly locate the latest network status, improving detection response speed and accuracy.

[0059] Finally, the operational status of the detection service is periodically checked through the third interface type to ensure the virtual machine service in the southbound database is running normally. In this step, a specific liveness detection interface is called to verify the health of the service. Once it is confirmed that all detection services are running well, the memory information to be released in the southbound database is further determined based on the second detection results. This is because the cleanup work of the second detection results releases a portion of the database's storage space. By analyzing this information, it is possible to intelligently determine which memory spaces can be safely reclaimed, thereby reducing the storage pressure on the database and improving its overall performance and stability.

[0060] In summary, this embodiment achieves full-process management of target virtual machine network connectivity detection through precise control of time point parameters. From data collection to result storage, and then to data cleaning and resource optimization, a closed-loop and efficient detection and database resource management mechanism is formed. This method not only improves the efficiency and accuracy of detection but also effectively reduces the burden on the cloud platform database, providing strong technical support for maintaining the network health and performance stability of the cloud environment.

[0061] In an exemplary embodiment, after periodically detecting the network used by the target virtual machine based on the data path binding table and the port binding table, the method further includes: if there are unbound port entries in the port binding table, obtaining other unbound detection service nodes in the virtual machine network, and associating the other detection service nodes with the unbound port entries.

[0062] In this exemplary embodiment, an intelligent association mechanism is designed to address the possibility of unbound ports during the virtual machine network connectivity detection process. This mechanism aims to optimize the utilization of detection service resources and improve the overall efficiency of the detection. After periodic network detection concludes—that is, after completing a series of detection activities based on the Datapath_Binding and Port_Binding tables—the status of the Port_Binding table is further analyzed to identify any potentially unbound port entries.

[0063] Unbound ports typically refer to virtual machine network ports that have been created but not yet associated with any detection service nodes. Their existence signifies underutilization of network resources and insufficient detection coverage. To overcome this challenge, the virtual machine network is proactively scanned to identify these unbound ports and to locate other available detection service nodes within the network. This process is dynamic, capable of rapidly responding to the real-time status of the network, ensuring that all ports are effectively included in the detection scope, thus improving the comprehensiveness and accuracy of the detection.

[0064] Once the unbound port entries and their number are identified, a suitable detection service node will be selected based on a resource scheduling algorithm (such as the least binding principle), and a relationship will be established between the two. This relationship not only solves the problem of uneven distribution of detection resources but also allows for flexible adjustment of detection task allocation based on network load changes, preventing some detection nodes from being overloaded and affecting detection quality. By effectively pairing unbound ports with detection service nodes, idle network resources can be fully utilized, enhancing overall detection capabilities and response speed, further improving the cloud platform's network connectivity detection level, and ensuring stable and efficient communication between virtual machines.

[0065] In summary, the intelligent association mechanism in this embodiment is an important component of the bridge between the detection service node and the virtual machine network port. It maximizes the utilization of detection service resources by actively discovering and optimizing the allocation of unbound ports.

[0066] In an exemplary embodiment, after periodically detecting the network used by the target virtual machine based on the data path binding table and the port binding table, the method further includes: determining the number of times the target virtual machine is called through the Internet Packet Explorer interface during periodic detection; if the number of calls is less than a preset number, identifying multiple detection service nodes associated with the target virtual machine as normal binding nodes; and if the number of calls is greater than or equal to the preset number, determining to rebind the multiple detection service nodes associated with the target virtual machine.

[0067] In this exemplary embodiment, a call-based evaluation mechanism for the binding status of detection service nodes is introduced to optimize the stability and efficiency of target virtual machine network connectivity detection. After periodic detection of the target virtual machine network is completed, this mechanism comes into play by tracking the number of calls to a specific interface—an Internet packet explorer (which can be viewed as a probe or tool for detecting network connectivity)—to dynamically evaluate the binding status of multiple detection service nodes associated with the target virtual machine.

[0068] Specifically, the system counts the number of calls made to the aforementioned interface to check the network connectivity of the target virtual machine within a certain period. This statistical operation provides a quantitative basis for subsequent binding status evaluation. If the number of calls is less than a preset threshold, it usually indicates that the multiple detection service nodes associated with the target virtual machine are performing stably and have not experienced any abnormalities. Therefore, these nodes will be marked as "normal binding nodes," indicating that their current binding status is valid and no adjustment is required.

[0069] However, if the number of calls reaches or exceeds a preset threshold, it may indicate some instability factors, such as network fluctuations, node failures, or a sudden increase in detection demand, affecting the normal operation of the detection. In this case, a rebinding decision process will be triggered, re-evaluating and rebinding multiple detection service nodes associated with the target virtual machine. This process may involve reassigning detection requests to other more stable nodes, or distributing the load by adding new detection service nodes to ensure high availability of the detection service and accuracy of the detection results.

[0070] Through this mechanism, the detection system can flexibly respond to changes in the network environment while ensuring detection continuity, automatically adjusting the binding status of detection nodes and achieving dynamic optimization of detection resources. This approach not only improves the responsiveness and stability of the detection service but also provides cloud platform operators with a more intuitive and refined means of monitoring network status, helping to promptly identify and resolve potential network problems and ensure communication quality and user experience between virtual machines.

[0071] In an exemplary embodiment, before periodically detecting the network used by the target virtual machine based on the data path binding table and the port binding table, the method further includes: loading a list of detection service nodes corresponding to the virtual machine network from the southbound database; calculating the hash value corresponding to each entry in the detection service node list to obtain multiple node hash values; matching the target hash value corresponding to the node where the target virtual machine is located with the multiple node hash values; and determining the target detection service node to synchronize the detection results to the target virtual machine based on the matching result.

[0072] In this exemplary embodiment, a pre-processing flow is designed to intelligently determine which detection service nodes will be responsible for synchronizing detection results to the target virtual machine before periodically detecting the target virtual machine network based on the Datapath_Binding and Port_Binding tables. The core of this flow lies in ensuring the efficient and accurate transmission of detection results through hash calculation and matching.

[0073] First, a list of detection service nodes related to the virtual machine network is loaded from the southbound database. This list contains information on all available detection service nodes and forms the basis for subsequent hash matching and node selection. After loading the node list, a hash value is calculated for each detection service node entry in the list. This process generates multiple node hash values, each corresponding to a detection service node and serving as its unique identifier in subsequent processes.

[0074] Next, the hash value corresponding to the node where the target virtual machine resides is calculated; this value is called the target hash value. By matching the target hash value with the previously calculated hash values ​​of multiple nodes, the detection service node associated with the target virtual machine can be quickly located. This hash matching mechanism is not only fast but also avoids potential problems associated with directly relying on node names or addresses for matching, such as name conflicts or format changes, thus improving the robustness and efficiency of the processing.

[0075] Finally, based on the hash matching results, one or more target detection service nodes are identified. These nodes will be responsible for synchronizing the latest detection results to the target virtual machine. This identification process ensures that the virtual machine receives network status updates from the most suitable detection service node, avoiding resource waste and delays in detection results. Through the above preprocessing, an efficient follow-up process—the synchronization of detection results—is provided for periodic network detection, thereby optimizing the performance of the entire detection system and improving the accuracy and response speed of virtual machine network connectivity detection.

[0076] In summary, the hash-matching-based detection service node selection strategy in this embodiment is a crucial step performed before the periodic detection of the virtual machine network. By calculating and comparing hash values, it achieves intelligent determination of the detection result synchronization node, providing strong technical support for the network operation and maintenance of the cloud platform.

[0077] In an exemplary embodiment, after controlling the target interfaces corresponding to at least three interface types to periodically detect the network used by the target virtual machine through time point parameters, the method further includes: determining the detection frequency corresponding to each of the at least three interface types, and the network quality parameter corresponding to the virtual machine network; increasing the frequency corresponding to the detection frequency when the network quality parameter is greater than a preset network quality parameter; and decreasing the frequency corresponding to the detection frequency when the network quality parameter is less than or equal to the preset network quality parameter.

[0078] In this exemplary embodiment, a strategy for dynamically adjusting the detection frequency is proposed, aiming to optimize the efficiency of periodic detection of the connectivity of a target virtual machine network based on the actual quality parameters of the virtual machine network. After performing target interface detection on the network for at least three interface types based on time-point parameters, the dynamic correlation between the detection frequency of these interface types and network quality parameters will be analyzed in depth to achieve intelligent and efficient network status monitoring.

[0079] The detection frequency is determined based on the functional characteristics and importance of each interface type. It refers to the number of times the target virtual machine network is detected through a specific interface within a certain period of time. For example, the first interface type may be used to frequently detect the real-time connectivity of the network, while the second interface type may be used to periodically clean up expired detection data, and the third interface type is responsible for detecting the health status of services. The detection frequency of each interface type is preset according to its role and requirements in monitoring network health.

[0080] The network quality parameters for virtual machine networks cover key indicators such as network latency, packet loss rate, and bandwidth utilization. These parameters directly reflect the current state and performance of the network. The preset network quality parameter is a threshold used to distinguish between good and bad network quality.

[0081] When network quality parameters are detected to exceed a preset threshold, indicating that network performance is better than expected, the system will automatically increase the detection frequency of interface types directly related to network connectivity. The logic behind this strategy is that in a high-quality network environment, more frequent detection can promptly capture subtle changes in the network status, helping to prevent potential network failures and ensuring stable and efficient communication between virtual machines.

[0082] Conversely, if network quality parameters are below or equal to a preset threshold, it indicates poor network performance or potential problems. In this case, the detection frequency should be appropriately reduced. Reducing the detection frequency is to avoid further burdening the already strained network under conditions of frequent detection, which could lead to performance degradation. At the same time, a lower detection frequency can also reduce resource consumption on the detection service nodes, ensuring that they can maintain stable operation even in inefficient network environments, without crashing or becoming slow to respond due to detection activities.

[0083] Through the aforementioned mechanism of dynamically adjusting the detection frequency, the detection can more intelligently respond to fluctuations in the network environment. This not only enables more precise network status monitoring under good network conditions but also avoids unnecessary resource waste when network quality is poor, ensuring the efficiency of detection activities and the stability of detection services. This adaptive network detection strategy provides strong technical support for the network operation and maintenance and optimization of cloud platforms, helping to improve the reliability of virtual machine networks and user experience.

[0084] In one exemplary embodiment, before binding the switch port to the detection service node and the virtual machine network, the method further includes: receiving health reports periodically uploaded by the detection service node; marking the detection service node as a prohibited binding node when the health report indicates that the detection service node is in a fault state; and marking the detection service node as a backup binding node when the health report indicates that the detection service node is in a non-operating state.

[0085] In this exemplary embodiment, a health status monitoring and node binding control mechanism is introduced to ensure that the detection service node is in a healthy and available state before binding the switch port to the detection service node and the virtual machine network. This mechanism continuously evaluates the node's operating status by receiving health reports uploaded periodically by the detection service node, thereby intelligently determining the node's binding eligibility and ensuring the stability and reliability of network detection.

[0086] First, we regularly receive health reports from the detection service nodes. These reports contain key information such as the nodes' current operational status, resource usage, and detection task execution efficiency. By analyzing these health reports, we can monitor the health level of each detection service node in real time, providing an important basis for subsequent node binding decisions.

[0087] If a health report reveals that a detection service node is in a faulty state, such as a hardware failure, software malfunction, or unstable network connection, a prompt response will be made to mark that detection service node as a "prohibited binding node." This means that until the fault is resolved, the node will not be selected for binding with switch ports and virtual machine networks, avoiding the potential negative impact of faulty nodes on network detection quality and overall performance.

[0088] Conversely, if a detection service node is shown as inactive in the health report, meaning it is not currently performing any detection tasks but its hardware and software environment are in good condition, it is marked as a "standby bound node". These standby nodes can be quickly activated when needed for network detection tasks, improving the flexibility and utilization of detection resources, ensuring a rapid response to sudden detection demands, and also providing preparation for replacing faulty nodes.

[0089] This mechanism enables a precise assessment of the health status of the detection service node before binding it to the switch port, detection service node, and virtual machine network. This ensures that only healthy and usable nodes participate in the binding process, thereby improving the accuracy and efficiency of network detection and reducing the risk of detection failures due to binding faulty or non-running nodes. This provides robust protection for virtual machine network connectivity detection in cloud environments. This approach not only optimizes the management of detection resources but also enhances the overall stability of the detection process and the user experience.

[0090] In one exemplary embodiment, after creating a switch port for detecting the Layer 2 gateway logic on the logical router, the method further includes: analyzing the current binding status of the switch port to confirm whether it has been successfully bound to the target detection service node and the virtual machine network; if the analysis results show that the switch port is not bound or the binding has failed, automatically selecting an available detection service node and attempting to rebind; after successful rebinding, recording the latest binding information of the switch port and updating the data path binding table and the port binding table to ensure that subsequent detection activities can be performed based on the latest binding status.

[0091] In an exemplary embodiment, after periodically detecting the network used by the target virtual machine based on the data path binding table and port binding table, the method further includes: evaluating the connectivity quality of the target virtual machine network based on the detection results and generating a corresponding quality report; automatically triggering a network repair mechanism when the connectivity quality is lower than a preset threshold, wherein the network repair mechanism is used to restore network connectivity by optimizing the path and / or adjusting the configuration parameters; and re-performing periodic detection after the network repair operation is completed to verify the repair effect and adjust the network configuration parameters of the target virtual machine based on the new detection results.

[0092] In an exemplary embodiment, when it is determined that a target virtual machine in the virtual machine network needs to be detected, the above method further includes: predicting changes in network demand within a target time period based on the network usage of the target virtual machine and historical detection data; and dynamically adjusting the binding strategies in the data path binding table and port binding table according to the prediction results.

[0093] In one exemplary embodiment, after dynamically adjusting the binding strategies in the data path binding table and port binding table based on the prediction results, the method further includes: real-time monitoring of the performance parameters of the virtual machine network; and, if the performance parameters are lower than preset detection parameters, sending a prompt message to the user of the target virtual machine indicating that the virtual machine needs to be configured and optimized.

[0094] The entities that perform the above steps can be servers, terminals, cloud platforms, etc., but are not limited to these.

[0095] To facilitate understanding of the implementation methods of this application, relevant scenarios are explained below, but these explanations do not limit the scope of this application.

[0096] As an optional implementation, this application proposes a method to create associated resources by asynchronously monitoring the virtual machine network, thereby addressing the issue of impacting the performance of existing resource operations. By designing the overall interaction framework and processing flow of the detection service, the detection function is achieved while minimizing the impact on existing functions.

[0097] Optionally, the process design of the detection service includes: adding a subprocess called Network-probe to the neutron-server service to automatically create open virtual network resources related to the detection network. This subprocess schedules and binds detection service nodes to each router. It also periodically retrieves detection results from each detection service. In the existing API worker process within the neutron-server service, it adds a listener to the detection service reports and records the detection service information. A neutron-probe-server service is added, deployed on the detection service nodes, primarily providing a REST interface service for neutron-server to obtain detection results. It also actually sends packets to detect virtual machine connectivity.

[0098] As an optional implementation method, Figure 3 This is a schematic diagram of the process interaction of the detection service according to an embodiment of this application; the specific interaction content is as follows:

[0099] 1. Report detection service information; 2. Notify detection service information; 3. Store available detection service nodes; 4. Notify the creation of logical routers; 5. Obtain available detection service nodes, initialize available virtual LANs, and allocate them to detection ports; 6. Connect the detection network on the logical router, and create the detection network, detection ports, etc.; 7. Obtain the detection ports bound to this node, virtual machine information, etc.; 8. Obtain detection results.

[0100] In other words, through the above interaction process, most of the processing is placed in the new subprocess Network-probe and the new service neutron-probe-server, reducing the impact on the original application programming interface worker processes, and at the same time reducing the pressure on the original northbound database ovn-nb and southbound database ovn-sb.

[0101] Optionally, the Network-probe subprocess mentioned above is a newly added process within the neutron-server service, primarily possessing the following functions: 1. Monitoring the creation of logical routers (Logical_Router) for the southbound database service, automatically identifying and connecting to the corresponding logical routers, and automatically creating L2 gateway logical switch ports (l2gatewayLogica_Switch_Port) for detection. It then schedules the binding of detection nodes and virtual LANs to the L2 gateway port (detection port). 2. Periodically obtaining the detection results from the detection nodes. 3. Detecting the service status of the detection nodes and implementing high availability measures.

[0102] The process implementation is as follows: A new child process, NetworkProbeWorker, is added based on the process neutron_lib.worker.BaseWorker, and its corresponding description is "network probe" used to launch the new process. A new plugin child process, Network-probe, is added to neutron. When implementing the plugin methods, the get_workers method returns [NetworkProbeWorker()] so that the Network-probe child process is launched when neutron-server starts.

[0103] The design of the process-to-southbound database connection is as follows: Processes no longer inherit the API worker process's method for connecting to the southbound database because the API worker process listens on too many tables. The child process, Network-probe, only needs to listen on logical routers, logical switches (Logical_Switch), logical router ports (Logical_Router_Port), and logical switch ports (Logical_Switch_Port). Therefore, the design involves the plugin child process, Network-probe, initializing a new southbound database connection upon detecting its presence, and listening to southbound database table entries as needed. Event handling only processes the creation and deletion of logical routers. This reduces unnecessary memory usage and event handling overhead.

[0104] Resource creation design: When creating detection ports and L2 gateway ports, write the router_id into the external_ids of the logical switch port to facilitate the association of detection services with detection virtual machines.

[0105] Binding a detection node: Each L2 gateway port needs to be bound to a detection node for detection. The child process Network-probe selects a node to bind to based on the available detection nodes recorded by the application programming interface worker process, following the principle of least binding. If no node or virtual LAN is bound, the detection port is left empty, waiting for a router to be removed, the detection port to be unbound, or a new detection node to be added.

[0106] Node detection: The child process Network-probe periodically checks for new detection service nodes and writes the results to the database. If a new detection service node is found, it checks if any detection ports are not bound to the detection node and binds them. The child process Network-probe periodically calls the detection service's detection interface. If it fails to call the detection interface of a detection node three times consecutively, it rebinds all detection ports bound to that detection node.

[0107] Southbound Database Event Multi-Node Processing Design: Currently, each neutron-server service starts a child process, Network-probe, which may run on multiple nodes. Therefore, multiple Network-probe child processes may exist within a cluster. To avoid duplicate processing, a new hash ring group named Network-probe is added to neutron, with each Network-probe child process registering as a member. The node handling the event is determined by a hash resource identifier. Regarding hash ring member keep-alive updates, unlike the original application programming interface worker process where maintenance process updates the ml2 hash ring members, the Network-probe child process updates them periodically, preventing member "dead" states.

[0108] The process design for acquiring detection results: Since there may be multiple sub-processes called Network-probe, conflicts still exist when retrieving detection results from each detection node. Because the newly designed Network-probe sub-process does not connect to the southbound database, the hash ring selection method cannot be used. At the end of each cycle, the current list of detection nodes is retrieved from the database. Members are matched by calculating hash values. If a matching member is the current node, the current node retrieves the detection result from the detection node.

[0109] The child process Network-probe-server adds a neutron-probe-server service for deployment on the detection service node. Its main functions include: designing the neutron-probe-server service to use a REST interface for retrieving detection results, avoiding the use of the southbound database to provide results and preventing instability in the southbound database cluster; and also sending actual packets to detect virtual machine connectivity.

[0110] Service Registration: The neutron-probe-server is designed to connect to the southbound database. It reports its service by writing its own service address and provided API service port to the `Chassis_Private` table of the southbound database, specifying `external_ids:probe-server=xxx`. The Neutron-server application programming interface worker process retrieves data from the `Chassis_Private` table to obtain the services of all detection nodes.

[0111] Security Design: neutron-probe-server provides the detection results. To ensure the caller is neutron-server, a trusted source address can be configured via configuration options, providing results only to the source address specified in the configuration. Simultaneously, the child process Network-probe-server provides only Hypertext Transfer Security (HTTP) services, requiring bidirectional encryption for requests, and the encryption certificates must be issued by the same certificate authority.

[0112] As an optional implementation, the process of obtaining the virtual machine to be detected includes: connecting to a southbound database and monitoring the Datapath_Binding and Port_Binding tables. Specific steps include:

[0113] 1. Retrieve all Port_Bindings from the southbound database, with the condition that type=l2gateway and chassis is the current node.

[0114] 2. Traverse the list of Port_Binding obtained in step one, get the router_id from external_ids, and then find the Datapath_Binding corresponding to each router based on the router_id.

[0115] 3. Obtain all Port_Bindings, with the condition type=patch (optional). The data path is the Datapath_Binding obtained in step 2, which can retrieve all router interfaces.

[0116] Fourth, traverse the Port_Binding list obtained in step 3, and obtain the peer attribute from the options to get the logical switch interfaces corresponding to all router interfaces.

[0117] 5. Traverse all logical switch interfaces to obtain the corresponding datapath, which will yield the Datapath_Binding for all logical switches.

[0118] 6. Retrieve all Port_Bindings, provided the condition is type=empty string and the datapath is the Datapath_Binding obtained in step 5. This will retrieve all virtual machine ports. The neutron-probe-server is designed to periodically detect the virtual machine network according to the configuration and store the results in memory. The results are provided via a REST API, offering the following three interfaces.

[0119] Interface 1: Return all results after the provided time t1.

[0120] Interface 2: Delete the results before time t2 in memory according to the provided time t2.

[0121] Interface 3: Provides a ping interface for neutron-server to check the current service.

[0122] When the Neutron-server service retrieves test results, it sets a time interval t1 based on the results already stored in the database, calls interface 1 to retrieve the test results, stores the results, sets t2 based on the results, and calls interface 2 to notify the release of memory. This two-interface design avoids neutron-server restarts and minimizes the number of results retrieved. It also avoids continuously storing test results, which could lead to excessive memory consumption.

[0123] The specific design of the application programming interface (API) worker process includes: Since the original neutron-server service contained an API process and was already monitoring the southbound database, the main adjustment is to monitor the southbound database table entry Chassis_Private, determine whether the node is a detection node by checking if Chassis_Privateexternal_ids contains the probe-server attribute, and obtain the address of the service provider based on the probe-server value.

[0124] When an additional detection node is detected: If the node information already exists, no action is taken. If it does not exist, the node is written to the database and marked as pending use. When a reduction in detection nodes is detected: If the node information does not exist, no action is taken. If it already exists, the node information is marked as pending obsolescence.

[0125] By applying the above implementation methods, an open virtual network is connected under the Neutron architecture, enabling the probe service to communicate with the virtual machine network. A new child process, Network-probe, is added to implement the new probe service without affecting the performance of the original application programming interface (API) process. The architecture design only adds a connection to the southbound database, minimizing the pressure on the original open virtual network cluster. Simultaneously, the new process listens to the logical router to automatically establish the open virtual network resources required for the detection network, eliminating the need for in-process notifications and reducing the impact on the original router operations. A new process is proposed to use a dedicated southbound database connection for precise resource monitoring, reducing the pressure on the southbound database. The API worker process is proposed to listen to the southbound database, record the detection service, and use the new process for binding and scheduling, without introducing new southbound database connections or adding significant processing pressure to the API worker process. The new process is proposed to perform detection service activation and switch detection port binding nodes, achieving high availability for the probe service. The detection service is proposed to provide detection results via a REST interface, without introducing additional pressure on the open virtual network cluster. A method for releasing memory in the detection service is proposed, ensuring efficient utilization of server or cloud platform resources.

[0126] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, 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 (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0127] This embodiment also provides a virtual machine network detection device, which is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0128] Figure 4 This is a structural block diagram of a virtual machine network detection device according to an embodiment of this application, such as... Figure 4 As shown, the device includes:

[0129] The first determining module 42 is used to monitor the logical routers created in the southbound database and determine the logical switches associated with the logical routers;

[0130] The binding module 44 is used to create a switching port for detecting the second-layer gateway logic for the logical router when the logical router and the logical switch establish a connection relationship, and bind the switching port to the detection service node and the virtual machine network;

[0131] The second determining module 46 is used to determine the data path binding table and port binding table corresponding to the target virtual machine based on the binding result when it is determined that the target virtual machine in the virtual machine network needs to be detected.

[0132] The detection module 48 is used to periodically detect the network used by the target virtual machine based on the data path binding table and the port binding table, so as to adjust the configuration parameters of the target virtual machine according to the detection results.

[0133] The aforementioned device focuses on monitoring the creation events of logical routers in the Southbound Database (OVN-SB) to quickly identify the logical switches associated with those routers. Once a connection is established between the logical router and the logical switch, a Layer 2 gateway logical switch port for network detection is automatically created and bound to the detection service node and the virtual machine network. The target virtual machine to be detected is identified within the virtual machine network, and based on the previous binding results, the data path binding table and port binding table associated with the target virtual machine are accurately determined. Using the data path binding table and port binding table provided by the second determination module, periodic connectivity checks are performed on the network used by the target virtual machine. The detection results are used to adjust the network configuration parameters of the target virtual machine, such as network paths and VLAN allocation, to ensure network connectivity. This approach achieves automated detection of virtual machine network connectivity while reducing the impact on cloud platform performance, improving detection accuracy and efficiency, and ensuring high availability of the detection service. It reduces the dependence on the OVN-SB database, avoids cluster instability issues that may be caused by excessive database pressure, and optimizes the resource allocation and management of the detection service nodes. It also solves the problem that virtual machine network connectivity detection often affects the overall virtual machine service performance, resulting in low efficiency of virtual machine network detection.

[0134] Optionally, the above detection module is further configured to determine at least three interface types for detecting access to the target virtual machine based on the data path binding table and the port binding table, wherein the at least three interface types include: a first interface type corresponding to the first result of all detection service nodes detecting the target virtual machine after obtaining the first time point; a second interface type corresponding to the second result of detection service nodes detecting the target virtual machine before the second time point is deleted from the southbound database; and a third interface type corresponding to the third result of the Internet packet explorer interface probing the target virtual machine; setting time point parameters for the at least three interface types using historical detection data stored in the southbound database; and controlling the target interface corresponding to the at least three interface types to periodically detect the network used by the target virtual machine using the time point parameters.

[0135] Optionally, the aforementioned detection module is further configured to monitor before or after the logical router created in the southbound database, monitor the physical host private information table entries in the southbound database, wherein the physical host private information table entries are used to record the network status of virtual machine networks associated with physical hosts; determine whether the target physical host corresponding to the target virtual machine has deployed a detection service based on the external identifier field in the physical host private information table entries, and update the node information corresponding to the detection service node in the southbound database based on the determination result.

[0136] Optionally, the above-mentioned detection module is further configured to: when the determination result indicates that the target physical host has deployed a detection service and the detection service adds a new detection service node, obtain first node data corresponding to the new detection service node and update the node information using the first node data; when the determination result indicates that the target physical host has not deployed a detection service and the detection service reduces the number of detection service nodes, obtain second node data corresponding to the reduced detection service nodes and update the node information using the second node data.

[0137] Optionally, the above detection module further includes: an update unit, configured to, after obtaining the first node data corresponding to the new detection service node, temporarily not use the first node data to update the node information if there is already some node information in the node information that is the same as the first node data; and write the first node data into the southbound database and mark the first node data as data to be updated if there is no part of the node information that is the same as the first node data in the node information.

[0138] Optionally, the above detection module further includes: a marking unit, used to determine that the node information has been updated if, after obtaining the second node data corresponding to the reduction detection service node, there is no part of the node information that is the same as the second node information in the node information; and to mark the second node data as data to be discarded if, in the case that there is part of the node information that is the same as the second node information in the node information.

[0139] Optionally, the above detection module is further configured to determine a first detection result based on the first interface type and the time point parameter; determine a second detection result based on the second interface type and the time point parameter when the first detection result has been stored; and determine the memory information to be released from the southbound database based on the second detection result when the virtual machine service corresponding to the southbound database is determined to be running normally through the third interface type.

[0140] Optionally, the above apparatus further includes: an association module, configured to, after periodically detecting the network used by the target virtual machine based on the data path binding table and the port binding table, if there are unbound port entries in the port binding table, obtain other unbound detection service nodes in the virtual machine network, and associate the other detection service nodes with the unbound port entries.

[0141] Optionally, the above apparatus further includes: a first identification module, configured to, after periodically detecting the network used by the target virtual machine based on the data path binding table and the port binding table, determine the number of times the target virtual machine is called through the Internet Packet Explorer interface during periodic detection; if the number of calls is less than a preset number, identify multiple detection service nodes associated with the target virtual machine as normal binding nodes; if the number of calls is greater than or equal to the preset number, determine to rebind the multiple detection service nodes associated with the target virtual machine.

[0142] Optionally, the above apparatus further includes: a calculation module, configured to: load a list of detection service nodes corresponding to the virtual machine network from the southbound database before periodically detecting the network used by the target virtual machine based on the data path binding table and the port binding table; calculate the hash value corresponding to each detection service node entry in the detection service node list to obtain multiple node hash values; match the target hash value corresponding to the node where the target virtual machine is located with the multiple node hash values; and determine the target detection service node to synchronize the detection results to the target virtual machine based on the matching result.

[0143] Optionally, the detection module is further configured to determine the detection frequency corresponding to each of the at least three interface types, and the network quality parameter corresponding to the virtual machine network; if the network quality parameter is greater than a preset network quality parameter, increase the frequency corresponding to the detection frequency; if the network quality parameter is less than or equal to the preset network quality parameter, decrease the frequency corresponding to the detection frequency.

[0144] Optionally, the above device further includes: a second identification module, used to receive health reports periodically uploaded by the detection service node before binding the switching port with the detection service node and the virtual machine network; if the detection service node is in a fault state according to the health report, the detection service node is identified as a prohibited binding node; if the detection service node is in a non-operating state according to the health report, the detection service node is identified as a backup binding node.

[0145] Optionally, the above apparatus further includes: a recording module, configured to analyze the current binding status of the switching port after creating a switching port for detecting the Layer 2 gateway logic for the logical router, to confirm whether it has been successfully bound to the target detection service node and the virtual machine network; if the analysis result shows that the switching port is not bound or the binding has failed, automatically select an available detection service node and attempt to rebind; after successful rebinding, record the latest binding information of the switching port and update the data path binding table and the port binding table to ensure that subsequent detection activities can be carried out based on the latest binding status.

[0146] Optionally, the above-mentioned recording module further includes: a repair unit, configured to, after periodically detecting the network used by the target virtual machine based on the data path binding table and the port binding table, evaluate the connectivity quality of the target virtual machine network according to the detection results and generate a corresponding quality report; if the connectivity quality is lower than a preset threshold, automatically trigger a network repair mechanism, wherein the network repair mechanism is used to restore network connectivity by optimizing the path and / or adjusting the configuration parameters; after the network repair operation is completed, perform periodic detection again to verify the repair effect, and adjust the network configuration parameters of the target virtual machine according to the new detection results.

[0147] Optionally, the second determining module further includes: a strategy unit, used to predict changes in network demand within a target time period based on the network usage and historical detection data of the target virtual machine after determining that the target virtual machine in the virtual machine network needs to be detected; and to dynamically adjust the binding strategies in the data path binding table and port binding table according to the prediction results.

[0148] Optionally, the second determining module further includes: a prompting unit, used to dynamically adjust the binding strategies in the data path binding table and port binding table according to the prediction results, and then monitor the performance parameters of the virtual machine network in real time; if the performance parameters are lower than preset detection parameters, send a prompt message to the user of the target virtual machine indicating that the virtual machine needs to be configured and optimized.

[0149] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same target processor; or, the above modules are located in different target processors in any combination.

[0150] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above method embodiments when run.

[0151] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0152] Embodiments of this application also provide an electronic device, including a target memory and a target processor, wherein the target memory stores a computer program and the target processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0153] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above method embodiments.

[0154] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps in any of the above method embodiments.

[0155] Embodiments of this application also provide a computer program that includes computer instructions stored in a computer-readable storage medium; a processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the steps in any of the above method embodiments.

[0156] Specific examples in this embodiment can be found in the examples described in the above embodiments and exemplary implementations, and will not be repeated here.

[0157] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0158] Obviously, those skilled in the art should understand that the modules or steps of this application described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those presented here, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, this application is not limited to any particular combination of hardware and software.

[0159] The foregoing has provided a detailed description of the method, apparatus, device, storage medium, and program for detecting virtual machine networks provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A method for detecting virtual machine networks, characterized in that, include: Monitor the logical routers created in the southbound database and determine the logical switches associated with the logical routers; When the logical router and the logical switch establish a connection, a switching port for detecting the second-layer gateway logic is created for the logical router, and the switching port is bound to the detection service node and the virtual machine network; If it is determined that a target virtual machine in the virtual machine network needs to be detected, the data path binding table and port binding table corresponding to the target virtual machine are determined according to the binding result. Based on the data path binding table and the port binding table, the network used by the target virtual machine is periodically detected, and the configuration parameters of the target virtual machine are adjusted according to the detection results.

2. The method for detecting virtual machine networks according to claim 1, characterized in that, Periodic detection of the network used by the target virtual machine based on the data path binding table and the port binding table includes: Based on the data path binding table and the port binding table, at least three interface types for detecting access to the target virtual machine are determined. The at least three interface types include: the first interface type corresponding to the first result of all detection service nodes detecting the target virtual machine after the first time point; the second interface type corresponding to the second result of detection service nodes detecting the target virtual machine before the second time point is deleted from the southbound database; and the third interface type corresponding to the third result of the Internet packet explorer interface probing the target virtual machine. The time point parameters for at least three interface types are set using historical detection data stored in the southbound database; The time point parameters are used to control the target interfaces corresponding to the at least three interface types to periodically detect the network used by the target virtual machine.

3. The method for detecting virtual machine networks according to claim 2, characterized in that, Before or after monitoring logical routers created in the southbound database, the method further includes: Monitor the physical host private information table entries in the southbound database, wherein the physical host private information table entries are used to record the network status of virtual machine networks associated with physical hosts; Based on the external identifier field in the physical host private information table, determine whether the target physical host corresponding to the target virtual machine has deployed a detection service, and update the node information corresponding to the detection service node in the southbound database based on the determination result.

4. The method for detecting virtual machine networks according to claim 3, characterized in that, Based on the determined results, the node information corresponding to the detection service node in the southbound database is updated, including: If the determination result indicates that the target physical host has deployed a detection service, and the detection service adds a new detection service node, the first node data corresponding to the new detection service node is obtained, and the node information is updated using the first node data; If the determination result indicates that the target physical host has not deployed the detection service, and the detection service has reduced the number of detection service nodes, the second node data corresponding to the reduced detection service nodes is obtained, and the node information is updated using the second node data.

5. The method for detecting virtual machine networks according to claim 4, characterized in that, After obtaining the first node data corresponding to the new detection service node, the process includes: If some node information that is identical to the first node data already exists in the node information, the first node data will not be used to update the node information for the time being; If no node information is identical to the first node data in the node information, the first node data is written to the southbound database and marked as data to be updated.

6. The method for detecting virtual machine networks according to claim 4, characterized in that, After obtaining the second node data corresponding to the reduced detection service node, the method further includes: If no part of the node information is identical to the second node information in the node information, it is determined that the node information has been updated. If there are some node information in the node information that is the same as the second node information, the second node data will be marked as data to be discarded.

7. The method for detecting virtual machine networks according to claim 2, characterized in that, The network used by the target virtual machine is periodically detected by the target interface corresponding to the at least three interface types through the time point parameters, including: The first detection result is determined based on the first interface type and the time point parameter; Once the first detection result is stored, the second detection result is determined using the second interface type and the time point parameter. If the virtual machine service corresponding to the southbound database is found to be running normally through the third interface type, the memory information of the southbound database to be released is determined according to the second detection result.

8. The method for detecting virtual machine networks according to claim 1, characterized in that, After periodically detecting the network used by the target virtual machine based on the data path binding table and the port binding table, the method further includes: If there are unbound port entries in the port binding table, obtain other unbound detection service nodes in the virtual machine network and associate the other detection service nodes with the unbound port entries.

9. The method for detecting virtual machine networks according to claim 1, characterized in that, After periodically detecting the network used by the target virtual machine based on the data path binding table and the port binding table, the method further includes: Determine the number of times the target virtual machine is called during periodic detection via the Internet Packet Explorer interface; If the number of calls is less than a preset number, the multiple detection service nodes associated with the target virtual machine will be identified as normal binding nodes; If the number of calls is greater than or equal to a preset number, it is determined that multiple detection service nodes associated with the target virtual machine will be rebound.

10. The method for detecting virtual machine networks according to claim 1, characterized in that, Before periodically detecting the network used by the target virtual machine based on the data path binding table and the port binding table, the method further includes: Load the list of detection service nodes corresponding to the virtual machine network from the southbound database; Calculate the hash value corresponding to each entry in the detection service node list to obtain multiple node hash values; Match the target hash value corresponding to the node where the target virtual machine is located with the hash values ​​of the plurality of nodes; The target detection service node is determined based on the matching results and the detection results are synchronized to the target virtual machine.

11. The method for detecting virtual machine networks according to claim 2, characterized in that, After periodically detecting the network used by the target virtual machine through the target interfaces corresponding to the at least three interface types by controlling the time point parameters, the method further includes: Determine the detection frequency for each of the at least three interface types, and the network quality parameters for the virtual machine network; If the network quality parameter is greater than the preset network quality parameter, increase the frequency corresponding to the detection frequency; If the network quality parameter is less than or equal to the preset network quality parameter, the frequency corresponding to the detection frequency is reduced.

12. The method for detecting virtual machine networks according to claim 1, characterized in that, Before binding the switch port to the detection service node and the virtual machine network, the method further includes: Receive health reports periodically uploaded by the detection service nodes; If the health report to testing service node is in a faulty state, the testing service node will be marked as a node that cannot be bound. If the health report to testing service node is not in operation, the testing service node will be marked as a backup binding node.

13. The method for detecting virtual machine networks according to claim 1, characterized in that, After creating a switching port for the logical router to detect the Layer 2 gateway logic, the method further includes: Analyze the current binding status of the switch port to confirm whether it has been successfully bound to the target detection service node and the virtual machine network; If the analysis results show that the switch port is not bound or the binding failed, an available detection service node is automatically selected and an attempt is made to rebind it; After successful rebinding, the latest binding information of the switch port is recorded, and the data path binding table and port binding table are updated to ensure that subsequent detection activities can be performed based on the latest binding status.

14. The method for detecting virtual machine networks according to claim 13, characterized in that, After periodically detecting the network used by the target virtual machine based on the data path binding table and the port binding table, the method further includes: Based on the detection results, assess the connectivity quality of the target virtual machine network and generate a corresponding quality report; When the connectivity quality is lower than a preset threshold, a network repair mechanism is automatically triggered, wherein the network repair mechanism is used to restore network connectivity by optimizing the path and / or adjusting the configuration parameters. After the network repair operation is completed, a periodic test is performed again to verify the repair effect, and the network configuration parameters of the target virtual machine are adjusted according to the new test results.

15. The method for detecting virtual machine networks according to claim 1, characterized in that, After determining that the target virtual machine in the virtual machine network needs to be detected, the method further includes: Based on the network usage and historical detection data of the target virtual machine, predict the changes in network demand within the target time period; Based on the prediction results, the binding strategies in the data path binding table and port binding table are dynamically adjusted.

16. The method for detecting virtual machine networks according to claim 15, characterized in that, Based on the prediction results, after dynamically adjusting the binding strategies in the data path binding table and port binding table, the method further includes: Real-time monitoring of the performance parameters of the virtual machine network; If the performance parameters are lower than the preset detection parameters, a prompt message is sent to the user of the target virtual machine to indicate that the virtual machine needs to be configured and optimized.

17. A detection device for virtual machine networks, characterized in that, include: The first determining module is used to monitor the logical routers created in the southbound database and determine the logical switches associated with the logical routers; The binding module is used to create a switching port for detecting the Layer 2 gateway logic for the logical router when the logical router and the logical switch establish a connection relationship, and to bind the switching port to the detection service node and the virtual machine network; The second determining module is used to determine the data path binding table and port binding table corresponding to the target virtual machine based on the binding result when it is determined that the target virtual machine in the virtual machine network needs to be detected. The detection module is used to periodically detect the network used by the target virtual machine based on the data path binding table and the port binding table, so as to adjust the configuration parameters of the target virtual machine according to the detection results.

18. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the virtual machine network detection method as described in any one of claims 1 to 16 when executing the computer program.

19. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the virtual machine network detection method as described in any one of claims 1 to 16.

20. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the virtual machine network detection method as described in any one of claims 1 to 16.

Images