故障排除¶

以下部分描述了在使用 Devstack 安装 OVN ML2 驱动程序后/期间可能遇到的常见问题以及解决这些问题的可能方案。

启动虚拟机失败¶

禁用 AppArmor¶

在使用 Ubuntu 时，您可能会在启动虚拟机后尝试创建 OVS 端口时遇到 libvirt 权限错误（来自 nova compute 日志）。禁用 AppArmor 可能会帮助解决此问题，请查看 https://help.ubuntu.com/community/AppArmor 以获取有关如何禁用它的说明。

多节点设置无法工作¶

Geneve 内核模块不支持¶

默认情况下，OVN 使用 Geneve 协议在计算节点之间创建隧道。较旧的内核（< 3.18）不支持 Geneve 模块，因此隧道无法工作。您可以使用此命令 ‘lsmod | grep openvswitch’ 进行检查（geneve 应该出现在结果列表中）

有关支持每种隧道类型所需的上游 Kernel 版本的信息，请参阅 OVS FAQ 中“为什么在使用 Open vSwitch 提供的模块以外的内核模块时隧道无法工作？”的答案。

MTU 配置¶

这个问题并非 OVN 独有，但由于 geneve 标头可能比其他常用隧道协议（VXLAN）更大的尺寸，因此被放大了。如果您将虚拟机用作计算节点，请确保降低虚拟接口上的 MTU 大小，或启用其分片。

重复或删除的 OVN 代理¶

“ovn-controller” 进程是 OVN 的本地控制器守护进程。它在属于 OVN 网络的每个主机上运行，负责通过在 Southbound 数据库中创建相应的“Chassis”和“Chassis_Private”寄存器来注册主机。同时，当进程被优雅地停止时，它会删除这两个寄存器。这些寄存器由 Neutron 用于控制 OVN 代理。

$ openstack network agent list -c ID -c "Agent Type" -c Host -c Alive -c State
+--------------------------------------+------------------------------+--------+-------+-------+
| ID                                   | Agent Type                   | Host   | Alive | State |
+--------------------------------------+------------------------------+--------+-------+-------+
| a55c8d85-2071-4452-92cb-95d15c29bde7 | OVN Controller Gateway agent | u20ovn | :-)   | UP    |
| 62e29a01-a0ac-55c9-b4ec-e223d5c90853 | OVN Metadata agent           | u20ovn | :-)   | UP    |
| ce9a1471-79c1-4472-adfc-9e5ce86eba07 | OVN Controller Gateway agent | u20ovn | XXX   | DOWN  |
| 3755938f-9aac-4f08-a1ab-32fcff56d1ce | OVN Metadata agent           | u20ovn | XXX   | DOWN  |
+--------------------------------------+------------------------------+--------+-------+-------+

如果在系统升级期间 OVS “system-id” 发生更改，则会重新创建“Chassis”和“Chassis_Private”寄存器，但具有不同的 UUID。如果未删除之前的寄存器（如果“ovn-controller”进程被优雅地停止，则应该删除），Neutron 将显示来自同一主机的重复代理。在这种情况下，只有一个代理处于活动状态，另一个代理将处于关闭状态，因为“Chassis_Private.nb_cfg_timestamp”未更新。在这种情况下，管理员应手动从 OVN Southbound 数据库中删除过时的寄存器。例如

列出“Chassis”寄存器，按主机名和名称（OVS “system-id”）过滤

$ sudo ovn-sbctl list Chassis | grep name
hostname            : u20ovn
name                : "a55c8d85-2071-4452-92cb-95d15c29bde7"
hostname            : u20ovn
name                : "ce9a1471-79c1-4472-adfc-9e5ce86eba07"

删除过时的“Chassis”寄存器

$ sudo ovn-sbctl destroy Chassis ce9a1471-79c1-4472-adfc-9e5ce86eba07

列出“Chassis_Private”寄存器，按名称过滤

$ sudo ovn-sbctl list Chassis_Private | grep name
name                : "a55c8d85-2071-4452-92cb-95d15c29bde7"
name                : "ce9a1471-79c1-4472-adfc-9e5ce86eba07"

删除过时的“Chassis_Private”寄存器

$ sudo ovn-sbctl destroy Chassis_Private ce9a1471-79c1-4472-adfc-9e5ce86eba07

如果主机名在系统升级期间也更新，Neutron 代理列表可能会显示来自不同主机名的条目，但旧的条目也会处于关闭状态。程序相同。

也可能发生的情况是，在节点退役期间，“Chassis”寄存器被删除，但“Chassis_Private”寄存器未被删除。在这种情况下，OVN 代理列表将显示相应的代理，并显示以下消息：“(‘Chassis’ register deleted)”。同样，程序相同：管理员应手动删除 OVN Southbound 数据库中孤立的寄存器。Neutron 将接收此事件并删除关联的 OVN 代理。

故障排除