OpenStack PortBindingFailed排查：Provider Network实例创建失败全解析

只要手动搭过 OpenStack多少都见过这个画面明明 provider network 创建成功subnet 也都是 ACTIVE结果 openstack server create 一执行实例状态直接变成 ERRORfault 里写着 PortBindingFailed: Binding failed for port…。第一次遇到这个报错的人十有八九是懵的因为从网络侧看好像什么都不缺但虚拟机就是起不来。这篇文章就专门拆解这个坑。我会把我在实验环境里排查 PortBindingFailed 的思路、命令和修复过程完整写出来包括这个报错到底出在哪一层、为什么 provider network 特别容易触发、以及改完配置之后怎么验证。无论你是自己搭 all-in-one 环境还是在多节点环境里做网络配置按这条链路走一遍基本都能定位问题。1. 报错现场还原什么样子的配置组合会触发 PortBindingFailed1.1 一套典型到不能再典型的 flat 网络配置先说我在环境里复现时的操作。假设控制节点和计算节点在一台设备上物理网卡是 eth1准备做一个 flat 类型的 provider network让虚拟机直接接入物理二层网络。创建网络和子网的命令大概长这样openstack network create \ --provider-network-type flat \ --provider-physical-network physnet1 \ --external \ --share provider_net openstack subnet create \ --network provider_net \ --subnet-range 10.10.200.0/24 \ --allocation-pool start10.10.200.100,end10.10.200.200 \ --gateway 10.10.200.1 \ provider_subnet接着用最小规格的镜像创建实例openstack server create \ --image cirros \ --flavor m1.tiny \ --nic net-idprovider_net \ --availability-zone nova:compute-1 \ demo-instance这里指定--availability-zone是为了把实例固定在某个计算节点上复现问题。如果不指定调度器可能会把实例分到其他节点排查时反而要花时间确认到底落在哪台机器上。执行完命令之后等十几秒再用openstack server show demo-instance查看发现 status 是 ERRORfault 字段里出现了本文标题里的那个报错。1.2 报错的实际形态和容易混淆的兄弟报错PortBindingFailed 这个错误会在不同地方出现最常见的两个位置是 openstack server show 的 fault 字段以及 nova-compute 日志里。日志中类似nova.compute.manager ... PortBindingFailed: Binding failed for port 6f8a...这个报错经常被和另外两个问题搞混我提一下方便区分。一个是NoValidHost这是调度阶段找不到合适主机另一个是 libvirt 启动时报internal error这已经是 qemu 层面的问题和端口绑定无关。PortBindingFailed 的关键特征在于实例已经完成了调度也已经分配到了计算节点但是在真正启动虚拟机之前nova 向 neutron 请求的虚拟端口没能成功绑定到宿主机的网络设施上。1.3 先理解这个错到底发生在哪一层很多人一看到 PortBindingFailed 就想去 neutron 那边找原因方向是对的但容易忽略一点端口绑定动作的实际执行者不是 neutron-server而是各计算节点上的 neutron agent。nova 负责把实例调度到某台计算节点然后告诉 neutron我要在这台机器上用这个网络neutron 收到请求后让对应节点上的 agent 去做物理层面的绑定。所以这个报错的核心矛盾通常集中在三个方面创建网络时声明的物理网络名称和 agent 配置里的映射名是否一致、agent 本身是否在线且配置正确、以及计算节点上是否真的存在可用的物理网桥或物理网卡。后面我会逐个展开。2. PortBinding 到底在绑什么nova、neutron 与 agent 的一次接力2.1 一次实例创建过程中的端口接力要理解为什么一个小小的端口绑定失败能把整个实例卡死得先看清楚一条虚拟网线是怎么从 neutron 数据库一路插到物理网卡上的。整个链条是这样走的nova 在决定启动实例之后会先为每个网卡调用一次 neutron 的 create port 操作。neutron-server 接收到请求先由 ML2 plugin 判断这个网络属于什么类型比如 flat、vlan 还是 vxlan然后看它挂在哪个 mechanism driver 下。如果部署用的是 linuxbridge 或 openvswitchplugin 就会请求对应计算节点上的 agent 去执行绑定。agent 在宿主机上会完成一系列操作比如创建 linux bridge或者向 OVS 网桥添加端口把虚拟机的虚拟网卡和物理网卡桥接起来。绑定成功之后agent 把结果回报给 neutron-server端口状态才会变成 ACTIVE。只有等这一步完成nova 才敢调用 libvirt 去真正启动虚拟机。整个过程中nova 并不会一直无限期等待。如果 agent 在规定时间内没有完成绑定或者直接返回了失败状态nova 就把实例标记为 ERROR抛出的就是这个 PortBindingFailed。2.2 谁在负责绑定linuxbridge 与 ovs 的差异同样叫 PortBinding底层机制其实不一样。linuxbridge agent 的工作方式是创建一个 brq 开头的 linux bridge把物理网卡和虚拟机的 tap 设备都加进去。ovs agent 则是通过 openvswitch 网桥实现常见做法是把物理网卡加进 br-ex 网桥再把虚拟机的虚拟网卡通过 internal port 或 patch port 接进来。这两种机制在 provider network 场景下有个共同点计算节点必须有一条真实的物理链路连接到目标二层网络中。区别只在于桥接工具不同一个用的是内核自带的 bridge 模块一个用的是 ovs 的 datapath。2.3 为什么 provider network 的坑比 tenant network 多这个问题我思考过很久最后发现根本原因在于物理依赖。租户网络如果是 vxlanagent 创建的是隧道接口对物理网卡的映射要求没那么敏感只要网络上能通就行。但 provider network 是直接把虚拟机和外部物理网络放在同一个二层域里计算节点必须真实接入这个二层域靠的就是物理网卡或者桥接到物理网卡的网桥。这导致一个结果所有计算节点的 agent 配置必须统一正确只要有一台机器的物理接口映射写错调度器一旦选中它就必然出现 PortBindingFailed。所以排查这类问题时不要只看网络本身要优先检查宿主机的 agent 配置和实际网桥状态。3. 几个最容易踩中的根因映射错位、agent 失联与 vnic_type 不匹配3.1 physical_network 名字对不上最隐蔽的低级错误在所有 PortBindingFailed 案例里我见到最多的是名字对不上。创建网络时指定了--provider-physical-network physnet1但 agent 配置里写的映射名可能叫 provider或者反过来。这个字段的作用就是让 neutron 知道这个 external network 应该落在宿主机的哪条链路上。linuxbridge agent 的配置在 /etc/neutron/plugins/ml2/linuxbridge_agent.ini[linux_bridge] physical_interface_mappings physnet1:eth1ovs agent 的配置在 /etc/neutron/plugins/ml2/openvswitch_agent.ini[ovs] bridge_mappings physnet1:br-ex创建网络时写的值、agent 配置里冒号前面的 key、以及实际物理网卡或网桥三者的对应关系必须一致。我整理成一张表方便对照位置参数示例值说明网络创建命令--provider-physical-networkphysnet1管理员自己定义的名字linuxbridge agentphysical_interface_mappingsphysnet1:eth1key 必须等于物理网络名OVS agentbridge_mappingsphysnet1:br-exkey 必须等于物理网络名宿主机网桥br-ex包含 eth1OVS 场景的硬性要求如果你在 OVS 场景下把bridge_mappings physnet1:br-ex配好了但宿主机上根本没有 br-ex让虚拟机插队的面板不存在绑定自然失败。这时候需要在每台计算节点上创建网桥并添加物理网卡ovs-vsctl add-br br-ex ovs-vsctl add-port br-ex eth1 ip link set br-ex up这是很多教程里一笔带过、但实际部署时最容易漏掉的关键步骤。3.2 agent 状态异常或配置不完整第二个高发原因是 agent 本身出了问题。这里要说明的是ML2 的 mechanism driver 配置必须和实际运行的 agent 匹配。假如 ml2_conf.ini 里写的是 linuxbridge但计算节点上起的是 openvswitch agent绑定就会失败因为 neutron-server 在等待一个不存在的 agent 回报。先看 agent 在线状态openstack network agent list输出里每一行代表一个 agent重点关注 Alive 和 State 两列。如果某个 agent 显示 dead或者 host 对应的 agent 没有出现在列表里那基本可以确定问题出在这里。修完 agent 配置后重启服务再等几秒钟心跳上报然后重新查看列表。另一个特别容易被忽略的情况是配置文件改了但 agent 没有重启。linuxbridge agent 和 ovs agent 都不会动态加载配置文件修改之后必须 systemctl restart这是我在实际环境里替别人擦过无数次屁股的坑。3.3 vnic_type 与底层能力不匹配还有一种场景端口本身要求了某种虚拟网卡类型但底层物理设施根本不支持。比如手动创建端口时用了 --vnic-type direct这通常意味着要求 SR-IOV 直通如果物理网卡和宿主机的 SR-IOV 配置没跟上agent 根本无从下手只会返回 binding 失败。排查时用端口 id 查看openstack port show port_id -c vnic_type -c binding:vif_type正常情况下普通虚拟机使用 vnic_typenormal 或者不指定。如果你在 provider network 上遇到绑定失败而且端口显示 vnic_typedirect先确认是不是创建端口时指定过特殊类型。很多情况下删掉端口重新用默认模式创建就能解决。3.4 OVN 部署下的另类场景如果用的是较新的发行版默认架构可能是 ML2/OVN这时候端口绑定的执行者变成了 ovn-controller而不是传统意义上的 linuxbridge agent 或 OVS agent。报错信息虽然一样但排查入口不同优先看 openstack network agent list 里有没有 ovn-controller确认 agent 是否 UP以及对应计算节点是否已经注册到 OVN 的 chassis 列表中。OVN 场景下传统网桥查不到是正常的不需要在计算节点上找 brq 网桥。如果 agent 在线但绑定失败重点去看 OVN 层面的日志通常会有更明确的上下文提示。这类案例不多但既然标题是使用 provider network 创建实例大版本差异还是值得提一句。4. 一步一步追日志从 nova-compute 到 neutron-server 再到 agent4.1 先从 nova 日志里找到端口 id排查 PortBindingFailed 的第一件事不是马上改配置而是通过 nova 日志找到那个绑定失败的端口 id后面所有动作都围绕它展开。在计算节点上执行grep -i PortBindingFailed /var/log/nova/nova-compute.log | tail -n 20日志里会包含类似 Binding failed for port 6f8a... 的记录把这个端口 id 抄下来。如果有多条记录以时间靠后、和当前实例对应的那一条为准。拿到端口 id 之后去看端口详情openstack port show 6f8a...重点看三个字段binding:host_id应为目标计算节点的主机名。如果为空说明 agent 根本没绑定。binding:vif_type正常应该是 bridge、ovs 或 dvs如果为空或不合理说明绑定流程中断。statusDOWN 是正常的绑定完成后才会 ACTIVE。这一步能快速判断问题到底出在 agent 没响应还是绑定之后状态上报异常。4.2 用 agent 状态和宿主机网桥互相验证接下来看两件事agent 是否在线以及宿主机上的网络设施是不是符合预期。查看整体 agent 状态openstack network agent list如果是 linuxbridge 场景还要在计算节点上看网桥实际状态brctl show正常情况下应该能看到一个和该端口对应的 brq 网桥桥上有物理网卡比如 eth1以及一个待接入的 tap 设备。如果网桥上只有 tap 没有物理网卡说明桥接链路上少了一环绑定不可能成功。如果是 OVS 场景ovs-vsctl show检查 br-ex 是否存在、是否 up、物理网卡是否已经加入。这一步是判断面板是否接好的最直接证据。4.3 在 neutron-server 和 agent 日志里找最终原因端口、agent、网桥都查完以后大概率已经能定位问题了。但如果你还是不确定或者想看到更精确的失败原因可以去翻 neutron-server 和 agent 的日志。控制节点上的 neutron-server 日志位置通常在 /var/log/neutron/neutron-server.log搜索关键字grep -i binding /var/log/neutron/neutron-server.log | tail -n 100计算节点上的 agent 日志根据部署产物不同可能是 /var/log/neutron/neutron-linuxbridge-agent.log 或 /var/log/neutron/neutron-openvswitch-agent.log搜索失败相关的关键字grep -i fail\|error /var/log/neutron/neutron-linuxbridge-agent.log | tail -n 100日志里如果出现 no physical bridge那就是映射没对上如果出现 agent not alive 或管理端的通信超时重点查 agent 服务和心跳如果有 vnic_type 相关字样检查端口类型。日志位置以你的发行版实际路径为准但关键字思路是通用的。4.4 重建验证删掉错误实例清理残留端口找到根因并修改配置之后不要直接在原 ERROR 实例上反复尝试最干净的做法是删除实例清理可能残留的端口然后重新创建。openstack server delete demo-instance删除后执行openstack port list --device-id instance_uuid如果还有端口残留手动删除openstack port delete port_id然后重新执行 openstack server create。这一步很多人会忽略导致明明配置已经改对但因为旧端口还残留在错误的绑定状态里重建实例时依然失败。5. 修复手法与预防清单怎么改配置、怎么重建、怎么避免再犯5.1 修正映射配置并重启 agent到这里就该动手修了。以 linuxbridge 为例打开 /etc/neutron/plugins/ml2/linuxbridge_agent.ini确认 [linux_bridge] 段[linux_bridge] physical_interface_mappings physnet1:eth1冒号前面的 key 必须和创建网络时的 --provider-physical-network 一致冒号后面的接口必须是宿主机上真实存在、且连接到目标二层网络的物理网卡。修改完成后重启服务systemctl restart neutron-linuxbridge-agent systemctl status neutron-linuxbridge-agent需要注意如果你的环境有多台计算节点必须确认每一台的映射都一致。nova 调度器可能把实例分配到任何一台满足条件的节点只要有一台配置不完整就存在间歇性失败的风险。这也是为什么实际运维中建议把这类映射关系集中登记而不是靠记忆。5.2 重建网络前的几个确认点我见过太多人遇到这个问题后第一反应是删网重建但网络本身没有错错的是主机侧映射。删网重建不但浪费时间还可能掩盖真正的问题。重建之前按这个顺序确认一遍openstack network show 里的 provider:physical_network 和 provider:network_type 是否符合预期。每一台计算节点的 agent 是否在线Alive 是否为 True。agent 配置里的物理网络名、物理接口和实际网桥是否对应。如果是 OVS确认 br-ex 真的存在且物理网卡已经加入。其中第 4 条是最容易被忽略的。br-ex 不存在时日志里不会给你一个特别显眼的报错但端口绑定就是会失败。5.3 后续运维检查清单最后分享一份我平时检查网络绑定问题的清单每次改完网络相关配置都会照着走一遍检查项命令/位置预期结果网络类型与物理网络名openstack network showprovider:physical_network 有值agent 在线状态openstack network agent listAlive / Truelinuxbridge 配置/etc/neutron/plugins/ml2/linuxbridge_agent.ini映射 key 与网络名一致OVS 网桥状态ovs-vsctl showbr-ex 存在且物理网卡已加入nova 日志报错grep -i PortBinding /var/log/nova/nova-compute.log无新增错误这套清单不仅适用于 PortBindingFailed遇到其他网络绑定方面的疑难杂症也可以复用。最后说句实在话PortBindingFailed 这个错看着吓人本质就是一个断言虚拟机需要的虚拟网线没能插到物理交换机上。排错时不用急着删网重建按 nova 日志 → 端口详情 → agent 状态 → 宿主机网桥的顺序走一遍基本十几分钟就能落地。我见过太多人把 provider 网络删了重建好几遍最后发现不过是 agent 配置里 physnet 的名字少了一个字母或者改了配置忘了重启。希望这篇能帮你少走点弯路。