KubeVirt-based physical network card direct-to-virtual machine life cycle management method and KubeVirt-based physical network card direct-to-virtual machine life cycle management device

Abstract

The invention provides a KubeVirt-based life cycle management method and device for directly connecting a physical network card to a virtual machine, and the method comprises the steps: firstly, carrying out the resource configuration of a network card of the virtual machine based on a network planning demand, and generating an SR-IOV scheme; and then, based on the SR-IOV scheme, performing automatic configuration management on physical server hardware, and generating physical network card configuration information. Based on the information, virtual function resources of the physical host machine are deployed through a Kubernetes network component, and plug-in management information is generated. And finally, based on the plug-in management information, virtual resource allocation information is generated by carrying out SR-IOV network card loading management on the virtual machine, and life cycle management of the physical network card through the virtual machine is completed. According to the embodiment of the invention, hardware-driven self-loading and starting-up self-loading of the straight-through network card are realized, the function of dynamically loading the straight-through network card by the virtual machine is ensured, the configuration process of automatic deployment and management of SR-IOV network card resources is simplified, and the utilization rate of virtual network resources is optimized.

Description

Technical Field

[0001] The present application relates to the field of cloud computing technology, and in particular to a lifecycle management method and device for a physical network card connected to a virtual machine based on KubeVirt. Background Art

[0002] KubeVirt: is an open source project based on Kubernetes cluster. It allows running and managing traditional virtual machines in Kubernetes clusters, so that virtualized and containerized workloads can coexist. SR-IOV (Single Root I / O Virtualization): is a hardware virtualization technology that allows physical devices (such as network cards) to be directly assigned to virtual machines in a virtualized environment, rather than being transferred through software virtual switches, to provide high-performance network access at the container level. Both are important technologies related to containers and virtualization. Their combination can achieve high-performance virtual machine and container network connections in Kubernetes clusters. KubeVirt abstracts virtual machine resources into Kubernetes objects and provides cloud-native management and orchestration methods, thereby enabling the collaboration of virtual machines and containerized applications, enhancing the flexibility and unity of the entire cloud-native stack. SR-IOV technology provides direct hardware access by dividing virtual functions (VFs) on physical network cards, improving the network performance of virtual machines and reducing latency. The combination of the two can effectively improve network efficiency in cloud environments.

[0003] However, the current process of integrating KubeVirt with SR-IOV still faces some technical challenges. First, the pass-through configuration of the physical network card involves multiple components, including hardware settings, SR-IOV network adapter configuration, installation of the SR-IOV CNI plug-in, and creation of the virtual machine network attachment definition (NAD). The entire integration process is relatively complex and prone to errors. Second, when managing SR-IOV resources, when multiple virtual machines share virtual function (VF) and physical function (PF) resources, resource competition problems may occur, resulting in resources that cannot be released or have been occupied, which affects the startup of the virtual machine and causes failure.

[0004] Therefore, one or more methods are needed to solve the above problems.

[0005] It should be noted that the information disclosed in the above background technology section is only used to enhance the understanding of the background of the present disclosure, and therefore may include information that does not constitute the prior art known to ordinary technicians in the field. Summary of the invention

[0006] The present application shows a lifecycle management method and device for a physical network card connected to a virtual machine based on KubeVirt.

[0007] In a first aspect, the present application shows a lifecycle management method for a physical network card pass-through virtual machine based on KubeVirt, the method comprising:

[0008] Based on network planning requirements, generate an SR-IOV solution by configuring resources for the virtual machine's network card;

[0009] Based on the SR-IOV solution, physical network card configuration information is generated by automatically configuring and managing physical server hardware;

[0010] Based on the physical network card configuration information, the virtual function resources of the physical host are deployed through the Kubernetes network component to generate plug-in management information;

[0011] Based on the plug-in management information, virtual resource allocation information is generated by loading management of the SR-IOV network card on the virtual machine, and life cycle management of the physical network card directly connected to the virtual machine is completed based on the virtual resource allocation information.

[0012] In an exemplary embodiment of the present disclosure, resource configuration is performed on a virtual machine network card, including:

[0013] Based on the VPC internal network architecture protocol, the default primary network card is allocated to the virtual machine through OVN to generate a virtual primary network card;

[0014] Based on the virtual primary network card, after evaluating the network environment, the SR-IOV virtualization technology is used to configure the additional network card of the virtual machine to generate a network planning solution;

[0015] Based on the network planning solution, an SR-IOV solution is generated by configuring resources of virtual functions and physical functions of the virtual machine.

[0016] In an exemplary embodiment of the present disclosure, automatic configuration management is performed on physical server hardware, including:

[0017] Based on the SR-IOV solution, by loading and configuring the vfio-pci driver on the physical server, vfio-pci driver self-loading information is generated;

[0018] Based on the vfio-pci driver self-loading information, a virtual function network card is generated by configuring a virtual function on a physical network card of the physical server;

[0019] Based on the vfio-pci driver self-loading information, physical network card configuration information is generated by binding the virtual function network card with the vfio-pci driver.

[0020] In an exemplary embodiment of the present disclosure, the virtual function resources of the physical host are deployed through the Kubernetes network component, including:

[0021] Generate a visual graphical interface based on the physical network card configuration information, and set the graphical interface according to user operation requirements;

[0022] Based on the physical network card configuration information, an interaction planning mechanism is generated by planning the interaction process between the plug-in network deployment and the Kubernetes cluster;

[0023] Based on the interactive planning mechanism, a plug-in repository is generated by binding preset network configuration parameters with preset network plug-ins.

[0024] In an exemplary embodiment of the present disclosure, the virtual function resources of the physical host are deployed through the Kubernetes network component, including:

[0025] Based on the network configuration parameters inputted in the graphical interface, the network configuration parameters are matched through the plug-in repository, the bound network plug-in is obtained, and plug-in automatic deployment information is generated;

[0026] Based on the plug-in automatic deployment information, the virtual function resources of the physical host are scanned to generate host virtual function resources, and the plug-in management information is generated by managing the host virtual function resources.

[0027] In an exemplary embodiment of the present disclosure, virtual resource allocation information is generated by performing loading management of an SR-IOV network card on a virtual machine, including:

[0028] Based on the network load demand, by judging whether the virtual machine needs to load the pass-through network card, when the virtual machine does not need to load the pass-through network card, the virtual machine uses the current virtual network interface;

[0029] When the virtual machine needs to load a pass-through network card, based on the plug-in management information, the Kubernetes network component interacts with the physical host machine to generate pass-through network card requirement information;

[0030] Based on the pass-through network card demand information, SR-IOV management resources are generated by configuring SR-IOV parameters;

[0031] Based on the SR-IOV management resource, the SR-IOV network card MAC address is generated by allocating a MAC address to the SR-IOV network card.

[0032] In an exemplary embodiment of the present disclosure, virtual resource allocation information is generated by performing loading management of an SR-IOV network card on a virtual machine, including:

[0033] Based on the SR-IOV network card MAC address, virtual resource occupation management information is generated by managing the occupation of virtual function resources;

[0034] Based on the SR-IOV network card MAC address, virtual resource protection management information is generated by performing protection management on the occupied virtual function resources;

[0035] Based on the SR-IOV network card MAC address, virtual resource recycling management information is generated by managing the recycling and reuse of virtual function resources;

[0036] By integrating the virtual resource occupation management information, the virtual resource protection management information and the virtual resource recovery management information, virtual resource allocation information is generated, and based on the virtual resource allocation information, life cycle management of the physical network card direct-to-virtual machine is completed.

[0037] In a second aspect, the present application shows a lifecycle management device for a physical network card pass-through virtual machine based on KubeVirt, the device comprising:

[0038] The network card planning module is used to configure resources for the network card of the virtual machine;

[0039] Hardware automatic configuration module, used for automatic configuration management of physical server hardware;

[0040] The network component automatic deployment module is used to deploy virtual function resources on physical hosts through Kubernetes network components;

[0041] The SR-IOV network card loading management module is used to perform loading management of the SR-IOV network card for the virtual machine, generate virtual resource allocation information, and complete the life cycle management of the physical network card directly connected to the virtual machine based on the virtual resource allocation information.

[0042] In a third aspect, the present application shows an electronic device, which includes: a processor; a memory for storing processor-executable instructions; wherein the processor is configured to execute the method described in any of the above aspects.

[0043] In a fourth aspect, the present application illustrates a non-temporary computer-readable storage medium, which, when instructions in the storage medium are executed by a processor of an electronic device, enables the electronic device to execute a method as described in any of the above aspects.

[0044] In a fifth aspect, the present application illustrates a computer program product. When instructions in the computer program product are executed by a processor of an electronic device, the electronic device is enabled to execute the method described in any of the above aspects.

[0045] The technical solution provided by this application may have the following beneficial effects:

[0046] Based on the embodiment of the present disclosure, first, according to the network planning requirements, the SR-IOV solution is generated by configuring the resources of the network card of the virtual machine. After that, based on the SR-IOV solution, the physical network card configuration information is generated by automatically configuring the physical server hardware. Based on this information, the virtual function resources of the physical host are deployed through the Kubernetes network component to generate plug-in management information. Finally, based on the plug-in management information, the virtual resource allocation information is generated by loading the SR-IOV network card of the virtual machine, and the life cycle management of the physical network card through the virtual machine is completed. Therefore, the embodiment of the present disclosure provides a simplified configuration and deployment scheme for the direct network card to reduce manual operations, hardware compatibility checks and configuration file modifications in the process of direct connection of the physical network card to the virtual machine. The self-loading of the hardware driver and the self-loading of the direct network card at power-on are realized, which ensures that the virtual machine dynamically loads the direct network card function, simplifies the configuration process of automatic deployment and management of SR-IOV network card resources, and optimizes the utilization rate of virtual network resources. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] Figure 1 This is a flowchart of the steps of a lifecycle management method for a physical network card directly connected to a virtual machine based on KubeVirt in this application;

[0048] Figure 2 This is a network planning flow chart of a lifecycle management method for a physical network card directly connected to a virtual machine based on KubeVirt in this application;

[0049] Figure 3 This is a hardware loading and plug-in deployment timing diagram of a lifecycle management method for a physical network card directly connected to a virtual machine based on KubeVirt in this application;

[0050] Figure 4 This is a timing diagram of a virtual machine dynamically loading a pass-through network card according to a lifecycle management method of a physical network card pass-through virtual machine based on KubeVirt of the present application;

[0051] Figure 5 It is a structural block diagram of a lifecycle management device for a physical network card directly connected to a virtual machine based on KubeVirt of the present application;

[0052] Figure 6 is a block diagram of an electronic device of the present application;

[0053] Figure 7 It is a block diagram of a computer-readable storage medium of the present application. DETAILED DESCRIPTION

[0054] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0055] Reference Figure 1 , shows a flow chart of the steps of a lifecycle management method of a physical network card pass-through virtual machine based on KubeVirt of the present application, the method can be applied to an electronic device, wherein the method can specifically include the following steps:

[0056] Step S101, based on the network planning requirements, generate an SR-IOV solution by configuring resources for the network card of the virtual machine;

[0057] Step S102, based on the SR-IOV solution, physical network card configuration information is generated by automatically configuring and managing the physical server hardware;

[0058] Step S103, deploying virtual function resources of the physical host machine through the Kubernetes network component based on the physical network card configuration information, and generating plug-in management information;

[0059] Step S104, based on the plug-in management information, virtual resource allocation information is generated by loading management of the SR-IOV network card for the virtual machine, and life cycle management of the physical network card directly connected to the virtual machine is completed based on the virtual resource allocation information.

[0060] Below, a lifecycle management method for a physical network card connected to a virtual machine based on KubeVirt in an embodiment of the present disclosure will be further described.

[0061] In step S101, an SR-IOV solution may be generated by configuring resources for a network card of a virtual machine based on network planning requirements.

[0062] In some optional embodiments of this example, Figure 2As shown in the figure, in the initial stage of network planning, it is necessary to clarify the allocation method of the primary network card of the virtual machine. Due to the characteristics of the VPC network architecture protocol, it can provide an independent and secure network environment for virtual machines. Therefore, through the rules and algorithms of OVN, it can ensure that the virtual primary network card is reasonably allocated within the VPC. Based on this allocation method, not only the connectivity and stability of the network are guaranteed, but also the network traffic between virtual machines can be effectively isolated to avoid mutual interference. At the same time, it can also facilitate network management and policy configuration, laying the foundation for subsequent network applications.

[0063] After the default primary network card is assigned, other network cards also need to be configured, and the process of configuring other additional network cards of the virtual machine requires the use of SR-IOV (Single Root I / O Virtualization) virtualization technology. Specifically, first, the entire network environment should be evaluated to understand the network load, application requirements for network bandwidth and latency, etc. Based on this information, the feasibility and necessity of implementing the network planning solution should be determined. Then, the hardware resources of the physical server, including the model of the network card, the supported functions, etc., should be studied to determine whether it meets the requirements of SR-IOV virtualization technology. When both the hardware and network requirements are adapted, the network planning solution can be implemented to improve network performance and effectively utilize resources.

[0064] After deciding to adopt a specific network planning solution, it is necessary to implement the SR-IOV solution by planning the configuration of VF (virtual function) and PF (physical function) resources.

[0065] Specifically, we can analyze the specific needs of each virtual machine for network resources, and determine the number and type of virtual functions that need to be allocated to each virtual machine based on different business application scenarios, such as database services, Web services, etc. At the same time, we must consider the load balancing of physical functions to avoid performance bottlenecks caused by excessive use of a physical function. Reasonable configuration of VF (virtual function) and PF (physical function) resources can not only improve the utilization of network resources, but also ensure that each virtual machine can obtain a stable and reliable network connection to meet the requirements of business operations.

[0066] In step S102, based on the SR-IOV solution, physical network card configuration information is generated by automatically configuring and managing physical server hardware.

[0067] In some optional embodiments of this example, the configuration of the physical network card requires the loading of the hardware automatic configuration module. This module is introduced to achieve seamless connection between server hardware resources and the SR-IOV solution. It can automatically identify the hardware environment of the server, including the type and quantity of network cards and other related hardware parameters. In modern data centers, server hardware configurations are complex and diverse, and manual configuration is prone to errors and inefficiency. The hardware automatic configuration module can greatly reduce manual intervention, improve the accuracy and efficiency of configuration, and ensure that the server is ready for the implementation of the SR-IOV solution when it starts.

[0068] The hardware auto-configuration module contains the vfio-pci driver self-loading information. When the server starts, the system automatically detects whether the vfio-pci driver needs to be loaded. This driver is crucial to the implementation of SR-IOV technology, which enables effective management and virtualization of hardware resources. The self-loading process requires good interaction with the server's BIOS and kernel to ensure that the driver is correctly loaded at the right time. At the same time, the loading process must be monitored and errors must be handled to prevent the entire network solution from failing to operate normally due to driver loading failure. For example, if the driver version is incompatible with the hardware or the loading order is wrong, it may cause a system failure, so the stability and accuracy of the self-loading process are key.

[0069] And, after the vfio-pci driver self-loading is completed, according to the vfio-pci driver self-loading information, the physical network card is obtained through the physical server to configure the virtual function, a virtual function network card is generated, and the virtual function network card is bound to the vfio-pci driver, completing the loading of the physical network card configuration information in the hardware automatic configuration module.

[0070] Specifically, first, through specific hardware detection mechanisms and commands, the detailed information of the physical network card is accurately obtained, including the number of virtual functions it supports, functional characteristics, etc. Then, based on this information, the virtual functions are reasonably configured, such as setting virtual function parameters, resource allocation, etc. Finally, the configured virtual function network card is bound to the vfio-pci driver. This binding process needs to follow the preset protocol and process to ensure smooth communication between the virtual function network card and the driver.

[0071] Only in this way can the smooth implementation of the SR-IOV solution at the physical server level be guaranteed, providing basic support for subsequent network functions.

[0072] In step S103, based on the physical network card configuration information, the virtual function resources of the physical host are deployed through the Kubernetes network component to generate plug-in management information.

[0073] Kubernetes (Kubernetes, abbreviated as K8s, is an abbreviation formed by replacing the eight characters "ubernete" in the middle of the name with 8. It is an open source containerized application for managing multiple hosts in the cloud platform. The goal of Kubernetes is to make the deployment of containerized applications simple and efficient (powerful). Kubernetes provides a mechanism for application deployment, planning, updating, and maintenance) The network component automatic deployment module plays a key role in the entire SR-IOV solution. Its main function is to realize the automatic deployment of the sriov-network-device-plugin plug-in and the sriov-network-cni plug-in. Among them, the sriov-network-device-plugin plug-in is responsible for interacting with physical devices and exposing the virtual function resources of the physical network card to the Kubernetes cluster. The sriov-network-cni plug-in is used for network configuration and management in the container network.

[0074] In some optional embodiments of this example, Figure 3 As shown in the figure, in order to facilitate user operations, first, a graphical interface is set up in the Kubernetes network component automatic deployment module for users to select SR-IOV network configuration parameters. When designing the graphical interface, the integrity and usability of the parameters should be considered. For example, parameters such as device identification ID and PCI address are essential for accurately identifying and configuring the virtual function resources of the physical network card. Moreover, the interface design should be clear so that users can easily enter these parameters. At the same time, the user input should be checked for legitimacy and prompted to prevent deployment failures due to incorrect input. In addition, the operating habits and permissions of different users should be considered to ensure that only authorized users can modify key parameters to ensure network security.

[0075] After that, we need to determine how the Kubernetes network component automatic deployment module connects to the Kubernetes cluster (through the API interface or other communication protocols). Based on this, we can plan the deployment location and operation mode of the Kubernetes network component automatic deployment module in the Kubernetes cluster and build an interactive planning mechanism between the two to ensure that it does not interfere with the normal operation of other components in the cluster.

[0076] At the same time, based on the interactive planning mechanism, a plug-in repository is constructed by binding the parameter configuration rules of the graphical interface with different plug-ins.

[0077] In some optional embodiments of this example, through the plug-in repository, the network plug-in required for SR-IOV can be automatically installed according to the network configuration parameters of SR-IOV (such as device identification ID, PCI address, etc.) entered by the user in the graphical interface, and the plug-in automatic deployment information can be generated.

[0078] Specifically, after the preparation work is completed, the sriov-network-device-plugin plug-in is automatically deployed. According to the network configuration parameters entered by the user in the graphical interface, or the default configuration rules, the installation package of the sriov-network-device-plugin plug-in is obtained from the plug-in repository. During the installation process, ensure the version compatibility of the plug-in with the Kubernetes cluster, and perform necessary configurations on the plug-in, such as setting connection parameters with the physical network card virtual function resources. After the installation is complete, the plug-in should be started and tested to check whether it can interact with the physical network card normally, accurately obtain virtual function resource information, and correctly feed this information back to the Kubernetes cluster to provide support for subsequent network resource management.

[0079] The deployment of the sriov-network-cni plug-in is similar to that of the sriov-network-device-plugin plug-in, and you also need to obtain the plug-in installation package. However, during the installation process, you should focus on the compatibility of the plug-in with the Kubernetes network model, because the sriov-network-cni plug-in plays a key role in the construction and configuration of the container network. When configuring the plug-in, set parameters such as network policies and IP allocation rules according to the network topology and user needs. After the deployment is complete, use test cases to check whether the plug-in can correctly allocate network resources to the container, realize network communication between containers, and ensure the stability and reliability of the container network.

[0080] After the plugin is deployed, the virtual function resources of the physical host are scanned, and all available host virtual function resources on the physical host are obtained through the interaction between the sriov-network-device-plugin plugin and the physical network card. Then, these virtual function resources are managed according to the network resource allocation strategy, and the plugin management information is constructed. This includes allocating virtual function resources to the required virtual machines or containers, and recording and monitoring the allocated resources. When the virtual function resources are no longer needed by the virtual machine or container, they should be recycled in time to ensure the effective use of resources. In addition, the use of resources should be counted and analyzed so that the resource allocation strategy can be adjusted according to the actual situation and the network performance can be optimized.

[0081] In step S104, based on the plug-in management information, virtual resource allocation information is generated by managing the loading of the SR-IOV network card on the virtual machine, and life cycle management of the physical network card connected to the virtual machine is completed based on the virtual resource allocation information.

[0082] In some optional embodiments of this example, Figure 4 As shown, first, you need to set the parameters that allow dynamic loading of the pass-through network card in the virtual machine's configuration file or management system. When the network resource demand changes during the startup or operation of the virtual machine, the system determines whether the pass-through network card needs to be loaded based on the preset conditions and algorithms. This judgment process needs to comprehensively consider the current network load demand of the virtual machine, the demand for network bandwidth of the business application, and the virtual function resources on the physical host. When loading is not required, the system continues to use the existing virtual network interface to run.

[0083] When loading is required, the system generates pass-through network card demand information based on the plug-in management information built above, by interacting with Kubernetes network components and physical servers.

[0084] Based on the demand information, the SR-IOV parameters of the virtual function network card are customized through the virtual machine to generate SR-IOV management resources.

[0085] Specifically, the SR-IOV-NetworkAttachmentDefinition resource can be automatically created based on the pass-through network card requirement information. Through the SR-IOV-NetworkAttachmentDefinition resource, the PCI address, VLAN and other information of the virtual function network card can be customized. And through the collaboration with the Kuber netes network component, the SR-IOV network card MAC address is automatically assigned to the virtual function network card.

[0086] The allocation of MAC addresses needs to follow certain rules, which not only ensures the uniqueness of the address, but also matches the network topology and IP allocation strategy. During the automatic allocation process, the migration of virtual machines and other situations must be taken into consideration to ensure the stability of MAC addresses in different environments. At the same time, the function that virtual machines can automatically migrate to nodes with virtual function network card resources must be implemented. During the migration process, the continuity of network connection must be guaranteed. Through reasonable resource management and network configuration updates, virtual machines can continue to use pass-through network cards for communication on new nodes without affecting the normal operation of services.

[0087] Finally, once created, the resource needs to be verified to ensure that it can properly direct network traffic and enable the virtual machine to communicate with other virtual machines or external networks through the pass-through network adapter.

[0088] In some optional embodiments of this example, Figure 4 As shown, when a virtual machine or container uses virtual function network card resources, the use of virtual function resources can be managed in many aspects by setting up a management module. Among them, on the one hand, based on the uniqueness of the MAC address of the SR-IOV network card, the resource occupancy is accurately recorded, including which virtual machine occupies which virtual function network cards, the occupied time and other virtual resource occupancy management information. Through this detailed record, the resource usage status can be monitored in real time to prevent excessive occupation or unreasonable allocation of resources. At the same time, a resource occupation priority mechanism should be established. For virtual machines of important businesses, virtual function network card resources can be allocated preferentially to ensure the network performance of key businesses. In addition, the resource occupation process should be monitored to promptly discover and handle possible resource conflicts.

[0089] Secondly, based on the uniqueness of the SR-IOV network card MAC address, an effective protection mechanism needs to be established to ensure that occupied virtual function network card resources will not be reused. During the resource allocation process, the occupied resources are marked through the management module to generate virtual resource protection management information. When other virtual machines or containers request resources, the system will first check the resource occupation mark. If the resources are already occupied, new allocation requests are rejected until the virtual machine or container occupying the resources releases the resources. This protection mechanism can avoid network failures and data loss caused by resource reuse, and ensure the stability and reliability of the network. At the same time, the resource occupation mark should be checked and cleaned regularly to prevent resource management problems caused by marking errors.

[0090] Thirdly, based on the uniqueness of the SR-IOV NIC MAC address, when the virtual machine is recycled, the virtual function NIC resources must be released in time and re-added to the resource pool. When the virtual machine stops running or no longer needs the virtual function NIC resources, the resource recycling process is triggered by the management module to generate virtual resource recycling management information. In this information, first ensure that the connection between the virtual machine and the virtual function NIC is completely disconnected, and release related network configurations and occupied memory and other resources. Then, mark the virtual function NIC resources as available and re-add them to the resource pool so that other virtual machines or containers can use them again. During the resource recycling process, the recycled resources must be checked and repaired. If problems are found with the resources, they must be handled in a timely manner to ensure that the virtual function NIC resources re-added to the resource pool are available and have good performance, thereby improving resource utilization and the overall performance of the network.

[0091] Through the above three aspects, accurate recording and monitoring of virtual function network card resources (including resource occupation, priority allocation, conflict detection and protection mechanism) are achieved, thereby ensuring the reasonable allocation of network resources for virtual machines and containers. In addition, by marking occupied resources and establishing protection mechanisms, failures caused by repeated resource allocation are avoided. Resources are also recovered and problems are repaired in a timely manner when the virtual machine stops running, ensuring efficient use and stability of resources. Finally, by integrating these management measures, virtual resource allocation information is generated, and life cycle management of physical network cards passing through virtual machines is realized.

[0092] It should be noted that, for the method embodiments, for the sake of simplicity, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the present application is not limited by the order of the actions described, because according to the present application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all optional embodiments, and the actions involved are not necessarily required by the present application.

[0093] Reference Figure 5 , shows a structural block diagram of a lifecycle management device for a physical network card that directly connects to a virtual machine based on KubeVirt of the present application, wherein the lifecycle management device 500 for a physical network card that directly connects to a virtual machine based on KubeVirt includes:

[0094] The network card planning module 501 is used to configure resources for the network card of the virtual machine;

[0095] The hardware automatic configuration module 502 is used to automatically configure and manage the physical server hardware;

[0096] The network component automatic deployment module 503 is used to automatically deploy virtual function resources of the physical host machine through the Kubernetes network component;

[0097] The SR-IOV network card loading management module 504 is used to manage the loading of the SR-IOV network card for the virtual machine, generate virtual resource allocation information, and complete the life cycle management of the physical network card directly connected to the virtual machine based on the virtual resource allocation information.

[0098] As for the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0099] Optionally, an embodiment of the present application further provides an electronic device, comprising: a processor, a memory, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, the various processes of the above-mentioned method embodiment are implemented, and the same technical effect can be achieved. To avoid repetition, it will not be described here.

[0100] The embodiment of the present application also provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, each process of the above method embodiment is implemented, and the same technical effect can be achieved. To avoid repetition, it is not repeated here. The computer-readable storage medium is, for example, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0101] Figure 6 800 is a block diagram of an electronic device 800 shown in the present application. For example, the electronic device 800 may be a mobile phone, a computer, a digital broadcast terminal, a messaging device, a game console, a tablet device, a medical device, a fitness device, a personal digital assistant, etc.

[0102] Reference Figure 6 , the electronic device 800 may include one or more of the following components: a processing component 802 , a memory 804 , a power component 806 , a multimedia component 808 , an audio component 810 , an input / output (I / O) interface 812 , a sensor component 814 , and a communication component 816 .

[0103] The processing component 802 generally controls the overall operation of the electronic device 800, such as operations associated with display, phone calls, data communications, camera operations, and recording operations. The processing component 802 may include one or more processors 820 to execute instructions to complete all or part of the steps of the above method. In addition, the processing component 802 may include one or more modules to facilitate the interaction between the processing component 802 and other components. For example, the processing component 802 may include a multimedia module to facilitate the interaction between the multimedia component 808 and the processing component 802.

[0104] The memory 804 is configured to store various types of data to support operations on the device 800. Examples of such data include instructions for any application or method operating on the electronic device 800, contact data, phone book data, messages, images, videos, etc. The memory 804 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk.

[0105] The power supply component 806 provides power to the various components of the electronic device 800. The power supply component 806 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the electronic device 800.

[0106] The multimedia component 808 includes a screen that provides an output interface between the electronic device 800 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touch screen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touch, slide, and gestures on the touch panel. The touch sensor may not only sense the boundaries of the touch or slide action, but also detect the duration and pressure associated with the touch or slide operation. In some embodiments, the multimedia component 808 includes a front camera and / or a rear camera. When the device 800 is in an operating mode, such as a shooting mode or a video mode, the front camera and / or the rear camera may receive external multimedia data. Each front camera and the rear camera may be a fixed optical lens system or have a focal length and optical zoom capability.

[0107] The audio component 810 is configured to output and / or input audio signals. For example, the audio component 810 includes a microphone (MIC), and when the electronic device 800 is in an operating mode, such as a call mode, a recording mode, and a voice recognition mode, the microphone is configured to receive an external audio signal. The received audio signal can be further stored in the memory 804 or sent via the communication component 816. In some embodiments, the audio component 810 also includes a speaker for outputting audio signals.

[0108] I / O interface 812 provides an interface between processing component 802 and peripheral interface modules, such as keyboards, click wheels, buttons, etc. These buttons may include but are not limited to: home button, volume button, start button, and lock button.

[0109] The sensor assembly 814 includes one or more sensors for providing various aspects of status assessment for the electronic device 800. For example, the sensor assembly 814 can detect the open / closed state of the device 800, the relative positioning of components, such as the display and keypad of the electronic device 800, and the sensor assembly 814 can also detect the position change of the electronic device 800 or a component of the electronic device 800, the presence or absence of contact between the user and the electronic device 800, the orientation or acceleration / deceleration of the electronic device 800, and the temperature change of the electronic device 800. The sensor assembly 814 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. The sensor assembly 814 may also include an optical sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, the sensor assembly 814 may also include an accelerometer, a gyroscope sensor, a magnetic sensor, a pressure sensor, or a temperature sensor.

[0110] The communication component 816 is configured to facilitate wired or wireless communication between the electronic device 800 and other devices. The electronic device 800 can access a wireless network based on a communication standard, such as WiFi, a carrier network (such as 2G, 3G, 4G or 5G), or a combination thereof. In an exemplary embodiment, the communication component 816 receives a broadcast signal or broadcast operation information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component 816 also includes a near field communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology and other technologies.

[0111] In an exemplary embodiment, the electronic device 800 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the above methods.

[0112] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 804 including instructions, and the instructions can be executed by a processor 820 of an electronic device 800 to perform the above method. For example, the non-transitory computer-readable storage medium can be a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, etc.

[0113] Figure 719 is a block diagram of a computer-readable storage medium 1900 shown in the present application. For example, the computer-readable storage medium 1900 may be provided as a server.

[0114] Reference Figure 7 , the computer-readable storage medium 1900 includes a processing component 1922, which further includes one or more processors, and a memory resource represented by a memory 1932 for storing instructions, such as an application, that can be executed by the processing component 1922. The application stored in the memory 1932 may include one or more modules, each corresponding to a set of instructions. In addition, the processing component 1922 is configured to execute instructions to perform the above method.

[0115] The computer readable storage medium 1900 may also include a power supply component 1926 configured to perform power management of the computer readable storage medium 1900, a wired or wireless network interface 1950 configured to connect the computer readable storage medium 1900 to a network, and an input / output (I / O) interface 1958. The computer readable storage medium 1900 may operate based on an operating system stored in the memory 1932, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™ or the like.

[0116] It should be noted that, in this article, the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the sentence "comprises a ..." does not exclude the existence of other identical elements in the process, method, article or device including the element.

[0117] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, a magnetic disk, or an optical disk), and includes a number of instructions for a terminal (which can be a mobile phone, a computer, a server, an air conditioner, or a network device, etc.) to execute the methods described in each embodiment of the present application.

[0118] The embodiments of the present application are described above in conjunction with the accompanying drawings, but the present application is not limited to the above-mentioned specific implementation methods. The above-mentioned specific implementation methods are merely illustrative and not restrictive. Under the guidance of the present application, ordinary technicians in this field can also make many forms without departing from the purpose of the present application and the scope of protection of the claims, all of which are within the protection of the present application.

[0119] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed in the present application can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0120] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0121] In the embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0122] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0123] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0124] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the methods described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as USB flash drives, mobile hard drives, ROM, RAM, magnetic disks, or optical disks.

[0125] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A lifecycle management method for a physical network card connected to a virtual machine based on KubeVirt, characterized in that: The method comprises: Based on network planning requirements, generate an SR-IOV solution by configuring resources for the virtual machine's network card; Based on the SR-IOV solution, physical network card configuration information is generated by automatically configuring and managing physical server hardware; Based on the physical network card configuration information, the virtual function resources of the physical host are deployed through the Kubernetes network component to generate plug-in management information; Based on the plug-in management information, virtual resource allocation information is generated by loading management of the SR-IOV network card on the virtual machine, and life cycle management of the physical network card directly connected to the virtual machine is completed based on the virtual resource allocation information.

2. The method according to claim 1, characterized in that By configuring resources for the virtual machine network card, including: Based on the VPC internal network architecture protocol, the default primary network card is allocated to the virtual machine through OVN to generate a virtual primary network card; Based on the virtual primary network card, after evaluating the network environment, the SR-IOV virtualization technology is used to configure the additional network card of the virtual machine to generate a network planning solution; Based on the network planning solution, an SR-IOV solution is generated by configuring resources of virtual functions and physical functions of the virtual machine.

3. The method according to claim 1, characterized in that Through automated configuration management of physical server hardware, including: Based on the SR-IOV solution, by loading and configuring the vfio-pci driver on the physical server, vfio-pci driver self-loading information is generated; Based on the vfio-pci driver self-loading information, a virtual function network card is generated by configuring a virtual function on a physical network card of the physical server; Based on the vfio-pci driver self-loading information, physical network card configuration information is generated by binding the virtual function network card with the vfio-pci driver.

4. The method according to claim 1, characterized in that Deploy virtual function resources on physical hosts through Kubernetes network components, including: Generate a visual graphical interface based on the physical network card configuration information, and set the graphical interface according to user operation requirements; Based on the physical network card configuration information, an interaction planning mechanism is generated by planning the interaction process between the plug-in network deployment and the Kubernetes cluster; Based on the interactive planning mechanism, a plug-in repository is generated by binding preset network configuration parameters with preset network plug-ins.

5. The method according to claim 4, characterized in that Deploy virtual function resources on physical hosts through Kubernetes network components, including: Based on the network configuration parameters inputted in the graphical interface, the network configuration parameters are matched through the plug-in repository, the bound network plug-in is obtained, and plug-in automatic deployment information is generated; Based on the plug-in automatic deployment information, the virtual function resources of the physical host are scanned to generate host virtual function resources, and the plug-in management information is generated by managing the host virtual function resources.

6. The method according to claim 1, characterized in that By loading and managing the SR-IOV network card of the virtual machine, virtual resource allocation information is generated, including: Based on the network load demand, by judging whether the virtual machine needs to load the pass-through network card, when the virtual machine does not need to load the pass-through network card, the virtual machine uses the current virtual network interface; When the virtual machine needs to load a pass-through network card, based on the plug-in management information, the Kubernetes network component interacts with the physical host machine to generate pass-through network card requirement information; Based on the pass-through network card demand information, SR-IOV management resources are generated by configuring SR-IOV parameters; Based on the SR-IOV management resource, the SR-IOV network card MAC address is generated by allocating a MAC address to the SR-IOV network card.

7. The method according to claim 6, characterized in that By loading and managing the SR-IOV network card of the virtual machine, virtual resource allocation information is generated, including: Based on the SR-IOV network card MAC address, virtual resource occupation management information is generated by managing the occupation of virtual function resources; Based on the SR-IOV network card MAC address, virtual resource protection management information is generated by performing protection management on the occupied virtual function resources; Based on the SR-IOV network card MAC address, virtual resource recycling management information is generated by managing the recycling and reuse of virtual function resources; By integrating the virtual resource occupation management information, the virtual resource protection management information and the virtual resource recovery management information, virtual resource allocation information is generated, and based on the virtual resource allocation information, life cycle management of the physical network card direct-to-virtual machine is completed.

8. A lifecycle management device for a physical network card connected to a virtual machine based on KubeVirt, characterized in that: include: The network card planning module is used to configure resources for the network card of the virtual machine; Hardware automatic configuration module, used for automatic configuration management of physical server hardware; The network component automatic deployment module is used to deploy virtual function resources on physical hosts through Kubernetes network components; The SR-IOV network card loading management module is used to perform loading management of the SR-IOV network card for the virtual machine, generate virtual resource allocation information, and complete the life cycle management of the physical network card directly connected to the virtual machine based on the virtual resource allocation information.

9. An electronic device, characterized in that: include: A processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the computer program implements the method according to any one of claims 1 to 7 when executed by the processor.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method according to any one of claims 1 to 7 is implemented.

Images