Patent ID: 12260241

DETAILED DESCRIPTION

FIG.1is a block diagram that depicts a virtualized computing environment in which one or more embodiments may be implemented. The components of the virtualized computing environment include, but are not limited to, one or more computer hosts125(125Aand125Bshown), each of which connect to one or more computer networks162A,162B. Further, the virtualized computing environment includes a virtual machine management server100and a virtual network manager110.

As shown, the embodiment depicted inFIG.1includes hosts125Aand125B. In certain embodiments, each host125A,125Bis, a server-class computer with one or more central processing units (CPUs) (not shown), random access memory (RAM) (not shown), and is attached to one or more external data storage devices (not shown) through a host bus adapter (HBA) (not shown). In alternative embodiments, hosts125A,125Bmay be commercially available desktop computers, laptop computers, tablets, and the like. Conceptually, CPUs, RAM, and other hardware components are included in a “hardware layer” depicted inFIG.1as hardware platforms190A,190B.

As shown, each of hardware platforms190also includes one or more physical network interface controllers (PNICs), including PNICs150Aand150B. A description of PNICs150A,150Bis given herein as representative of other PNICs that may be implemented in hardware platform190but not shown inFIG.1. Each PNIC150provides the corresponding host125with connectivity to a computer network. In embodiments, each PNIC150sends and receives network data packets over a physical network connection to a wired computer network, such as an Ethernet or other local area network (LAN). In other embodiments, PNIC150may be a wireless network adapter that sends and receives data packets over a wireless network, such as a wireless LAN based on the IEEE® 802.11 standard (i.e., a Wi-Fi® network). Each PNIC150also has unique media access control (MAC) and IP addresses, which enables the corresponding host125to be located on the network to which the PNIC connects.

Each of hosts125executes system software that manages access to the components residing in hardware layer190by application programs or, in some instances, virtual machines. This system software is referred to herein as a hypervisor kernel185. As shown inFIG.1, host125Aexecutes hypervisor kernel (“Kernel”)185Aand host125Bexecutes hypervisor kernel185B. Each hypervisor kernel185A,185Bperforms the functions that are typically performed by an operating system, such as controlling and allocating hardware resources of the corresponding host125, scheduling and dispatching processes for execution on the host, and providing user interface and input/output services. Hypervisor180includes kernel185and other components, such as one or more virtual machine monitors (not shown) that function as the emulation layer enable the concurrent instantiation and execution of one or more virtual machines (VMs) (only one shown on each host), depicted inFIG.1as VMs130Aand130B. In one embodiment, each hypervisor180may be ESXi® Server, which is commercially available from VMware, Inc. of Palo Alto, California. In other embodiments, hypervisor180may be another hypervisor, such as KVM, which provides virtualization functionality to the Linux kernel and is available for various popular Linux distributions including Debian, Red Hat, SUSE, Ubuntu, and others. The virtualization architecture described herein is exemplary only and does not necessarily form part of the present invention, and any architectural variations from that shown inFIG.1is contemplated. For example, in some virtualization implementations, the driver (not shown) for PNIC150may reside in a privileged virtual machine, referred to as “domain zero” (“Dom0”) or the “root partition” through which input/output data to and from VMs may pass. In other implementations, a host operating system manages physical resources while co-resident system-level software provides virtualization services (e.g., physical device emulations) for each virtual machine. The virtualization software may be provide paravirtualization, which requires that the guest operating system executing within the virtual machine be aware of the virtualization and/or cooperate with the virtualization software in some manner. It should furthermore be recognized that the boundaries between VM130and hypervisor180are somewhat arbitrarily drawn because, while it is convenient to refer to a virtual machine as including virtual hardware such as VNICs, the processes that emulate that hardware are often considered to reside within or form part of hypervisor180. The term, “hypervisor” has no consistent meaning but is used herein to refer to all the software logically interposed between a virtual machine and the hardware platform that enables the virtual machine to operate, including any required input/output connectivity.

As mentioned above, each hypervisor180enables the instantiation of one or more VMs130. After instantiation, each VM130can be thought of as an encapsulation of a physical computing machine platform that is executed under the control of the hypervisor. VMs130may be configured with virtual devices that are embodied in a virtual hardware platform (not shown), which comprises one or more virtual CPUs, virtual RAM, and virtual storage devices. The virtual hardware platform supports the installation of a guest operating system on the VM, which is capable of supporting the execution of software applications. Examples of guest operating systems include any of the well-known commodity operating systems, such as Microsoft Windows®, Linux®, etc.

As shown inFIG.1, each of VMs130also includes one or more virtual network interface controllers (or VNICs) (only one shown for each VM). VNICs perform functions analogous to those performed by PNICs150. That is, a VNIC receives and sends data packets to and from a virtual machine. As with PNIC150, each VNIC has a unique MAC address and an IP address.

Each VNIC connects the corresponding VM130to a network in the same way each PNIC150connects a corresponding physical host125to a network. Virtual switches140A,140Bprovide connectivity between and among VMs executing on each host and with the outside world over physical and/or virtual networks. Conceptually, virtual networks are logical networks implemented by a set of network devices to which one or more virtual machines connect in order to communicate amongst themselves. Network devices may include switches, firewalls (which control incoming and outgoing traffic for the virtual network), and bridges and routers (which, in embodiments, route network traffic between networks. Virtualized networks may be implemented by one or more hypervisors180A,180B, as further described by way of example below.

InFIG.1, hypervisor180Aof host125Aand hypervisor180Bof host125Beach have instantiated therein a respective virtual switch, namely, virtual switches140Aand140B. One or more virtual switches140A,140Bmay be managed and/or configured as opaque virtual networks. For example, the creation, configuration, and management of virtual switches140may be handled by a centralized virtual network manager110which can be a third-party provider, such that the details and configuration of the virtual network are not readily available to hypervisors180, VM management server100, or other software components that may rely on networking information. In these cases, opaque virtual networks are managed by a network management plane (also described below) separate from the virtual machine (or “compute”) management plane. In embodiments, a virtual machine management platform (or hypervisor) accesses an opaque network by referring to it by a unique network identifier. For example, virtual machine management platforms typically deploy virtual machines to a hypervisor180executing on a particular host125. Among the tasks that the virtual machine management platform performs is provisioning a virtual network to a deployed virtual machine. In embodiments that provide opaque virtual networks, the virtual machine management platform connects the virtual machine to the opaque network by configuring the virtual machine to access the network using the unique network identifier. The virtual machine is then able to transmit and receive data over the opaque network based on this identifier. Virtual machine management platforms, hypervisor (or components thereof aside from a third-party managed virtual switch140, or components thereof), and the virtual machine itself need not be aware of the details of the network. Rather, the configuration details are separately handled by a virtual network manager110, the detailed functions of which are further described below. In this way, virtual machine (or “compute”) management is decoupled from virtual network management.

As shown inFIG.1, each virtual switch140also connects to one or more PNICs150(only one shown) on the corresponding host125. This enables VMs130executing on hypervisor180in one host to communicate with applications that are external to the host, or with other VMs that execute on another host. Thus, inFIG.1, virtual switch140A, which is instantiated within hypervisor180Aon host125A, connects, via PNIC150A, to network A162. Thus, VMs130Athat connect to virtual switch140Aof host125Aare able to communicate with servers and applications that also connect to (or are accessible from) network A162. In like manner, PNIC150Bof host125Bconnects directly to network B164. Therefore, VMs130Bthat execute on top of hypervisor180Bof host125Bare able to communicate (via virtual switch140Binstantiated within hypervisor180Bof host125B) with applications and computers connected directly to network B164.

In addition, in the embodiment depicted inFIG.1, a gateway165exists between networks A and B162,164, respectively. In certain embodiments, gateway165is a physical router or a proxy server that routes traffic between networks A and B. Thus, in the embodiment ofFIG.1, gateway165enables VMs130Aon host125Ato communicate with VMs130Bon host125B.

Further, VMs130on each of hosts125Aand125Bmay be configured as existing on the same VLAN, overlay network, or other logical network or network segment. An example of an overlay network is a logical layer 2 network that is implemented on a layer 3 network using a VPN tunnel or other traffic isolation technology. In such an embodiment, VMs130executing on each of hosts125Aand125Bconnect to the designated logical network or network segment and communicate with each other through networks A and B with some measure of isolation that is afforded by the logical network technology or implementation. In one embodiment, virtual switches140A,140Bimplement the logical overlay network by encapsulating and decapsulating, respectively, outgoing and incoming packets. In another embodiment, the virtual network is implemented using VLAN tagging, in which case VMs130Aand130Bmay be assigned to the same port group on virtual switches140A,140Band hence transmitted packets may be tagged with a corresponding VLAN tag, in a known manner, either at the VM or within some component such as the virtual switch140, of each hypervisor180.

FIG.1also depicts management servers that provide, respectively, virtual machine and network management for the virtualized computing environment. VM management server100provides virtual machine management services. VM management server100typically executes on one or more physical servers and/or within one or more VMs. VM management server100performs virtual machine management functions on hosts125by communicating with an associated agent process on each host, which is depicted as compute agents160A and160B on hosts125Aand125B, respectively. In certain embodiments, a system administrator may access VM management server100through a user interface, (e.g., using a web-based interface) and instruct VM management server100to perform specific virtual machine management functions, such as starting and stopping VMs130, and performing certain configuration changes on the VMs. VM management server100then communicates directly, e.g., using a RESTful API, with a compute agent160executing on a host125in order to carry out the instructions.

As shown, VM management server100includes at least two components: a load balancer101and a VM deployer102. Through load balancer101, VM management server100provides for the balancing of compute resources among a plurality of VMs. For example, load balancer101may detect that a particular host computer (e.g., host125A) is experiencing a performance bottleneck, which may be caused by having too many VMs instantiated therein. As a result, load balancer101determines that one or more VMs should be migrated away from host125Ato another host125(e.g., host125B, where host125Bdoes not experience a performance bottleneck). In this case, load balancer101first determines that target host125Bprovides the required level of support for the migrated VMs130Athat the source host provides before initiating migration. That is, load balancer101determines that the target host125Bhas sufficient CPU and memory resources available in order to instantiate and execute the migrated VM. Further, load balancer101may be configured to ensure that target host125Bhas the required network connectivity for the migrated VM. In other words, prior to migrating a VM to a target host, load balancer101ensures that a virtual network has been configured on the target host and that the configured virtual network provides the same or sufficient connectivity for the migrated VM as was provided for the VM by the source host.

However, as mentioned above, in some embodiments, virtual machine management platforms (i.e., VM management server100) may lack sufficient network configuration information to determine whether the network connectivity that is expected by VM130Ais available on the target host, and that such connectivity is operative, i.e., functioning as expected. For example, referring toFIG.1, load balancer101may determine that VM130Aon host125Aneeds to be migrated. Accordingly, load balancer101inspects host125B, by communicating with compute agent160B, to determine, among other things, whether host125Bhas the required physical network connectivity for VM130A. Load balancer101(through compute agent160B) also determines whether host125Bhas sufficient CPU and memory resources to support migration of VM130A. However, compute agent160Bmay lack network configuration and status information with respect to network connectivity required by VM130A. In fact, such information may not be directly ascertainable by hypervisor180B. For example, a required virtual network may be unavailable because one or more software or hardware components that make up the virtual network have failed. Further, if one or more of a plurality of PNICs150B(only one shown) on host125Bhave failed, then host125Bmay not provide the required connectivity for the migrated VM130, namely, connectivity to networks A and B. Additionally, the required virtual network may be available, but may be running in a degraded state due to performance bottlenecks or the failure of one or more physical links in network A or network B. Therefore, according to one or more embodiments, load balancer101determines the operational status of virtual network140by communicating (via compute agent160B) with other components of hypervisor180B, as will be described below.

As shown inFIG.1, VM management server100also includes VM deployer102for deploying one or more virtual machines to a target host125. In one or more embodiments, VM deployer102reads configuration data pertaining to a VM that is to be deployed and determines (by communicating with a compute agent160) whether the target host125has sufficient resources to support instantiation of the VM. The configuration of a VM may be provided in one or more configuration files associated with the VM and may include the configuration of one or more VNICs and designated port group, virtual network identifier for opaque networks, or other information identifying a virtual network, which is used to determine which virtual networks140that the VNICs are to be connected to. However, as was the case for load balancer101, VM deployer102may initially lack specific configuration and status information about virtual networks configured on a target host125. However, embodiments of VM deployer102determine the status of the virtual network by communicating (via a compute agent160) with a hypervisor180, according to methods described below.

FIG.1also depicts virtual network manager110. Virtual network manager110is a software component that runs on one or more physical servers or within virtual appliances, and provides virtual network management services to the virtualized computing environment. A system administrator may access virtual network manager110through a user interface, such as a web interface, and provide instructions through the interface to manage the various virtual network components deployed to the computing environment. The management instructions are transmitted from virtual network manager110to one or more corresponding network agents170, each of which executes in a host125. Network agent170then carries out tasks on the corresponding host125associated with the management instructions.

Among the functions that virtual network manager110performs are the creation and configuration of virtual networks for hosts125. That is, a system administrator accesses virtual network manager110to create and configure virtualized networks. Configuration may be performed by virtual network manager110transmitting a request to a network agent170executing on one or more of the hosts125. Each network agent170then communicates with other components, such as kernel185or some subcomponent thereof such as virtual switch140in order to instantiate the virtual network configurations on the target host. Once the configurations are deployed, each virtual machine130may then be connected to the one or more of the virtual networks via the target host.

As shown inFIG.1, virtual network manager110deploys different types of virtual networks. One type that is depicted is a virtual LAN (or VLAN), which, in embodiments, comprises a plurality of ports of a plurality of virtual switches that are configured as being connected in a single VLAN network segment. Another type is an L2 over L3 overlay logical network, in which configurations for encapsulating layer 3 (L3) packets within a layer 2 (L2) encapsulation are provisioned to a plurality of hosts. In such a configuration, virtual network140on host125appends additional header information to data packets transmitted by the VMs and tunnels the traffic to destination hosts that hosts a destination VM, which then, according to the deployed configurations, decapsulates the L3 packet, i.e., removes the outer L2 header, for delivery to the destination VM. The L2 encapsulation enables the packets to be routed only to hosts containing other VMs that are connected to the same virtual network, even if those virtual machines execute on a different host.

In some embodiments, virtual network manager110also monitors the physical network of the virtualized computing environment, as well as the virtualized network components instantiated in each host125. Such monitoring can be by way of proprietary management channels, protocols, etc., implemented by various network device vendors. Specifically, embodiments of virtual network manager110are configured to detect outages to physical network devices. For example, referring toFIG.1, virtual network manager110is configured to detect whether gateway165is available, or whether either PNICs150on either host125Aor125Bhave failed. Further, through network agent170, virtual network manager110is configured to detect whether a virtual network140(or any sub-component of the virtual network) is available. Management traffic from virtual network manager110and VM management server100to hosts125may be routed over an isolated management network (not shown) with communications arriving at separate PNICs (not shown) on each host125A,125B, to provide management communication independent of tenant or VM data traffic on networks A and B.

As was previously mentioned, VM management server100requires information as to whether virtual network connectivity exists on a host prior to deploying or migrating a virtual machine to that host. Thus, in order to ensure that virtual network resources are available to a newly deployed or migrated virtual machine, embodiments described herein set forth a mechanism whereby the status of one or more virtual networks configured on a target host is communicated to the hypervisor on the target host. Further, once the hypervisor receives the virtual network configurations, embodiments of VM management server100transmit, prior to deploying virtual machines to the target host, network status queries to the hypervisor in order to determine virtual network availability on the target host.

In the embodiment ofFIG.1, virtual network manager110(which monitors physical and virtual network resources for the virtualized computing environment) communicates to each hypervisor180the status of all virtual networks140configured on the corresponding host125. For instance, if PNIC150Aon host125Ashould fail, then virtual network manager determines that all virtual networks140Athat connect to PNIC150Aare in a failed status, and communicates this status (via network agent170A) to kernel185A. This is depicted inFIG.1as communication from network agent170Ato kernel185A.

Virtual network status145Aand145Bshown inFIG.1are repositories where the status of each corresponding virtual networks configured on host125is stored. In various embodiments, each network agent170periodically communicates a status of configured virtual networks to a corresponding kernel185. Kernel185then stores the status information in a virtual network status145. Each virtual network status145may be structured as a list of name/value pairs, where the name is a unique network identifier for a virtual network. The value is an indicator as to the status of the network. For example, the network status may be “available” or “unavailable.” Further, intermediate values may be stored in order to provide an indication that the virtual network provides connectivity, but operates in an impaired state. Such a case may arise when all necessary components along a network path are available, but where certain redundant components which serve to enhance network performance or reliability are unavailable.

Once a hypervisor180obtains and stores status145of the configured virtual networks, status145may then be used by other components of the virtualized computing environment. For instance, VM management server110may look to deploy one or more virtual machines to host125A. In certain embodiments, VM management server might transmit a network status request to compute agent160A. Compute agent160Athen sends a request to kernel185Aregarding the status of the virtual networks configured on host125A. In response, kernel185Aaccesses virtual network status145Aand sends the virtual network status stored therein to compute agent160A. Compute agent160Acan then provide the status to VM management server100, which is then able to make a deployment decision based on the status of the virtual networks available on host125A. If the network status indicates that none of virtual networks are available (or that only virtual networks that are incompatible with the to-be deployed virtual machine are available), then VM management server100can choose to deploy the VM to another host.

VM management server100performs a similar process when executing load balancer101in order to determine whether to migrate a VM to a target host125. In this case, load balancer101transmits a network status request to a compute agent160. Compute agent160transmits a network status request to a corresponding kernel185, which responds to the request by accessing its virtual network status145and transmitting the network status of each virtual network accessible on that host to compute agent160. Compute agent160then transmits the network status back to load balancer101executing in VM management server100. If the network status indicates that no available virtual network on host125can provide the required connectivity to the VM to be migrated, then load balancer101would not perform the migration to that host.

FIG.2is a flow diagram that illustrates a method200for monitoring the status of one or more virtual networks on a host, according to embodiments. The steps of method200are performed by virtual network manager110and a network agent170.

Method200begins at step210, where virtual network manager110performs a process of monitoring a physical network to which host computers are connected. That is, virtual network manager110monitors the gateways, routers, links, bridges, and physical NICs that comprise the network connectivity for VMs. With reference toFIG.1, this includes networks A and B, gateway16, and physical NICs150of servers125Aand125B. It should be noted that, in one or more embodiments, virtual network manager110is also configured to monitor one or more virtualized network components.

Next, at step220, virtual network manager110transmits the physical network status information to a network agent170. At step230, network agent170receives the status information. At step240, network agent170determines the status of each of the virtual networks configured on the host on which it executes. In embodiments, network agent170makes this determination based on the received physical network status as described above. For example, if the network status indicates that some physical network components (such as a router in network A) are unavailable, then network agent170may determine that one or more virtual networks are unavailable, or are available, but impaired. Further, the network status information may indicate that all physical network components are operating. Yet, network agent170may independently determine that one or more software components that embody a virtual network on the host have failed. In such a case, network agent170determines that one or more virtual networks are unavailable or impaired, depending on how critical the failed software components are.

After determining the status of the virtual networks on the host at step240, method200then proceeds to step250. At step250, network agent170transmits the status of the virtual networks on the host to another component of hypervisor180such as kernel185(or subcomponents thereof) that executes on that host. In embodiments, network agent170transmits a name/value pair for each virtual network, where the name is a unique network identifier for the virtual network and the value is an indication of the status of the network. Further, once kernel185receives the network status, the network status is stored in a corresponding repository for later use, such as virtual network status145depicted inFIG.1.

Once network agent170transmits the virtual network status to hypervisor180at step250, method200returns back to step230, where network agent170receives further updates regarding the status of the physical network from virtual network manager110.

Referring back to step220inFIG.2, once virtual network manager110transmits the status of the physical network to network agent170, method200proceeds to step260. At step260, virtual network manager110determines whether to continue monitoring the physical network. In some embodiments, virtual network manager110monitors the physical network only upon request. In other embodiments, virtual network manager110continuously monitors the physical network until receiving instructions from a system administrator to cease monitoring. If the virtual network manager determines that it should continue monitoring the physical network, method200proceeds back to step210, where additional monitoring of the physical network is performed, e.g., periodically every few minutes or several times an hour. If virtual network manager110determines, at step260, that monitoring should not continue, then method200terminates.

FIG.3is a flow diagram depicting a method300of deploying a virtual machine to a host, in accordance with one or more embodiments of the present invention. As shown, the steps of method300are executed by VM management server100, by a compute agent160, and by a hypervisor180.

Method300begins at step305, where VM management server100receives a request to deploy a virtual machine to a host computer, where the host computer has a hypervisor180executing therein. At step310, VM management server100determines the virtual network requirements for the virtual machine that is to be deployed. For instance, in one or more embodiments, VM management server100determines connectivity requirements for the virtual machine, as well as the types of networks that the virtual machine may connect to. These requirements may be obtained from one or more configuration files associated with the VM to be deployed. VM management server100then transmits, at step315, a virtual network status query to compute agent160. The content of the query may comprise a network type, a set of connectivity requirements, or even a specific network identifier (if the virtual machine may only connect to one specific virtual network).

Next, at step320, compute agent160receives the status query from VM management server100. Method300then proceeds to step325, where compute agent160transmits the received status query to another component, e.g., a kernel185, of hypervisor180. As previously noted in the description ofFIG.2, kernel185(or other hypervisor component) may receive virtual network status information from network agent170.

At step330, the kernel or other component of hypervisor180receives the status query from compute agent160. Next, at step335, the kernel or other component determines the status of one or more virtual networks configured on the host. In some embodiments, kernel185determines, based on the received query, which virtual networks it should determine the status for. In some cases, the query will indicate that all virtual networks configured on the host should be checked for availability. In other cases, the query will indicate that only certain types of networks (e.g., VLANs) are to be checked. In some embodiments, kernel185performs the check by reading the status of the virtual networks from a repository, where the repository contains status information that the kernel received from network agent170, as described above in connection withFIG.2. One example of such a repository is virtual network status145, depicted inFIG.1.

Once the kernel or other component determines the status of the virtual networks configured on the host, method300proceeds to step340, where hypervisor180transmits the virtual network status to compute agent160.

It should be noted that the communication of network status information between compute agent160and hypervisor180may be achieved in other ways. For example, instead of transmitting network status information, compute agent160may access directly a corresponding virtual network status145in a producer/consumer model. In such an embodiment, kernel185is the producer, saving virtual network status to an associated virtual network status145, and compute agent160is the consumer. Other methods of communication (such as named pipes, remote procedure call, and shared RAM) are contemplated.

Referring back toFIG.3, once kernel185(or other component) transmits virtual network status to compute agent160, method300proceeds to step345, where compute agent160receives the network status. Next, at step350, compute agent160transmits the virtual network status received from hypervisor180to VM management server100. At step355, VM management server100receives the virtual network status.

Method300then proceeds to step360. At step360, VM management server100determines, based on the received virtual network status, whether one or more virtual networks that meet the connectivity requirements of the virtual machine are in fact available. If no virtual networks are available, then method300terminates and the virtual machine deployment does not take place. In embodiments, VM management server100is configured to generate and send an error message to a system administrator that indicates that the requested virtual machine failed to deploy.

If, however, VM management server100determines that there is one or more available virtual networks on the host as required by the VM, then, at step365, VM management server100transmits a virtual machine deployment request to compute agent160. According to embodiments, such a deployment request includes a target network to which the deployed virtual machine should be connected. Compute agent160then communicates with kernel185in order to instantiate the virtual machine on the host.

Once the deployment request is transmitted by VM management server100, method300terminates.

FIG.4is a flow diagram depicting a method400of migrating a virtual machine from a source host to a target host, according to one or more embodiments. As shown inFIG.4, the steps of method400are executed by load balancer101, a compute agent160, and a hypervisor180.

Method400begins at step405, where load balancer101determines a target host having the required virtual network for a virtual machine that needs to be migrated. That is, the load balancer101determines that a source host that the virtual machine executes on and the target host have connectivity to the same physical networks, and that the target host has a virtual network configured therein such that the virtual machine can connect to and transmit packets over the virtual network after migration is complete.

Once load balancer101identifies the virtual machine that is to be migrated, as well as a first target host to which the virtual machine should be migrated, then method400proceeds to step410. At step410, load balancer101transmits a virtual network status query to compute agent160executing on the target host. In embodiments, the transmitted query indicates the connectivity requirements for the virtual machine in order to enable hypervisor180to determine the status of a virtual network configured to meet these connectivity requirements.

Next, at step415, compute agent160receives the status query from load balancer101. Once compute agent160receives the status query, method400proceeds to step420, where compute agent160transmits the status query to a another hypervisor component, such as kernel185, subcomponent thereof, or another hypervisor component executing on the target host. Method400then proceeds to step425.

At step425, kernel185or other component on the first target host receives the status query from compute agent160. Next, at step430, hypervisor180determines the status of one or more virtual networks on the first target host. Hypervisor180determines the status in a similar manner as described in connection with step335of method300, as depicted inFIG.3. After determining the status of one or more virtual networks of the first target host, hypervisor180then, at step435, transmits the virtual network status to compute agent160.

Next, at step440, compute agent160receives the virtual network status from hypervisor180. At step445, compute agent160transmits the virtual network status received from hypervisor180to load balancer101. Method400then proceeds to step450, where load balancer101receives the virtual network status.

Next, at step455, load balancer101determines, based on the received virtual network status, whether one or more virtual networks that meet the connectivity requirements of the virtual machine that is to be migrated are available on the first target host. If no virtual networks are available on the first target host, then method400proceeds to step460, where load balancer101determines a next target host having the required virtual network for the virtual machine. This next target host serves as the next candidate host to which the virtual machine may be migrated. Method400then proceeds back to step410, where load balancer101transmits a virtual network status query to a compute agent160executing on the next target host. The process of determining the availability of the virtual network is then repeated.

If, however, load balancer101determines, based on the received virtual network status, that one or more virtual networks are available on the first target system, then load balancer101, at step465, transmits a migration request to compute agent160on the first target host. The migration request causes compute agent160to communicate with hypervisor180in order to deploy the virtual machine to the first target host.

Although one or more embodiments have been described herein in some detail for clarity of understanding, it should be recognized that certain changes and modifications may be made without departing from the spirit of the disclosure. The various embodiments described herein may employ various computer-implemented operations involving data stored in computer systems. For example, these operations may require physical manipulation of physical quantities—usually, though not necessarily, these quantities may take the form of electrical or magnetic signals, where they or representations of them are capable of being stored, transferred, combined, compared, or otherwise manipulated. Further, such manipulations are often referred to in terms, such as producing, yielding, identifying, determining, or comparing. Any operations described herein that form part of one or more embodiments of the disclosure may be useful machine operations. In addition, one or more embodiments of the disclosure also relate to a device or an apparatus for performing these operations. The apparatus may be specially constructed for specific required purposes, or it may be a general purpose computer selectively activated or configured by a computer program stored in the computer. In particular, various general purpose machines may be used with computer programs written in accordance with the teachings herein, or it may be more convenient to construct a more specialized apparatus to perform the required operations.

The various embodiments described herein may be practiced with other computer system configurations including hand-held devices, microprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, and the like.

One or more embodiments of the present disclosure may be implemented as one or more computer programs or as one or more computer program modules embodied in one or more computer readable media. The term computer readable medium refers to any data storage device that can store data which can thereafter be input to a computer system—computer readable media may be based on any existing or subsequently developed technology for embodying computer programs in a manner that enables them to be read by a computer. Examples of a computer readable medium include a hard drive, network attached storage (NAS), read-only memory, random-access memory (e.g., a flash memory device), a CD (Compact Discs)—CD-ROM, a CD-R, or a CD-RW, a DVD (Digital Versatile Disc), a magnetic tape, and other optical and non-optical data storage devices. The computer readable medium can also be distributed over a network coupled computer system so that the computer readable code is stored and executed in a distributed fashion.

Although one or more embodiments of the present disclosure have been described in some detail for clarity of understanding, it will be apparent that certain changes and modifications may be made within the scope of the claims. Accordingly, the described embodiments are to be considered as illustrative and not restrictive, and the scope of the claims is not to be limited to details given herein, but may be modified within the scope and equivalents of the claims. In the claims, elements and/or steps do not imply any particular order of operation, unless explicitly stated in the claims.

Many variations, modifications, additions, and improvements are possible. Plural instances may be provided for components, operations or structures described herein as a single instance. Boundaries between various components, operations and data stores are somewhat arbitrary, and particular operations are illustrated in the context of specific illustrative configurations. Other allocations of functionality are envisioned and may fall within the scope of the disclosure(s). In general, structures and functionality presented as separate components in exemplary configurations may be implemented as a combined structure or component. Similarly, structures and functionality presented as a single component may be implemented as separate components. These and other variations, modifications, additions, and improvements may fall within the scope of the appended claim(s).