Networking OpenNebula主机网络更改,虚拟机失去所有连接

Networking OpenNebula主机网络更改,虚拟机失去所有连接,networking,virtualization,opennebula,Networking,Virtualization,Opennebula,我最近更改了底层主机网络配置(将VLAN标记从主机移动到交换机),它似乎完全阻止了我的虚拟机的任何类型的网络连接 我在Ubuntu 16.04上运行OpenNebula 5.4.6 我有4个物理网络接口,用于在主机上配置: auto br_admin iface br_admin inet dhcp bridge_ports eno1 bridge_stp off bridge_fd 0 bridge_maxwait 0 auto br_service ifac

我最近更改了底层主机网络配置(将VLAN标记从主机移动到交换机),它似乎完全阻止了我的虚拟机的任何类型的网络连接

我在Ubuntu 16.04上运行OpenNebula 5.4.6

我有4个物理网络接口,用于在主机上配置:

auto br_admin
iface br_admin inet dhcp
    bridge_ports eno1
    bridge_stp off
    bridge_fd 0
    bridge_maxwait 0

auto br_service
iface br_service inet dhcp
    bridge_ports eno2
    bridge_stp off
    bridge_fd 0
    bridge_maxwait 0

auto eno2.20
iface eno2.20 inet manual

auto eno2.30
iface eno2.30 inet manual

auto br_public
iface br_service inet dhcp
    bridge_ports eno2.20
    bridge_stp off
    bridge_fd 0
    bridge_maxwait 0

auto br_data
iface br_service inet dhcp
    bridge_ports eno2.30
    bridge_stp off
    bridge_fd 0
    bridge_maxwait 0
我能够将VLAN网桥移动到单独的接口上,而不是其他两个网桥未经修改

auto br_admin
iface br_admin inet dhcp
    bridge_ports eno1
    bridge_stp off
    bridge_fd 0
    bridge_maxwait 0

auto br_service
iface br_service inet dhcp
    bridge_ports eno2
    bridge_stp off
    bridge_fd 0
    bridge_maxwait 0

auto br_public
iface br_service inet dhcp
    bridge_ports eno3
    bridge_stp off
    bridge_fd 0
    bridge_maxwait 0

auto br_data
iface br_service inet dhcp
    bridge_ports eno4
    bridge_stp off
    bridge_fd 0
    bridge_maxwait 0
我的虚拟机都不使用br_public或br_数据,而且它们也不构成OpenNebula配置的任何部分,因此当我发现我的虚拟机在这次更改后失去了连接时,我感到非常震惊。我重新启动了所有虚拟机,后来又重新启动了主机,但问题仍然存在

我删除并重新创建了OpenNebula中的虚拟网络,分离了旧的NIC,并将新的NIC添加到虚拟机中。即使从头开始创建全新的虚拟机,我似乎也无法恢复任何网络连接


有什么想法吗??提前感谢…

在使用
tcpdump
进行大量调试后,我发现我的主机网桥正在接收来自M的数据包,但没有在上转发它们。我运行了下面的命令并再次开始获取网络连接

# echo "0" > /proc/sys/net/bridge/bridge-nf-call-iptables
我在
/etc/sysctl.d/50 bridge nf call.conf

net.bridge.bridge-nf-call-arptables = 0
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
环顾四周,我发现Ubuntu中有一个非常老的bug,它导致在启动过程中过早加载sysctl配置,因此无法为尚未加载的模块应用设置。在Ubuntu的示例部分中,明确解释了在模块正确加载后如何使用udev规则设置桥接过滤

添加此项后,我重新启动主机并确认虚拟机将保持连接