From: Ben Pfaff Date: Fri, 28 Dec 2012 19:01:41 +0000 (-0800) Subject: work on testing docs X-Git-Url: https://pintos-os.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=cd3074b5d59ebbe2f92fbdbd6ace2511aa68917c;p=openvswitch work on testing docs --- diff --git a/doc/manual.texi b/doc/manual.texi index 969d4dd9..a303efef 100644 --- a/doc/manual.texi +++ b/doc/manual.texi @@ -38,7 +38,7 @@ permissions and limitations under the License. @node Top @top TITLE -This manual is for PROGRAM, version VERSION. +This manual is for Open vSwitch, version 1.9. @end ifnottex @menu @@ -72,8 +72,8 @@ software. 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:: @@ -127,21 +127,152 @@ will often use it in examples in this book. @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.