Virtual machine DHCP configuration method and device

Abstract

The invention provides a virtual machine DHCP (Dynamic Host Configuration Protocol) configuration method and device, and relates to the technical field of cloud computing, in particular to the technical field of network virtualization. A specific embodiment of the method comprises the following steps: intercepting a target DHCP request initiated by a virtual machine; querying network configuration information of the virtual machine based on the target DHCP request; in response to the inquired network configuration information of the virtual machine, generating a target DHCP response based on the target DHCP request and the network configuration information; and sending the target DHCP response to the virtual machine.

Description

Technical Field

[0001] This disclosure relates to the field of cloud computing technology, specifically the field of network virtualization technology. Background Technology

[0002] With the rapid development of cloud computing and network virtualization technologies, KVM (Kernel-based Virtual Machine) virtualization solutions based on the x86 architecture are widely used in various computing scenarios. After network virtualization is implemented, the KVM virtual machine network running on the compute nodes generally adopts an overlay network architecture. This architecture uses tunnel technology to connect the KVM virtual machine and the network node. The network data of the KVM virtual machine needs to complete the interaction with the underlying network through the network node, thereby achieving isolation and communication between the virtual network and the physical network, and meeting the needs of flexible allocation and management of network resources in different business scenarios. Under this architecture, the accurate configuration of network parameters such as the KVM virtual machine's network interface card (NIC) IP (Internet Protocol), Gateway, DNS (Domain Name System), and MTU (Maximum Transmission Unit) becomes a key prerequisite for ensuring that the KVM virtual machine can carry out network communication and perform business functions normally.

[0003] Currently, there are three main methods in the industry for setting network parameters for KVM virtual machines: Firstly, a dedicated DHCP (Dynamic Host Configuration Protocol) server is deployed for each VPC (Virtual Private Cloud) within the virtual network. This dedicated DHCP server allocates and manages network parameters for the KVM virtual machines within the corresponding VPC. Secondly, by deploying a specific Agent program inside the KVM virtual machine, network parameters can be set and adjusted directly within the virtual machine's operating system. Third, relying on OVN (Open Virtual Network) technology, and utilizing OVN's logical switch components and DHCP_Options function module, a parameter configuration mechanism at the virtual network layer is constructed to achieve unified configuration and distribution of KVM virtual machine network parameters. Summary of the Invention

[0004] This disclosure presents a virtual machine DHCP configuration method, apparatus, device, storage medium, and program product.

[0005] In a first aspect, embodiments of this disclosure propose a virtual machine DHCP configuration method, comprising: intercepting a target DHCP request initiated by a virtual machine; querying the network configuration information of the virtual machine based on the target DHCP request; in response to the querying of the network configuration information of the virtual machine, generating a target DHCP response based on the target DHCP request and the network configuration information; and sending the target DHCP response to the virtual machine.

[0006] Secondly, embodiments of this disclosure provide a virtual machine DHCP configuration device, comprising: an interception module configured to intercept a target DHCP request initiated by a virtual machine; a query module configured to query network configuration information of the virtual machine based on the target DHCP request; a generation module configured to generate a target DHCP response based on the target DHCP request and the network configuration information in response to the query of the virtual machine's network configuration information; and a sending module configured to send the target DHCP response to the virtual machine.

[0007] Thirdly, embodiments of this disclosure provide an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the method as described in the first aspect.

[0008] Fourthly, embodiments of this disclosure provide a non-transitory computer-readable storage medium storing computer instructions for causing a computer to perform the methods described in the first aspect.

[0009] Fifthly, embodiments of this disclosure provide a computer program product including a computer program that, when executed by a processor, implements the method described in the first aspect.

[0010] The key or essential features of the embodiments disclosed herein are not intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0011] Other features, objects, and advantages of this disclosure will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings. The drawings are provided for a better understanding of the invention and are not intended to limit the scope of this disclosure. Wherein: Figure 1 This is a system component and interaction diagram used to implement the virtual machine DHCP configuration method of the embodiments of this disclosure; Figure 2This is a flowchart of one embodiment of the virtual machine DHCP configuration method according to this disclosure; Figure 3 This is a flowchart of yet another embodiment of the virtual machine DHCP configuration method according to the present disclosure; Figure 4 This is a schematic diagram of a structure of an embodiment of the virtual machine DHCP configuration apparatus according to the present disclosure; Figure 5 This is a block diagram of an electronic device used to implement the virtual machine DHCP configuration method of the embodiments of this disclosure. Detailed Implementation

[0012] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0013] It should be noted that, unless otherwise specified, the embodiments and features described in this disclosure can be combined with each other. This disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0014] Figure 1 The diagram illustrates system components and interactions used to implement the virtual machine DHCP configuration method according to embodiments of this disclosure. The system is deployed on a compute node and mainly includes the following components: KVM Virtual Machines: Includes multiple x86 KVM virtual machines such as KVM VM1, KVM VM2, and KVM VM3. Each KVM virtual machine is configured with an independent virtual network interface (vnet1, vnet2, vnet3). The KVM virtual machine network is set to DHCP automatic acquisition mode. After startup, it will initiate DHCP requests (such as DHCP discover and DHCP request) to obtain network parameters.

[0015] OVS (Open vSwitch): Deployed within the physical compute nodes, it directly connects to the virtual network interfaces (vnet1, vnet2, vnet3) of each KVM virtual machine, and communicates with the external Gateway VTEP (Virtual Tunnel Endpoint) through the physical machine's eth0 network card. OVS is pre-configured with two types of openflow tables: one to intercept DHCP requests initiated by KVM virtual machines, and the other to implement security protection (allowing DHCP requests matching the KVM virtual machine's openflow port, MAC (Media Access Control) address, IP (Internet Protocol) address, etc., to enter and exit the physical machine).

[0016] The DHCP Openflow Controller establishes real-time communication with OVS via the Openflow protocol. Its main functions include receiving DHCP requests forwarded by OVS, querying virtual machine network configurations, assembling DHCP responses, and sending them to OVS. The DHCP Openflow Controller has a unified special Openflow port used to identify DHCP responses processed by it.

[0017] Control plane Agent: Deployed within the physical machine of the compute node, it maintains data synchronization with the DHCP Openflow Controller and is responsible for receiving virtual machine network configuration information (including but not limited to virtual machine IP, subnet gateway MAC, subnet gateway IP, DNS server address, IP validity period, MTU, VLAN (Virtual Local Area Network) identifier, etc.) from the upper control plane, and storing it in the local virtual machine network configuration table for the DHCP Openflow Controller to query and call.

[0018] Network interaction link: DHCP requests initiated by KVM virtual machines are transmitted to OVS through the vnet interface. OVS matches the openflow table and forwards it to the DHCP Openflow Controller. The DHCP response generated by the DHCP Openflow Controller is forwarded back to the corresponding KVM virtual machine by OVS. At the same time, the compute node uses the eth0 network card and the Gateway VTEP to realize data interaction between the overlay network and the underlay network through the Vxlan UDP (Virtual Extensible Local Area Network User Datagram Protocol) protocol, ensuring data communication after the KVM virtual machine is configured.

[0019] Continue to refer to Figure 2 This document illustrates a flow 200 of an embodiment of a virtual machine DHCP configuration method according to this disclosure. This virtual machine DHCP configuration method is applicable to scenarios where compute node component deployment (OVS, DHCP OpenflowController, control plane Agent) and virtual network DHCP mode settings have been completed, and includes the following steps: Step 201: Intercept the target DHCP request initiated by the virtual machine.

[0020] In this embodiment, the execution entity of the virtual machine DHCP configuration method can intercept the target DHCP request initiated by the virtual machine.

[0021] In a compute node's local physical machine environment, when a virtual machine starts up or the network configuration is reset, it can automatically initiate a DHCP request to obtain network parameters. A DHCP request can include two key data packets: DHCP discover (used to discover DHCP services in the network) and DHCP request (used to request network parameters from a DHCP service). The OVS deployed on the compute node can monitor all DHCP requests passing through its virtual ports in real time and match them using a pre-configured OpenFlow flow table. OpenFlow flow table matching conditions may include, but are not limited to: the DHCP request originating from the OpenFlow port corresponding to the current virtual machine, the protocol type being UDP, the protocol source port being 68 (the standard port for DHCP clients), and the protocol destination port being 67 (the standard port for DHCP servers). When a DHCP request meets all of the above conditions, it is determined to be a target DHCP request. OVS can intercept this DHCP request and forward it to the DHCP OpenFlow Controller according to the flow table's action instructions (actions = controller), completing the interception and transmission of the target DHCP request.

[0022] Step 202: Based on the target DHCP request, query the network configuration information of the virtual machine.

[0023] In this embodiment, the aforementioned execution entity can query the network configuration information of the virtual machine based on the target DHCP request.

[0024] After receiving a target DHCP request forwarded by OVS, the DHCP Openflow Controller first extracts two key identifying pieces of information from the request: the MAC address of the virtual machine initiating the request (used to uniquely identify the virtual machine's network interface) and the Openflow port number corresponding to that virtual machine in OVS (used to associate the specific virtual machine instance). Subsequently, the DHCP Openflow Controller can perform an exact match query in its locally stored virtual machine network configuration table based on these two identifying pieces of information. This virtual machine network configuration table can be maintained by the compute node's control plane agent. The agent can receive the network configurations of each virtual machine from the upper control plane in real time and synchronize them to the DHCP Openflow Controller's local storage. During the query process, the DHCP Openflow Controller can verify the consistency between the identifying information and the records in the virtual machine network configuration table, ensuring that the obtained configuration belongs to the virtual machine that initiated the target DHCP request and avoiding configuration mismatches.

[0025] Step 203: In response to the query of the virtual machine's network configuration information, generate a target DHCP response based on the target DHCP request and the network configuration information.

[0026] In this embodiment, when the network configuration information of the virtual machine is queried, the aforementioned execution entity can generate a target DHCP response based on the target DHCP request and the network configuration information.

[0027] If the DHCP Openflow Controller successfully obtains valid network configuration information for the current virtual machine through the query in step 202 (i.e., there is a record in the configuration table that matches both the virtual machine's MAC address and Openflow port, and the configuration information is complete and correctly formatted), it proceeds to the target DHCP response generation stage. First, the DHCP Openflow Controller determines the corresponding DHCP response format based on the type of the target DHCP request (DHCP discover or DHCP request). For a DHCP discover request, the DHCP response may include basic network configuration information to inform the virtual machine of available DHCP services; for a DHCP request, the DHCP response may include complete network parameters to complete the configuration distribution. Subsequently, the DHCP Openflow Controller fills the retrieved network configuration information into the corresponding fields of the DHCP response one by one. This configuration information may include, but is not limited to: Virtual machine IP address: A unique logical network address assigned to a virtual machine; The MAC address of the subnet gateway: the physical address of the gateway interface used for communication between the virtual machine and other subnets; The IP address of the subnet gateway: the logical address that the virtual machine must pass through to access the external network; DNS server address: The service address used for resolving domain names on virtual machines; IP validity period: The valid usage period of an IP address; MTU of a network interface card (NIC): The maximum data packet size that a virtual machine NIC can transmit, adapted to the transmission requirements of overlay network tunnels; Virtual machine VLAN identifier: used to divide the virtual network segment to which the virtual machine belongs, and to achieve network isolation.

[0028] Meanwhile, the DHCP Openflow Controller can configure the Openflow port information of the response: the source Openflow port is set to the unified special port of the DHCP Openflow Controller to identify that the DHCP response is processed by the DHCP Openflow Controller; the destination Openflow port is set to the Openflow port corresponding to the virtual machine that initiated the target DHCP request, ensuring that the response can be sent back to the virtual machine that initiated the target DHCP request, and finally assembled into the target DHCP response.

[0029] Step 204: Send the target DHCP response to the virtual machine.

[0030] In this embodiment, the aforementioned executing entity can send the target DHCP response to the virtual machine.

[0031] After assembling the target DHCP response, the DHCP OpenFlow Controller can send it to OVS according to the OpenFlow protocol specification. Upon receiving the target DHCP response, OVS can parse two key pieces of information: the VLAN identifier, used to determine the virtual network segment to which the DHCP response belongs, ensuring transmission within the correct VLAN; and the destination OpenFlow port, used to locate the virtual machine that initiated the target DHCP request. Subsequently, OVS can use this information to accurately forward the target DHCP response to the virtual network interface of the virtual machine that initiated the request. After receiving the target DHCP response, the virtual machine can automatically parse the network configuration information within it and apply these parameters to its own network interface card configuration, completing the setting of parameters such as IP address, gateway, and DNS. At this point, the entire DHCP configuration process is complete, and the virtual machine possesses normal network communication capabilities.

[0032] In some optional implementations of this embodiment, step 202 is followed by the following: If the DHCP OpenflowController does not find valid network configuration information for the current virtual machine (e.g., there is no corresponding virtual machine identifier record in the configuration table, the configuration information is missing, or the configuration information is invalid), the DHCP OpenflowController can directly discard the target DHCP request and not return any response to the virtual machine. At this time, the virtual machine, having not obtained network parameters, will be unable to perform normal network communication until the upper control plane sends valid configuration information and synchronizes it to the DHCP OpenflowController. Only then can the virtual machine re-initiate the DHCP request to complete the configuration.

[0033] This disclosure provides a virtual machine DHCP configuration method. By implementing DHCP request interception, configuration query, response generation and forwarding locally on the compute node, it eliminates the need for an external DHCP server or an agent within the virtual machine, effectively simplifying the configuration process and reducing system resource consumption. At the same time, by leveraging the precise matching of OpenFlow flow tables and the local processing of the controller, it improves the security and efficiency of configuration, making it suitable for large-scale x86 KVM virtualization network scenarios.

[0034] Further reference Figure 3 This illustrates flow 300 of yet another embodiment of the virtual machine DHCP configuration method according to this disclosure. This virtual machine DHCP configuration method further refines the specific operational steps based on OVS and the DHCP Openflow Controller, focusing more on the collaboration logic between components, including the following steps: Step 301: In OVS, intercept the target DHCP request.

[0035] In this embodiment, the execution entity of the virtual machine DHCP configuration method can intercept the target DHCP request in OVS.

[0036] During the compute node deployment phase, a dedicated OpenFlow flow table can be configured for each virtual machine in OVS. The configuration of this OpenFlow flow table corresponds one-to-one with the network identifier of the virtual machine.

[0037] The matching rules for each OpenFlow flow table can include, but are not limited to: the virtual machine's OpenFlow port (a unique virtual port number assigned to each virtual machine by OVS); the protocol type (fixed to UDP, as the DHCP protocol is based on UDP transmission); the protocol source port (fixed to 68, the standard port for DHCP clients to send requests); and the protocol destination port (fixed to 67, the standard port for DHCP servers to receive requests). Furthermore, OpenFlow flow tables can be configured with action directives (actions = controller) to explicitly forward successfully matched DHCP requests to the DHCP OpenFlow Controller.

[0038] When a virtual machine initiates a DHCP request (including DHCP discover and DHCP request), the DHCP request can be transmitted to the corresponding OpenFlow port of OVS through the virtual machine's virtual network interface. OVS can match the DHCP request with the corresponding virtual machine's OpenFlow flow table item by item. If the port, protocol, source port, and destination port of the DHCP request all match the flow table rules, it is determined to be a target DHCP request. OVS can intercept the DHCP request and, according to the action instructions of the flow table, encapsulate it into an OpenFlow format data packet and send it to the DHCP OpenFlow Controller, ensuring that the request data is accurately delivered to the processing components.

[0039] Step 302: In the DHCP Open Flow Controller, the MAC address in the target DHCP request and the open flow port of the virtual machine are matched in the virtual machine network configuration table to obtain the network configuration information of the successful match.

[0040] In this embodiment, the aforementioned execution entity can match the MAC address in the target DHCP request with the virtual machine's OpenFlow port in the virtual machine network configuration table in the DHCP OpenFlow Controller to obtain the successfully matched network configuration information.

[0041] After receiving the target DHCP request forwarded by OVS, the DHCP Openflow Controller can initiate the following configuration query process: First, key identifier extraction: The DHCP Openflow Controller extracts the MAC address of the virtual machine that initiated the target DHCP request by parsing the Ethernet header of the target DHCP request; at the same time, it obtains the OVS Openflow port number from which the target DHCP request originates by using the metadata information of the Openflow protocol. These two identifiers together form a dual index for the query, ensuring the uniqueness of the query results.

[0042] Next, the configuration table is matched and queried: The virtual machine network configuration table stored locally by the DHCP Openflow Controller uses a key-value pair structure, with the MAC address and Openflow port number as the composite key, and the corresponding value being the complete network configuration information of the virtual machine. During the query, the DHCP Openflow Controller can perform an exact match between the extracted dual index and the composite key in the virtual machine network configuration table. If a completely matching record exists, and the configuration information in the record (IP, gateway, DNS, etc.) all conform to network communication standards (e.g., the IP address is within a valid subnet and the gateway address is reachable), then the match is considered successful, and the DHCP Openflow Controller can read all the configuration information in that record as the basis for generating subsequent responses; if no matching record is found or the configuration information is invalid, then the match is considered unsuccessful, triggering the subsequent DHCP request discard operation.

[0043] Step 303: In response to the query of the virtual machine's network configuration information, in the DHCP Open Flow Controller, set the source open flow port to a specific port of the DHCP Open Flow Controller, set the destination open flow port to the open flow port of the virtual machine, set the VLAN to the VLAN identifier of the virtual machine, fill in the network configuration information according to the response packet format corresponding to the target DHCP request, generate the target DHCP response, and send the target DHCP response to OVS.

[0044] In this embodiment, when the network configuration information of the virtual machine is queried, the above-mentioned execution entity can set the source openflow port to a specific port of the DHCP Openflow Controller, set the destination openflow port to the openflow port of the virtual machine, set the VLAN to the VLAN identifier of the virtual machine, fill in the network configuration information according to the response packet format corresponding to the target DHCP request, generate the target DHCP response, and send the target DHCP response to OVS.

[0045] Once the DHCP Openflow Controller obtains valid network configuration information through step 302, it can proceed to the generation and sending phase of the target DHCP response, including the following steps: First, the DHCP Openflow Controller can configure the Openflow port parameters of the target DHCP response. Specifically, the source Openflow port is set to the unified special port of the DHCP Openflow Controller (this port is shared by all virtual machine responses and is used by OVS to identify DHCP responses processed by the DHCP Openflow Controller), and the destination Openflow port is set to the virtual machine Openflow port extracted in step 302. Simultaneously, the VLAN tag of the target DHCP response is set to the queried virtual machine VLAN identifier to ensure that the target DHCP response is transmitted within the correct virtual network segment when it is sent back, avoiding cross-VLAN interference.

[0046] Then, the DHCP Openflow Controller can select the appropriate DHCP response format based on the type of the target DHCP request (DHCP discover or DHCP request). For a DHCP discover request, the DHCP response can include basic configuration information such as subnet mask, gateway IP, and DNS server address in the options fields, informing the virtual machine of the range of available network parameters. For a DHCP request, the DHCP response can include complete configuration information (virtual machine IP, IP validity period, MTU, subnet gateway MAC, subnet gateway IP, DNS address, etc.) in the options fields and set an acknowledgment flag to inform the virtual machine that the configuration has taken effect. The DHCP Openflow Controller can then fill in the retrieved network configuration information into the corresponding fields one by one, ensuring that the field format conforms to the DHCP protocol standard specifications to avoid virtual machine resolution failures.

[0047] Finally, the response is sent to OVS: After the response assembly is completed, the DHCP Openflow Controller can send the target DHCP response to OVS according to the Openflow protocol, along with the VLAN identifier and destination port information, for OVS to use for subsequent forwarding.

[0048] Step 304: Send the target DHCP response to the virtual machine via OVS.

[0049] In this embodiment, the aforementioned execution entity can send the target DHCP response to the virtual machine through OVS.

[0050] After receiving the target DHCP response from the DHCP Openflow Controller, OVS can perform the final forwarding operation: First, response information parsing: OVS parses the OpenFlow metadata in the response, obtains the destination OpenFlow port and VLAN identifier, and determines the target virtual machine and its network segment for forwarding.

[0051] Then, the DHCP response is precisely forwarded to the virtual machine: OVS locates the corresponding virtual machine's virtual network interface based on the destination OpenFlow port, and simultaneously ensures that the DHCP response is transmitted within the specified VLAN based on the VLAN identifier, avoiding data packet confusion with other VLANs. Subsequently, OVS forwards the DHCP response packet to the target virtual machine's virtual network interface. Upon receiving the DHCP response, the virtual machine's operating system can automatically trigger the network configuration loading process, applying the IP, gateway, DNS, and other parameters from the DHCP response to the network card, completing the entire DHCP configuration process.

[0052] This disclosure provides a virtual machine DHCP configuration method in which all operations are completed within the local physical machine of the compute node, and data does not need to be transmitted to external devices or remote servers, effectively reducing data transmission latency and mitigating the impact of external network failures on the configuration process. At the same time, through precise matching of OVS flow tables and local processing by the controller, the security risks brought by agents within the virtual machine and the resource consumption of OVN components are avoided, significantly improving the stability of configuration and resource utilization efficiency.

[0053] Further reference Figure 4 As an implementation of the methods shown in the above figures, this disclosure provides an embodiment of a virtual machine DHCP configuration device, which is similar to... Figure 2 Corresponding to the method embodiments shown, this device can be specifically applied to various electronic devices.

[0054] like Figure 4 As shown, the virtual machine DHCP configuration device 400 of this embodiment may include: an interception module 401, a query module 402, a generation module 403, and a sending module 404. The interception module 401 is configured to intercept a target DHCP request initiated by a virtual machine; the query module 402 is configured to query the network configuration information of the virtual machine based on the target DHCP request; the generation module 403 is configured to generate a target DHCP response based on the target DHCP request and the network configuration information in response to the query of the virtual machine's network configuration information; and the sending module 404 is configured to send the target DHCP response to the virtual machine.

[0055] In this embodiment, the specific processing of the interception module 401, query module 402, generation module 403, and sending module 404 in the virtual machine DHCP configuration device 400, and the resulting technical effects, can be found in reference to [reference needed]. Figure 2The relevant descriptions of steps 201-204 in the corresponding embodiments will not be repeated here.

[0056] In some optional implementations of this embodiment, the virtual machine DHCP configuration device 400 further includes a discard module configured to discard a target DHCP request in response to the failure to find network configuration information for the virtual machine.

[0057] In some optional implementations of this embodiment, the interception module 401 is further configured to: intercept the target DHCP request in the Open Virtual Switch (OVS).

[0058] In some optional implementations of this embodiment, the interception module 401 is further configured to: match the DHCP request initiated by the virtual machine with the virtual machine's open flow table in OVS, intercept the matched DHCP request as the target DHCP request, and send the target DHCP request to the DHCP open flow controller. The open flow table includes at least one of the following: the virtual machine's open flow port, protocol type, protocol source port, protocol target port, and action command.

[0059] In some optional implementations of this embodiment, the query module 402 is further configured to: in the DHCP Open Flow Controller, match the Media Access Control MAC address in the target DHCP request with the virtual machine's Open Flow Port in the virtual machine network configuration table to obtain the successfully matched network configuration information.

[0060] In some optional implementations of this embodiment, the network configuration includes at least one of the following: the virtual machine's Internet Protocol (IP) address, the subnet gateway's MAC address, the subnet gateway's IP address, the Domain Name System (DNS) server address, the IP validity period, the network interface card's (NIC) maximum transmission unit (MTU), and the virtual local area network (VLAN) identifier of the virtual machine.

[0061] In some optional implementations of this embodiment, the generation module 403 is further configured to: set the source open flow port to a specific port of the DHCP open flow controller, set the destination open flow port to the open flow port of the virtual machine, set the VLAN to the VLAN identifier of the virtual machine, fill in the network configuration information according to the response packet format corresponding to the target DHCP request, generate the target DHCP response, and send the target DHCP response to OVS; and the sending module 404 is further configured to: send the target DHCP response to the virtual machine through OVS.

[0062] The acquisition, storage, and application of user personal information involved in the technical solution disclosed herein comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0063] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0064] Figure 5 A schematic block diagram of an example electronic device 500 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0065] like Figure 5 As shown, device 500 includes a computing unit 501, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 502 or a computer program loaded from storage unit 508 into random access memory (RAM) 503. RAM 503 may also store various programs and data required for the operation of device 500. The computing unit 501, ROM 502, and RAM 503 are interconnected via bus 504. Input / output (I / O) interface 505 is also connected to bus 504.

[0066] Multiple components in device 500 are connected to I / O interface 505, including: input unit 506, such as keyboard, mouse, etc.; output unit 507, such as various types of monitors, speakers, etc.; storage unit 508, such as disk, optical disk, etc.; and communication unit 509, such as network card, modem, wireless transceiver, etc. Communication unit 509 allows device 500 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0067]

[01] The computing unit 501 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 501 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 501 performs the various methods and processes described above, such as the virtual machine DHCP configuration method. For example, in some embodiments, the virtual machine DHCP configuration method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 508. In some embodiments, part or all of the computer program may be loaded and / or installed on device 500 via ROM 502 and / or communication unit 509. When the computer program is loaded into RAM 503 and executed by the computing unit 501, one or more steps of the virtual machine DHCP configuration method described above may be performed. Alternatively, in other embodiments, the computing unit 501 may be configured to perform the virtual machine DHCP configuration method by any other suitable means (e.g., by means of firmware).

[0068] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0069] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0070] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0071] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0072] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0073] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, distributed system servers, or servers incorporating blockchain technology.

[0074] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution provided in this disclosure can be achieved, and this is not limited herein.

[0075] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A method for configuring a Virtual Machine Dynamic Host Configuration Protocol (DHCP) protocol, comprising: Intercept the target DHCP request initiated by the virtual machine; Based on the target DHCP request, query the network configuration information of the virtual machine; In response to the query of the virtual machine's network configuration information, a target DHCP response is generated based on the target DHCP request and the network configuration information; Send the target DHCP response to the virtual machine.

2. The method according to claim 1, wherein, The method further includes: In response to the failure to find network configuration information for the virtual machine, the target DHCP request is discarded.

3. The method according to claim 1, wherein, The interception of the target DHCP request initiated by the virtual machine includes: In the Open Virtual Switch (OVS), intercept the target DHCP request.

4. The method according to claim 3, wherein, The interception of the target DHCP request via the Open Virtual Switch (OVS) includes: In the OVS, the DHCP request initiated by the virtual machine is matched with the open flow table of the virtual machine, the matched DHCP request is intercepted as the target DHCP request, and the target DHCP request is sent to the DHCP open flow controller. The open flow table includes at least one of the following: the open flow port of the virtual machine, the protocol type, the protocol source port, the protocol target port, and the action command.

5. The method according to claim 4, wherein, The step of querying the network configuration information of the virtual machine based on the target DHCP request includes: In the DHCP Open Flow Controller, the Media Access Control MAC address in the target DHCP request and the open flow port of the virtual machine are matched in the virtual machine network configuration table to obtain the network configuration information that matches successfully.

6. The method according to claim 5, wherein, The network configuration includes at least one of the following: the virtual machine's Internet Protocol (IP) address, the subnet gateway's MAC address, the subnet gateway's IP address, the Domain Name System (DNS) server address, the IP validity period, the network interface card's (NIC) maximum transmission unit (MTU), and the virtual machine's Virtual Local Area Network (VLAN) identifier.

7. The method according to claim 6, wherein, The step of generating a target DHCP response based on the target DHCP request and the network configuration information includes: In the DHCP Open Flow Controller, the source open flow port is set to a specific port of the DHCP Open Flow Controller, the destination open flow port is set to the open flow port of the virtual machine, the VLAN is set to the VLAN identifier of the virtual machine, the network configuration information is filled in according to the response packet format corresponding to the target DHCP request, the target DHCP response is generated, and the target DHCP response is sent to the OVS; and Sending the target DHCP response to the virtual machine includes: The target DHCP response is sent to the virtual machine via the OVS.

8. A Virtual Machine Dynamic Host Configuration Protocol (DHCP) configuration device, comprising: The interception module is configured to intercept target DHCP requests initiated by the virtual machine. The query module is configured to query the network configuration information of the virtual machine based on the target DHCP request; The generation module is configured to generate a target DHCP response based on the target DHCP request and the network configuration information in response to a query of the virtual machine's network configuration information; The sending module is configured to send the target DHCP response to the virtual machine.

9. An electronic device, comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-7.

10. A non-transitory computer-readable storage medium storing computer instructions for causing the computer to perform the method according to any one of claims 1-7.

11. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1-7.

Images