Why Open vSwitch?
=================
-We love the existing network stack in Linux. It is robust, flexible,
-and feature rich. Linux already contains an in-kernel L2 switch (the
-Linux bridge) which can be used by VMs for inter-VM communication. So,
-it is reasonable to ask why there is a need for a new network switch.
+Hypervisors need the ability to bridge traffic between VMs and with the
+outside world. On Linux-based hypervisors, this used to mean using the
+built-in L2 switch (the Linux bridge), which is fast and reliable. So,
+it is reasonable to ask why Open vSwitch is used.
The answer is that Open vSwitch is targeted at multi-server
-virtualization deployments, a landscape for which the existing stack is
+virtualization deployments, a landscape for which the previous stack is
not well suited. These environments are often characterized by highly
dynamic end-points, the maintenance of logical abstractions, and
(sometimes) integration with or offloading to special purpose switching
migratable between different hosts. This may include traditional
"soft state" (such as an entry in an L2 learning table), L3 forwarding
state, policy routing state, ACLs, QoS policy, monitoring
- configuration (e.g. NetFlow, sFlow), etc.
+ configuration (e.g. NetFlow, IPFIX, sFlow), etc.
Open vSwitch has support for both configuring and migrating both slow
(configuration) and fast network state between instances. For
environments, and so forth.
Open vSwitch supports a number of features that allow a network
- control system to respond and adapt as the environment changes. This
- includes simple accounting and visibility support such as NetFlow and
- sFlow. But perhaps more useful, Open vSwitch supports a network state
- database (OVSDB) that supports remote triggers. Therefore, a piece of
- orchestration software can "watch" various aspects of the network and
- respond if/when they change. This is used heavily today, for example,
- to respond to and track VM migrations.
+ control system to respond and adapt as the environment changes.
+ This includes simple accounting and visibility support such as
+ NetFlow, IPFIX, and sFlow. But perhaps more useful, Open vSwitch
+ supports a network state database (OVSDB) that supports remote
+ triggers. Therefore, a piece of orchestration software can "watch"
+ various aspects of the network and respond if/when they change.
+ This is used heavily today, for example, to respond to and track VM
+ migrations.
Open vSwitch also supports OpenFlow as a method of exporting remote
access to control traffic. There are a number of uses for this
There are many ongoing efforts to port Open vSwitch to hardware
chipsets. These include multiple merchant silicon chipsets (Broadcom
- and Marvell), as well as a number of vendor-specific platforms.
+ and Marvell), as well as a number of vendor-specific platforms. (The
+ PORTING file discusses how one would go about making such a port.)
The advantage of hardware integration is not only performance within
virtualized environments. If physical switches also expose the Open
network control.
In many ways, Open vSwitch targets a different point in the design space
-than the existing Linux networking stack, focusing on the need for
+than previous hypervisor networking stacks, focusing on the need for
automated and dynamic network control in large-scale Linux-based
virtualization environments.
The goal with Open vSwitch is to keep the in-kernel code as small as
possible (as is necessary for performance) and to re-use existing
subsystems when applicable (for example Open vSwitch uses the existing
-QoS stack). Open vSwitch limits disruption by using existing hooks into
-the kernel, so Open vSwitch can be deployed as a module without
-requiring any modification to the kernel.
+QoS stack). As of Linux 3.3, Open vSwitch is included as a part of the
+kernel and packaging for the userspace utilities are available on most
+popular distributions.
git://git.onelab.eu / sliver-openvswitch.git / blobdiff