@node Top
@top TITLE
-This manual is for PROGRAM, version VERSION.
+This manual is for Open vSwitch, version 1.9.
@end ifnottex
@menu
Open vSwitch runs on top of a wide variety of hardware, operating
systems, and hypervisors, and it has been integrated with multiple
-cloud management systems. Please refer to other Open vSwitch and
-vendor documentation for details.
+cloud management systems. Please refer to Open vSwitch and vendor
+documentation for details.
@menu
* Architecture::
@program{ovs-vswitchd} and @program{ovsdb-server}. It is occasionally
useful for special purposes, especially in testing and debugging.
+@node Testing
+@chapter Testing
+
+Testing is essential to writing reliable software, so as network
+operation becomes programmable, testing becomes essential to designing
+a network. This chapter discusses different ways that one can test
+a network containing Open vSwitch elements.
+
+The goal of testing is to model a network setup that one would use in
+production, to allow one to assess important properties of that setup,
+such as its correctness, performance, and scalability. How the model
+is constructed determines which properties can be assessed and how
+accurately. The model also determines properties of the testing
+itself, such as how easy or difficult the testing is to set up, to
+replicate, and to change, how expensive and time-consuming the testing
+is, and how easy or difficult the results are to interpret.
+
+@menu
+* Physical Test Models::
+* Virtual Test Models::
+@end menu
+
+@node Physical Test Models
+@section Physical Test Models
+
+The most obvious way to test Open vSwitch is to use a model that
+replicates the production system, or to use the production system for
+testing. This form of modeling allows accurate performance
+measurements, but in most other respects, it is inconvenient. Setting
+up a new network topology may require physically replugging network
+cables, which is time-consuming and error-prone. Recovering from
+errors in the network programming, which are sure to be encountered
+during testing, may require setting up an extra out-of-band network.
+Finally, running multiple tests in parallel requires replicating the
+entire setup.
+
+Simple setups, such as those that involve only one machine acting as a
+switch, can often be tested satisfactorily as physical models. At
+least one Open vSwitch developer tests his changes this way
+exclusively.
+
+@node Virtual Test Models
+@section Virtual Test Models
+
+Virtualization is one way to ease the inconvenience of testing with a
+physical model, that is, to use virtual machines instead of physical
+ones, and virtual switches instead of physical switches. Because
+virtual machines and virtual switches are easier to reconfigure than
+physical machines and physical switches, this makes running different
+tests easier. Virtual environments also reduce the need for physical
+hardware and at the same time, it is easier to replicate virtual
+environments, so taken together it becomes cheaper to run multiple
+tests in parallel.
+
+A virtual environment doesn't perfectly reproduced the performance of
+the physical environment that it models. A virtual environment
+usually performs slightly worse than the corresponding physical setup,
+so one may assume that, if the performance of the virtual model is
+adequate, then the performance of the corresponding physical setup
+would also be acceptable. (This makes it difficult, of course, to
+have confidence in the physical performance if the virtual environment
+does not perform acceptably.)
+
+One important way that a virtual environment can perform better than a
+physical one is that a virtual network within a single virtual server
+host may outperform a typical physical network. The aggregate
+performance of virtual network connections between collocated VMs, for
+example, can easily exceed 5 Gb/s, whereas the most common physical
+Ethernet connections have a maximum bandwidth of 1 Gb/s. At the same
+time, many implementations of quality-of-service (QoS) features to
+limit bandwidth, including the Linux QoS features that Open vSwitch
+has built-in support for configuring, are designed for physical
+Ethernet connections and do not work well within a virtual server
+host.
+
+Using a virtual model can become more difficult if the network setup
+that one wishes to test uses virtualization itself. Sometimes it is
+possible to ``factor'' the model so that a simple virtualization setup
+still adequately models the physical setup. For example, one might
+decide that how virtual machines are assigned to physical hypervisors
+is not an important characteristic of the physical environment, so
+that one may model these virtual machines of the physical environment
+as virtual machines in the test model, leaving the hypervisors of the
+physical environment out of the model.
+
+In situations where factoring the physical hypervisors out of the test
+model is not acceptable, one may resort to @dfn{nested
+virtualization}, that is, running hypervisors inside hypervisors.
+This decision is not to be made lightly, because nested virtualization
+has disadvantages beyond those of ordinary virtualization. First, not
+all hypervisors support nested virtualization.@footnote{In my
+experience, nested virtualization works best with VMware ESX as the
+outer hypervisor.} Second, nested virtualization compounds
+performance issues. It is much more common to see poor performance
+and timeouts that cannot be reproduced in a corresponding physical
+setup in a virtual environment that includes nested hypervisors.
+
+@node Dummy Test Models
+@section Dummy Test Models
+
+
+
@node outline
* Test setups.
** Physical
** Virtual
+*** start-test-vm
+**** non-persistent
+**** install ethtool, tcpdump, strace, valgrind, hping3, netperf (from non-free)
+**** set up serial port in inittab (just uncomment the T0:... line)
+**** runme, put this in /etc/rc.local and mark it executable:
+**** NFS setup (mount -o ro,udp,timeo=1 10.0.2.2:/home/blp/ovs /mnt)
+#!/bin/sh
+mount -t iso9660 /dev/sr0 /cdrom
+exec sh -x /cdrom/runme
+exit 0
+
** Nested virtual
** Dummy-based.
** test-vm based
+*** not for performance simulation (including QoS)
* Test techniques.
** ofproto/trace
+** netdev-dummy/receive
+** write some tools for arp, ping, more?
* Introduction to OpenFlow.
* Packet processing pipeline.
** The ``normal'' action's pipeline.
+* Examples of proactive programming.
+** Hub (flood)
+** Virtual switch
+** Ingress-only firewall
+* Limitations of proactive programming in OF1.0
+** Can't do MAC learning (solution: NX or reactive programming)
+** Cartesian product is expensive (OF1.1+ or NX or reactive programming)
+* Reactive programming.
+** Slow
+** High latency
+** Handles disconnection badly
+** Hard to scale
+* Hybrid approaches
+** Proactive with a few packets to controller
+** Proactive with local controller
* Management plane.
** Ports and interfaces.
projects / openvswitch / commitdiff