Virtual machine agent-free IP self-healing method suitable for hyper-converged architecture

Abstract

The invention relates to a virtual machine agent-free IP self-healing method suitable for a hyper-converged architecture. The method comprises the following steps: dividing a self-healing IP pool based on an etcd distributed cluster, and constructing an MAC-VM asset library; aRP flow is monitored through an OpenvSwitch port mirror image, and IP conflicts are accurately recognized in combination with a multiple confirmation mechanism; locating a conflicting virtual machine and a corresponding CephRBD disk path according to the conflicting MAC address; the IP configuration mode of the virtual machine is judged by integrating the multi-source data; determining a repair target according to the priority of the operation state priority, the configuration mode subordinate and the response time bottom; executing a hierarchical repair strategy for the DHCP mode, the static agency-free mode and the static agency mode; and the repair effect is ensured through repair verification and a closed loop mechanism, and rollback operation is executed when the repair effect fails. The method is compatible with an agency-free environment and a DHCP and static IP mixed deployment scene, permanent restoration of IP conflicts is achieved, manual intervention is greatly reduced, the stability and autonomous ability of a hyper-fusion platform are improved, and the method has the advantages of being safe and reliable in data, compatible in production-level operation and the like.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of network operation and maintenance of hyper-converged architecture, and particularly relates to a virtual machine agentless IP self-recovery method suitable for hyper-converged architecture. BACKGROUND

[0002] In the hyper-converged architecture based on KVM+Ceph+OpenvSwitch, the network configuration of a virtual machine (VM) is usually dynamically allocated through DHCP or manually set. Due to the fact that the network configuration is not cleaned up in image cloning, the user misoperates to repeatedly set IP, or the IP allocation conflicts caused by the failure of configuration management tools, etc., which often leads to the situation that multiple virtual machines (or virtual machines and physical devices) use the same IP address.

[0003] Such IP conflicts can cause ARP spoofing, network packet loss, service access anomalies and other problems, which seriously affect the stability of the hyper-converged platform. Therefore, the automatic detection and repair of IP conflicts has become one of the core needs to ensure the stable operation of the hyper-converged architecture cloud platform.

[0004] At present, the industry mainly uses the following technical solutions to deal with IP conflict problems: IP acquisition and detection based on qemu-guest-agent: By installing qemu-guest-agent in the virtual machine, calling the guest-network-get-interfaces interface to obtain the IP address and MAC address mapping configured in the guest operating system, and combining the global IP-MAC mapping table constructed by the host side through ARP listening, it is identified whether there is a situation that the same IP address is declared by multiple MAC addresses, so as to judge the IP conflict. This method has high accuracy, but it is heavily dependent on the installation and operation of the agent program in the guest, and cannot be used in legacy systems, security hardened systems or temporary debugging virtual machines that do not install qemu-guest-agent.

[0005] Conflict detection based on DHCP lease: By analyzing the lease file (leases) of the DHCP server (such as dnsmasq), the IP-MAC mapping in the lease is compared with the actual ARP response. If it is found that the same IP corresponds to multiple MACs, it is determined to be a conflict. This method is suitable for pure DHCP environment, but it cannot handle virtual machines using static IP addresses, and cannot achieve automatic repair.

[0006] ARP listening + manual intervention: Administrators manually analyze whether there is an IP conflict by using tcpdump or ovs-appctl to capture ARP traffic on OpenvSwitch. Once an IP conflict is found, the administrator needs to log in to the virtual machine or manually modify the IP through the operation and maintenance platform. This method does not rely on qemu-guest-agent, but has low automation degree, slow response, and is not suitable for large-scale deployment.

[0007] Network isolation strategy: After detecting an IP conflict, the network traffic of the conflicting virtual machine is isolated (such as discarding its data packets or only retaining the management channel) through the OpenvSwitch flow table to prevent network pollution from spreading. Although such a solution can limit damage, it does not solve the root cause of the IP address conflict, and the service is still interrupted.

[0008] The existing technologies have the following deficiencies: they rely on virtual machine-side components (such as qemu-guest-agent), have poor universality, and cannot cover the agentless scenario; they lack automated repair capabilities, especially for virtual machines using static IP addresses, and have no effective intervention means; most solutions stop at "detection + isolation" and do not form a "detection → repair → verification" closed loop.

[0009] Therefore, the present application provides an IP conflict management solution that does not rely on client agents, is compatible with mixed DHCP and static IP environments, and has automatic repair capabilities. SUMMARY

[0010] The present application aims to provide a virtual machine agentless IP self-healing method suitable for hyper-converged architecture to solve the technical problems in the prior art that rely on virtual machine-side components, have poor universality, cannot cover the agentless scenario, lack automated repair capabilities, especially for virtual machines using static IP addresses, and most solutions stop at "detection + isolation" and do not form a "detection → repair → verification" closed loop.

[0011] To solve the above technical problems, the technical solutions adopted by the present application are as follows: The virtual machine agentless IP self-healing method suitable for hyper-converged architecture comprises the following steps: S1: Based on the etcd distributed cluster, divide a self-healing IP pool independent of the business network segment, and construct a MAC-VM asset library; S2: Listen to ARP traffic, extract SPA and SHA to form an IP-MAC mapping relationship, use the Watch mechanism of etcd to monitor the IP-MAC mapping table, trigger conflict preliminary judgment when the same IP is associated with two or more different MACs, and perform a multiple confirmation mechanism to confirm the real IP conflict and record the CONFLICT_IP and conflict MAC list; S3: Query the MAC-VM asset library according to the conflict MAC list, obtain the corresponding VM_TAP_INTERFACE and VM_ID, and determine the CephRBD disk path of the conflict virtual machine; S4: Based on the virtual machine DHCP message, metadata service information, and compatible calling of the qemu-guest-agent interface when the qemu-guest-agent interface exists, determine the IP configuration mode of the virtual machine as DHCP or static; S5: When the conflict involves multiple virtual machines, determine the repair target according to the preset priority: preferentially select the virtual machine in the running state; if they are all in the running state, preferentially select the virtual machine in the DHCP mode; if the IP configuration modes are consistent, select the virtual machine with the later timestamp of the latest ARP response time; S6: Perform the corresponding repair operation according to the IP configuration mode and hierarchical repair strategy.

[0012] Preferably, it further includes a repair verification and closed loop process, specifically as follows: Verify the repair result: Under the DHCP mode, confirm that the virtual machine declares NEW_IP and no longer declares CONFLICT_IP; Under the static mode, confirm that the virtual machine uses NEW_IP and stops declaring CONFLICT_IP; If the verification is successful: update the self-healing IP pool state and IP-MAC mapping relationship in etcd, clean up temporary resources including snapshots and flow tables, and record the repair log; If the verification fails: perform rollback operation, delete ARP spoofing flow table under DHCP mode, rollback CephRBD snapshot and start the virtual machine under static proxy-free mode, trigger alarm and record failure log.

[0013] Preferably, the specific process of step S1 is as follows: S11: Divide and manage the self-healing IP pool: build a unified / ip_pool / data path through etcd cluster, which is used for centralized management of network configuration and address state of the self-healing IP pool; The IP addresses of the self-healing IP pool flow through the life cycle of available→used→released→available.

[0014] S12: Build MAC-VM asset library: build a unified / mac_vm / data path based on etcd cluster, which is used for centralized management of MAC address and host virtual machine relationship.

[0015] Preferably, the rules for the life cycle flow of the IP addresses of the self-healing IP pool in step S11 are set as follows: Allocation: Extract the first available IP from / ip_pool / available as NEW_IP when repairing, and move it to / ip_pool / used / <NEW_IP> and record the associated VM_ID and allocation time; Release: When the virtual machine is destroyed, the IP conflict repair verification is successful, and there is no need to retain, delete the / ip_pool / used / <NEW_IP> entry, and add the IP to / ip_pool / available again; Ban: If there is a second conflict or exception after IP allocation, move it to / ip_pool / banned.

[0016] Preferably, the specific process of step S2 is as follows: S21: Perform traffic monitoring: based on the port mirroring function of OpenvSwitch, build a network ARP traffic collection channel in each host in the hyper-converged cluster; S22: Information extraction: analyze the captured ARP packets through a specified network analysis tool to extract key mapping information; S23: Build a global IP-MAC mapping table based on the etcd distributed cluster to realize unified management of mapping data across hosts, and guarantee data validity through a life cycle mechanism; S24: Conflict preliminary judgment: use the Watch mechanism of etcd to realize real-time monitoring of the global IP-MAC mapping table, when a different MAC address is added to the MAC address set corresponding to any IP address, and the set size is ≥2, judge it as IP conflict, trigger conflict detection event; S25: Perform three-layer confirmation mechanism to confirm real IP conflict.

[0017] Preferably, the specific process of step S3 is as follows: S31: Conflict MAC list preprocessing: obtain the conflict MAC list after multiple confirmations, and perform format verification on each MAC address in the list to remove illegal format data; S32: Query MAC-VM asset library to obtain specified association information; S33: TAP interface validity verification; S34: Determine the CephRBD disk path of the conflict virtual machine; S35: Integrate the positioning information corresponding to each valid conflict MAC to form a structured positioning result set.

[0018] Preferably, the specific process of step S4 is as follows: S41: Real-time collection of virtual machine DHCP messages and metadata service information, and detection of qemu-guest-agent interface availability; S42: Based on the collected DHCP messages and ARP response data, perform a preliminary configuration mode determination to obtain basic identification results; S43: Based on the basic identification results, perform cross-validation by combining the qemu-guest-agent interface (if available) with metadata service information to correct the initial judgment bias; S44: Output structured recognition results.

[0019] Preferably, the specific process of step S5 is as follows: When CONFLICT_IP is associated with multiple VM_IDs, a hierarchical priority decision-making mechanism is used to determine the target virtual machine for repair. The decision follows the principle of "prioritizing the repair of virtual machines that are later added or configured to be volatile." The specific decision-making process is as follows: Running status priority: The system prioritizes virtual machines in the running state as repair targets; If any candidate virtual machine instance is already shut down, its priority is reduced in the decision-making process, and the repair is performed on the running virtual machine first. Configuration mode is secondary: If all candidate virtual machines are running, the virtual machine with IP configuration mode set to DHCP will be selected as the repair target. Response time fallback: If all candidate virtual machines are in the same configuration mode, compare the timestamps of their most recent ARP responses and select the virtual machine with the later response time as the repair target.

[0020] Preferably, the graded repair strategy execution process in step S6 is as follows; If it is in DHCP mode: ARP spoofing flow table is issued through ovs-ofctl to intercept the virtual machine's DHCPRequest message and construct a DHCPNAK message, so that the virtual machine releases CONFLICT_IP and reacquires NEW_IP. After communication is restored, the ARP spoofing flow table is deleted. If it is in static mode and there is no qemu-guest-agent: isolate the virtual machine network through OpenvSwitch flow tables, create a CephRBD snapshot, after shutdown, mount the disk root partition through guestmount, identify the operating system type and modify the persistent network configuration file, replace CONFLICT_IP with NEW_IP from the self-healing IP pool, unmount the disk and start the virtual machine. If it is a static mode and there is qemu-guest-agent: write a network configuration script through the guest-file-write interface, call the guest-exec interface to execute the script to modify the IP configuration, and realize online hot repair.

[0021] The beneficial effects of the present application include: 1. Agent compatible, covering all scenarios: without relying on qemu-guest-agent inside the virtual machine, IP conflict management is realized through existing components of the hyper-converged architecture, perfectly adapting to agentless environments, solving the problem of insufficient generality of existing technologies, and covering all types of virtual machine network configuration scenarios.

[0022] 2. Mixed scene adaptation, comprehensive repair capability: unified processing of IP conflicts in DHCP and static IP mixed deployment scenarios, both through the "ARP spoofing + DHCP NAK expelling" mechanism to realize the rapid repair of DHCP mode virtual machines, and through the "CephRBD snapshot backup + offline mounting modification on the host side" or "qemu-guest-agent online hot repair" mechanism to realize the root cause repair of static IP virtual machines, making up for the defects of existing technologies that only support DHCP scenarios and lack effective static IP repair methods.

[0023] 3. Full-process automation, reducing operation and maintenance costs: build a full-process automation closed-loop mechanism of "detection → positioning → identification → repair → verification", from ARP traffic monitoring, conflict confirmation, to virtual machine positioning, configuration mode identification, to repair target decision-making, hierarchical repair execution, and finally to result verification and resource cleaning, without human intervention throughout, greatly reducing the repeated operations of operation and maintenance personnel, improving IP conflict processing efficiency, and enhancing the autonomy of the hyper-converged platform.

[0024] 4. Data security and reliability, no repair risk: during the repair process, make full use of the capabilities of the hyper-converged storage layer, automatically create CephRBD snapshots before modifying the configuration of static IP virtual machines, and quickly roll back to the original state in case of repair failure, ensuring zero data damage; at the same time, through lease expiration, event-driven cleaning and other mechanisms, the accuracy of IP-MAC mapping data is guaranteed, avoiding misjudgment and misoperation, solving the problem of data security in the repair process of existing technologies.

[0025] 5. Accurate and intelligent decision-making, ensuring business stability: adopt a hierarchical priority decision-making mechanism of "running state first, configuration mode second, response time last", preferentially repair running, configuration-volatile DHCP mode virtual machines, and try to avoid modifying static IP virtual machines that are critical to business, and the "latecomer responsible" logic makes the repair more reasonable, minimizing the impact of repair operations on online business, and ensuring the stable operation of the hyper-converged platform. BRIEF DESCRIPTION OF DRAWINGS

[0026] Figure 1 Flowchart of the virtual machine agentless IP self-healing method suitable for hyper-converged architecture of the present application.

[0027] Figure 2 Flowchart of the hierarchical repair strategy execution of the present application. DETAILED DESCRIPTION

[0028] The present application will be further described in detail below. Figures 1-2 Further detailed description of the present application: Example 1 Referring to the accompanying drawings Figure 1 and Figure 2 As shown in the figure, the virtual machine agentless IP self-healing method suitable for hyper-converged architecture includes the following steps: S1: Pre-preparation: Based on the etcd distributed cluster, divide the self-healing IP pool independent of the business network segment, and build the MAC-VM asset library.

[0029] S2: ARP monitoring and conflict detection: Monitor ARP traffic, extract SPA and SHA to form IP-MAC mapping relationship, use the Watch mechanism of etcd to monitor the IP-MAC mapping table, and trigger conflict preliminary judgment when the same IP is associated with two or more different MACs.

[0030] And perform multiple confirmation mechanisms: delay 1 second to verify the persistence of the conflict, query the MAC-VM asset library and call the libvirt interface to check the real running state of the virtual machine, combine the OUI database to filter the physical device occupation scene, confirm the real IP conflict and record the CONFLICT_IP and conflict MAC list.

[0031] S3: Virtual machine attribution positioning: According to the confirmed conflict MAC list, query the MAC-VM asset library to obtain the corresponding VM_TAP_INTERFACE and VM_ID, verify the validity of the TAP interface, and determine the CephRBD disk path of the conflict virtual machine.

[0032] S4: IP configuration mode identification: Comprehensive analysis of virtual machine DHCP message, metadata service information, compatible calling of qemu-guest-agent interface (if exists), judgment of virtual machine IP configuration mode as DHCP or static.

[0033] S5: Conflict repair decision: When the conflict involves multiple virtual machines, determine the repair target according to the following priority: preferentially select the virtual machine in running state; if they are all in running state, preferentially select the virtual machine in DHCP mode; if the configuration modes are consistent, select the virtual machine with the later timestamp of the latest ARP response time.

[0034] S6: Hierarchical repair strategy execution: Perform corresponding repair operations according to IP configuration mode; If it is DHCP mode: Through ovs-ofctl, issue ARP spoofing flow table, intercept virtual machine DHCPRequest message and construct DHCP NAK message, force virtual machine to release CONFLICT_IP and reacquire NEW_IP, and delete ARP spoofing flow table after communication is restored.

[0035] If it is static mode and there is no qemu-guest-agent: Isolate virtual machine network through OpenvSwitch flow table, create CephRBD snapshot, mount disk root partition through guestmount after shutdown, identify operating system type and modify persistent network configuration file, replace CONFLICT_IP with NEW_IP of self-healing IP pool, unload disk and start virtual machine.

[0036] If it is static mode and there is qemu-guest-agent: Write network configuration script through guest-file-write interface, call guest-exec interface to execute script to modify IP configuration, and realize online hot repair.

[0037] In another embodiment of the present embodiment, a repair verification and closed loop process is also included, specifically as follows: Verify repair results: In DHCP mode, confirm that virtual machine declares NEW_IP and no longer declares CONFLICT_IP; in static mode, confirm that virtual machine uses NEW_IP and stops declaring CONFLICT_IP; If verification succeeds: Update etcd self-healing IP pool state and IP-MAC mapping relationship, clean up temporary resources such as snapshots and flow tables, and record repair log; If verification fails: Perform rollback operation, delete ARP spoofing flow table in DHCP mode, rollback CephRBD snapshot and start virtual machine in static agentless mode, trigger alarm and record failure log: Differential processing of verification failure: For DHCP mode: The system ensures that ovs-ofctl del-flows is executed to delete the created ARP spoofing flow table rules, restores the basic network communication of the virtual machine, but the IP conflict state still exists.

[0038] For static IP offline repair mode: The system automatically executes rollback process, rolls back virtual machine disk to snapshot and starts, and restores to the configuration state before repair, but is still in network isolation.

[0039] For static IP online hot repair: This path cannot be automatically rolled back. The system records the failure state and requires manual intervention.

[0040] Trigger an alarm: After the above operation, trigger a high-level alarm to inform the operation and maintenance personnel to intervene manually.

[0041] Record failure log: record repair failure log for subsequent audit and problem analysis. The log contains operation time, operator (ovs-heal), VM_ID, CONFLICT_IP, NEW_IP, repair path (DHCP / Static without agent / Static with agent), operation steps (such as flow table creation, snapshot backup), verification result, error code, rollback operation, stored in JSON format, supporting operation and maintenance platform query export.

[0042] In this embodiment, the specific process of step S1 is as follows: S11: Divide and manage self-healing IP pool: build a unified / ip_pool / data path through etcd cluster, which is used to centrally manage network configuration and address state of self-healing IP pool; Select an independent network segment that does not overlap with the existing business network segment of the hyper-converged platform, such as 192.168.116.0 / 24, with a subnet mask of 255.255.255.0, and set the default gateway to 192.168.116.1. This address is not involved in allocation to ensure that it does not overlap with the existing business network segment of the hyper-converged platform; Build a unified / ip_pool / root data path in the etcd distributed cluster as the centralized management entrance of the self-healing IP pool. All IP resource states and network parameters are stored under this path to ensure global consistency. Maintain available IP list, used record, banned list and network parameters under / ip_pool / to realize the state management of IP resources; Reserve 10% emergency IP, which is only used when regular IP is exhausted, to ensure repair capability in extreme scenarios. When the usage rate of self-healing IP pool is ≥90%, trigger an expansion alarm to avoid no available IP for repair; The system regularly (every 60 seconds) counts the number of used IPs under the / ip_pool / used / path, calculates the usage rate, and the formula is: usage rate = used IP number / (total IP number - emergency IP number); When the usage rate is ≥90%, send an expansion alarm through email or operation and maintenance platform to remind the administrator to expand the network segment or clean up idle IP; The IP addresses of the self-healing IP pool go through the life cycle of available → used → released → available.

[0043] S12: Build MAC-VM asset library: build a unified / mac_vm / data path based on etcd cluster to centrally manage MAC addresses and host virtual machine relationships; With MAC address as the key, the corresponding virtual machine identifier (such as VMID), TAP interface, status and other information are stored in the / mac_vm / <MAC_ADDRESS> path to realize global visibility and dynamic maintenance of MAC-VM mapping. The asset library supports real-time query and event listening, providing data basis for ARP conflict detection and positioning. The storage key-value structure is as follows: / mac_vm / <MAC_ADDRESS>→{vm_id:"i-00000017",vm_tap_interface:"tap00000017.0",status:"running"} Where <MAC_ADDRESS> is a 6-byte hexadecimal MAC address (such as 28:6E:D4:8A:39:29). The library maintains real-time synchronization through the following two mechanisms: Timing synchronization: The system deploys a synchronization agent on each host machine, which iterates through all local virtual machines every 5 minutes, executes virsh domif list <VM_ID> to obtain all TAP interfaces and corresponding MAC addresses, and executes virsh dominfo <VM_ID> to obtain its running status, and synchronizes these information to etcd in batches.

[0044] Event-driven synchronization: Libvirt API is used to listen to virtual machine lifecycle events (such as started, stopped) and device change events (device-added, device-removed). When an event is triggered, the system performs incremental updates according to the event type: For virtual machine started event: update the mapping entries of all known MAC addresses of the virtual machine, and set status:"running"; For virtual machine stopped or shutdown event: update the mapping entries of all known MAC addresses of the virtual machine, and set status:"shutoff"; For device-added event: extract the MAC address of the newly added network card from the event payload, create a new / mac_vm / <mac>Item, and associate VM_ID and TAP interface name; For the network card removal device-removed event: delete the / mac_vm / <MAC_ADDRESS> item corresponding to the MAC of the network card; For the virtual machine deletion Domain-Removed event: clean up all / mac_vm / items corresponding to the MAC addresses associated with the VM_ID, and completely recycle resources.

[0045] Through the above mechanism, low delay and high precision MAC-VM mapping update is realized. Timing synchronization as a fault-tolerant mechanism makes up for the case of event loss or processing failure.

[0046] Among them, the IP addresses of the self-healing IP pool in step S11 are set according to the life cycle flow of available->used->released->available as follows: Allocation: extract the first available IP from / ip_pool / available as NEW_IP when repairing, and move it to / ip_pool / used / <NEW_IP> and record the associated VM_ID and allocation time; Release: When the virtual machine is destroyed, the IP conflict repair verification is successful, and there is no need to keep it, delete the / ip_pool / used / <NEW_IP> item, and add the IP to / ip_pool / available again; Ban: If there is a second conflict or abnormality after IP allocation, move it to / ip_pool / banned to avoid repeated allocation, and it needs to be manually checked and unlocked.

[0047] etcd data consistency guarantee: Use the distributed characteristics of etcd to ensure that all host nodes access the / ip_pool / path to obtain consistent data; Use the atomic operation of etcd, such as Compare-and-Swap, for IP allocation, release and other operations to avoid IP allocation conflicts in concurrent scenarios.

[0048] Embodiment 2 On the basis of embodiment 1, the specific process of step S2 is as follows: S21: Perform traffic monitoring: based on the port mirroring function of OpenvSwitch (OVS) on each host in the hyper-converged cluster, build a full-network ARP traffic collection channel: Configure the port mirroring rule for the OVS bridge (service bridge br1) on the host, and copy all ARP request packets and gratuitous ARP (Gratuitous ARP) packets passing through the bridge to the monitoring port; The monitoring process continuously captures ARP traffic of the mirror port without affecting the normal forwarding of service traffic, ensuring that the monitoring behavior has no significant impact on the performance of the hyper-converged platform. Only ARP protocol related messages (Ethernet type 0x0806) are focused on, and other irrelevant network traffic is filtered to improve data processing efficiency. S22: Information extraction: Use scapy or tcpdump to analyze the captured ARP messages and extract key mapping information. The rules are as follows: Extract the source IP address (SPA, SenderProtocolAddress) and source MAC address (SHA, SenderHardwareAddress) from the ARP message header to form an "IP→MAC" mapping relationship. Support multiple IP address declarations for the same MAC address, such as virtual machine configuration with multiple IP binding scenarios. The system will record all legal declaration behaviors and will not be judged as a conflict. If the same IP address is declared by two or more different MAC addresses, a preliminary conflict suspicion flag is triggered to provide basic data for subsequent conflict determination. S23: Build a global IP-MAC mapping table based on the etcd distributed cluster to achieve unified management of mapping data across hosts, and ensure data validity through a life cycle mechanism: Data storage structure: Create a unified / ip_mac / data path in etcd, use IP address as key, and store all MAC addresses associated with the IP and the latest declaration timestamp in JSON format. The timestamp records the time when the MAC address last declared the IP, which provides a basis for subsequent conflict resolution. Automatic lease expiration mechanism: Set a 300-second etcdLease (lease) for each / ip_mac / <IP_ADDRESS> entry. The self-healing agent on the host scans the local active virtual machines every 60 seconds and performs renewal operations for the IP-MAC mapping entries associated with them. If the virtual machine is powered off, migrated, or network interruption causes the renewal to fail, the entry will be automatically deleted from etcd after the lease expires, avoiding the accumulation of zombie data affecting the accuracy of conflict detection. Event-driven cleaning mechanism: Listen to virtual machine related events on the libvirt interface to perform differentiated data cleaning and ensure the real-time nature of the mapping table. The cleaning rules are as follows: Table 1 Cleaning rules table IP address change processing procedure is set: When it is found that a MAC address stops declaring the original IP and starts declaring a new IP, the system automatically performs: Remove the MAC address from the / ip_mac / <original IP> mapping corresponding to the original IP; Add the MAC address and a new timestamp to the / ip_mac / <new IP> mapping corresponding to the new IP; This mechanism only handles normal IP change scenarios for virtual machines. If an IP conflict has been detected, the active repair mechanism is preferred to resolve the conflict, and the passive change logic is not relied on.

[0049] S24: Initial conflict judgment: Real-time monitoring of the global IP-MAC mapping table is achieved using the Watch mechanism of etcd, and the specific judgment logic is set as follows: The system continuously monitors all data changes under the / ip_mac / path. When a different MAC address is added to the MAC address set corresponding to any IP address, and the size of the set is greater than or equal to 2, a conflict detection event is triggered; Record the conflict core information: conflict IP address (CONFLICT_IP), all conflict MAC address list, conflict initial judgment timestamp, provide data support for subsequent multiple confirmations; S25: To exclude network jitter, residual data, physical device occupation and other interference factors, a three-layer confirmation mechanism is executed to confirm the real IP conflict: Conflict persistence verification: After the initial conflict judgment, capture ARP traffic again after a delay of 1 second to verify whether the same IP is still declared by multiple MAC addresses; If the conflict disappears after the delay, it is determined to be a false positive caused by network jitter, and the subsequent repair process is not triggered, only logs are recorded; If the conflict persists, proceed to the next confirmation step.

[0050] Virtual machine running state verification: Based on the conflict MAC address list, query the MAC-VM asset library in etcd to obtain the corresponding VM_ID and recorded running state; For VM_ID with a state of "running", further call the virshdomstate<VM_ID> interface of libvirt to query the real-time running state; If the real-time state is "shutoff", mark the MAC address as "possibly residual" and reduce its weight or exclude it in subsequent repair decisions to avoid false operations on offline virtual machines, but keep the conflict record for auditing.

[0051] OUI vendor filtering verification: Query the local OUI database (periodically synchronize the IEEE official OUI data, support manual addition of custom manufacturer whitelist), identify the hardware manufacturer of the conflicting MAC address; If the manufacturer of a certain MAC address does not belong to the known virtualization platform (such as QEMU / KVM, VMware, etc.), it is determined that CONFLICT_IP may be occupied by a physical network device; In such scenarios, the system does not perform automatic repair, only records logs and terminates the process, avoiding false intervention on physical devices.

[0052] Final conflict confirmation: After the above three-layer verification, if there is still a case of "the same IP being declared by multiple active virtual machine MAC addresses", it is finally determined as a real IP conflict, and the CONFLICT_IP, the confirmed conflict MAC list, the associated VM_ID, etc. information is output, triggering the subsequent virtual machine attribution positioning process.

[0053] The specific process of step S3 is as follows: S31: Conflict MAC list preprocessing: Get the conflict MAC list (CONFLICT_MAC_LIST) after multiple confirmations, which has filtered out physical device MAC, marked "possible residual" offline virtual machine MAC, and only kept valid conflict MAC addresses related to active virtual machines (format: 6-byte hexadecimal, such as 28:6E:D4:8A:39:29). The system performs format verification on each MAC address in the list (ensures compliance with the standard MAC format separated by colons), removes illegal format data, and avoids invalid queries; S32: Query MAC-VM asset library to obtain specified association information: For each conflict MAC address after preprocessing, the following query operations are performed: Use the MAC address as the key to access the corresponding entry under the / mac_vm / root path in the etcd distributed cluster, i.e., query / mac_vm / <MAC_ADDRESS>; From the JSON data stored in this entry, extract core association information: virtual machine unique identifier (VM_ID, such as i-00000017), host-side TAP network interface name (VM_TAP_INTERFACE, such as tap00000017.0); If a conflict MAC address is not queried to the corresponding entry under the / mac_vm / path (may be due to synchronization delay, MAC address anomaly, etc.), the system marks it as "unassociated virtual machine MAC", records logs and temporarily excludes it from the subsequent positioning process, and only continues to process MAC addresses that have queried association information; S33: TAP interface validity verification: To avoid invalidation of associated information due to interface logout, virtual machine migration, etc., the extracted VM_TAP_INTERFACE needs to be verified for validity to ensure that it still belongs to the OpenvSwitch bridge of the current host machine. The specific operation is as follows: On the host machine corresponding to the conflicting MAC address, execute the OpenvSwitch query command: ovs-vsctllistinterface<VM_TAP_INTERFACE>; Parse the command return result: if the result contains detailed information of the VM_TAP_INTERFACE (such as interface state, associated bridge, MAC address binding relationship, etc.), and the interface state is "up" or "active", it is determined that the TAP interface is valid; If the command returns "interfacedoesnotexist" or the interface state is "down" and there is no associated bridge information, it is determined that the TAP interface is invalid: Trigger the MAC-VM asset library synchronization compensation mechanism: immediately perform an incremental synchronization of virtual machine information for the host machine (call the virshdomiflist and dominfo interfaces to update the MAC-VM mapping); After synchronization, requery / mac_vm / <MAC_ADDRESS>, if valid TAP interface information cannot still be obtained, the virtual machine associated with the MAC is marked as "positioning failed", logs are recorded and an alarm is triggered, and it is temporarily not included in the repair process; If valid TAP interface information is obtained after synchronization, the subsequent process continues; S34: Determine the CephRBD disk path of the conflicting virtual machine: Through the valid VM_ID associated query of virtual machine storage configuration, the CephRBD disk path is accurately located, and the steps are as follows: Based on the verified valid VM_ID, call the hyper-converged platform management interface or libvirt related interface to query the storage configuration metadata of the virtual machine; If queried through libvirt, execute the command virshdomblklist<VM_ID>, which will return the mapping relationship of all block devices of the virtual machine, including disk device names (such as vda, sda) and corresponding backend storage paths; If queried through the hyper-converged platform management interface, directly obtain the storage resource configuration associated with the VM_ID, including Ceph storage pool name, disk image name, etc. From the query result, filter out the backend storage path corresponding to the root disk: The root disk is usually the primary block device of the virtual machine (such as the path corresponding to "vda" in the domblklist result), and the path format is the CephRBD standard path, for example: / dev / rbd / <storage pool name> / <virtual machine disk image name> (such as / dev / rbd / pool / vm-disk-i-00000017); If the query result contains multiple block devices, the system identifies the disk label (such as "root" identification) or takes the first valid block device path by default to ensure that the core disk used to store the operating system and network configuration files is located; Verify the validity of the CephRBD disk path: execute the rbdinfo<RBD path> command (such as rbdinfo / dev / rbd / pool / vm-disk-i-00000017), if the disk size, creation time, status, etc. Information is returned, and the status is "available", the path is valid; If it returns "image not found" or the status is abnormal, it is marked as "invalid storage path", logs are recorded and an alarm is triggered, and the subsequent repair process of the virtual machine is terminated; S35: Output the positioning result: integrate the positioning information corresponding to each valid conflict MAC to form a structured positioning result set.

[0054] Embodiment 3 On the basis of Embodiment 1 or Embodiment 2, the specific process of step S4 is as follows: S41: Real-time collection of virtual machine DHCP packets, metadata service information, and qemu-guest-agent interface availability detection; S42: Based on the collected DHCP packets and ARP response data, preliminary configuration mode determination is performed: DHCP mode preliminary determination: If there is a DHCPDiscover or DHCPRequest packet of the virtual machine in the temporary data buffer; Further query the lease file (leases) of the DHCP server (such as dnsmasq) to extract the lease IP corresponding to the MAC address of the virtual machine; Compare the lease IP with the actual declared IP address of the virtual machine (obtained from the SPA field of ARP listening), if they are consistent, it is preliminarily determined as DHCP mode; Static mode preliminary determination: If no DHCP protocol packets (UDP67 / 68 port data) of the virtual machine are captured; But through ARP listening, it is confirmed that the virtual machine has stable ARP response (i.e. continuously declares a fixed IP address); and the metadata service has no explicit DHCP configuration record (or the metadata service is unavailable), then it is preliminarily determined as a static IP mode; S43: Precision optimization (second layer verification, improve identification accuracy): For the basic identification result, cross-verification is performed in combination with the qemu-guest-agent interface (if available) and metadata service information to correct the preliminary determination deviation: qemu-guest-agent interface verification (preferentially executed if available): The guest-network-get-interfaces interface of qemu-guest-agent is called to directly obtain the network interface configuration details inside the virtual machine, including the IP address, configuration source ("dhcp" or "static"), ETH_NAME (such as enp4s0, eth0) of each interface; If the configuration source returned by the interface is "dhcp", it is directly confirmed that the virtual machine is in DHCP mode, which overrides the basic identification result; If the configuration source is "static", it is directly confirmed that the virtual machine is in static mode, and the ETH_NAME is recorded synchronously (to provide a basis for locating the configuration file in subsequent static IP repair); Metadata service assisted verification: If the metadata service query result shows that the virtual machine is preset to be in DHCP mode and is consistent with the basic identification of DHCP mode, the determination result is strengthened; If the metadata service shows that it is preset to be in static mode and is consistent with the basic identification of static mode, the determination result is also strengthened; If the metadata service result conflicts with the basic identification result (such as metadata preset DHCP but no DHCP packet captured), the basic identification result is used as the standard, and the conflict information is recorded in the log for subsequent audit analysis; Special scene processing: If the virtual machine simultaneously exists DHCP packet and static IP declaration (such as multi-network card scene), then the network interfaces are identified respectively: for each network card, the above basic identification and precision optimization processes are executed separately to determine the configuration mode of each network card; If the basic identification has no clear result (such as a small amount of DHCP packet loss), and the agent is not available and the metadata service has no information, then the ARP listening window is extended (additional 30 seconds), and the data is captured again to execute the basic identification again; if there is still no result, it is determined as a static mode (default bottom-up strategy to avoid identification failure); S44: Output structured identification result, including the following core information: Table 2 Structured identification result information table The specific process of step S5 is as follows: When multiple VM_IDs are associated with CONFLICT_IP, a hierarchical priority decision mechanism is adopted to determine the target virtual machine that should be repaired, ensuring that the repair operation is accurate and safe, and avoiding affecting online services. The decision follows the core principle of "preferably repairing the virtual machine that enters the scene later or is configured to be variable". The specific decision process is as follows: Running state priority: The system preferentially selects a virtual machine in the running state as the repair target. If there is a shutoff instance among the candidate virtual machines, its priority is reduced in the decision, and the repair is preferentially performed on the virtual machine in the running state. This strategy ensures that the repair operation is targeted at the entity that is currently actually causing the network conflict, avoiding invalid intervention on offline template machines, backup virtual machines, and other non-active instances. Configuration mode second: If all candidate virtual machines are running, the virtual machine with the IP configuration mode of DHCP is preferentially selected as the repair target. Because the design semantics of the DHCP mode is "dynamic and variable", its IP address is variable; and static IP is usually used for key business systems, which have higher stability requirements and should be avoided from being modified as much as possible.

[0055] Response time bottom: If all candidate virtual machines are of the same configuration mode (such as DHCP or static), the time stamp of the latest ARP response (recorded in the etcd MAC-VM asset library) is compared, and the virtual machine with the later response time is selected as the repair target. The virtual machine that sends the ARP response later is more likely to be newly started or newly configured, and belongs to "the one who enters the scene later", and it is more reasonable for it to bear the responsibility of IP adjustment. If the time stamps are the same, one is randomly selected for repair.< / mac>

Claims

1. A method for virtual machine agentless IP self-healing suitable for hyper-converged architecture, characterized in that, Comprising the following steps: S1: Divide self-healing IP pool independent of business network segment based on etcd distributed cluster, and construct MAC-VM asset library; S2: Listen to ARP traffic, extract SPA and SHA to form IP-MAC mapping relationship, monitor IP-MAC mapping table using etcd Watch mechanism, trigger conflict preliminary judgment when the same IP is associated with two or more different MACs, and perform multiple confirmation mechanism to confirm real IP conflict and record CONFLICT_IP and conflict MAC list; S3: Query MAC-VM asset library according to conflict MAC list, obtain corresponding VM_TAP_INTERFACE and VM_ID, and determine CephRBD disk path of conflict virtual machine; S4: Determine IP configuration mode of virtual machine as DHCP or static based on virtual machine DHCP message, metadata service information, and compatible invocation of qemu-guest-agent interface when it exists; S5: When the conflict involves multiple virtual machines, determine the repair target according to the preset priority: preferentially select virtual machines in running state; If they are all in running state, preferentially select virtual machines in DHCP mode; If the IP configuration mode is consistent, select the virtual machine with the latest ARP response timestamp; S6: Perform corresponding repair operation according to IP configuration mode and hierarchical repair strategy.

2. The method for virtual machine agentless IP self-healing suitable for hyper-converged architecture according to claim 1, wherein, It also includes repair verification and closed loop process, as follows: Verify repair results: In DHCP mode, confirm that the virtual machine declares NEW_IP and no longer declares CONFLICT_IP; In static mode, confirm that the virtual machine uses NEW_IP and stops declaring CONFLICT_IP; If the verification is successful: update the self-healing IP pool state and IP-MAC mapping relationship in etcd, clean up temporary resources including snapshots and flow tables, and record repair logs; If the verification fails: perform rollback operation, delete ARP spoofing flow table in DHCP mode, rollback CephRBD snapshot and start virtual machine in static agentless mode, trigger alarm and record failure logs.

3. The method for virtual machine agentless IP self-healing suitable for hyper-converged architecture according to claim 1, wherein, The specific process of step S1 is as follows: S11: Divide and manage self-healing IP pool: build a unified / ip_pool / data path through etcd cluster, which is used for centralized management of network configuration and address state of self-healing IP pool; The IP addresses of self-healing IP pool go through the life cycle of available→used→released→available; S12: Construct MAC-VM asset library: build a unified / mac_vm / data path based on etcd cluster, which is used for centralized management of MAC address and host virtual machine relationship.

4. The method for virtual machine agentless IP self-healing suitable for hyper-converged architecture according to claim 3, wherein, The rules for the life cycle of self-healing IP pool in step S11 are as follows: Allocation: extract the first available IP from / ip_pool / available as NEW_IP, and move it to / ip_pool / used / <NEW_IP> and record the associated VM_ID and allocation time; Release: When the virtual machine is destroyed, IP conflict repair verification is successful, and there is no need to retain, delete the / ip_pool / used / <NEW_IP> entry, and add the IP to / ip_pool / available again; Ban: If there is a second conflict or exception after IP allocation, it is moved to / ip_pool / banned.

5. The method for virtual machine agentless IP self-healing suitable for hyper-converged architecture according to claim 1, wherein, The specific process of step S2 is as follows: S21: Perform traffic monitoring: based on the port mirroring function of Openv Switch, build a full-network ARP traffic collection channel on each host in the hyper-converged cluster; S22: Information extraction: analyze the captured ARP packets through a specified network analysis tool to extract key mapping information; S23: Build a global IP-MAC mapping table based on the etcd distributed cluster to realize unified management of mapping data across hosts, and guarantee data validity through the life cycle mechanism; S24: Conflict preliminary judgment: use the Watch mechanism of etcd to realize real-time monitoring of the global IP-MAC mapping table. When a different MAC address is added to the MAC address set corresponding to any IP address, and the set size is greater than or equal to 2, it is determined as an IP conflict, triggering a conflict detection event; S25: Perform three-layer confirmation mechanism to confirm the real IP conflict.

6. The method for virtual machine agentless IP self-healing suitable for hyper-converged architecture according to claim 1, wherein, The specific process of step S3 is as follows: S31: Conflict MAC list preprocessing: obtain the conflict MAC list after multiple confirmations, and perform format verification on each MAC address in the list to remove illegal format data; S32: Query the MAC-VM asset library to obtain specified association information; S33: TAP interface validity verification; S34: Determine the CephRBD disk path of the conflict virtual machine; S35: Integrate the positioning information corresponding to each valid conflict MAC to form a structured positioning result set.

7. The method for virtual machine agentless IP self-healing suitable for hyper-converged architecture according to claim 1, wherein, The specific process of step S4 is as follows: S41: Real-time collection of virtual machine DHCP packets and metadata service information, and qemu-guest-agent interface availability detection; S42: Based on the collected DHCP packets and ARP response data, perform preliminary configuration mode judgment to obtain basic recognition results; S43: For the basic recognition results, cross-verify with qemu-guest-agent interface and metadata service information to correct the preliminary judgment bias; S44: Output structured recognition results.

8. The method for virtual machine agentless IP self-healing suitable for hyper-converged architecture according to claim 1, wherein, The specific process of step S5 is as follows: When CONFLICT_IP is associated with multiple VM_ID, a hierarchical priority decision mechanism is used to determine the target virtual machine for repair. The decision follows the principle of preferentially repairing virtual machines that enter the scene later or have variable configurations. The specific decision process is as follows: Running state priority: the system preferentially selects virtual machines in the running state as the repair target; If there are instances of virtual machines that have been shut down in the candidate virtual machines, their priority is reduced in the decision, and the running virtual machines are preferentially repaired; Configuration mode second: if all candidate virtual machines are running, preferentially select virtual machines with DHCP IP configuration mode as the repair target; Response time bottom line: If all candidate virtual machines are in the same configuration mode, compare the timestamp of their last ARP response, and select the virtual machine with the later response time as the repair target.

9. The method for virtual machine agentless IP self-healing suitable for hyper-converged architecture according to claim 1, wherein, The hierarchical repair strategy of step S6 is executed as follows: If it is in DHCP mode: ARP spoofing flow table is issued through ovs-ofctl to intercept virtual machine DHCPRequest message and construct DHCP NAK message, so that the virtual machine releases CONFLICT_IP and reacquires NEW_IP. After the communication is restored, the ARP spoofing flow table is deleted. If it is in static mode and there is no qemu-guest-agent: Isolate the virtual machine network through the OpenvSwitch flow table, create a Ceph RBD snapshot, mount the disk root partition through guest after shutdown, identify the operating system type and modify the persistent network configuration file, replace CONFLICT_IP with NEW_IP of the self-healing IP pool, unload the disk and start the virtual machine. If it is in static mode and there is qemu-guest-agent: Write a network configuration script through the guest-file-write interface, execute the script to modify the IP configuration through the guest-exec interface, and realize online hot repair.

Images