虚拟机网络的四种模式

一句话总结

VM 网络模式的选择取决于由谁处理数据包：用户空间（SLIRP）、内核（TAP）、内核网桥，以及内核中的 virtio 处理（vhost-net）。

为什么需要了解这些

“VM 能访问互联网，但外部无法连接 VM。”这类问题几乎总是由 user（SLIRP）模式引起。它常被用作开发环境的默认值，如果不了解其特性，就可能原样带入生产环境。

工作原理

user（SLIRP）

QEMU 在用户空间完整实现 TCP/IP 协议栈。QEMU 解析客户机发出的数据包，再将其转换为宿主机上的普通套接字流量发送出去。

• 完全不需要特权。 这是它在本实验环境中成为唯一可用方式的原因。
• 客户机位于 10.0.2.0/24 网段，网关为 10.0.2.2，DNS 为 10.0.2.3。
• 外部无法直接连接客户机。 必须通过 hostfwd 单独开放端口。
• ICMP 支持有限。客户机内经常无法使用 ping，这是正常现象。
• 性能较低。所有数据包都要额外经过一次用户空间。

tap

在内核中创建虚拟以太网设备，由 QEMU 持有其中一端。由于数据包会直接进入内核网络栈，从宿主机看，它就像一个真实接口。但创建 TAP 设备需要特权，或者需要对预先创建的设备拥有权限。

bridge

将 TAP 接入 Linux 网桥。如果物理 NIC 也接入该网桥，VM 就会像直接连接物理网络一样工作。VM 可以通过 DHCP 获取企业内网地址，其他服务器也能直接通过该地址连接它。这是生产环境的基本配置。

ip link add br0 type bridge
ip link set eth0 master br0
ip link set br0 up
qemu-system-x86_64 -netdev tap,id=n0,ifname=tap0,script=no -device virtio-net-pci,netdev=n0

vhost-net

在内核中处理 virtio 环形缓冲区。无需往返 QEMU 用户空间，因此可以显著降低延迟和 CPU 使用率。配置方式为 -netdev tap,...,vhost=on。

模式	特权	外部→内部连接	性能	用途
user	不需要	仅限 hostfwd	低	开发/测试
tap	需要	可以	中	隔离的 VM 网络
bridge	需要	可以（直连物理网络）	中～高	生产环境
vhost-net	需要	可以	高	高性能工作负载

生产现场中的常见情况

开发环境中正常的功能到了预发布环境却无法工作。 开发环境使用 user 模式，只通过 hostfwd 开放了 22 端口，而预发布环境使用 bridge，所有端口都可以访问。反过来，从只能依靠 hostfwd 访问的环境迁移到网桥后，必须重新设计防火墙——此前 QEMU 实际上承担了防火墙的作用。

MTU 问题。 在网桥上叠加 VXLAN 等覆盖网络后，有效 MTU 会减小。VM 内仍然使用 1500，导致大数据包悄无声息地丢失。此时需要降低客户机 MTU，或进行 MSS 钳制。

与容器网络有何异同

前面介绍的四种模式，在容器网络中几乎都会原样出现。名称不同，作用却相同；理解其中一侧，另一侧也就很容易掌握。

• VM 的 user 模式 ≈ 容器端口转发。内部可以访问外部，而外部只能通过明确开放的端口进入内部。
• VM 的 tap ≈ 容器的 veth 对。在内核中创建虚拟接口，一端放在内部，另一端留在外部。
• VM 的 bridge ≈ Docker 默认网桥网络。将多个实例接入同一网桥，使它们能够相互通信。
• VM 的 vhost-net ≈ 将数据平面下沉到内核或 eBPF。避免往返用户空间，从而提高速度。

两者的差异也很明确。容器共享宿主机内核，只隔离网络命名空间；VM 则拥有自己的内核。 因此，在 VM 内修改内核参数不会影响宿主机；而容器内的许多内核设置要么与宿主机共享，要么根本无法修改。另一方面，VM 启动时间更长，也会完整占用所分配的内存。

转化为实际决策就是：如果必须操作内核本身（加载模块、使用不同内核版本）、确实需要极高隔离级别，或需要运行非 Linux 系统，就选择 VM。除此之外，容器几乎总是更轻、更快。而且二者混合使用十分常见——典型结构是 Kubernetes 节点本身运行在 VM 中，容器再运行于其上。此时网络层叠加两层，前面提到的 MTU 问题尤其容易出现。

下一步要做什么

本模块只讲解概念。现在应当能够解释为何前面的 vm-boot 实验使用 -netdev user,hostfwd=...——因为在无特权环境中，这是唯一可行的选择。