A KVM-based virtual network card management method and system

Abstract

The application discloses a kind of virtual network card management methods based on KVM, applied to KVM virtualization environment, comprising: a, start kvm-br-sync daemon process, b, from virtual bridge module actual connection state of virtual bridge and virtual network card is obtained;C, the consistency of the mapping relationship and the actual connection state is verified;D, detect whether virtual machine is not running or virtual network card is invalid;E, detect whether the connection of virtual bridge and virtual network card is lost without reason;F, after network restart or virtual bridge / hardware network card fault repair, read the mapping relationship in database, detect whether the current virtual machine and virtual network card state match.Through database storage effective mapping, solve the core pain point of " unable to automatically recover after fault repair", guarantee virtual machine network reachability.

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 and OpenvSwitch) build virtual bridges and establish connections with the virtual network cards (vnet) of virtual machines (Guest Domains) to implement the construction of virtual network scenarios. Currently, when a virtual machine is in the powered-on state, libvirt will actively establish the mapping relationship between the virtual network card and the virtual bridge. However, the validity of this mapping relationship completely depends on the normal operation of both 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 or hardware recovery), thereby causing the problem of unreachable virtual machine networks. 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 abnormal faults or human misoperations, the existing solutions lack effective detection and automatic repair mechanisms, which are prone to 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] In order to solve the technical problems in the existing KVM virtualization environment where the mapping relationship between the virtual network card and the virtual bridge in virtual network card management has no persistent storage and cannot be automatically restored after fault repair, resulting in unreachable virtual machine networks; lacking the联动 detection of the "running or non-running" state of the virtual machine, the effective or ineffective state of the virtual network card, and the connection state of the bridge, which is prone to generating zombie virtual network cards and affecting network stability; and having no automated repair mechanism for connection loss caused by service exceptions, human misoperations, etc., and requiring manual intervention, resulting in low operation and maintenance efficiency.

[0005] The technical solutions adopted by the present invention to solve the above technical problems are as follows:

[0006] Provide a virtual network card management method based on KVM, which is applied to a KVM virtualization environment and includes the following steps:

[0007] It should be noted that there is an unclear expression "联动检测" in the original text. You may need to further clarify this part for a more accurate translation.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.

[0008] b. Obtain the actual connection status between the virtual bridge and the virtual network card from the virtual bridge module;

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

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

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

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

[0013] To better achieve the purpose of the invention, this application also has the following superior technical solutions:

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

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

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

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

[0018] 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).

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

[0020] KVM virtualization environment: provides a virtual machine runtime environment, including at least one virtual machine and its corresponding virtual network card;

[0021] libvirt management module: provides an interface for querying virtual machine status, virtual network interface card (NIC) and virtual bridge mapping relationships;

[0022] Virtual bridge module: Provides connection management for virtual bridges and virtual network cards, and supports querying or operating connection status;

[0023] Persistent database: stores valid mapping relationship data;

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

[0025] 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

[0026] Figure 1: Flowchart of the mapping relationship acquisition and storage of the present invention;

[0027] Figure 2: Flowchart of the virtual machine non-running / virtual network card failure scenario processing of the present invention;

[0028] Figure 3: Flowchart of the present invention for handling scenarios where the virtual bridge and network card connection is lost without cause;

[0029] Figure 4: Fault recovery flowchart of the present invention. Detailed Implementation

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

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

[0032] 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).

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

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

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

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

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

[0038] This application also provides a KVM-based virtual network interface card (NIC) management system to implement the above method, including:

[0039] KVM virtualization environment: provides a virtual machine runtime environment, including at least one virtual machine and its corresponding virtual network card;

[0040] libvirt management module: provides an interface for querying virtual machine status, virtual network interface card (NIC) and virtual bridge mapping relationships;

[0041] Virtual bridge module: Provides connection management for virtual bridges and virtual network cards, and supports querying or operating connection status;

[0042] Persistent database: stores valid mapping relationship data;

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

[0044] 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).

[0045] 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".

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

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

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

[0049] 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 virtual network interface card (NIC) management method based on KVM, 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 described in 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