Virtual machine agentless IP self-recovery method suitable for hyper-converged architecture

Abstract

The present application relates to a virtual machine agentless IP self-recovery method suitable for super-converged architecture, divides self-recovery IP pool and constructs MAC-VM asset library based on etcd distributed cluster; through OpenvSwitch port mirror listening ARP flow, combines multiple confirmation mechanism to accurately identify IP conflict; according to conflict MAC address, locates conflict virtual machine and corresponding CephRBD disk path; comprehensively judges virtual machine IP configuration mode according to multiple source data; according to running state priority, configuration mode second, response time bottom-up priority, determines repair target; according to DHCP mode, static agentless mode, static agent mode, executes hierarchical repair strategy; through repair verification and closed loop mechanism, ensures repair effect, and executes rollback operation when failing.The present application is compatible with agentless environment and DHCP and static IP mixed deployment scene, realizes permanent repair of IP conflict, greatly reduces manual intervention, improves stability and autonomy of super-converged platform, and has advantages of data safety and reliability, production level operation compatibility and the like.

Description

Technical Field

[0001] This invention belongs to the field of network operation and maintenance technology for hyperconverged architectures, and particularly relates to a self-healing method for virtual machine IPs without agents applicable to hyperconverged architectures. Background Technology

[0002] In a hyperconverged infrastructure based on KVM+Ceph+OpenvSwitch, the network configuration of virtual machines (VMs) is usually dynamically assigned via DHCP or manually set statically. Due to reasons such as incomplete network configuration during image cloning, user error leading to duplicate IP settings, or IP allocation conflicts caused by configuration management tool malfunctions, multiple virtual machines (or virtual machines and physical devices) often end up using the same IP address.

[0003] Such IP conflicts can cause problems such as ARP spoofing, network packet loss, and abnormal service access, seriously affecting the stability of hyperconverged platforms. Therefore, automatic detection and remediation of IP conflicts has become one of the core requirements for ensuring the stable operation of hyperconverged cloud platforms.

[0004] Currently, the industry mainly uses the following technical solutions to address IP conflict issues:

[0005] IP Acquisition and Detection Based on qemu-guest-agent:

[0006] By installing qemu-guest-agent inside the virtual machine and calling the guest-network-get-interfaces interface to obtain the IP address and MAC address mappings configured in the guest operating system, and combining this with the global IP-MAC mapping table built on the host side through ARP listening, the system can identify whether the same IP address is claimed by multiple MAC addresses, thus determining IP conflicts. This method has high accuracy, but it heavily relies on the installation and operation of the agent program on the guest machine and cannot be used on legacy systems, security-hardened systems, or temporary debugging virtual machines without qemu-guest-agent installed.

[0007] Conflict detection based on DHCP leases:

[0008] By analyzing the lease files of a DHCP server (such as dnsmasq), the IP-MAC mappings in the leases are compared with the actual ARP responses. If multiple MAC addresses are found to correspond to the same IP address, a conflict is identified. This method is suitable for pure DHCP environments, but it cannot handle virtual machines using static IP addresses and cannot achieve automatic repair.

[0009] ARP monitoring + manual intervention:

[0010] Administrators manually analyze OpenvSwitch by capturing ARP traffic using tcpdump or ovs-appctl to check for IP conflicts. If a conflict is found, the IP address must be manually modified by logging into the virtual machine or through the operations and maintenance platform. This method does not rely on qemu-guest-agent, but it has low automation, slow response time, and is not suitable for large-scale deployments.

[0011] Network isolation strategy:

[0012] Upon detecting an IP conflict, OpenvSwitch flow tables isolate the network traffic of the conflicting virtual machine (e.g., dropping its packets or retaining only the management channel) to prevent the spread of network pollution. While this approach mitigates the damage, it does not address the root cause of IP address conflicts, and service remains interrupted.

[0013] Existing technologies generally suffer from the following shortcomings: they rely on virtual machine-side components (such as qemu-guest-agent), have poor versatility, and cannot cover agentless scenarios; they lack automated repair capabilities, especially for virtual machines using static IP addresses, where there are no effective intervention methods; and most solutions remain at the level of "detection + isolation," failing to form a closed loop of "detection → repair → verification."

[0014] Therefore, this invention aims to provide 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 of the Invention

[0015] The purpose of this invention is to provide a self-healing method for agentless IPs of virtual machines suitable for hyperconverged architectures, in order to solve the problems of existing technologies that rely on virtual machine-side components, have poor versatility, cannot cover agentless scenarios, lack automated repair capabilities, especially for virtual machines using static IP addresses, and most solutions remain at the level of "detection + isolation" without forming a closed loop of "detection → repair → verification".

[0016] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows:

[0017] A method for agentless IP self-healing of virtual machines in hyperconverged architectures includes the following steps:

[0018] S1: Based on the etcd distributed cluster, divide the self-healing IP pool independent of the business network segment and build a MAC-VM asset library;

[0019] S2: Monitor ARP traffic, extract SPA and SHA to form IP-MAC mapping relationship, use etcd's Watch mechanism to monitor IP-MAC mapping table, trigger initial conflict judgment when the same IP is associated with two or more different MACs, and execute a multi-confirmation mechanism to confirm the real IP conflict and record CONFLICT_IP and the list of conflicting MACs.

[0020] S3: Query the MAC-VM asset library based on the conflict MAC list, obtain the corresponding VM_TAP_INTERFACE and VM_ID, and determine the CephRBD disk path of the conflicting virtual machine;

[0021] S4: Based on the virtual machine DHCP message and metadata service information, and with compatibility with calling the qemu-guest-agent interface when it exists, determine whether the virtual machine's IP configuration mode is DHCP or static.

[0022] S5: When a conflict involves multiple virtual machines, the repair target is determined according to a preset priority: virtual machines in the running state are selected first; if all are in the running state, virtual machines in DHCP mode are selected first; if the IP configuration modes are the same, virtual machines with the later ARP response timestamp are selected.

[0023] S6: Perform the corresponding repair operation according to the IP configuration mode and hierarchical repair strategy.

[0024] Preferably, it also includes a repair verification and closed-loop process, as follows:

[0025] Verify the repair results:

[0026] In DHCP mode, the virtual machine's MAC address is confirmed to declare NEW_IP and no longer declares CONFLICT_IP;

[0027] In static mode, confirm that the virtual machine uses NEW_IP and stop declaring CONFLICT_IP;

[0028] If the verification is successful: Update the self-healing IP pool status and IP-MAC mapping relationship in etcd, clean up temporary resources including snapshots and flow tables, and record the repair log;

[0029] If verification fails: Perform a rollback operation. In DHCP mode, delete the ARP spoofing flow table. In static agentless mode, roll back the CephRBD snapshot and start the virtual machine, triggering an alarm and logging the failure.

[0030] Preferably, the specific process of step S1 is as follows:

[0031] S11: Divide and manage self-healing IP pools: Build a unified / ip_pool / data path through the etcd cluster for centralized management of the network configuration and address status of the self-healing IP pools;

[0032] The IP addresses in the self-healing IP pool go through a lifecycle of available → used → released → available.

[0033] S12: Building a MAC-VM asset repository: Based on the etcd cluster, a unified / mac_vm / data path is built for centralized management of the relationship between MAC addresses and host virtual machines.

[0034] Preferably, the IP addresses in the self-healing IP pool in step S11 are configured according to the lifecycle flow rules of available → used → released → available as follows:

[0035] Allocation: During repair, the first available IP is retrieved from / ip_pool / available as NEW_IP, and simultaneously moved to / ip_pool / used / <NEW_IP> And record the associated VM_ID and allocation time;

[0036] Release: When the virtual machine is destroyed, IP conflict resolution is successfully verified, and there is no need to retain it, release / ip_pool / used / <NEW_IP> The entry is deleted, and the IP address is added back to / ip_pool / available.

[0037] Banning: If a secondary conflict or anomaly occurs after IP allocation, move it to / ip_pool / banned.

[0038] Preferably, the specific process of step S2 is as follows:

[0039] S21: Perform traffic monitoring: On each host machine in the hyperconverged cluster, build a network-wide ARP traffic collection channel based on the port mirroring function of OpenvSwitch;

[0040] S22: Extract information: Parse the captured ARP packets using a specified network analysis tool to extract key mapping information;

[0041] 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 lifecycle mechanism;

[0042] S24: Perform initial conflict judgment: Utilize etcd's Watch mechanism to achieve 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, it is judged as an IP conflict and a conflict detection event is triggered.

[0043] S25: Implement a three-tier confirmation mechanism to confirm the real IP conflict.

[0044] Preferably, the specific process of step S3 is as follows:

[0045] S31: Conflicting MAC List Preprocessing: Obtain the conflicting MAC list after multiple confirmations, perform format verification on each MAC address in the list, and remove illegal format data;

[0046] S32: Query the MAC-VM asset library to obtain specified associated information;

[0047] S33: TAP interface validity verification;

[0048] S34: Determine the CephRBD disk path of the conflicting virtual machine;

[0049] S35: Integrate the positioning information corresponding to each valid conflicting MAC to form a structured positioning result set.

[0050] Preferably, the specific process of step S4 is as follows:

[0051] S41: Real-time collection of virtual machine DHCP messages and metadata service information, and detection of qemu-guest-agent interface availability;

[0052] S42: Based on the collected DHCP messages and ARP response data, perform a preliminary configuration mode determination to obtain basic identification results;

[0053] 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;

[0054] S44: Output structured recognition results.

[0055] Preferably, the specific process of step S5 is as follows:

[0056] 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:

[0057] Running status priority: The system prioritizes virtual machines in the running state as repair targets;

[0058] 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.

[0059] 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.

[0060] 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.

[0061] Preferably, the graded repair strategy execution process in step S6 is as follows;

[0062] 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.

[0063] 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.

[0064] If it is in static mode and has qemu-guest-agent: the network configuration script is written through the guest-file-write interface, and the script is executed by calling the guest-exec interface to modify the IP configuration, thus realizing online hot repair.

[0065] The beneficial effects of this invention include:

[0066] 1. Agentless compatibility, covering all scenarios: It does not rely on the qemu-guest-agent inside the virtual machine. It only uses the existing components of the hyperconverged architecture to achieve IP conflict management, perfectly adapting to the agentless environment. It solves the problem of insufficient universality of existing technologies and is applicable to all types of virtual machine network configuration scenarios.

[0067] 2. Adaptable to mixed scenarios and comprehensive repair capabilities: It uniformly handles IP conflicts in mixed deployment scenarios of DHCP and static IP. It achieves rapid repair of DHCP mode virtual machines through the "ARP spoofing + DHCPNAK eviction" mechanism, and achieves root cause repair of static IP virtual machines through the "CephRBD snapshot backup + host-side offline mounting modification" or "qemu-guest-agent online hot repair" mechanism. It makes up for the shortcomings of existing technologies that only support DHCP scenarios and lack effective repair methods for static IP.

[0068] 3. Full-process automation reduces operation and maintenance costs: A closed-loop mechanism of full-process automation is built, which includes "detection → location → identification → repair → verification". From ARP traffic monitoring and conflict confirmation to virtual machine location and configuration pattern recognition, to repair target decision-making and hierarchical repair execution, and finally to result verification and resource cleanup, no manual intervention is required throughout the process. This greatly reduces repetitive operations for operation and maintenance personnel, improves the efficiency of IP conflict handling, and enhances the autonomy of the hyper-converged platform.

[0069] 4. Data security and reliability with no risk of damage during repair: The repair process fully utilizes the capabilities of the hyperconverged storage layer, automatically creating CephRBD snapshots before modifying the configuration of static IP virtual machines. In case of repair failure, it can quickly roll back to the original state, ensuring zero data loss. At the same time, mechanisms such as lease expiration and event-driven cleanup ensure the accuracy of IP-MAC mapping data, avoiding misjudgment and misoperation, thus solving the problem of data security not being guaranteed during the repair process of existing technologies.

[0070] 5. Precise and intelligent decision-making to ensure business stability: Adopting a hierarchical priority decision-making mechanism of "running status first, configuration mode second, and response time as a backup", priority is given to repairing running virtual machines with DHCP mode that are prone to configuration changes, and modification of static IP virtual machines that critical business depends on is avoided as much as possible. The "last entrant takes responsibility" logic makes the repair more reasonable, minimizes the impact of repair operations on online business, and ensures the stable operation of the hyper-converged platform. Attached Figure Description

[0071] Figure 1 This is a flowchart illustrating the agentless IP self-healing method for virtual machines applicable to hyperconverged architectures according to the present invention.

[0072] Figure 2 This is a schematic diagram of the execution process of the graded repair strategy of the present invention. Detailed Implementation

[0073] The following is in conjunction with the appendix Figures 1-2 The present invention will be further described in detail below:

[0074] Example 1

[0075] See appendix Figure 1 and Figure 2 As shown, the agentless IP self-healing method for virtual machines applicable to hyperconverged architectures includes the following steps:

[0076] S1: Preparatory work: Based on the etcd distributed cluster, divide the self-healing IP pool into independent business network segments and build a MAC-VM asset library.

[0077] S2: Perform ARP listening and conflict detection: Listen to ARP traffic, extract SPA and SHA to form IP-MAC mapping relationship, use etcd's Watch mechanism to monitor the IP-MAC mapping table, and trigger the initial conflict judgment when the same IP is associated with two or more different MACs.

[0078] It also implements a multi-confirmation mechanism: delaying for 1 second to verify the persistence of the conflict, querying the MAC-VM asset library and calling the libvirt interface to verify the actual running status of the virtual machine, combining the OUI database to filter physical device occupancy scenarios, confirming the real IP conflict and recording the CONFLICT_IP and conflict MAC list.

[0079] S3: Virtual machine attribution location: Query the MAC-VM asset library based on the confirmed conflict MAC list, obtain the corresponding VM_TAP_INTERFACE and VM_ID, verify the validity of the TAP interface, and determine the CephRBD disk path of the conflicting virtual machine.

[0080] S4: IP Configuration Mode Recognition: By comprehensively analyzing the virtual machine's DHCP messages and metadata service information, and by calling the qemu-guest-agent interface (if it exists), the virtual machine's IP configuration mode is determined to be either DHCP or static.

[0081] S5: Conflict Resolution Decision: When a conflict involves multiple virtual machines, the resolution target is determined according to the following priority: prioritize virtual machines in the running state; if all are in the running state, prioritize virtual machines in DHCP mode; if the configuration modes are the same, select the virtual machine with the later ARP response timestamp.

[0082] S6: Tiered repair strategy execution: Perform corresponding repair operations according to the IP configuration mode;

[0083] If in DHCP mode: ARP spoofing flow table is issued via ovs-ofctl, intercepting virtual machine DHCPRequest messages and constructing DHCPNAK messages, forcing the virtual machine to release CONFLICT_IP and reacquire NEW_IP, and deleting the ARP spoofing flow table after communication is restored.

[0084] 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 root partition of the disk 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.

[0085] If it is in static mode and has qemu-guest-agent: the network configuration script is written through the guest-file-write interface, and the script is executed by calling the guest-exec interface to modify the IP configuration, thus realizing online hot repair.

[0086] In another embodiment of this example, a repair verification and closed-loop process is also included, as detailed below:

[0087] Verification and repair results: In DHCP mode, it was confirmed that the virtual machine MAC address declares NEW_IP and no longer declares CONFLICT_IP; in static mode, it was confirmed that the virtual machine uses NEW_IP and stops declaring CONFLICT_IP.

[0088] If verification is successful: Update the self-healing IP pool status and IP-MAC mapping relationship in etcd, clean up temporary resources such as snapshots and flow tables, and record the repair log;

[0089] If verification fails: Perform a rollback operation. In DHCP mode, delete the ARP spoofing flow table. In static agentless mode, roll back the CephRBD snapshot and start the virtual machine, triggering an alarm and logging the failure.

[0090] Differential handling for validation failures:

[0091] For DHCP mode: The system ensures that ovs-ofctldel-flows is executed to delete the created ARP spoofing flow table rules, restoring basic network communication for the virtual machine, but IP conflict states still exist.

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

[0093] For online hotfixing of static IPs: This path cannot be automatically rolled back. The system records the failure status, requiring manual intervention.

[0094] Alarm triggered:

[0095] After performing the above operations, a high-level alarm is triggered, notifying the operations and maintenance personnel to intervene manually.

[0096] Record failure logs: Record repair failure logs for subsequent auditing and problem analysis. The logs include 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 results, error codes, and rollback operations. The logs are stored in JSON format and can be queried and exported from the operations and maintenance platform.

[0097] In this embodiment, the specific process of step S1 is as follows:

[0098] S11: Divide and manage self-healing IP pools: Build a unified / ip_pool / data path through the etcd cluster for centralized management of the network configuration and address status of the self-healing IP pools;

[0099] Select an independent network segment that does not overlap with the existing service network segment of the hyperconverged platform, such as 192.168.116.0 / 24, with a subnet mask of 255.255.255.0 and a default gateway of 192.168.116.1. This address will not participate in the allocation, ensuring that it does not overlap with the existing service network segment of the hyperconverged platform.

[0100] In the etcd distributed cluster, a unified root data path / ip_pool / is built as the centralized management entry point for the self-healing IP pool. All IP resource status and network parameters are stored under this path to ensure global consistency. The available IP list, used records, blocked list and network parameters are maintained under / ip_pool / to realize state-based management of IP resources.

[0101] Reserve 10% of emergency IPs, which will only be used when regular IPs are exhausted, to ensure repair capabilities in extreme scenarios. When the self-healing IP pool utilization rate is ≥90%, trigger an expansion alarm to avoid having no available IPs for repair.

[0102] The system periodically (every 60 seconds) counts the number of used IPs under the path / ip_pool / used / and calculates the utilization rate using the formula: Utilization rate = Number of used IPs / (Total number of IPs - Number of emergency IPs);

[0103] When the utilization rate is ≥90%, a capacity expansion alarm will be pushed via email or the operation and maintenance platform to remind the administrator to expand the network segment or clean up idle IPs;

[0104] The IP addresses in the self-healing IP pool go through a lifecycle of available → used → released → available.

[0105] S12: Building a MAC-VM asset repository: Based on the etcd cluster, a unified / mac_vm / data path is built for centralized management of the relationship between MAC addresses and host virtual machines;

[0106] Using the MAC address as the key, in / mac_vm / <MAC_ADDRESS> The path stores information such as the corresponding virtual machine identifier (e.g., VMID), TAP interface, and status, enabling global visibility and dynamic maintenance of MAC-VM mapping;

[0107] This asset repository supports real-time querying and event monitoring, providing a data foundation for ARP conflict detection and localization. The storage key-value structure is as follows:

[0108] / mac_vm / <MAC_ADDRESS> →{vm_id:"i-00000017",vm_tap_interface:"tap00000017.0",status:"running"}

[0109] in<MAC_ADDRESS> A 6-byte hexadecimal MAC address (e.g., 28:6E:D4:8A:39:29);

[0110] The library maintains real-time synchronization through the following two mechanisms:

[0111] Scheduled synchronization: The system deploys a synchronization agent on each host machine, which iterates through all local virtual machines every 5 minutes and executes virshdomiflist.<VM_ID> Obtain all its TAP interfaces and their corresponding MAC addresses, and execute virshdominfo.<VM_ID> Obtain its running status and synchronize this information to etcd in batches.

[0112] Event-driven synchronization: The system listens for virtual machine lifecycle events (such as started and stopped) and device change events (device-added and device-removed) via the libvirt API. When an event is triggered, the system performs incremental updates based on the event type.

[0113] For the virtual machine startup started event: update the mapping entries for all known MAC addresses of the virtual machine and set status: "running";

[0114] For virtual machine shutdown events (stopped or shutdown): Update the mapping entries for all known MAC addresses of the virtual machine and set status: "shutoff";

[0115] To add a device-added event to a network interface card (NIC): extract the MAC address of the newly added NIC from the event payload and create a new / mac_vm / <mac>The entry is associated with the VM_ID and TAP interface name;

[0116] For network card removal (device-removed) events: delete the / mac_vm / directory corresponding to the MAC address of that network card.<MAC_ADDRESS> entry;

[0117] For virtual machine Domain-Removed events: clean up all / mac_vm / entries corresponding to the MAC address associated with the VM_ID, and completely reclaim resources.

[0118] The above mechanism enables low-latency, high-precision MAC-VM mapping updates. Timed synchronization serves as a fault-tolerance mechanism to compensate for event loss or processing failures.

[0119] In step S11, the IP addresses in the self-healing IP pool are configured according to the lifecycle flow of available → used → released → available as follows:

[0120] Allocation: During repair, the first available IP is retrieved from / ip_pool / available as NEW_IP, and simultaneously moved to / ip_pool / used / <NEW_IP> And record the associated VM_ID and allocation time;

[0121] Release: When the virtual machine is destroyed, IP conflict resolution is successfully verified, and there is no need to retain it, release / ip_pool / used / <NEW_IP> The entry is deleted, and the IP address is added back to / ip_pool / available.

[0122] Banning: If a secondary conflict or anomaly occurs after IP allocation, it will be moved to / ip_pool / banned to avoid duplicate allocation. Manual investigation is required before unlocking.

[0123] etcd data consistency guarantees:

[0124] By leveraging the distributed nature of etcd, we ensure that all host nodes obtain consistent data when accessing the / ip_pool / path;

[0125] IP allocation and release operations use etcd's atomic operations, such as Compare-and-Swap, to avoid IP allocation conflicts in concurrent scenarios.

[0126] Example 2

[0127] Based on Example 1, the specific process of step S2 is as follows:

[0128] S21: Perform traffic monitoring: On each host machine within the hyperconverged cluster, build a network-wide ARP traffic collection channel based on the port mirroring function of OpenvSwitch (OVS):

[0129] Configure port mirroring rules on the OVS bridge (service bridge br1) on the host machine to copy all ARP request packets and gratuitous ARP packets flowing through the bridge to the listening port;

[0130] The monitoring process continuously captures ARP traffic on the mirror port without affecting the normal forwarding of business traffic, ensuring that the monitoring behavior has no significant impact on the performance of the hyperconverged platform;

[0131] It focuses only on ARP protocol-related packets (Ethernet type 0x0806), filtering out other irrelevant network traffic and improving data processing efficiency;

[0132] S22: Extract information: Use a network analysis tool such as scapy or tcpdump to parse the captured ARP packets and extract key mapping information. Set the rules as follows:

[0133] Extract the source IP address (SPA, SenderProtocolAddress) and source MAC address (SHA, SenderHardwareAddress) from the ARP packet header to form an "IP→MAC" mapping relationship;

[0134] It supports declaring multiple IP addresses using the same MAC address. In scenarios where virtual machines are configured to bind multiple IP addresses, the system will record all legal declaration behaviors and will not judge them as conflicts.

[0135] If the same IP address is detected to be claimed by two or more different MAC addresses, a preliminary conflict suspicion flag is triggered to provide basic data for subsequent conflict determination.

[0136] 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 lifecycle mechanism.

[0137] Data storage structure:

[0138] Create a unified / ip_mac / data path in etcd, using IP address as the key, and store all MAC addresses associated with that IP and their most recent declaration timestamp in JSON format. The timestamp records the time when the MAC address last declared the corresponding IP, providing a basis for subsequent conflict decision-making.

[0139] Automatic lease expiration mechanism:

[0140] For each / ip_mac / <IP_ADDRESS> The entry sets a 300-second etcdLease.

[0141] The self-healing agent on the host machine scans the local active virtual machines every 60 seconds and performs renewal operations on their associated IP-MAC mapping entries;

[0142] If the renewal fails due to virtual machine shutdown, migration, or network interruption, the entry will be automatically deleted from etcd after the lease expires to avoid the accumulation of zombie data affecting the accuracy of conflict detection.

[0143] Event-driven cleanup mechanism:

[0144] By monitoring virtual machine-related events related to the libvirt interface, differential data cleanup is performed to ensure the real-time performance of the mapping table. The cleanup rules are as follows:

[0145] Table 1 Cleanup Rules

[0146]

[0147] Configure the IP address change handling process:

[0148] When the monitoring detects that a MAC address has stopped declaring its original IP address and started declaring a new IP address, the system automatically executes:

[0149] Remove the MAC address from the mapping / ip_mac / <original IP> corresponding to the original IP;

[0150] Add the MAC address and the new timestamp to the / ip_mac / <newIP> mapping corresponding to the new IP;

[0151] This mechanism only handles normal IP changes for virtual machines. If an IP conflict is detected, it will be resolved through the proactive repair mechanism first, without relying on this passive change logic.

[0152] S24: Conduct initial conflict assessment:

[0153] The global IP-MAC mapping table is monitored in real time using etcd's Watch mechanism. The specific decision logic is set as follows:

[0154] 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 set size is ≥2, a conflict detection event is triggered.

[0155] Record the core information of the conflict: the conflicting IP address (CONFLICT_IP), a list of all conflicting MAC addresses, and the initial conflict determination timestamp, to provide data support for subsequent multiple confirmations;

[0156] S25: To eliminate interference factors such as network jitter, residual data, and physical device occupancy, a three-layer confirmation mechanism is executed to confirm the true IP conflict:

[0157] Conflict persistence verification:

[0158] After the initial conflict assessment, ARP traffic was captured again after a 1-second delay to verify whether the same IP address was still being claimed by multiple MAC addresses.

[0159] If the conflict disappears after the delay, it is determined to be a false alarm caused by network jitter, and no subsequent repair process is triggered; only the log is recorded.

[0160] If the conflict persists, proceed to the next confirmation stage.

[0161] Virtual machine running status verification:

[0162] Based on the list of conflicting MAC addresses, query the MAC-VM asset database in etcd to obtain the corresponding VM_ID and the recorded running status;

[0163] For VM_IDs with a status of "running", libvirt's virshdomstate is further called.<VM_ID> The interface queries the real-time running status;

[0164] If the real-time status is "shutoff", the MAC address will be marked as "potentially residual" and its weight will be reduced or excluded in subsequent repair decisions to avoid accidental operation on offline virtual machines, but the conflict record will be retained for auditing.

[0165] OUI vendor filtering verification:

[0166] Query the local OUI database (which is regularly synchronized with the official IEEE OUI data and supports manually adding custom vendor whitelists) to identify hardware manufacturers with conflicting MAC addresses.

[0167] If the vendor of a certain MAC address does not belong to a known virtualization platform (such as QEMU / KVM, VMware, etc.), then it is determined that CONFLICT_IP may be occupied by a physical network device.

[0168] In such scenarios, the system does not perform automatic repairs, but only logs and terminates the process to avoid accidental intervention in physical devices.

[0169] Final conflict confirmed:

[0170] After the above three layers of verification, if the situation of "the same IP being claimed by multiple active virtual machine MAC addresses" still exists, it will be finally determined to be a real IP conflict, and output information such as CONFLICT_IP, the confirmed list of conflicting MAC addresses, and associated VM_ID, triggering the subsequent virtual machine attribution and location process.

[0171] The specific process of step S3 is as follows:

[0172] S31: Conflicting MAC List Preprocessing:

[0173] The system retrieves a multi-confirmed list of conflicting MAC addresses (CONFLICT_MAC_LIST). This list filters physical device MAC addresses and offline virtual machine MAC addresses marked as "potentially residual," retaining only valid conflicting MAC addresses related to active virtual machines (in 6-byte hexadecimal format, e.g., 28:6E:D4:8A:39:29). The system performs format validation on each MAC address in the list (ensuring it conforms to the standard colon-separated MAC format), removing invalid data and avoiding invalid queries.

[0174] S32: Query the MAC-VM asset library to retrieve specified associated information:

[0175] For each preprocessed colliding MAC address, perform the following query operation:

[0176] Using the MAC address as the key, access the corresponding entry under the root path / mac_vm / in the etcd distributed cluster, i.e., query / mac_vm / <MAC_ADDRESS> ;

[0177] Extract the core associated information from the JSON data stored in this entry: the unique identifier of the virtual machine (VM_ID, such as i-00000017) and the name of the host-side TAP network interface (VM_TAP_INTERFACE, such as tap00000017.0).

[0178] If a conflicting MAC address is not found in the / mac_vm / path (possibly due to synchronization delay, abnormal MAC address, etc.), the system marks it as "unassociated virtual machine MAC", logs it, and temporarily excludes it from the subsequent location process. Only MAC addresses for which association information has been found will continue to be processed.

[0179] S33: TAP Interface Validation:

[0180] To prevent the associated information from becoming invalid due to interface deregistration, virtual machine migration, etc., the extracted VM_TAP_INTERFACE needs to be validated to ensure that it still belongs to the OpenvSwitch bridge on the current host machine. Specific steps are as follows:

[0181] On the host machine corresponding to the conflicting MAC address, execute the OpenvSwitch query command: ovs-vsctllistinterface<VM_TAP_INTERFACE> ;

[0182] The parsing command returns the following result: If the result contains detailed information about the VM_TAP_INTERFACE (such as interface status, affiliated bridge, MAC address binding relationship, etc.), and the interface status is "up" or "active", then the TAP interface is considered valid;

[0183] If the command returns "interface doesnotexist" or the interface status is "down" and there is no associated bridge information, then the TAP interface is considered invalid.

[0184] Trigger the MAC-VM asset library synchronization compensation mechanism: Immediately perform an incremental synchronization of virtual machine information on the host machine (call the virshdomiflist and dominfo interfaces to update the MAC-VM mapping).

[0185] After synchronization, re-query / mac_vm / <MAC_ADDRESS> If valid TAP interface information still cannot be obtained, the virtual machine associated with the MAC address will be marked as "location failed", logs will be recorded and alarms will be triggered. It will not be included in the repair process for the time being.

[0186] If valid TAP interface information is obtained after synchronization, continue with the subsequent process;

[0187] S34: Determine the CephRBD disk path of the conflicting virtual machine:

[0188] To accurately locate the CephRBD disk path of a virtual machine by querying its storage configuration using a valid VM_ID, the steps are as follows:

[0189] Based on the verified and valid VM_ID, call the hyperconverged platform management interface or libvirt related interface to query the storage configuration metadata of the virtual machine;

[0190] If querying via libvirt, execute the command virshdomblklist.<VM_ID> This command will return the mapping relationship of all block devices of the virtual machine, including the disk device name (such as vda, sda) and the corresponding backend storage path;

[0191] If you query through the hyperconverged platform management interface, you can directly obtain the storage resource configuration associated with the VM_ID, including information such as the Ceph storage pool name and disk image name;

[0192] Filter the query results to find the backend storage path corresponding to the root disk:

[0193] 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 its path format is the CephRBD standard path. Example: / dev / rbd / <storage pool name> / <virtual machine disk image name> (such as / dev / rbd / pool / vm-disk-i-00000017);

[0194] If the query result contains multiple block devices, the system locates the core disk for storing the operating system and network configuration files by identifying the disk label (such as the "root" identifier) or defaulting to the path of the first valid block device;

[0195] 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 information such as disk size, creation time, and status is returned and the status is "available", the path is determined to be valid; if "imagenotfound" is returned or the status is abnormal, it is marked as "invalid storage path", the log is recorded and an alarm is triggered, and the subsequent repair process of the virtual machine is terminated;

[0196] S35: Output the positioning result: Integrate the positioning information corresponding to each valid conflicting MAC to form a structured positioning result set.

[0197] Embodiment 3

[0198] Based on Embodiment 1 or Embodiment 2, the specific process of step S4 is as follows:

[0199] [[ID=​​​​​​​​​​​​​​Compare the leased IP address with the actual IP address declared by the virtual machine (obtained from the SPA field extracted from ARP sniffing). If the two match, it is preliminarily determined to be in DHCP mode.

[0205] Preliminary determination of static mode:

[0206] If no DHCP protocol messages are captured from the virtual machine (no data on UDP ports 67 / 68);

[0207] However, ARP sniffing confirmed that the virtual machine had a stable ARP response (i.e., it continuously declared a fixed IP address).

[0208] If the metadata service has no explicit DHCP configuration record (or the metadata service is unavailable), it is initially determined to be a static IP mode;

[0209] S43: Accuracy Optimization (Second-layer verification to improve recognition accuracy):

[0210] Based on the basic identification results, cross-validation is performed using the qemu-guest-agent interface (if available) and metadata service information to correct initial judgment biases.

[0211] qemu-guest-agent interface verification (execute first, if available):

[0212] Call the guest-network-get-interfaces interface of qemu-guest-agent to directly obtain the configuration details of the virtual machine's internal network interfaces, including the IP address, configuration source ("dhcp" or "static"), and ETH_NAME (such as enp4s0, eth0) of each interface.

[0213] If the configuration source returned by the interface is "dhcp", then the virtual machine is directly confirmed to be in DHCP mode, overriding the basic identification result;

[0214] If the configuration source is "static", then the virtual machine is directly confirmed to be in static mode, and ETH_NAME is recorded synchronously (to provide a basis for locating the configuration file when fixing static IP later).

[0215] Metadata service auxiliary verification:

[0216] If the metadata service query results show that the virtual machine's default configuration mode is DHCP, and it is consistent with the DHCP mode identified by the basic identification, then the judgment result is strengthened.

[0217] If the metadata service displays a preset static mode that is consistent with the static mode of basic identification, the judgment result will be strengthened.

[0218] If the metadata service result conflicts with the basic identification result (e.g., the metadata is set to DHCP but DHCP messages are not captured), the basic identification result shall prevail, and the conflict information shall be recorded in the log for subsequent audit analysis.

[0219] Special scene handling:

[0220] If the virtual machine has both DHCP messages and static IP declarations (such as in a multi-NIC scenario), then identify them separately according to the network interface: for each NIC, perform the above basic identification and accuracy optimization process separately to clarify the configuration mode of each NIC;

[0221] If the basic identification yields no clear results (e.g., a small number of DHCP packets are lost), and the agent is unavailable or the metadata service has no information, the ARP listening window is extended (for an additional 30 seconds), and the basic identification is performed again after data is recaptured; if there are still no results, it is determined to be in static mode (the default fallback strategy to avoid identification failure).

[0222] S44: Outputs structured recognition results, containing the following core information:

[0223] Table 2. Structured Recognition Result Information Table

[0224]

[0225] The specific process of step S5 is as follows:

[0226] When CONFLICT_IP is associated with multiple VM_IDs, a hierarchical priority decision-making mechanism is adopted to determine the target virtual machine to be repaired, ensuring the accuracy and security of the repair operation and avoiding impact on online services. The decision follows the core principle of "prioritizing the repair of virtual machines before entering the system or configuring volatile virtual machines," and the specific decision-making process is as follows:

[0227] Running status priority: The system prioritizes virtual machines in the running state as repair targets. If any candidate virtual machines are shut-off, their priority is reduced in the decision-making process, and repair is performed on running virtual machines first. This strategy ensures that repair operations target the actual entities causing network conflicts and avoids ineffective intervention on inactive instances such as offline template machines and backup virtual machines.

[0228] The next best configuration mode is the virtual machine with DHCP IP configuration. If all candidate virtual machines are running, the virtual machine with DHCP IP configuration mode should be selected as the repair target. This is because the design semantics of DHCP mode are "dynamically variable", and its IP address is variable; while static IP is usually used for critical business systems with higher stability requirements, and modification should be avoided as much as possible.

[0229] Response time fallback: If all candidate virtual machines are in the same configuration mode (e.g., all DHCP or all static), compare the timestamps of their most recent ARP responses (recorded in the etcdMAC-VM asset repository) and select the virtual machine with the later response time as the repair target. Virtual machines that send ARP responses later are more likely to be newly started or newly configured, belonging to the "latecomer," making it more reasonable for them to bear the responsibility for IP address adjustment. If the timestamps are the same, randomly select one for repair.< / mac>

Claims

1. A method for agentless IP self-healing of virtual machines in hyperconverged architectures, characterized in that, Includes the following steps: S1: Based on the etcd distributed cluster, divide the self-healing IP pool independent of the business network segment and build a MAC-VM asset library; S2: Monitor ARP traffic, extract SPA and SHA to form IP-MAC mapping relationship, use etcd's Watch mechanism to monitor IP-MAC mapping table, trigger initial conflict judgment when the same IP is associated with two or more different MACs, and execute a multi-confirmation mechanism to confirm the real IP conflict and record CONFLICT_IP and the list of conflicting MACs. S3: Query the MAC-VM asset library based on the conflict MAC list, obtain the corresponding VM_TAP_INTERFACE and VM_ID, and determine the CephRBD disk path of the conflicting virtual machine; S4: Based on the virtual machine DHCP message and metadata service information, and with compatibility with calling the qemu-guest-agent interface when it exists, determine whether the virtual machine's IP configuration mode is DHCP or static. S5: When a conflict involves multiple virtual machines, the repair target is determined according to a preset priority: virtual machines in the running state are selected first; if all are in the running state, virtual machines in DHCP mode are selected first; if the IP configuration modes are the same, virtual machines with the later ARP response timestamp are selected. S6: Perform the corresponding repair operation according to the IP configuration mode and hierarchical repair strategy; It also includes the repair verification and closed-loop process, as detailed below: Verify the repair results: In DHCP mode, the virtual machine's MAC address is confirmed to declare NEW_IP and no longer declares CONFLICT_IP; In static mode, confirm that the virtual machine uses NEW_IP and stop declaring CONFLICT_IP; If the verification is successful: Update the self-healing IP pool status and IP-MAC mapping relationship in etcd, clean up temporary resources including snapshots and flow tables, and record the repair log; If verification fails: Perform a rollback operation. In DHCP mode, delete the ARP spoofing flow table. In static agentless mode, roll back the CephRBD snapshot and start the virtual machine, trigger an alarm and record the failure log. The execution process of the graded repair strategy 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 Ceph RBD snapshot, after shutdown, mount the root partition of the disk through guest mount, 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 in static mode and has qemu-guest-agent: the network configuration script is written through the guest-file-write interface, and the script is executed by calling the guest-exec interface to modify the IP configuration, thus realizing online hot repair.

2. The agentless IP self-healing method for virtual machines applicable to hyperconverged architectures according to claim 1, characterized in that, The specific process of step S1 is as follows: S11: Divide and manage self-healing IP pools: Build a unified / ip_pool / data path through the etcd cluster for centralized management of the network configuration and address status of the self-healing IP pools; The IP addresses in the self-healing IP pool go through a lifecycle of available → used → released → available; S12: Building a MAC-VM asset repository: Based on the etcd cluster, a unified / mac_vm / data path is built for centralized management of the relationship between MAC addresses and host virtual machines.

3. The agentless IP self-healing method for virtual machines applicable to hyperconverged architectures according to claim 2, characterized in that, In step S11, the rules for the lifecycle flow of IP addresses in the self-healing IP pool, from available to used to released to available again, are set as follows: Allocation: During repair, the first available IP is retrieved from / ip_pool / available as NEW_IP, and simultaneously moved to / ip_pool / used / <NEW_IP> And record the associated VM_ID and allocation time; Release: When the virtual machine is destroyed, IP conflict resolution is successfully verified, and there is no need to retain it, release / ip_pool / used / <NEW_IP> The entry is deleted, and the IP address is added back to / ip_pool / available. Banning: If a secondary conflict or anomaly occurs after IP allocation, move it to / ip_pool / banned.

4. The agentless IP self-healing method for virtual machines applicable to hyperconverged architectures according to claim 1, characterized in that, The specific process of step S2 is as follows: S21: Perform traffic monitoring: On each host machine in the hyperconverged cluster, build a network-wide ARP traffic collection channel based on the port mirroring function of Openv Switch; S22: Extract information: Parse the captured ARP packets using 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 achieve unified management of mapping data across hosts and ensure data validity through a lifecycle mechanism; S24: Perform initial conflict judgment: Utilize etcd's Watch mechanism to achieve 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, it is judged as an IP conflict, and a conflict detection event is triggered. S25: Implement a three-tier confirmation mechanism to confirm the real IP conflict.

5. The agentless IP self-healing method for virtual machines applicable to hyperconverged architectures according to claim 1, characterized in that, The specific process of step S3 is as follows: S31: Conflicting MAC List Preprocessing: Obtain the conflicting MAC list after multiple confirmations, perform format verification on each MAC address in the list, and remove illegal format data; S32: Query the MAC-VM asset library to obtain specified associated information; S33: TAP interface validity verification; S34: Determine the CephRBD disk path of the conflicting virtual machine; S35: Integrate the positioning information corresponding to each valid conflict MAC to form a structured positioning result set.

6. The agentless IP self-healing method for virtual machines applicable to hyperconverged architectures according to claim 1, characterized in that, 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, cross-validate the qemu-guest-agent interface with metadata service information to correct the initial judgment bias; S44: Output structured recognition results.

7. The agentless IP self-healing method for virtual machines applicable to hyperconverged architectures according to claim 1, characterized in that, 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 repaired virtual machines before those that are configured to be vulnerable. 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.

Images