Virtual network card management method and system based on KVM

Abstract

The invention discloses a virtual network card management method based on a KVM (Keyboard Video Mouse), which is applied to a KVM virtualization environment and comprises the following steps: a, starting a kvm-br-sync daemon process, b, acquiring an actual connection state of a virtual network bridge and a virtual network card from a virtual network bridge module; c, verifying the consistency of the mapping relation and the actual connection state; d, detecting whether the virtual machine is not operated or whether the virtual network card is invalid; e, detecting whether the connection between the virtual network bridge and the virtual network card is lost for no reason; and f, after the network is restarted or the fault of the virtual network bridge / hardware network card is repaired, reading the mapping relation in the database, and detecting whether the current state of the virtual machine is matched with the state of the virtual network card or not. Effective mapping is stored through a database, the core pain point that automatic recovery cannot be achieved after fault recovery is solved, and the reachability of a virtual machine network is guaranteed.

Description

Technical Field

[0001] The present invention relates to the technical field of KVM virtualization, and particularly to a virtual network card management method and system based on KVM. Background Art

[0002] In a KVM virtualization environment, mainstream virtual network management tools (such as Linux Bridge, OpenvSwitch) build a virtual bridge and establish a connection with the virtual network card (vnet) of a virtual machine (Guest Domain) to implement the construction of a virtual network scenario. Currently, when the virtual machine is in the powered-on state, libvirt will actively establish a mapping relationship between the virtual network card and the virtual bridge, but the effectiveness of this mapping relationship completely depends on the simultaneous normal operation of the libvirt service and the virtual bridge service (Linux Bridge or Open vSwitch). If any one of these services fails, the mapping relationship cannot be established.

[0003] More critically, in the prior art, the mapping relationship between the virtual network card and the virtual bridge is not stored in a persistent data form. This results in the inability to automatically restore the previous mapping relationship even after subsequent fault repair (such as service restart, hardware recovery), thereby causing the problem of unreachable virtual machine network. In addition, when the virtual machine is in a non-running state, the virtual network card fails, or the connection between the virtual bridge and the virtual network card is lost due to an abnormal fault or human error, the existing solutions lack an effective detection and automatic repair mechanism, easily generating "zombie virtual network cards" (i.e., virtual network cards that have failed but still occupy bridge resources), causing waste of virtual network bandwidth, topological chaos, and even triggering a series of problems such as network instability. Summary of the Invention

[0004] To solve the technical problems in the existing virtual network card management in a KVM virtualization environment, where the mapping relationship between the virtual network card and the virtual bridge has no persistent storage and cannot be automatically restored after fault repair, resulting in an unreachable virtual machine network; there is a lack of linkage detection of the "running or non-running" state of the virtual machine, the effective or invalid state of the virtual network card, and the connection state of the bridge, easily generating zombie virtual network cards and affecting network stability; and there is no automated repair mechanism for connection loss caused by service exceptions, human errors, etc., requiring manual intervention and having low operation and maintenance efficiency.

[0005] The technical solutions adopted by the present invention to solve the above technical problems are as follows: Provide a virtual network card management method based on KVM, which is applied to a KVM virtualization environment and includes the following steps: a. Start the kvm-br-sync daemon process, and obtain the list of running virtual machines and the mapping relationship between virtual network cards and virtual bridges of each virtual machine from the libvirt management module through polling or event triggering. b. Obtain the actual connection status between the virtual bridge and the virtual network card from the virtual bridge module; c. Verify the consistency between the mapping relationship and the actual connection state; if consistent, store the mapping relationship in the persistent database; if inconsistent, re-execute steps ab to confirm the data. d. When a virtual machine is detected to be not running or a virtual network adapter is found to be faulty, check the connection status between the virtual bridge and the faulty virtual network adapter: if a connection exists, delete the connection; if no connection exists, synchronize the status of the mapping relationship in the database. e. When the connection between the virtual bridge and the virtual network adapter is detected to be lost without cause, check the status of the virtual machine and the virtual network adapter: if the virtual machine is running and the virtual network adapter is valid, automatically rebuild the connection; otherwise, synchronize the status of the mapping relationship in the database. f. When the network restarts or the virtual bridge / hardware network card fails and is repaired, read the mapping relationship in the database and match the current virtual machine and virtual network card status: if the virtual machine is running and the virtual network card is valid, the connection is automatically rebuilt; otherwise, the mapping relationship is marked as pending activation.

[0006] To better achieve the purpose of the invention, this application also has the following superior technical solutions: The event triggering includes events such as new virtual machine startup, virtual machine shutdown, and virtual network adapter addition or deletion, which are implemented by listening to the libvirt event API.

[0007] The mapping relationship includes virtual machine ID, virtual network card identifier, and virtual bridge identifier.

[0008] The virtual bridge module is either a Linux Bridge or an Open vSwitch. When it is a Linux Bridge, the connection status can be queried or manipulated using the brctl command; when it is an Open vSwitch, the connection status can be queried or manipulated using the ovs-vsctl command.

[0009] The persistent database is SQLite or MySQL, and the stored data includes virtual machine ID, virtual network card identifier, virtual bridge identifier, and timestamps of mapping relationships.

[0010] The mapping relationship follows the 1:N:M rule: that is, one virtual machine can have N virtual network cards (N≥1), one virtual network card is mapped to only one virtual bridge, and one virtual bridge can be associated with M virtual network cards (M≥1).

[0011] Based on the same concept, this application also provides a KVM-based virtual network interface card (NIC) management system to implement the above method, including: KVM virtualization environment: provides a virtual machine runtime environment, including at least one virtual machine and its corresponding virtual network card; libvirt management module: provides an interface for querying virtual machine status, virtual network interface card (NIC) and virtual bridge mapping relationships; Virtual bridge module: Provides connection management for virtual bridges and virtual network cards, and supports querying or operating connection status; Persistent database: stores valid mapping relationship data; The kvm-br-sync daemon is used to listen for events, retrieve data, verify consistency, perform automatic repairs, and interact with the database. It is developed in Python or Go and supports configuring a round-robin triggering cycle.

[0012] By effectively mapping storage through the database, it addresses the core pain point of "inability to automatically recover after fault repair," ensuring network reachability for virtual machines. It covers the entire process of "normal storage mapping," "anomaly repair," and "fault recovery," requiring no manual intervention, reducing operational costs. It automatically detects and removes zombie virtual network adapters, preventing invalid connections from consuming resources and reducing network topology chaos and bandwidth waste. It supports two mainstream virtual bridge tools: Linux Bridge and OpenvSwitch, and can be directly adapted to existing KVM virtualization environments without requiring reconstruction of the underlying architecture. Attached Figure Description

[0013] Figure 1: Flowchart of the mapping relationship acquisition and storage of the present invention; Figure 2: Flowchart of the virtual machine non-running / virtual network card failure scenario processing of the present invention; Figure 3: Flowchart of the present invention for handling scenarios where the virtual bridge and network card connection is lost without cause; Figure 4: Fault recovery flowchart of the present invention. Detailed Implementation

[0014] The present invention will be further described in detail below with reference to the embodiments.

[0015] refer to Figures 1 to 4 As shown, this application provides a KVM-based virtual network interface card (NIC) management method, applied to a KVM virtualization environment, characterized by including the following steps: a. Start the kvm-br-sync daemon process. It retrieves a list of running virtual machines and the mapping relationship between virtual network adapters (NICs) and virtual bridges for each virtual machine from the libvirt management module via polling or event triggering. Event triggering includes events such as new virtual machine startup, virtual machine shutdown, and virtual NIC addition or deletion, implemented by listening to the libvirt eventAPI. The mapping relationship includes the virtual machine ID, virtual NIC identifier, and virtual bridge identifier, following a 1:N:M rule: one virtual machine can have N virtual NICs (N≥1), one virtual NIC is mapped to only one virtual bridge, and one virtual bridge can be associated with M virtual NICs (M≥1).

[0016] b. Obtain the actual connection status of the virtual bridge and the virtual network card from the virtual bridge module; the virtual bridge module is either Linux Bridge or Open vSwitch. When it is Linux Bridge, the connection status is queried or manipulated using the brctl command; when it is Open vSwitch, the connection status is queried or manipulated using the ovs-vsctl command.

[0017] c. Verify the consistency between the mapping relationship and the actual connection state; if consistent, store the mapping relationship in a persistent database; if inconsistent, re-execute steps ab to confirm the data; the persistent database is SQLite or MySQL, and the stored data includes virtual machine ID, virtual network card identifier, virtual bridge identifier, and timestamp of the mapping relationship.

[0018] d. When a virtual machine is detected to be not running or a virtual network adapter is found to be faulty, check the connection status between the virtual bridge and the faulty virtual network adapter: if a connection exists, delete the connection; if no connection exists, synchronize the status of the mapping relationship in the database. e. When the connection between the virtual bridge and the virtual network adapter is detected to be lost without cause, check the status of the virtual machine and the virtual network adapter: if the virtual machine is running and the virtual network adapter is valid, automatically rebuild the connection; otherwise, synchronize the status of the mapping relationship in the database. f. When the network restarts or the virtual bridge / hardware network card fails and is repaired, read the mapping relationship in the database and match the current virtual machine and virtual network card status: if the virtual machine is running and the virtual network card is valid, the connection is automatically rebuilt; otherwise, the mapping relationship is marked as pending activation.

[0019] This application also provides a KVM-based virtual network interface card (NIC) management system to implement the above method, including: KVM virtualization environment: provides a virtual machine runtime environment, including at least one virtual machine and its corresponding virtual network card; libvirt management module: provides an interface for querying virtual machine status, virtual network interface card (NIC) and virtual bridge mapping relationships; Virtual bridge module: Provides connection management for virtual bridges and virtual network cards, and supports querying or operating connection status; Persistent database: stores valid mapping relationship data; The kvm-br-sync daemon is used to listen for events, obtain data, verify consistency, perform automatic repairs, and interact with the database. This kvm-br-sync daemon is developed in Python or Go and supports configuring a polling trigger cycle. In some embodiments, the hardware environment is as follows: the server CPU supports Intel VT-x or AMD-V virtualization technology, memory ≥16GB, and hard disk ≥500GB (for storing databases and virtual machine images). Software environment: Operating system is CentOS 7.x / 8.x or Ubuntu 20.04+, with KVM virtualization suite (qemu-kvm, libvirt), Linux Bridge (bridge-utils) or Open vSwitch (openvswitch-switch) installed. Database is SQLite (lightweight scenario) or MySQL (large-scale deployment scenario); kvm-br-sync process deployment: kvm-br-sync daemon is developed using Python or Go, configured with a polling period of 30 seconds, and the event triggering mechanism is to listen for libvirt's "virtual machine start / stop" and "network card addition / removal".

[0020] Taking the complete scenario of "virtual machine startup → mapped storage → accidental deletion of connection → automatic repair" as an example in some embodiments, the specific execution steps are as follows: Virtual machine startup: The administrator starts the virtual machine vm1 using `virsh start vm1`. libvirt automatically creates the virtual network interface vnet0 and attempts to establish a connection with the virtual bridge virbr0. Mapping acquisition and storage: kvm-br-sync obtains the running status of vm1 through "event triggering", calls `virsh domiflist vm1` to get the mapping relationship (vnet0→virbr0), and then calls `brctl show` to confirm that vnet0 is connected to virbr0. It writes "vm1-ID:1, vnet0, virbr0, timestamp: 2024-XX-XX XX:XX:XX" to the database. Human error in deleting a connection: The administrator accidentally executes `brctl delif virbr0 vnet0`, causing the connection between vnet0 and virbr0 to be lost. Automatic repair: kvm-br-sync detects the connection loss through polling, calls the libvirt API to confirm that vm1 is running and vnet0 is valid, automatically executes `brctl addif virbr0 vnet0` to rebuild the connection, and updates the database timestamp.

[0021] This solution addresses the core pain point of "inability to automatically recover after fault repair" through efficient database storage mapping, ensuring virtual machine network reachability. It covers the entire process of "normal storage mapping," "anomaly repair," and "fault recovery" without manual intervention, reducing operational costs. It automatically detects and removes zombie virtual network adapters, preventing invalid connections from consuming resources and reducing network topology chaos and bandwidth waste. It supports two mainstream virtual bridge tools: Linux Bridge and OpenvSwitch, and can be directly adapted to existing KVM virtualization environments without requiring reconstruction of the underlying architecture.

[0022] The above descriptions are merely some embodiments of the present invention. Those skilled in the art can make various modifications and improvements without departing from the inventive concept of the present invention, and these all fall within the scope of protection of the present invention.

Claims

1. A KVM-based virtual network interface card (NIC) management method, applied to a KVM virtualization environment, characterized in that, Includes the following steps: a. Start the kvm-br-sync daemon process, and obtain the list of running virtual machines and the mapping relationship between virtual network cards and virtual bridges of each virtual machine from the libvirt management module through polling or event triggering. b. Obtain the actual connection status between the virtual bridge and the virtual network card from the virtual bridge module; c. Verify the consistency between the mapping relationship and the actual connection state; if consistent, store the mapping relationship in a persistent database. If there is a discrepancy, repeat steps ab to confirm the data; d. When a virtual machine is detected to be not running or a virtual network adapter is found to be faulty, check the connection status between the virtual bridge and the faulty virtual network adapter: if a connection exists, delete the connection. If no connection exists, synchronize the state of the mapping relationship in the database; e. When the connection between the virtual bridge and the virtual network adapter is detected to be lost without cause, check the status of the virtual machine and the virtual network adapter: if the virtual machine is running and the virtual network adapter is valid, automatically rebuild the connection; otherwise, synchronize the status of the mapping relationship in the database. f. When the network restarts or the virtual bridge / hardware network card fails and is repaired, read the mapping relationship in the database and match the current virtual machine and virtual network card status: if the virtual machine is running and the virtual network card is valid, the connection is automatically rebuilt; otherwise, the mapping relationship is marked as pending activation.

2. The virtual network interface card (NIC) management method according to claim 1, characterized in that, The event triggering includes events such as new virtual machine startup, virtual machine shutdown, and virtual network adapter addition or deletion, which are implemented by listening to the libvirt event API.

3. The virtual network interface card (NIC) management method according to claim 1, characterized in that, The mapping relationship includes virtual machine ID, virtual network card identifier, and virtual bridge identifier.

4. The virtual network interface card (NIC) management method according to claim 1, characterized in that, The virtual bridge module is either a Linux Bridge or an Open vSwitch. When it is a Linux Bridge, the connection status can be queried or manipulated using the brctl command; when it is an Open vSwitch, the connection status can be queried or manipulated using the ovs-vsctl command.

5. The virtual network interface card (NIC) management method according to claim 1, characterized in that, The persistent database is SQLite or MySQL, and the stored data includes virtual machine ID, virtual network card identifier, virtual bridge identifier, and timestamps of mapping relationships.

6. The virtual network interface card (NIC) management method according to claim 1 or 3, characterized in that, The mapping relationship follows the 1:N:M rule: that is, one virtual machine can have N virtual network cards (N≥1), one virtual network card is mapped to only one virtual bridge, and one virtual bridge can be associated with M virtual network cards (M≥1).

7. A KVM-based virtual network interface card (NIC) management system, used to implement the method according to any one of claims 1-6, characterized in that, include: KVM virtualization environment: provides a virtual machine runtime environment, including at least one virtual machine and its corresponding virtual network card; libvirt management module: provides an interface for querying virtual machine status, virtual network interface card (NIC) and virtual bridge mapping relationships; Virtual bridge module: Provides connection management for virtual bridges and virtual network cards, and supports querying or operating connection status; Persistent database: stores valid mapping relationship data; The kvm-br-sync daemon is used to listen for events, retrieve data, verify consistency, perform automatic repairs, and interact with the database.

8. The system according to claim 7, characterized in that, The kvm-br-sync daemon is developed using Python or Go and supports configuration of a polling trigger cycle.

Images