我有一个KVM/QEMU主机和客户机 (VM) 都运行Ubuntu 18.04 LTS的设置bridged networking。VM 随机配置了静态 IP 松散网络连接（没有模式）。配置了 DHCP 的 VM 工作正常。
这是我的主机网络配置，
network:
version: 2
ethernets:
eno1:
dhcp4: no
dhcp6: no
eno4:
dhcp4: true
eno5np0:
dhcp4: true
eno6np1:
dhcp4: true
ens2f0np0:
dhcp4: true
ens2f1np1:
dhcp4: true
bridges:
br0:
interfaces: [eno1]
dhcp4: no
addresses:
- 10.2.0.92/24
gateway4: 10.2.1.252
nameservers:
addresses:
- 8.8.8.8
这是我的虚拟机（来宾）网络配置，具有静态 IP，
network:
version: 2
ethernets:
ens3:
dhcp4: no
addresses:
- 10.2.0.210/23
gateway4: 10.2.1.252
nameservers:
addresses:
- 8.8.8.8
这是我的虚拟机（来宾）使用 DHCP 的网络配置，
network:
version: 2
ethernets:
ens3:
dhcp4: true
具有静态 IP 的虚拟机会进入某种空闲状态。因此，每当尝试 SSH 或访问其中的服务时，都需要花费一些时间才能连接，
$ nc -z -v -w5 10.2.0.210 22
nc: connect to 10.2.0.210 port 22 (tcp) timed out: Operation now in progress
再试一次，它会起作用，因为虚拟机由于第一次尝试而从空闲状态移至工作状态，
$nc -z -v -w5 10.2.0.210 22
Connection to 10.2.0.210 22 port [tcp/ssh] succeeded!
具有 DHCP 的虚拟机没有问题。它随时都可以正常连接，
$ nc -z -v -w5 10.2.0.184 22
Connection to 10.2.0.184 22 port [tcp/ssh] succeeded!
我检查了以下链接，
但没有帮助。
KVM 配置有问题吗？不仅是 SSH，虚拟机中公开的任何服务都无法访问。我VMs are in running state在查询时已验证了这一点virsh。
答案1
我发现一个相当基本的问题是 br0 上的网关不在地址范围内。您定义了 /24 而不是 /23。
br0:
interfaces: [eno1]
dhcp4: no
addresses:
- 10.2.0.92/**24**
gateway4: 10.2.1.252
nameservers:
addresses:
- 8.8.8.8
你只需要改变/24进入 /23
10.2.0.92/23 将涵盖 10.2.0.0 到 10.2.1.255，就像您的虚拟机中的主机一样。问题不是空间重叠，而是主机无法通过 /24 访问主机网关。
如果你从客户机 ping 到主机...数据包将离开客户机，并进行广播，因为主机位于网络掩码针对客户机的当前网络。主机将接收数据包。主机将发送回复。由于 xx1.x 的目的地不在 xx0.x 的当前网络上，因此数据包通常会被路由到网关。哦，等等，网关也不在 xx0.x 上。数据包将无处可去。
请记住，数据包并不智能。它们只会去你指定的地方。
我上面没有提到的部分是 ARP。@Gerrit 上面的评论也提到了这一点。当数据包在冲突域内发送时，它们通过 MAC 地址而不是 IP 进行传输。当 10.2.0.210/23 向 10.2.0.92 发送数据包时，在 10.2.0.210/23 发送广播数据包询问谁是 10.2.0.92 之后，出站数据包将直接发送到 10.2.0.92。我不确定访客是否会收到回复。可能会，因为 ARP 回复了请求者的 MAC。访客会将该信息添加到自己的 ARP 表中。
但是，主机在回复中不会有访客的 MAC 地址，因为对于主机而言，访客位于其 /24 冲突域之外。它通常会转到网关进行路由，但它也无法这样做，因为主机网关也不在本地网络中。网关（即路由器）无法将数据包路由回它们进入的线路。数据包需要穿过设备。如果它可以到达网关，它可能会被丢弃。
我发现更有趣的是它有时确实有效。网络掩码、广播和冲突域都只影响数据包的发送者，而不影响数据包的接收者。可能是因为 Guest 是主机上的虚拟事物，所以一些数据包会通过虚拟交换机并被看到。