cloudparts

Open vSwitch

A programmable software switch for hypervisors and container hosts: it connects VMs and containers to each other and to tunnels across the physical network, and forwards packets by OpenFlow rules that a controller can change.

Linux Foundation project
Type
Open source
Made by
Open vSwitch project (Linux Foundation), created at Nicira
Foundation
The Linux Foundation, joined August 2016
License
Apache 2.0 (the Linux kernel module upstream is GPLv2)
Facts checked
28 October 2026

What it is

Open vSwitch (OVS) is a multilayer software switch. On a server running VMs or containers, it sits where a physical switch would: each virtual interface plugs into an OVS bridge, and the bridge connects them to each other, to the physical NICs and to tunnels that reach other hosts. It does what a managed switch does, such as 802.1Q VLANs, NIC bonding with or without LACP, QoS policing, NetFlow, sFlow and port mirroring, and it encapsulates traffic in Geneve, VXLAN, GRE, ERSPAN and other tunnels so that tenants’ networks can span many hosts over a shared fabric. Two daemons run it: ovsdb-server keeps the configuration (bridges, ports, interfaces, controllers) in a small transactional database, and ovs-vswitchd implements the switch. Its forwarding is described as OpenFlow tables, which an SDN controller or a tool such as ovs-ofctl fills in.

Forwarding is split in two. Packets arrive at a datapath, which keeps a cache of flows mapping header fields to actions. When a packet matches a cached flow, the datapath applies the actions straight away; when it doesn’t, the packet goes up to ovs-vswitchd, which runs it through the full OpenFlow pipeline and installs a cached flow so that later packets of the same kind stay in the fast path. The usual datapath is a module in the Linux kernel, part of mainline Linux since 3.3 in 2012. OVS can also run entirely in user space, taking packets from DPDK or AF_XDP sockets for higher throughput, and it can push flows down to NICs that support Linux TC flower hardware offload.

OVS is the switch underneath a lot of software-defined networking. OVN builds virtual networks on top of it, and so do OpenStack Neutron’s ML2/OVS and ML2/OVN drivers and OpenShift’s default network plugin, OVN-Kubernetes, which runs OVS on every node. It has been a Linux Foundation project since August 2016. Releases come every six months, in February and August, with a long-term support release picked every two years; 4.0.0, released on 17 August 2026, dropped Windows support, the old out-of-tree tunnel ports and several obsolete tools.

Why teams pick it

  • The de facto virtual switch for open-source clouds: OpenStack, OVN and OVN-Kubernetes all build on it, so skills and tooling carry over
  • Programmable through OpenFlow and OVSDB, so a controller can change forwarding on thousands of hosts without touching the kernel
  • Several datapaths for one configuration: the Linux kernel, user space with DPDK or AF_XDP, and hardware offload to capable NICs
  • Long-lived and vendor-neutral: developed since 2009, Apache 2.0 licensed, and governed by its committers at the Linux Foundation

Watch out for

  • Low-level on its own: you write OpenFlow rules and manage tunnels yourself unless a control plane such as OVN or OpenStack Neutron does it
  • Performance depends on the datapath: the kernel path can fall short at high packet rates, and DPDK means dedicating CPU cores and hugepages to the switch
  • The cached-flow design makes troubleshooting a two-level job: OpenFlow tables in ovs-vswitchd and the datapath’s flows can differ, and tools such as ofproto/trace are needed to follow a packet
  • Windows support was removed in 4.0, and the kernel datapath, the usual one, exists only in Linux

Alternatives

What all software-defined networking have in common →Compare side by side →

How it fits with other technologies

A bridge with a VM’s port and a VXLAN tunnel to another host, then two OpenFlow rules · bash

ovs-vsctl add-br br0
ovs-vsctl add-port br0 tap0
ovs-vsctl add-port br0 vx1 -- set interface vx1 type=vxlan \
    options:remote_ip=192.0.2.20 options:key=5001

# drop SSH coming from the VM, switch everything else like a normal L2 switch
ovs-ofctl add-flow br0 "priority=100,in_port=tap0,tcp,tp_dst=22,actions=drop"
ovs-ofctl add-flow br0 "priority=0,actions=normal"
ovs-ofctl dump-flows br0

# the flows the datapath has actually cached
ovs-appctl dpctl/dump-flows

See it in a real stack

No architecture uses Open vSwitch yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2009–2026

Open vSwitch came out of Nicira, a Palo Alto start-up founded in 2007 by pioneers of OpenFlow. Its first release came in 2009. Nicira used it as the switch in every hypervisor for its network virtualisation platform, controlled centrally over OpenFlow. The kernel datapath was merged into mainline Linux in version 3.3 in March 2012, and XenServer 6.0 made OVS its default switch the same year. In July 2012 VMware agreed to buy Nicira for about $1.26 billion, and the OVS team carried on there.

In January 2015 Justin Pettit, Ben Pfaff, Chris Wright and Madhu Venugopal announced OVN, a control plane for building virtual networks on OVS, and the team described OVS’s flow caching design at NSDI that year. On 9 August 2016 Open vSwitch became a Linux Foundation project, with governance by its top committers; more than 300 people from companies including Cisco, Ericsson, Huawei, IBM, Intel, Red Hat and VMware had contributed. OVN moved to its own repository in 2019.

Since then the project has added user-space datapaths on DPDK and AF_XDP and hardware offload, and trimmed what it no longer needs. Version 4.0.0 in August 2026 removed Windows support, the legacy tunnel ports from the old out-of-tree kernel module, AVX512-specific code paths and several obsolete utilities.

Why it’s built this way

A fast datapath plus a smart user-space daemon
Keeping only a flow cache in the kernel kept the kernel module small and stable, while the complex OpenFlow pipeline, which changes often, lives in user space where it is easier to develop and upgrade.
OpenFlow and a configuration database as the interfaces
Exposing forwarding as OpenFlow tables and configuration as OVSDB let external controllers program every host’s switch the same way, which is what network virtualisation needs.
Several datapaths behind one switch
Users wanted different trade-offs: the kernel for simplicity, DPDK or AF_XDP for packet rate, NIC offload for CPU savings, so OVS keeps the same OpenFlow behaviour on all of them.

Timeline

  1. 2009

    First release, developed at Nicira

  2. 2012

    Kernel datapath merged into Linux 3.3 in March; VMware agrees to buy Nicira in July

  3. 2015

    OVN announced in January; design paper at NSDI

  4. 2016

    Becomes a Linux Foundation project on 9 August

  5. 2019

    OVN split into its own repository

  6. 2026

    Version 4.0.0 on 17 August drops Windows and legacy tunnel support

Sources11 · facts checked 28 October 2026

Improve this page on GitHub