Open vSwitch源码编译安装全攻略：从环境准备到生产实践

1. 为什么要自己编译安装OVS直接装系统自带的不行吗很多朋友第一反应是apt install openvswitch-switch或者yum install openvswitch一条命令就完事了为什么要折腾编译安装这个问题的答案取决于你的使用场景。Open vSwitch后面统称OVS是一款开源的虚拟交换机软件核心价值在于通过软件实现二层交换、VLAN、隧道封装VxLAN/GRE/STT、OpenFlow流表转发等能力在云计算虚拟网络、NFV、容器网络等领域扮演着核心角色。我最早接触OVS是在做基于KVM的云平台网络虚拟化项目当时需要修改OVS源码来定制流表匹配字段发行版仓库里的旧版本根本没办法满足需求只能从源码编译。编译安装的意义不只是“能装上”这么简单。第一你可以获得比发行版仓库更新的特性。比如DPDK版本支持、最新的隧道协议、新的流表匹配字段这些往往只有新版本才有。第二你可以自己打patch、开启或关闭某些编译选项按需裁剪功能。第三生产环境里你还可以通过编译参数做性能调优。如果你只是桌面环境跑个小实验那apt装一个确实够了但如果你想深入OVS内部机制、做二次开发或者部署大规模网络虚拟化环境编译安装基本是必经之路。这里我还要多说一句从源码编译得到的是“最真实”的OVS你在生产环境里排查问题时99%的资料和社区讨论都基于源码编译版本自己动手编译一遍你对OVS目录结构、模块组成、编译产物都会有一个非常直观的认识这个收获是装二进制包永远替代不了的。搞清楚了为什么要自己编译接下来就把整个流程拆开揉碎从环境准备到生产案例一步步讲清楚。文章里的命令行我都是在真实环境验证过的你可以直接照抄但参数要根据你自己的系统情况调整。2. 编译安装前的环境准备依赖、内核与版本匹配2.1 版本选择与内核匹配编译OVS之前第一个要确定的是版本。OVS版本迭代很快各版本对内核、DPDK、Python的依赖要求都不一样。建议到官网的release页面看一眼选择当前阶段的stable版本。同时要注意如果系统内核比较旧OVS新版本的内核模块可能编译不过因为datapath模块要跟着内核的API走内核头文件变了、某个函数签名改了都可能编译失败。我常用的策略是先确认内核版本再反推OVS版本。内核5.4以上的系统选OVS 2.15比较稳内核3.10的老系统比如CentOS 7.x老老实实用OVS 2.11到2.13如果只是用户态使用不加载内核模块比如配合DPDK走userspace datapath那对内核版本的要求就松很多。查内核版本uname -r查gcc版本OVS编译需要c编译器建议gcc 4.9以上gcc --version这里有个细节容易被忽略如果你打算用--with-linux编译内核模块那么系统里必须有完整的内核头文件和构建工具链。Debian/Ubuntu上执行apt install linux-headers-$(uname -r)CentOS/RHEL上执行yum install kernel-devel。没有这些头文件后面的configure检查都能过但make到datapath时你会面对一屏一屏的报错那场面一点都不愉快。2.2 依赖包对照OVS源码编译依赖下面这些组件我在CentOS和Ubuntu两个体系下都列一下方便你对照。Debian/Ubuntu系统apt install -y gcc g make autoconf automake libtool \ libssl-dev python3 python3-pip python3-sphinx \ libcap-ng-dev libnuma-dev libunbound-dev \ graphviz checkCentOS/RHEL系统yum install -y gcc gcc-c make autoconf automake libtool \ openssl-devel python3 python3-pip python3-sphinx \ libcap-ng-devel numactl-devel unbound-devel \ graphviz check如果没有对应软件包编译时configure那一步就会直接提示缺少某某依赖单独装再重跑就行。需要说明的是libcap-ng是OVS运行时的能力管理库libnuma用于NUMA内存分配libunbound用于OVS的DNS解析功能主要是给ovs-vswitchd的控制器连接用的这些在大型部署时最好都装好。还有几个非必须但建议装的组件。graphviz主要用来生成OVS文档里的图表check是单元测试框架如果只是部署不跑测试可以跳过。但libssl-dev/openssl-devel建议一定装有些版本的OVS在configure时会检测openssl缺了它虽然能编译过但后续某些远程连接功能会受限。2.3 准备源码包源码包下载建议直接去官方GitHub仓库拉release tar包不要用git clone master分支。master分支是开发版可能带着未验证的代码做生产环境不太合适。wget https://www.openvswitch.org/releases/openvswitch-2.17.9.tar.gz tar xf openvswitch-2.17.9.tar.gz cd openvswitch-2.17.9如果你要打自己的patch在这一步之后先打patch再编译。打过patch之后别忘了看patch的说明确认它适用于哪个版本区间强行在一个完全不匹配的版本上打patch编译报错了也不要觉得奇怪。3. 完整编译安装流程与关键参数说明3.1 生成configure脚本./boot.shOVS源码包不直接带configure脚本需要先执行./boot.sh来自动生成。它会依次调用autoconf、automake、libtoolize等工具把整个编译体系搭建起来。./boot.sh这一步如果报错基本就是autoconf没装或者版本太老。另外要注意boot.sh只做构建系统初始化不会验证功能依赖真正的依赖检查在configure那步。./boot.sh执行完之后目录里会多出configure脚本和一堆Makefile.in文件。如果之前已经跑过一次boot.sh再跑之前建议先make distclean清理之前的构建产物否则可能出现缓存的Makefile干扰新配置的情况。3.2 重要编译参数configure选项详解接下来是configure这是整个编译过程中最关键的一步参数选择直接决定你装出来的OVS长什么样。./configure --prefix/usr --localstatedir/var --sysconfdir/etc \ --with-linux/lib/modules/$(uname -r)/build逐项说明--prefix/usr安装目录前缀。默认是/usr/local如果你的系统PATH里没有/usr/local/sbin最好指定/usr这样ovs-vswitchd、ovsdb-server等二进制文件直接进/usr/sbin省去配置PATH的麻烦。--localstatedir/var运行时状态目录OVS的数据库文件、运行socket会放在/var/lib/openvswitch和/var/run/openvswitch下面默认是/usr/local/var改成/var更符合绝大多数发行版的习惯。--sysconfdir/etc配置文件目录OVS的配置文件会装到/etc下面。--with-linux/lib/modules/$(uname -r)/build告诉OVS编译内核模块时用当前内核的构建目录。只有你需要Linux内核模块datapath时才需要这个选项。如果你只做DPDK userspace datapath或者纯用户态转发就不需要。其他常用选项--with-dpdk/path/to/dpdk指定DPDK的安装路径启用DPDK支持后用户态数据面走DPDK大页内存和轮询模式性能能好很多。--enable-shared生成共享库如果你要基于OVS做二次开发、写自己的app建议开启。--enable-debug加上调试符号编译时-O2降为-O0方便gdb调试。生产环境别加性能损失明显。--enable-sflow、--enable-netflow开启sFlow和NetFlow采集功能做流量监控的人会用到。这里我要特别提醒一点configure参数不是越多越好。每次加一个--with-xxx就会引入一个依赖而依赖带不来、版本不符都会导致configure失败或运行时异常。我的习惯是先在干净系统上跑一个最小化配置确认能编译通过再加自己需要的特性。这样出问题的时候排查面会小很多。另外有一点很多人不知道configure输出最后会有一个汇总清单列出启用的特性、默认路径、Python版本、内核模块是否启用等。不要只扫一眼就往下走认真读一遍这个汇总很多配置错误其实在这里就已经暴露了。比如你本来想启用DPDK结果summary里显示DPDK not found那就不用等make了直接回头看dpdk路径的问题。3.3 编译与安装configure完成之后就是标准的make和make installmake -j$(nproc) make install-j$(nproc)是并行编译参数$(nproc)会自动取CPU核心数能明显缩短编译时间。如果编译过程中某个文件报错不要慌先看是不是并行编译导致的内存不够内存不够就降低并行度比如改成make -j4。编译过程中可能会看到一些warning只要不是error一般可以先放一放。但有一种warning要特别留意如果编datapath内核模块时报出“function declared static but never defined”或者“incompatible pointer type”这往往意味着内核头文件版本和OVS预期的不一致即使编译过了后续模块加载也可能出问题。编译完会生成几个重要的东西内核模块datapath/linux/openvswitch.ko用户态二进制vswitchd/ovs-vswitchd、ovsdb/ovsdb-server控制工具utilities/ovs-vsctl、utilities/ovs-ofctl、utilities/ovsdb-tool数据库ovsdb/ovsdb-tool安装后再确认一下二进制和模块是否存在ls -l /usr/sbin/ovs-vswitchd /usr/sbin/ovsdb-server ls -l /usr/sbin/ovs-vsctl /usr/sbin/ovs-ofctl /usr/sbin/ovsdb-tool modinfo openvswitch 2/dev/null || echo module not installed yetmodinfo openvswitch这条命令很关键。如果显示模块不存在说明make install没有把内核模块装到指定目录就要走手动拷贝流程了。3.4 加载内核模块与启动服务如果你编译时指定了--with-linuxmake install会自动把openvswitch.ko拷贝到内核模块目录。安装完先加载模块modprobe openvswitch如果没有自动拷贝需要手动拷贝cp datapath/linux/openvswitch.ko /lib/modules/$(uname -r)/kernel/net/openvswitch/ depmod -a modprobe openvswitch加载成功后用lsmod | grep openvswitch看看。然后是初始化OVS数据库和启动服务。新的OVS版本推荐用ovsdb-tool创建数据库文件mkdir -p /var/lib/openvswitch ovsdb-tool create /var/lib/openvswitch/conf.db /etc/openvswitch/vswitch.ovsschema这里的vswitch.ovsschema是编译时自动生成的schema文件路径一般在/etc/openvswitch/或/usr/share/openvswitch/。如果创建时报找不到文件用find / -name vswitch.ovsschema找一下。创建完数据库后先启动ovsdb-server再启动ovs-vswitchdovsdb-server /var/lib/openvswitch/conf.db \ --remotepunix:/var/run/openvswitch/db.sock \ --remotedb:Open_vSwitch,Open_vSwitch,manager_options \ --pidfile --detach ovs-vswitchd --pidfile --detach这里我再展开说一下启动参数的细节。--remotepunix:/var/run/openvswitch/db.sock是给本地ovs-vsctl和ovs-ofctl用来连接数据库的unix socket这个路径后面所有工具都会用到如果改位置后续所有命令都要跟着改。--remotedb:Open_vSwitch,Open_vSwitch,manager_options是从数据库里的manager_options表读取远程管理器配置也就是允许通过数据库动态添加OVSDB管理连接。--pidfile把进程PID写到默认位置这样后面kill进程不用自己再ps去查很方便。--detach让进程后台运行不加的话两个进程会一直占着终端。验证服务状态ovs-vsctl show这条命令会通过db.sock连接本地OVS数据库输出当前网桥列表等信息。如果能正常输出版本和网桥列表说明编译安装成功。如果用的是systemd系统也可以直接使用OVS源码里的rpm或deb打包脚本生成service但手动方式更直观也方便排查问题。4. 安装后先做这几件基础配置再开始玩安装完成后先做三个基础配置能少踩很多坑。4.1 让OVS服务开机自启编译安装方式没有systemd unit文件你需要自己写一个或者用rc.local。我个人推荐写systemd unit更规范。以/etc/systemd/system/ovs.service为例[Unit] DescriptionOpen vSwitch Afternetwork.target [Service] Typeoneshot RemainAfterExityes ExecStart/usr/sbin/ovsdb-server /var/lib/openvswitch/conf.db --remotepunix:/var/run/openvswitch/db.sock --remotedb:Open_vSwitch,Open_vSwitch,manager_options --pidfile --detach ExecStartPost/usr/sbin/ovs-vswitchd --pidfile --detach ExecStop/usr/bin/kill $(cat /var/run/openvswitch/ovs-vswitchd.pid) ExecStopPost/usr/bin/kill $(cat /var/run/openvswitch/ovsdb-server.pid) [Install] WantedBymulti-user.target然后systemctl daemon-reload systemctl enable ovs systemctl start ovs要注意ovsdb-server和ovs-vswitchd的pid文件位置就是你配置里的--pidfile参数决定的。如果你没指定--pidfile那上面的cat路径就要相应修改。这里有一个systemd写unit文件时容易踩的坑ExecStop里用cat $(cat file)这个写法systemd的ExecStart和ExecStop默认不会走shell如果pid文件里有换行符命令会执行失败。更稳妥的写法是用/bin/sh -c kill $(cat /var/run/openvswitch/ovs-vswitchd.pid)或者让ExecStop只调用/usr/bin/killall ovs-vswitchd这种简单命令。4.2 配置OVS目录权限有时提示“could not create /var/run/openvswitch”是因为Open vSwitch需要写/var/run/openvswitch和/var/lib/openvswitch这两个目录。启动前手动创建并授权mkdir -p /var/run/openvswitch /var/lib/openvswitch /etc/openvswitch chmod 755 /var/run/openvswitch要养成一个习惯编译安装的OVS在启动服务之前先确认这两个目录存在。很多新手启动失败最后发现就是少了目录。还有一个容易被忽视的小问题/var/run在某些系统上是个tmpfs重启后内容会清空。也就是说你每次重启机器之后/var/run/openvswitch目录可能不存在了。如果systemd unit里没有自动创建目录服务就会启动失败。我建议在ExecStartPre里加上mkdir -p /var/run/openvswitchExecStartPre/bin/mkdir -p /var/run/openvswitch这样无论重启多少次目录都不需要手动管。4.3 创建第一个网桥做冒烟测试基础配置做完建议先创建第一个网桥验证可用性ovs-vsctl add-br br0 ovs-vsctl show ovs-vsctl add-port br0 eth0 ovs-vsctl list-ports br0第二条命令应该能看到br0第三条是把物理网卡eth0接入网桥。注意这里把eth0接入br0后eth0原有的IP会失效你需要把IP配置到br0上否则网络会断。这个和Linux bridge的行为一样是新手最容易踩的坑。具体来说原先是eth0上配了192.168.1.10/24接入br0之后你要把IP从eth0挪到br0上ip addr del 192.168.1.10/24 dev eth0 ip addr add 192.168.1.10/24 dev br0 ip link set br0 up如果在远程操作这条命令执行完你的SSH会话可能瞬间断开因为IP从物理网卡挪到网桥时会出现短暂的网络中断。建议这种操作在带外管理通道比如IPMI、KVM或后台任务里执行避免把自己锁在外面。如果只是做网桥实验这步可以先不加物理网卡纯创建一个OVS内部接口体验一下也行ovs-vsctl add-br br0 ovs-vsctl add-port br0 dummy0 -- set Interface dummy0 typeinternal ip addr add 192.168.100.1/24 dev dummy0 ip link set dummy0 up纯内部接口的好处是没有物理网卡风险适合练手。5. 实际案例三个贴近生产场景的部署建议编译安装只是开始真正的挑战来自使用场景。下面分享三个我实际在项目中做过、验证过的案例部署建议难度从低到高也是OVS最核心的三种用法作为虚拟化网络集成、作为隧道网关、作为高性能数据面。5.1 案例一OVS接入KVM/QEMU替代Linux Bridge场景描述你有一台物理服务器上面跑了多台KVM虚拟机想用OVS做虚拟交换把虚拟机的虚拟网卡统一接入到一个虚拟交换机中同时支持VLAN隔离、流表控制等高级功能。在这种场景下OVS扮演的是传统物理交换机的角色虚拟机就是接入到交换机端口的“终端”。和Linux Bridge相比OVS的优势在于支持OpenFlow流表转发、支持VLAN灵活配置、支持远端控制器集中管理在云计算虚拟网络场景下你可以用流表下发规则控制流量走向。操作步骤大致如下创建网桥ovs-vsctl add-br ovsbr0在libvirt中配置虚拟机的网络使用OVS类型的接口。编辑虚拟机XML在interface片段中这样写interface typebridge source bridgeovsbr0/ virtualport typeopenvswitch/ model typevirtio/ /interface在宿主机上查看有没有虚拟端口自动添加到网桥ovs-vsctl list-ports ovsbr0正常情况下会把每台虚拟机的虚拟网卡比如vnet0、vnet1加入网桥。此时虚拟机之间的二层互通就打通了。如果需要VLAN隔离就在OVS上给每个端口设置VLAN tagovs-vsctl set port vnet0 tag100 ovs-vsctl set port vnet1 tag200这样vnet0的流量带VLAN 100vnet1的流量带VLAN 200两者之间就实现了二层隔离物理交换机的trunk口上也能看到对应的VLAN标记。这个场景最容易遇到的坑是libvirt的typebridge需要确保libvirt有openvswitch的支持参数virtualport typeopenvswitch老的libvirt版本可能不支持这个配置需升级libvirt或用typeethernet配合managed手动接入。再说一个细节现在很多云平台都会建议给OVS网桥配置fail-mode防止OVS服务挂了之后所有流量直接断掉。你可以在创建网桥时设置ovs-vsctl set-fail-mode ovsbr0 standalonestandalone模式表示OVS在没有控制器的情况下仍然会走正常的MAC学习转发逻辑类似普通交换机。如果是secure模式没有控制器时所有流量都会被丢弃。生产环境里如果你依赖远端控制器统一下发流表那可以考虑secure但如果没有控制器一定要用standalone否则一重启OVS流量就全断了这个坑我印象太深了。还有性能相关的一个小建议在虚拟机场景下虚拟网卡的model建议统一用virtio不要用e1000或rtl8139。virtio是在半虚拟化模式下与宿主机OVS交互报文可以直接从virtqueue进入OVS数据路径性能好一个量级。另外给网桥开启rstp或者其它环路保护机制之前确认你的交换机支持对应的协议否则可能出现环路广播风暴。5.2 案例二OVS构建VxLAN隧道打通跨节点二层网络场景描述你有两台物理服务器分别叫host1和host2每台上面都有多台虚拟机希望让两台物理服务器上的虚拟机像在同一个局域网一样互通也就是实现跨节点的二层网络大二层。这里OVS的VxLAN隧道就派上用场了。VxLAN是基于UDP的隧道协议标准端口4789外层是UDP/IP封装内层是以太网帧。OVS天然支持VxLAN你只需要在网桥上创建VxLAN类型的端口作为隧道端点两边一对接二层就通了。在host1上的操作# 创建网桥 ovs-vsctl add-br vxlan-br # 加入物理网卡用于承载隧道外层流量 ovs-vsctl add-port vxlan-br eth0 # 创建VxLAN隧道端口remote_ip指向对端 ovs-vsctl add-port vxlan-br vxlan0 -- set interface vxlan0 typevxlan options:remote_ip192.168.1.2 options:key100在host2上的操作是对称的ovs-vsctl add-br vxlan-br ovs-vsctl add-port vxlan-br eth0 ovs-vsctl add-port vxlan-br vxlan1 -- set interface vxlan1 typevxlan options:remote_ip192.168.1.1 options:key100这里的options:key100是VNIVXLAN Network Identifier两边的VNI要一致才能互相识别隧道。如果你不需要VXLAN封装后面的VLAN把key写成流表可以match的任意数字保证两边一致即可。为了验证隧道是否打通可以在host1上创建一对veth设备一端插到vxlan-br里另一端设置IP然后从host1 ping host2上同样插到vxlan-br的接口IP。具体这样操作# host1 ip link add veth0 type veth peer name veth1 ip link set veth0 up ovs-vsctl add-port vxlan-br veth0 ip addr add 10.10.10.1/24 dev veth1 ip link set veth1 up# host2 ip link add veth0 type veth peer name veth1 ip link set veth0 up ovs-vsctl add-port vxlan-br veth0 ip addr add 10.10.10.2/24 dev veth1 ip link set veth1 up然后从host1上ping 10.10.10.2能通就说明隧道打通了。VxLAN场景的坑主要在MTU。VxLAN封装会额外增加50字节左右的包头外层IPUDP8字节VxLAN头原来物理网卡的MTU是1500封装后有效载荷只有1450左右。如果你不改MTU大包就会在中间被丢弃表现是“小包能通、大包不通”。解决办法有两种一是把物理网卡的MTU调到1600或更高让封装后的大包有空间二是把虚拟机网卡的MTU调成1450。云厂商的VPC里普遍用的是第二种方案。我再补充一个容易被忽略的排查点如果隧道不通先检查两台宿主机之间UDP 4789端口是否被防火墙拦截。VxLAN使用UDP 4789作为默认目的端口某些安全组或iptables规则会放行TCP和ICMP却把UDP大包拦了。用tcpdump -ni eth0 udp port 4789在两台主机上同时抓包能看到封装后的UDP包在发但收不到基本就是防火墙或路由的问题。关于VNI和VLAN的关系也要理清楚。VNI是VxLAN的二层隔离标识类似传统网络里的VLAN ID但范围更大24位。而OVS里VxLAN端口还可以通过options:keyflow的方式从流表动态匹配key这样单个网桥上就可以承载成千上万个不同VNI的隧道容器网络方案比如Kubernetes的OVN-Kubernetes就是靠这个能力做多租户隔离的。5.3 案例三OVS-DPDK让数据面跑在用户态性能飙升场景描述你发现默认的OVS内核态datapath转发性能不够好尤其是在小包场景下频繁的内核态与用户态切换、软中断处理导致转发吞吐上不去。你想把它改造成基于DPDK的高性能数据面。OVS-DPDK的原理其实不算复杂传统OVS的转发路径是收包到内核协议栈再到openvswitch内核模块根据流表转发而OVS-DPDK通过DPDK的userspace驱动直接接管网卡收包不再经过内核直接在用户态用大页内存做轮询模式收包然后通过OVS的userspace datapath完成流表匹配和转发。少了内核中断和系统调用小包转发性能提升非常明显。编译步骤比普通OVS多一步先编译安装DPDK。DPDK版本要跟OVS要求的版本匹配OVS源码里的Documentation/intro/install/dpdk.rst有明确的版本对应表编译前一定要看。以OVS 2.17为例建议DPDK 21.11以上。DPDK编译大致是这样wget https://fast.dpdk.org/rel/dpdk-21.11.tar.xz tar xf dpdk-21.11.tar.xz cd dpdk-21.11 meson build ninja -C build ninja -C build install ldconfig然后重新编译OVSconfigure时加上DPDK路径cd openvswitch-2.17.9 ./configure --prefix/usr --localstatedir/var --sysconfdir/etc \ --with-dpdk/usr/local/share/dpdk make -j$(nproc) make install这里的--with-dpdk参数指向DPDK的share目录OVS会自动找libdpdk.a等库文件。启动时给ovs-vswitchd加上DPDK参数通常是修改启动脚本或systemd unit加上--dpdk -l 0-3 -n 4 --socket-mem 1024参数含义-l绑定CPU逻辑核-n指定内存通道数--socket-mem指定每个NUMA节点的大页内存大小单位MB。数值都要根据你的服务器配置来。同时需要预留大页内存echo 1024 /proc/sys/vm/nr_hugepages mkdir -p /mnt/huge mount -t hugetlbfs hugetlbfs /mnt/huge这样配置完后OVS的ovs-vswitchd进程就在用户态通过DPDK收发报文流表转发也不经过内核。我实测过在同样的物理机上跑64字节小包转发OVS-DPDK相比内核态datapath吞吐能翻几倍CPU占用还更低。代价是部署复杂度明显上升、网卡需要DPDK驱动支持Mellanox、Intel大部分网卡都支持、CPU核被独占需要专门规划。这里我要讲一下大页内存的分配逻辑很多人在这里迷糊。DPDK的收发包内存必须从hugepage上分配因为普通内存的页表是4KBDPDK为了减少TLB miss需要2MB甚至1GB的大页。echo 1024 /proc/sys/vm/nr_hugepages是临时分配1024个2MB的hugepage总共2GB。如果系统内存不够或者/sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages这个路径写入失败说明内核限制或权限问题要检查/etc/sysctl.conf里的vm.nr_hugepages。如果不希望重启后大页配置丢失在/etc/sysctl.conf里加一行vm.nr_hugepages1024然后sysctl -p生效。OVS-DPDK调试时有个比较隐蔽的问题如果你在配置里指定了--dpdk参数但网卡驱动没有绑定到DPDK支持的userspace驱动比如vfio-pci启动时可能是好的但收不到包。解决办法是通过dpdk-devbind.py绑定网卡dpdk-devbind.py -b vfio-pci 0000:01:00.0如果你的网卡不支持vfio-pci也可以走uio_pci_generic但vfio-pci更安全、功能更完整建议优先用vfio-pci。前提是BIOS和内核都开启了IOMMUVT-d或AMD-Vi没开的话vfio-pci绑定会失败。在绑卡之前先看当前网卡在哪个PCI地址dpdk-devbind.py --status这个命令会列出所有网卡的PCI地址、驱动和NUMA节点信息选好要绑的网卡后执行绑定。绑定后该网卡上的IP等配置会全部消失因为它已经从内核协议栈脱离这一点在远程操作时同样要小心先确保有带外通道或用另一块网卡管理。OVS-DPDK跑起来的另一个特征是网桥端口不再是物理网卡名而是DPDK设备名比如dpdk0、dpdk1。你用ovs-vsctl add-port br0 dpdk0 -- set Interface dpdk0 typedpdk把DPDK端口加进网桥时网卡必须已经被DPDK接管。如果ovs-vsctl报Interface dpdk0 type dpdk is not supported先回configure的summary确认--with-dpdk有没有生效。6. 编译安装和日常使用中的常见问题与排查技巧编译安装看起来步骤不复杂但真到了生产环境各种奇葩问题层出不穷。我把这些年踩过的坑汇总成一张速查表遇到问题直接对着查。6.1 编译阶段常见问题现象原因解决方案./boot.sh报command not foundautoconf、automake没装安装autoconf automake libtoolconfigure报checking for Python... nopython3缺失或版本太老安装python3确保python3 --version正常make时报error: implicit declaration of function内核头文件与OVS不匹配检查内核版本换对应OVS版本make复制内核模块时权限不足当前用户无写/lib/modules权限使用root执行make install或修改目录权限modprobe openvswitch提示模块不存在openvswitch.ko没装到内核模块目录手动cp后再depmod -aconfigure在检查DPDK时失败DPDK版本与OVS要求不匹配核对Documentation里的版本对应表重新装DPDK这里特别强调权限问题。我在测试机上图省事用普通用户执行了make install结果内核模块没拷贝成功单独查modinfo openvswitch一直报not found后来才发现是权限问题。生产环境里建议编译安装这一步直接切root用户操作或者用sudo避免内核模块拷贝失败这个隐蔽问题。另外一个编译阶段的隐藏问题是磁盘空间。OVS编译过程中中间产物加安装后的文件总共可能占用1到2GB空间。在df -h /看一下剩余空间如果小于1GB建议先清理一下否则make到一半报磁盘满前面的编译全白费。6.2 运行时常见问题现象原因解决方案ovs-vsctl show卡住或报cannot connectovsdb-server没启动或db.sock路径不对确认/var/run/openvswitch/db.sock存在不存在就重新启动ovsdb-serverovs-vswitchd启动后立即退出数据库损坏或端口被占用检查journalctl -u ovs日志或删除conf.db重新创建创建网桥成功但流量不通可能是网桥的fail-mode不对、物理网卡配置错误、或MTU问题先检查ovs-ofctl show br0查看流表再逐层ping排查收不到VxLAN报文VTEP地址不对、UDP端口被过滤、VNI不匹配用tcpdump抓4789端口检查options:remote_ip和key修改流表不生效流表优先级配置有误用ovs-ofctl dump-flows br0查看流表检查优先级和匹配字段ovs-vswitchd启动日志报reallocated频繁流表数量过大或配置不合理评估流表表项数考虑加大--max-idle或优化flow表结构运行时的排查思路我的经验是“进程到表再到链路”三段式。先用ps aux | grep ovs看进程在不在然后用ovs-vsctl show看网桥端口状态再用ovs-ofctl dump-flows br0看流表规则最后才看物理链路和底层网络。大部分人一上来就想ping结果ping不通来回折腾了半天其实网桥上的流表已经被清了问题就在OVS自身状态上。6.3 一个真实的排障案例有一次客户环境里OVS网桥上的虚拟机突然全部对外失联机器本身活着OVS进程也在。我登上去看到ovs-vsctl show还能正常返回网桥信息说明ovsdb-server和ovs-vswitchd都活着问题一定出在转发路径。再用ovs-ofctl dump-flows br0一看流表全是空的正常状态应该有很多normal流表项。然后我就想到前面说的fail-mode问题客户创建网桥用的是默认模式在OVS重启而没有控制器连接的情况下流表被清空、进入丢弃所有包的状态。解决方案就是用ovs-vsctl set-fail-mode br0 standalone把模式改成即使没有控制器也允许MAC学习转发。改完后流表恢复、网络恢复。这个案例说明OVS这种软件交换机故障排查一定要从头到尾走一遍“链路排查法”。先确认进程再看端口再看流表再看物理链路一层一层来不要一上来就怀疑底层网络。很多时候问题都出在OVS自身的状态配置上。再补充说一个和这个案例很像的情形ovs-vswitchd更新或升级后旧网桥还在但流表空了。这是因为升级后ovs-vswitchd会重新连接数据库如果fail-mode是默认的secure在控制器连上之前流表是空的所有数据包都会被丢弃。解决办法同样是设为standalone或者确保控制器能自动重连。6.4 关于升级OVS要注意的事最后说一下升级。如果你是编译安装的旧版本想升级到新版本最省事的方式是在新版本源码包里重新走一遍编译安装流程但要注意先备份数据库cp /var/lib/openvswitch/conf.db /var/lib/openvswitch/conf.db.bak停止服务kill $(cat /var/run/openvswitch/ovs-vswitchd.pid)和kill $(cat /var/run/openvswitch/ovsdb-server.pid)编译安装新版本启动时如果提示数据库schema版本太旧OVS会自动做schema迁移但保险起见先备份升级后在ovs-vsctl show里确认版本号和schema版本。实测下来OVS的schema迁移都比较成熟大部分场景下数据库可以直接复用。但生产环境一定不要跳过备份万一迁移失败导致数据库损坏你再回滚就麻烦了。再提醒一个升级时的坑如果你原来是带着--with-dpdk编译的升级时configure里忘了加DPDK参数新版ovs-vswitchd启动时会发现数据库里有的端口是dpdk类型但自己又不支持轻则报warning重则直接退出。所以升级前一定要把旧版的configure参数记下来config.log里能看到全部信息或者用./configure --help逐项核对。7. 编译安装后的一些个人经验和建议做了这么多年的网络虚拟化和OVS相关项目编译安装这个动作本身其实只占整个工作量的很小一部分真正费心思的是编译参数的选择、版本匹配、以及安装后的调优。我自己每次编译OVS之前都会建立一个简单的checklist确认内核版本、确认依赖、选择OVS版本、按需配置启用功能、编译、安装、冒烟测试。走完这套流程基本上不会出大问题。再说一个很少有人提但很实用的点编译之前最好准备一个干净的系统环境或者干净的容器镜像不要在已经装了乱七八糟东西的环境里编译。OVS编译过程对autoconf、automake等构建工具的版本很敏感环境里如果有其他项目装的旧版本autoconf很容易导致boot.sh或configure报出莫名其妙的错误。我在一次性容器里编译OVS整个流程二十分钟就能走完比在宿主环境里一次次排错省心太多了。另外如果你后续要做OVS二次开发建议编译时加上--enable-debug并安装对应的开发包。虽然性能会差一些但用gdb调试流表下发、调试ovs-vswitchd内部逻辑时带调试符号的二进制会帮你省大量时间。调试完再重新编译一个release版本上线。最后再分享一个小技巧源码包解压后不要直接就地编译可以先在虚拟机里编译一遍确认步骤没问题再到生产机器上走流程。尤其是你带着自己打的patch做批量部署时这一步能有效减少因为环境差异导致的意外。OVS编译安装这件事说难不难说简单也不简单但只要你把版本对应关系、依赖清单、编译参数这三点吃透剩下的就是机械执行而已。我在实际项目里还有一个习惯每次编译完都会把configure的完整命令行、依赖版本、内核版本、编译日期记录下来写在一个README文件里和源码包放在一起。半年后要升级或复现环境时这个README就是最好的参考文档比翻聊天记录和邮件快得多。这个习惯帮我省了不少事也推荐你用起来。