Flow rule installation latency testing in software defined networks

Systems and methods for flow rule installation latency testing in software defined networks. In some examples, a hypervisor may deploy a virtual network switch configured to route data to virtualized computing environments executing on the hypervisor. A client process may be deployed in a first container executing on the hypervisor. A server process may be deployed on the hypervisor. The client process may receive a first request to deploy a virtual machine on the hypervisor. The client process may generate first instructions configured to cause the server process to generate a first namespace. The server process may generate the first namespace and may communicatively couple the first namespace to the virtual network switch.

BACKGROUND

The present disclosure generally relates to testing latency associated with software defined networks (SDNs). SDN technology is an approach to network management that enables dynamic, programmatically efficient network configuration for maintaining a current and consistent state of operation for a network. SDN enables virtual networking in a cloud computing environment. Cloud computing is the act of running compute workloads within distributed computing environments that abstract, pool, and share scalable resources across a computing network. The term “cloud” in the computing context refers to a pool of compute, network, and storage resources within one or more datacenters. These resources may be managed and provisioned through application programming interfaces (APIs) with common authentication mechanisms. Different tenants of a cloud may access the APIs in order to avail themselves of the cloud's resources. Accordingly, each tenant of a cloud computing environment may instantiate their own virtual machines in networks that are dedicated to that tenant (and isolated from other tenants), even though all tenant resources are, in a sense, physically executing on the same underlying hardware.

SUMMARY

The present disclosure provides a new and innovative system, methods and apparatus for flow rule installation latency testing in SDNs. In an example, a hypervisor may deploy a virtual network switch configured to route data to and from virtualized computing environments executing on the hypervisor. In some further examples, a client process may be deployed in a first container executing on the hypervisor. A server process may be deployed on the hypervisor. In various examples, the client process may receive a first request to deploy a first virtual machine on the hypervisor. In response to the first request, the client process may generate first instructions configured to cause the server process to generate a first namespace. The server process may generate the first namespace. In some examples, the server process may communicatively couple the first namespace to the virtual network switch.

In another example, at least one processor is configured in communication with at least one non-transitory computer-readable memory. The at least one processor may be effective to execute a hypervisor. In various examples, the hypervisor may be effective to deploy a virtual network switch configured to route data to and from virtualized computing environments executing on the hypervisor. The hypervisor may be further configured to deploy a client process in a first container executing on the hypervisor. The hypervisor may be further configured to deploy a server process on the hypervisor. The client process may be configured to receive a first request to deploy a first virtual machine on the hypervisor. In response to the first request, the client process may generate first instructions configured to cause the server process to generate a first namespace. The server process may be configured to generate the first namespace in response to the first instructions. In some examples, the server process may communicatively couple the first namespace to the virtual network switch.

In yet another example, a non-transitory machine-readable medium may store a program, that when executed by at least one processor may cause the at least one processor to deploy, by a hypervisor, a virtual network switch configured to route data to and from virtualized computing environments executing on the hypervisor. In various examples, the program, when executed by the at least one processor may further cause the at least one processor to execute first code configured to instantiate a client process in a first container. In another example, the program, when executed by the at least one processor may further cause the at least one processor to execute second code configured to instantiate a server process on the hypervisor. In another example, the program, when executed by the at least one processor may further cause the at least one processor to receive, by the client process, a first request to deploy a first virtual machine on the hypervisor. In still other examples, the program, when executed by the at least one processor may further cause the at least one processor to generate, by the client process in response to the first request, first instructions configured to cause the server process to generate a first namespace. In at least some other examples, the program, when executed by the at least one processor may further cause the at least one processor to generate, by the server process, the first namespace. In yet other examples, the program, when executed by the at least one processor may further cause the at least one processor to communicatively couple the first namespace to the virtual network switch by the server process.

Additional features and advantages of the disclosed method and apparatus are described in, and will be apparent from, the following Detailed Description and the Figures.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

SDNs enable virtual cloud-based networking and provide dynamic and efficient network configuration to maintain a current and consistent state of the network. There are typically two main components of an SDN: 1) an SDN controller that maintains a holistic view of the network and sends out network configuration instructions; and 2) virtual switches which receive configuration instructions from the SDN controller (e.g., through some protocol such as OpenFlow®) and implement the dataplane which establishes network connectivity.

Testing SDNs at scale is challenging due to the amount of hardware and virtualized systems needed to perform testing. For example, large scale testing may require a large number of virtual machines (VMs) (e.g., hundreds and/or thousands of VMs) to be booted and deployed on many different hypervisors to simulate a realistic workload. However, deploying a large number of virtual machines and/or hypervisors is time consuming and resource intensive. Additionally, the amount of hardware that is set aside for testing purposes is often limited, further limiting the number of virtualized computing environments that can be deployed during testing. Furthermore, programming a virtual switch to enable communication between the various virtual machines (e.g., to establish the dataplane) takes time which can fluctuate depending on the number of virtual machines and/or the workload being deployed on the SDN. In fact, flow rule installation latency, which is the time taken by the SDN controller to program networking flows on the virtual switch (leading to establishment of the dataplane for the deployed virtual machines), is a key performance metric for SDNs. However, for the reasons described above, it is difficult and time consuming to test flow rule installation latency at scale. Flow rule installation tends to increase as the number of VMs deployed increases. For example, flow rule installation latency may vary from 5 seconds to greater than 300 seconds, depending on the number VMs deployed.

In various examples, a fake driver may be used to emulate VM deployments by generating an entry in a database representing a VM and by emulating typical VM messaging workflows. However, the “fake” VMs generated by such a fake driver do not actually boot the VM or connect the VM to the virtual switch. Described herein are flow rule installation latency testing techniques that generate network namespaces (e.g., Linux namespaces) which simulate virtual machine deployments using a modified fake driver architecture. In the modified fake driver architecture described herein, network ports are created inside the namespaces and are connected to the virtual switch (a process referred to as “VIF plugging”). Thereafter, tests can be performed through which the “VM interfaces” are pinged to determine the flow rule installation latency. Note that no actual VM interface is deployed; instead, a port inside the network namespace is used as a simulated VM interface. Accordingly, instead of booting bulky VMs (the number of which may be highly constrained based on the testing environment), network namespaces may be used to emulate the workload VMs and their network functionality (e.g., through creation of ports/network interfaces within the namespaces). Such an approach represents a lightweight, faster approach to flow rule installation latency testing in SDNs relative to booting a large number of VMs and performing VIF plugging.

Note that the virtual switch on the compute nodes to which ports from the namespaces are communicatively coupled (e.g., “plugged”) reside on the parent network namespace of the hypervisor. Since the virtual switch resides on the parent network namespace, it can connect to ports from other network namespaces on the parent network namespace. This is because the parent network namespace has access to the other network namespaces deployed on the hypervisor. As such, in order to be communicatively coupled to the virtual switch, the namespaces that mimic VMs should be accessible by the parent network namespace.

In some examples, it may be problematic for the modified fake driver architecture of the compute service (e.g., the compute service deploying the “VMs”) to directly generate the network namespaces that mimic VMs. This is because the compute service including the modified fake driver architecture may be running in a container on the hypervisor (in a containerized deployment model). If this is the case, any namespaces generated by the compute service will not be visible to the virtual switch on the parent network namespace. This occurs because each container is deployed in a namespace. Accordingly, any namespaces created within a container are nested namespaces, which are visible to, and accessible by, only the container namespace. In other words, such nested namespaces are not accessible by the virtual switch executing on the hypervisor in the parent namespace.

Accordingly, in various examples described herein, a server process may be deployed on the hypervisor (in the parent namespace). The compute service executing inside a container (with the modified fake driver architecture) acts as a client process and communicates with the server process deployed on the hypervisor. The client process may emulate a driver and may be effective to perform the various operations described herein. When the compute service generates a request to deploy a virtual machine, the modified fake driver architecture generates instructions configured to cause the server process deployed on the hypervisor to create a network namespace (instead of booting a VM). The server process generates a port on the virtual switch and communicatively couples the network namespace to the virtual switch. As the server process is executing on the hypervisor and not inside the compute service container, the resulting network namespaces are accessible to the virtual switch. Accordingly, large numbers of namespaces may be generated to simulate large scale testing of dataplane connectivity/SDN flow install latency even if the compute service is containerized. A ping-like test may be used to ping the ports in the network namespaces to identify the amount of time taken for establishing dataplane connectivity. This flow rule installation latency may be used to quantify SDN performance and identify bottlenecks/delays in SDN flow programming.

FIG.1is a block diagram of a system100including a computing device102configured in communication with an SDN controller123according to an example of the present disclosure. Although only a single computing device102is depicted inFIG.1, it may be appreciated that multiple computing devices (sometimes referred to as compute nodes) may be used in accordance with the various techniques described herein. The computing device102may include one or more physical host(s), including physical host110. Physical host110may in turn include one or more physical processor(s) (e.g., CPU112) communicatively coupled to one or more memory device(s) (e.g., MDs114A-B) and one or more input/output device(s) (e.g., I/O116). As used herein, physical processor or processors112refer to devices capable of executing instructions encoding arithmetic, logical, and/or I/O operations. In one illustrative example, a processor may follow Von Neumann architectural model and may include an arithmetic logic unit (ALU), a control unit, and a plurality of registers. In an example, a processor may be a single core processor which is typically capable of executing one instruction at a time (or process a single pipeline of instructions), or a multi-core processor which may simultaneously execute multiple instructions and/or threads. In another example, a processor may be implemented as a single integrated circuit, two or more integrated circuits, or may be a component of a multi-chip module (e.g., in which individual microprocessor dies are included in a single integrated circuit package and hence share a single socket). A processor may also be referred to as a central processing unit (“CPU”).

As discussed herein, memory device(s)114A-B refer to volatile or non-volatile memory devices, such as RAM, ROM, EEPROM, or any other device capable of storing data. In an example, memory devices114A-B may be persistent storage devices such as hard drive disks (“HDD”), solid-state drives (“SSD”), and/or persistent memory (e.g., Non-Volatile Dual In-line Memory Module (“NVDIMM”)). Memory devices114A-B may additionally include replication of data to prevent against data loss due to a failure in any one device. This replication may be implemented through, for example, a redundant array of independent disks (“RAID”) setup. RAID arrays may be designed to increase performance, to provide live data backup, or a combination of both. As discussed herein, I/O device(s)116refer to devices capable of providing an interface between one or more processor pins and an external device, the operation of which is based on the processor inputting and/or outputting binary data. In various examples, I/O device(s)116may communicate through physical switch134with SDN controller123. Physical switch134may be a hardware device used to connect devices and enable communication over a network. SDN controller123may be an application acting as a strategic control point of an SDN comprising computing device102. SDN controller123may manage flow control to the physical switch134(and/or to other physical switches of other computing devices) to deploy and maintain an SDN. In various examples, SDN controller123may use OpenFlow® and/or open virtual switch database (OVSDB) to communicate with physical switch134.

CPU(s)112may be interconnected using a variety of techniques, ranging from a point-to-point processor interconnect, to a system area network, such as an Ethernet-based network. Local connections within physical host110, including the connections between processors112and memory devices114A-B and between processors112and I/O device116may be provided by one or more local buses and/or interconnects of suitable architecture, for example, peripheral component interconnect (PCI).

In an example, physical host110may run one or more isolated guests, for example, VM122, which may in turn host additional virtual environments (e.g., VMs and/or containers). In an example, a container (e.g., container162) may be an isolated guest using any form of operating system level virtualization, for example, OpenShift®, Docker® containers, chroot, Linux®-VServer, FreeBSD® Jails, HP-UX® Containers (SRP), VMware ThinApp®, etc. Container162may run directly on a host operating system (e.g., host OS118) or run within another layer of virtualization, for example, in a virtual machine (e.g., VM122). In an example, containers that perform a unified function may be grouped together in a container cluster that may be deployed together (e.g., in a Kubernetes® pod). In an example, a given compute service may require the deployment of multiple VMs, containers and/or pods in multiple physical locations. In an example, VM122may be a VM executing on physical host110.

Computing device102may run one or more VMs (e.g., including VM122) and/or other virtualized execution environments, by executing a software layer (e.g., hypervisor120) above the hardware and below the VM122, as schematically shown inFIG.1. The various VMs and/or containers may be configured to communicate with one another and/or with other devices via ports on virtual switch132. Virtual switch132may be executing on hypervisor120.

In an example, the hypervisor120may be a component of respective host operating system118executed on physical host110, for example, implemented as a kernel based virtual machine function of host operating system118. In another example, the hypervisor120may be provided by an application running on host operating system118. In an example, hypervisor120may run directly on physical host110without an operating system beneath hypervisor120(e.g., in a “bare metal” implementation). Hypervisor120may virtualize the physical layer, including processors, memory, and I/O devices, and present this virtualization to VM122as devices, including virtual central processing unit (“VCPU”)190, virtual memory devices (“VIVID”)192, virtual input/output (“VI/O”) device194, and/or guest memory195. In an example, another virtual guest (e.g., a VM or container) may execute directly on host OSs118without an intervening layer of virtualization.

In an example, a VM122may be a virtual machine and may execute a guest operating system196, which may utilize the underlying VCPU190, VIVID192, and VI/O194. Processor virtualization may be implemented by the hypervisor120scheduling time slots on physical CPUs112such that from the guest operating system's perspective those time slots are scheduled on a virtual processor190. VM122may run on any type of dependent, independent, compatible, and/or incompatible applications on the underlying hardware and host operating system118. The hypervisor120may manage memory for the host operating system118as well as memory allocated to the VM122and guest operating system196such as guest memory195provided to guest OS196.

In an example, container162may execute a compute service, such as a service configured to deploy a workload on compute resources of computing device102and/or system100. In various examples, in order to deploy the workload, the compute service may be effective to generate requests to deploy virtual machines. In some examples, the requests to deploy virtual machines may be received from a cloud management system (e.g., OpenStack®). The requests may include a unique identifier for the VM and a dictionary (key-value pair “network_info” defining various network parameters for the VM such as the media access control (MAC) address, IP address, IP routing information, etc., for each network interface of the VM.

As described in further detail below, in some examples, a client process (e.g., a web server gateway interface (WSGI) client164) may act as a modified fake driver architecture configured to receive and/or detect requests to deploy VMs generated by the compute service. In response to receipt and/or detection of a request to deploy a VM, the client process (e.g., WSGI client164) may generate instructions configured to cause a server process (e.g., WSGI server160) executing on hypervisor120to generate a network namespace (e.g., namespaces170A,170B) that represents the VM network stack requested by the cloud management system. Since the server process, such as WSGI server160, is executing on the hypervisor120(e.g., in the parent network namespace), network namespaces generated by the server process may be accessible by, and communicatively coupled to, the virtual switch132. Additionally, the client process (e.g., the modified fake driver architecture of WSGI client164) may send instructions to the server process (e.g., WSGI server160) describing a network port to be added to the respective namespaces. WSGI server160may parse the instructions to determine the appropriate namespace to which to add the port. In the example depicted inFIG.1, WSGI server160may add port171A to namespace170A and port171B to namespace171B. In addition, although not shown inFIG.1, the WSGI server160may attach respective internet protocol (IP) addresses to the ports171A,171B and may insert IP routing information specified by the instructions received from the modified fake driver architecture of the client process (e.g., WSGI client164) to communicatively couple the namespaces170A,170B to the virtual switch132. Thereafter, ping-like requests may be sent to the namespaces170A,170B via their respective ports171A,171B, and the amount of time it takes for the namespaces170A,170B to respond may be determined in order to estimate flow rule installation latency.

In an example, any form of suitable network for enabling communications between computing devices (and between VMs/containers and SDN controller123), for example, a public network (e.g., the Internet), a private network (e.g., a local area network (LAN) or wide area network (WAN)), or a combination thereof, may be employed to connect the component parts of the system to each other.

FIG.2is a block diagram illustrating deployment of namespaces that may be used for flow rule installation latency testing, according to various aspects of the present disclosure. Compute service218may be any compute service that may deploy a workload on an underlying physical system (e.g., computing device102). For example, a cloud management system such as OpenStack® may request deployment of a number of VMs on hypervisor220. The cloud management system may pass the request to deploy the VMs to compute service218. Virtual networking information (e.g., IP address, MAC address, IP routing information, etc.) for the VMs may be stored in a database for the requested VMs. The virtual networking information may be passed to the client process (e.g., WSGI client264) as a dictionary (key-value pair) “network_info.” An instance ID (e.g., a UUID) may be generated for each requested VM.

In various examples, compute service218may execute within a container162. However, in other examples, compute service218may execute directly on hypervisor220. A modified fake driver architecture (e.g., a client process such as WSGI client264) of compute service218may detect requests generated by compute service218to deploy a VM and may receive the network_info and UUID for each requested VM. In response to detection of a request to deploy a VM, WSGI client264may deploy namespace instructions212and may send the instructions to WSGI server260. WSGI server260may be a server process executing directly on hypervisor220(in the parent network namespace). In various examples, the deploy namespace instructions212may be sent to WSGI server260as a first JSON message. The first JSON message may comprise the name of the namespace (e.g., “Namespace-<VM UUID>”).

WSGI server260may receive the first JSON message (or other instructions) and may parse the first JSON message and execute the add_namespace( )222method to create the particular network namespace. Accordingly, the WSGI server260may create a network namespace with the requested namespace name using execute_command( )228a. In the example depicted inFIG.2, WSGI server260creates namespace270A using the add_namespace( )222instruction in response to the first JSON message.

WSGI client264may also send add port instructions214(e.g., port request data) as a second JSON message. The add port instructions214may include the name of the namespace (e.g., the UUID) along with the IP address and MAC address for each interface in the fake VM. This information is stored in the dictionary (key-value pair) “network_info” received by the WSGI client264. The network_info may also include IP routing information (describing how network traffic should be routed by the particular interface of the namespace).

WSGI server260may receive the second JSON message and may parse the second JSON message. WSGI server260may execute the add_port( )224method. The add_port( )224method may receive from the WSGI client264, the namespace name and device details (e.g., IP address, MAC, etc.). The add_port( )24method may create the port271A in the named namespace (e.g., namespace270A) with the MAC address/IP info received in the second JSON (e.g., via execute_command( )228b). The namespace270A may be added to the virtual switch232executing on the hypervisor220.

Since the WSGI server260is executing in the parent namespace on the hypervisor, namespaces (such as namespace270A) created by the WSGI server260are accessible by the virtual switch232which is also executing on the hypervisor220in the parent namespace. Once the namespace270A is communicatively coupled to the virtual switch232via port271A, the namespace270A may be pinged to determine a response time. These operations may be replicated for each namespace (e.g., for each “fake” VM) generated using the above-described techniques. Accordingly, the above-described techniques may be used to estimate flow rule installation latency for a given workload (e.g., requiring deployment of a particular number of VMs) without booting any VMs.

In various examples, the following pseudocode (or functionally equivalent code) may be used to implement the modified fake driver architecture (e.g., the WSGI client264):

In various examples, the above code may execute inside container162executing compute service218and may generate the deploy namespace instructions212for creating a new network namespace instead of a VM. Additionally, the above code may generate the add port instructions214to add the port to the namespace and connect the port to the virtual switch232. The modified fake driver (e.g., WSGI client264) may send commands to WSGI server260(e.g., a server process executing on hypervisor220) using the following pseudocode (or functionally equivalent code):

def send_command(command):# Note that the message is sent via a Unix domain socket so that# the URL does not matter.resp, content = httplib2.Http( ).request(′http://127.0.0.1/′,method=″POST″,headers={′Content-Type′: ′application/json′},body=json.dumps(command),connection_type=FakeNovaDriverClientConnection)if resp.status != 200:raise Exception(′Unexpected response %s′ % resp)

The above command is not executed inside the container162and instead is sent to the WSGI server260listening on the Unix socket on the hypervisor220.

In various examples, the following pseudocode (or functionally equivalent code) may be used by the WSGI server260to create a new network namespace mimicking the requested VM:

In various examples, the following pseudocode (or functionally equivalent code) may be used by the WSGI server260to add a port to the network namespace mimicking the requested VM. Additionally, default network routes, etc., are added to the newly created network namespace:

In various examples, a cleanup process used to deprovision the network namespaces may be used. For example, a cloud management system may send a request to deprovision a particular VM. The request may include the UUID of the particular VM as well as “network_info” for the particular VM. The WSGI client264may generate an instruction to delete the port. The instruction may be sent to the WSGI server260(e.g., as a JSON message). The WSGI server260may perform a method (e.g., a delete_port( ) method) to delete the port corresponding to the particular network namespace. In various examples, the appropriate network namespace may be identified based on the UUID and the port may be identified based on the MAC. Accordingly, the port may be deleted from the virtual switch232. Additionally, the WSGI client264may generate an instruction to delete the namespace corresponding to the UUID. The instruction may be sent to the WSGI server260(e.g., as a JSON message). The WSGI server260may, in turn, delete the appropriate network namespace (e.g., using a delete_namespace( ) method).

FIG.3is flowchart illustrating an example process300for flow rule installation latency testing according to an example of the present disclosure. Although the example process300is described with reference to the flowchart illustrated inFIG.3, it will be appreciated that many other methods of performing the acts associated with the process300may be used. For example, the order of some of the blocks may be changed, certain blocks may be combined with other blocks, blocks may be repeated, and some of the blocks described may be optional. The process300may be performed by processing logic that may comprise hardware (circuitry, dedicated logic, etc.), software, or a combination of both. In some examples, the actions described in the blocks of the process300may represent a series of instructions comprising computer-readable machine code executable by one or more processing units of one or more computing devices. In various examples, the computer-readable machine codes may be comprised of instructions selected from a native instruction set of and/or an operating system (or systems) of the one or more computing devices.

The example process300includes deploying, by a hypervisor, a virtual network switch configured to route data to and from virtualized computing environments executing on the hypervisor (block305). For example, virtual network switch232may be deployed on the hypervisor220. The virtual network switch232may be effective to route data to and from various virtual machines and/or other virtualized execution environments executing on the SDN.

In an example, the process300may include deploying a client process in a first container executing on the hypervisor (block315). For example, the WSGI client264may be deployed in a container executing on the hypervisor220. In an example, the process300may include deploying a server process on the hypervisor (block325). For example, WSGI server260may be executed by hypervisor220. As previously described, the WSGI server260may execute on the hypervisor220. Accordingly, namespaces generated by the WSGI server260may be accessible by a virtual switch (e.g., virtual switch232) executing on the hypervisor220.

Process300may include receiving, by the client process, a request to deploy a first virtual machine on the hypervisor (block335). For example, the WSGI client264(e.g., a modified fake driver) may receive a request to deploy a first virtual machine from a cloud management system. Additionally, in some examples, the WSGI client264may receive a dictionary (key-value pair) “network_info” for the first virtual machine that specifies a UUID for the VM, MAC addresses and/or IP addresses for each network interface of the VM, etc. Process300may include generating, by the client process, first instructions configured to cause the server process to generate a first namespace (block345). For example, WSGI client264may generate a first JSON message effective to cause the WSGI server260to execute the add_namespace( )222method. The first instructions may specify a name of the namespace (e.g., the UUID of the requested VM), MAC address(es), IP addresses, routing information, etc.

In various examples, process300may include generating, by the server process, the first namespace (block355). For example, the WSGI server260may execute the add_namespace( )222method to generate a network namespace with the requested name (e.g., the UUID of the requested VM). The newly-generated network namespace (e.g., namespace270A) may include the name (UUID) specified in the first instructions received from the WSGI client264(e.g., in the first JSON message). In various examples, process300may include communicatively coupling the first namespace to the virtual network switch by the server process (block365). For example, the WSGI server260may receive a second JSON message from the WSGI client264. The second JSON message may include the namespace name (e.g., the UUID), MAC details and IP addresses for each interface in the VM request. The WSGI server260may execute the add_port( ) method to create the port on the virtual switch232in the namespace. The port includes the MAC and IP address specified by the second JSON message. Accordingly, the namespace (e.g., namespace270A) may be communicatively coupled to the virtual switch232and dataplane connectivity may be established.

FIGS.4A and4Billustrate a flow diagram400of an example of a flow rule installation latency test according to an example of the present disclosure. Although the examples below are described with reference to the flow diagram illustrated inFIGS.4A and4B, it will be appreciated that many other methods of performing the acts associated withFIGS.4A and4Bmay be used. For example, the order of some of the blocks may be changed, certain blocks may be combined with other blocks, and some of the blocks described are optional. The methods may be performed by processing logic that may comprise hardware (circuitry, dedicated logic, etc.), software, or a combination of both. In the illustrated example flow diagram400, compute service402generates a request to boot a first virtual machine (block408). In various examples, the request may be generated by a cloud management system. The request to boot the first virtual machine may be sent to the WSGI client (e.g., the modified fake driver) (block410). In various examples, the UUID of the first virtual machine and the dictionary (key-value pair) “network_info” for the first virtual machine may be sent to the WSGI client404. The WSGI client404may intercept the VM request (block412). Instead of booting a VM, WSGI client404may generate a JSON message configured to cause WSGI server406to generate a namespace emulating the requested VM network stack (block414). The first JSON message may comprise the name of the namespace to be generated by the WSGI server406.

The send_command( )416may be used to send the first JSON message to the WSGI server406. The WSGI server406may receive the first JSON message (block418). The WSGI server406may parse the first JSON message and may generate a namespace representing the requested VM network stack using the add_namespace( ) method (block420). The generated namespace may have the name (e.g., a UUID) specified in the first JSON message received from WSGI client404. In various examples, WSGI server406may send a namespace generation confirmation message422to the WSGI client404to indicate that the requested network namespace has been created. WSGI client404may receive confirmation of namespace generation (block424).

As illustrated inFIG.4B, the WSGI client404generates a second JSON message to add a port to the created namespace using the plug_vifs( ) method (block426). The second JSON message may include add port instructions that may include the name of the network namespace, the IP address and MAC address for each interface of the VM that is represented by the network namespace, and routing information for the port. WSGI client404may send the second JSON message to WSGI server using the Send_command( )428. The WSGI server406may receive the second JSON message (block430). The WSGI server406may parse the second JSON message to determine the namespace ID (e.g., the namespace name—UUID), the IP address(es) and MAC address(es), the network interface controller (NIC), IP routing information, etc. (block432). The WSGI server406may generate the port in the identified namespace (block434). The WSGI server406may attach the IP address and/or MAC address for the port and may provide the IP routing information for the port to the virtual switch (block436). The WSGI server406may connect the port to the virtual switch (block438). For example, the WSGI server406may execute the add_port( ) method to create the port in the named namespace (e.g., the namespace named in the second JSON message) with the MAC address/IP info received in the second JSON. The named namespace may be added to the virtual switch executing on the hypervisor.

The compute service402, or some other component, may ping the VM (e.g., the namespace emulating the VM) (block440). The compute service402, or other component, may measure the time for response (block442). Accordingly, the flow rule installation latency may be estimated.

FIG.5is a block diagram of a system500configured to perform flow rule installation latency testing, according to an example of the present disclosure. The system500may include at least one processor501executing a hypervisor504. The system500may further include a memory502(e.g., a non-transitory computer-readable memory). In some examples, the memory502may store instructions that, when executed, may cause processor501to perform one or more of the various techniques described herein (e.g., in reference toFIGS.1-4B). The hypervisor504may be configured to deploy a virtual network switch532that may route data522to and from virtualized computing environments590. Virtualized computing environments590may be, for example, VMs and/or containers that may be executed on hypervisor504and/or on some other compute node.

Hypervisor504may be configured to deploy a client process564executing in a container562. The client process564may be a modified fake driver (e.g., a WSGI client) that may receive requests to deploy VMs580on hypervisor504. In some examples, the request may be received from a cloud management system. The client process564may generate instructions582in response to the request to deploy VM580. The instructions582may be configured to cause a server process560that is deployed on the hypervisor504to generate namespace584. Additionally, the instructions582(or separate instructions) may be effective to communicatively couple the namespace584to the virtual network switch532(e.g., performing virtual interface plugging).