BACKGROUND

To date, several solutions have been proposed for assigning IP (Internet Protocol) addresses to virtual machines executing on hosts. Like other devices, virtual machines require an IP address to access network resources. In virtualized environments, IP addresses are assigned usually by using a DHCP server, running agents in the VM (such as VM tools) or customizing the virtual machine at first use (such as Sysprep).

To obtain IP addresses, some VMs use dynamic host configuration protocol (DHCP), which broadcast DHCP messages to interact with DHCP servers in the network in order to obtain the desired IP addresses and other DHCP data. A broadcast packet usually consumes much more resources than a unicast packet as it is sent to many destinations. When the number of hosts becomes large, the broadcast traffic becomes prohibitively high.

Previous techniques for assigning IP addresses have several drawbacks. Customization (e.g., using Sysprep) is a one-time operation and the applied configuration cannot be changed at a subsequent boot of the VM. Also, it is not always desirable or possible to use an agent inside the VM. Using standalone DHCP servers requires running separate physical servers or VMs that perform the DHCP service. The VM and the DHCP server (or relays) must be connected to the same virtualized broadcast domain. When operating on a cloud-scale, running these DHCP services consumes resources (VMs, virtualized networks) and overhead for maintaining the distributed configuration of those servers. Accordingly, there is a need in the art to assign IP addresses and other DHCP configuration data without relying on guest agents or stand-alone DHCP servers.

BRIEF SUMMARY

Some embodiments use proxies on host devices to intercept broadcast DHCP traffic in a network, in order to assign IP addresses to virtual machines without broadcasting messages to DHCP servers. Each host in some embodiments executes one or more virtual machines (VMs). In some embodiments, a proxy operates on each host between each VM and the underlying network. For instance, in some embodiments, a VM's proxy operates between the VM and a physical forwarding element executing on the VM's host. In some embodiments, the physical forwarding elements are software forwarding elements that execute on the host devices to collectively implement different logical forwarding elements (e.g., logical switches, logical routers, etc.) for different logical networks of different tenants, users, departments, etc. that use the same shared computing and networking resources.

To capture DHCP broadcast messages, the proxy for a particular VM monitors the VM's traffic to detect and intercept a DHCP discover message. When the proxy receives a DHCP discover message, the proxy retrieves DHCP configuration data that was previously stored on the host for the VM. In some embodiments, the DHCP configuration data is stored on the host for the VM during the initiation of the VM (e.g., during the installation or during the boot-up of the VM) in response to an administrator's request or as part of an initiation script that initiates (e.g., installs or boots-up) the VM. The DHCP configuration data in some embodiments is stored in one common data store for all the VMs that execute on the host, while in other embodiments, each VM's DHCP configuration data is stored in a DHCP data store that is uniquely maintained for the VM. In some of these latter embodiments, the data in the unique DHCP data store for a VM can easily migrate with the VM when the VM migrates from one host to another host.

In some embodiments, the proxy retrieves the DHCP configuration data for a VM through an agent that (1) executes on the host device and (2) connects various proxies that execute on the host with one or more data stores that store DHCP configuration data for the VMs of the proxies. In these embodiments, the proxy converts the DHCP discover broadcast message to a unicast message to the agent, in order to direct the agent to obtain the DHCP configuration data. The agent then retrieves the requested DHCP configuration from the common or unique DHCP data store. The DHCP configuration data includes IP addresses and other DHCP configuration data in some embodiments of the invention. Also, in some embodiments, the IP address for a VM is a logical address that is assigned to the VM.

Upon receiving the requested DHCP configuration data (including the IP address) from the agent, the proxy formulates a DHCP offer message and supplies this message as a packet to the particular VM as if the packet was sent from the DHCP server. In some embodiments, the DHCP offer packet will be formatted in the same manner that a traditional DHCP server provides such packets. Accordingly, in some embodiments, the supplied DHCP offer message includes DHCP configuration data including the IP address.

After receiving the DHCP offer, the VM sends a DHCP request broadcast in some embodiments. The proxy intercepts this packet and in response, generates a DHCP acknowledge message and supplies this DHCP acknowledge message to the VM. The supplied DHCP acknowledge message is in the DHCP acknowledgment format that a DHCP server would use to send such an acknowledge message. In some embodiments, the DHCP acknowledgment message may include additional configuration information.

The preceding Summary is intended to serve as a brief introduction to some embodiments of the invention. It is not meant to be an introduction or overview of all inventive subject matter disclosed in this document. The Detailed Description that follows and the Drawings that are referred to in the Detailed Description will further describe the embodiments described in the Summary as well as other embodiments. Accordingly, to understand all the embodiments described by this document, a full review of the Summary, Detailed Description and the Drawings is needed. Moreover, the claimed subject matters are not to be limited by the illustrative details in the Summary, Detailed Description and the Drawing.

