KVM虚拟机与Docker容器共用香港服务器时，网络和存储隔离边界怎么验证？

同一台香港服务器上同时运行 KVM 虚拟机和 Docker 容器，并不意味着两者天然共享资源，也不意味着它们已经完成了严格隔离。KVM 主要通过独立的虚拟机内核、虚拟 CPU、虚拟内存和虚拟设备形成边界；Docker 则主要依靠 Linux 命名空间、控制组和文件系统层实现进程级隔离。两种边界的强度、可见范围和失效条件并不相同。

验证网络和存储隔离，不能只看“虚拟机能启动”“容器有独立 IP”或“容器里看不到宿主机目录”。更可靠的判断方式是同时核对四件事：数据包实际经过哪些接口和防火墙链路，虚拟磁盘和容器挂载实际落在哪个存储对象，是否存在显式共享配置，以及资源争用时是否仍有可观测的限制。

先划清“共用服务器”的边界

三种常见部署关系

“ KVM 与 Docker 共用香港服务器”通常对应以下三种拓扑，验证方法不能混用。

第一种是物理服务器宿主机同时运行 KVM 和 Docker：

物理网卡
   ├── br-public ── vnet0 ── KVM虚拟机
   └── docker0 ── veth pair ── Docker容器

这种情况下，KVM 虚拟机使用独立的客户机内核，Docker 容器使用宿主机内核。虚拟机和容器之间通常没有直接的进程或文件系统关系，但它们可能共享物理网卡、CPU、内存、磁盘控制器和底层文件系统。

第二种是KVM 虚拟机内部运行 Docker：

物理服务器
   └── KVM虚拟机
          └── Docker daemon
                 └── Docker容器

此时容器与虚拟机共享的是客户机内核，而不是物理宿主机内核。物理宿主机通常只能看到该虚拟机的虚拟磁盘、虚拟网卡和 QEMU/KVM 进程，不能像客户机内部的 Docker 管理员一样直接列出容器网络命名空间。

第三种是多个 KVM 虚拟机分别运行 Docker。这时隔离关系至少有两层：物理宿主机到 KVM 客户机，以及客户机内部 Docker 到容器。容器之间是否互通，应在各自客户机内部单独判断，不能因为它们位于同一个香港机房就推断为同一网络。

香港只是服务器所在地域，不会自动改变 KVM、Docker、Linux 网桥、文件系统和防火墙的工作机制。真正决定隔离边界的是部署层次、接口连接方式、挂载关系、权限配置和底层存储形态。

A5数据提供香港物理服务器租用，涵盖Xeon Gold与AMD EPYC平台，搭配大内存及SSD或NVMe存储，为KVM虚拟机与Docker容器混合部署提供计算和数据承载基础。这类资源可用于业务后台、数据库与容器应用的集中部署，支持围绕宿主机规划虚拟网络、虚拟磁盘和容器数据卷。香港产品另有CN2与国际带宽方案，为面向不同访问人群的业务提供网络资源选择。

网络隔离、数据隔离和性能隔离不是一回事

可以把隔离拆成三类：

例如，Docker 容器看不到 KVM 虚拟机的文件，并不能说明双方没有共享 SSD。它们可能分别使用不同的虚拟磁盘和 Docker 数据目录，但这些对象最终仍然位于同一个物理阵列上。

反过来，两个容器能够访问同一个 Docker volume，也不一定意味着它们可以访问宿主机全部文件。实际边界需要结合挂载源、权限、用户身份和容器能力逐项确认。

网络隔离的工作机制

KVM 虚拟机如何连接到网络

KVM 本身并不规定唯一的网络方案，常见实现是客户机虚拟网卡连接到宿主机的 TAP 设备，再接入 Linux 网桥。

客户机 eth0/ens3
        │
    虚拟网卡
        │
宿主机 vnet0/TAP
        │
     br-public
        │
    物理网卡

客户机内部看到的可能是 ens3、eth0 等设备，宿主机看到的通常是 vnet0、vnet1。如果网桥直接接入物理网卡，客户机可能获得与宿主机同一二层网络中的地址；如果使用 NAT 网络，客户机的出站流量则会经过宿主机转发和地址转换。

因此，KVM 网络是否隔离，至少要回答以下问题：

• 虚拟机网卡接入哪个网桥？
• 网桥是否直接连接公网物理网卡？
• 虚拟机和宿主机是否处于同一个二层广播域？
• 流量经过宿主机的 INPUT、FORWARD 还是桥接过滤路径？
• IPv4 和 IPv6 是否采用了相同的控制策略？
• 是否配置了 VLAN、网桥端口过滤或 libvirt 网络过滤规则？

如果多个 KVM 虚拟机都接入同一个二层网桥，它们可能可以直接进行 ARP、邻居发现或二层通信。即使应用端口被防火墙拦截，也不能简单称为“网络完全隔离”。

Docker 容器如何连接到网络

Docker 默认常见的桥接模式会在宿主机和容器之间建立一对虚拟以太网设备：

容器 eth0
   │
容器网络命名空间
   │
veth pair
   │
docker0 或用户自定义 bridge
   │
宿主机路由、NAT和防火墙

容器内部看到的是自己的 eth0，宿主机看到的是对应的 veth 端。容器的 IP 通常来自 Docker 网络的私有地址池，出站流量可能通过宿主机做 NAT。

但 Docker 的网络模式会改变这个边界：

• bridge：容器有独立网络命名空间，通常经过 Docker 网桥。
• host：容器直接使用宿主机网络栈，容器不再拥有传统意义上的独立 IP 隔离。
• none：容器几乎不配置网络，需要应用自行处理网络。
• macvlan 或类似直连模式：容器可能直接出现在物理二层网络中，通信规则与普通 Docker bridge 不同。
• 发布端口：即使容器使用私有地址，宿主机也可能把公网端口转发到容器。

因此，看到容器地址是 172.17.0.0/16 或其他私网地址，只能说明它可能使用了桥接网络，不能直接证明公网不可达，也不能证明 KVM 虚拟机无法访问它。

混合部署时容易出现的网络交叉

如果 KVM 使用 br-public，Docker 使用独立的 docker0，两者通常处于不同的逻辑网络。它们之间是否能互通，主要取决于宿主机路由、转发规则、发布端口和应用监听地址。

如果 Docker 容器被直接接入 KVM 使用的公共网桥，或者使用了面向物理网络的直连模式，容器可能成为该二层网络中的独立节点。这种架构不是一定错误，但需要明确配置地址、ARP、入站策略和 IPv6 防火墙。

一个更容易核对的逻辑拓扑通常是：

物理网卡 ── br-public ── KVM虚拟机
                     └── 宿主机必要服务

宿主机 ── docker0 ── Docker容器
          │
          └── 仅通过明确发布的端口与外部通信

这只是结构示意，不代表所有服务器都应使用相同接口名称。关键在于：KVM 网桥和 Docker 网桥是否被有意分开，跨网段通信是否经过可审计的路由和防火墙。

存储隔离的工作机制

KVM 的磁盘边界

KVM 虚拟机通常以以下一种形式获得磁盘：

• 宿主机上的 qcow2 或 raw 文件；
• LVM 逻辑卷；
• 独立块设备；
• 远程存储映射；
• 通过 virtiofs、9p 或其他方式显式共享的目录。

客户机内部只会看到虚拟块设备，例如 /dev/vda、/dev/sda，再在其上创建分区、文件系统和挂载点。客户机通常不会知道自己对应的是宿主机上的哪个具体文件，除非管理员进行了额外映射。

但这并不意味着宿主机无法访问客户机数据。拥有宿主机管理权限的人员通常可以看到虚拟磁盘文件或逻辑卷，并可能通过虚拟机工具、快照或离线挂载分析其中内容。KVM 的隔离重点是阻止普通客户机进程直接访问宿主机文件，而不是阻止宿主机管理员查看客户机磁盘。

Docker 的文件系统边界

Docker 容器常见的文件系统由镜像只读层、容器可写层和 volume 或 bind mount 组成。使用 overlay 类存储驱动时，容器内看到的是合并后的目录树，宿主机上则存在多个底层目录。

需要区分三种挂载：

1. 镜像和容器可写层

由 Docker 存储驱动管理，容器删除或重建时可能变化，不适合直接作为数据持久化方案。

1. Docker volume

由 Docker 管理，容器内显示为一个挂载点。它与容器生命周期相对独立，但仍然存放在 Docker 数据根目录或指定的卷后端中。

1. bind mount

将宿主机指定目录直接映射到容器内。它最直观，也最容易扩大容器的宿主机可见范围。映射宿主机根目录、Docker socket、设备目录或敏感配置目录，会显著削弱容器边界。

例如，容器内的 /data 如果对应宿主机 /srv/app-data，那么“容器看不到宿主机其他目录”并不等于“容器和宿主机完全隔离”。容器对 /srv/app-data 的读写权限仍然受宿主机权限、挂载参数和容器用户身份影响。

共享目录和直通设备会改变结论

如果 KVM 使用了 virtiofs、9p 或其他共享目录机制，客户机可以直接访问宿主机导出的目录。这属于明确的数据共享，不应继续按“虚拟磁盘完全隔离”来验收。

如果把宿主机块设备直通给虚拟机，也必须确认该设备是否由宿主机同时挂载。一个文件系统通常不能在没有集群文件系统协调的情况下被多个系统随意同时读写，否则可能造成元数据损坏。涉及块设备直通时，必须先备份数据、确认设备专属关系，并准备好关闭虚拟机或撤销设备映射的回滚方案。

同理，如果 Docker 容器挂载了宿主机目录，而该目录又位于 KVM 虚拟磁盘文件所在的文件系统中，双方虽然没有直接共享客户机文件，但仍然会共享宿主机的容量、inode、缓存和磁盘队列。

影响隔离效果的关键因素

网络模式比软件名称更重要

判断网络边界时，不能只记录“使用 KVM”或“使用 Docker”，还要记录具体模式：

特别要检查服务是否监听在 0.0.0.0 或 IPv6 的 ::。只限制 IPv4 而忽略 IPv6，可能导致验收结果与实际暴露面不一致。

权限模式可能使容器边界失效

以下配置不一定意味着立即出现问题，但都应列入高风险核对项：

• 使用 --privileged；
• 增加高权限 Linux capability；
• 使用 --network host；
• 使用 --pid host；
• 映射宿主机 /、/dev、/proc 或敏感配置目录；
• 将 Docker daemon 的控制 socket 映射进容器；
• 将宿主机设备直接映射给容器；
• 让容器以宿主机 root 身份运行并拥有过宽的写权限。

其中，Docker socket 特别值得单独检查。能够控制宿主机 Docker daemon 的容器，往往可以请求 daemon 创建具有宿主机目录挂载的其他容器，这已经不是普通应用容器的文件隔离范围。

存储后端决定“容量隔离”和“性能隔离”

即使 KVM 虚拟磁盘和 Docker volume 使用不同路径，也可能共享以下资源：

• 同一块物理 SSD 或 RAID 阵列；
• 同一 LVM thin pool；
• 同一个文件系统的空闲空间和 inode；
• 同一虚拟化存储队列；
• 同一宿主机页缓存；
• 同一远程存储连接。

因此需要把“看不到对方数据”和“不会影响对方性能”分开验收。独立目录只能解决路径管理问题，不能自动提供 IOPS 上限或带宽上限。

qcow2 的写时复制、Docker overlay 的 copy-up、数据库同步写、日志突发写入和文件系统缓存，都会使简单的 df 或单次复制测试失去代表性。薄置备存储还可能出现客户机内部显示有空间，但宿主机实际存储池已经接近耗尽的情况。

如何验证网络隔离边界

第一步：建立接口和拓扑清单

建议在宿主机先执行只读检查，确认接口、网桥、虚拟机网卡和 Docker 网络的对应关系。以下命令适用于常见 Linux 环境，接口名称和虚拟机名称需要替换为实际值。

ip -br addr
ip -d link show type bridge
bridge link
bridge vlan show
ss -lntup

如果使用 libvirt 管理 KVM，可以继续查看：

virsh list --all
virsh domiflist vm-name
virsh domifaddr vm-name --source agent

domifaddr 依赖客户机代理或其他地址发现方式，没有结果不等于虚拟机没有网络。此时应进入客户机内部查看 ip -br addr 和 ip route。

查看 Docker 网络和容器地址：

docker network ls
docker network inspect bridge
docker inspect -f '{{.Name}} {{range .NetworkSettings.Networks}}{{.NetworkID}} {{.IPAddress}} {{.Gateway}}{{"\n"}}{{end}}' container-name

重点不是记住某个接口名称，而是建立这样的对应关系：

vnet7       master br-public
vethxxxx    master docker0
ens3        客户机内部网卡
eth0        容器内部网卡

如果发现 KVM 的 vnet 和 Docker 的 veth 都加入了同一个公共网桥，就需要进一步确认这是有意设计还是误接。仅凭 br0、docker0 这样的名称，不能判定隔离情况。

第二步：核对路由和有效防火墙路径

宿主机上查看路由和防火墙规则：

ip route
ip -6 route
nft list ruleset

如果系统没有使用 nftables，而是由其他防火墙管理工具生成规则，应查看实际生效的规则集，不要根据发行版默认配置猜测。

需要重点确认：

• KVM 网桥到 Docker 网桥之间是否存在路由；
• 宿主机是否开启了 IPv4 或 IPv6 转发；
• 跨网桥流量进入的是 FORWARD 还是其他过滤路径；
• Docker 发布端口是否监听在所有地址；
• 虚拟机的公网地址是否绕过了 Docker 端口策略；
• 上游安全组、宿主机防火墙和客户机防火墙是否形成一致策略。

Docker 发布端口经常造成误判。例如，容器内部使用私有 IP，但宿主机将 0.0.0.0:8080 转发到容器的 80 端口，那么外部仍可能通过宿主机地址访问该服务。反过来，服务只绑定在 127.0.0.1 时，容器内部端口开放也不代表外部可达。

第三步：使用“允许路径”和“禁止路径”做定向测试

网络隔离验证应使用已知的服务端口，不建议以大范围扫描代替边界测试。可以先建立一张测试矩阵：

从源端检查目标路由：

ip route get 10.20.30.11
ip -6 route get 2001:db8::11

对已经确认存在的测试服务，可使用连接测试：

curl --connect-timeout 3 --max-time 5 -v http://10.20.30.11:8080/

如果只需要确认 TCP 端口，而没有 HTTP 服务，可以使用环境中已有的端口测试工具。不要因为 ICMP 不通就直接判定隔离成立：很多系统会单独丢弃 ICMP，但仍然允许 TCP 连接；同样，ICMP 可达也不代表所有应用端口都开放。

测试期间可以在宿主机短时间观察数据包路径：

sudo timeout 15 tcpdump -ni br-public -nn 'host 10.20.30.11'
sudo timeout 15 tcpdump -ni docker0 -nn 'host 172.18.0.2'

上述地址只是示例，应替换为实际虚拟机和容器地址。抓包可能暴露业务元数据，生产环境应限定时间、接口和过滤条件，并妥善保存或删除抓包文件。若系统没有 timeout，可以手动运行后及时按 Ctrl-C 停止。

判断时可以结合三类证据：

• 连接测试显示端口确实允许或拒绝；
• ip route get 显示流量经过预期网关；
• tcpdump 显示数据包确实出现在预期网桥或接口，而不是绕过了设计路径。

如果测试结果与防火墙规则不一致，应以实际连接和抓包结果为准，再回头检查 Docker 生成规则、网桥过滤和 IPv6 路径。

如何验证存储隔离边界

第一步：把虚拟磁盘映射到实际存储对象

宿主机先查看块设备和文件系统：

lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS,UUID
findmnt
df -hT
df -ih

查看某台 KVM 虚拟机使用的磁盘：

virsh domblklist vm-name --details

如果输出中是文件路径，可以对该路径进行只读查询：

qemu-img info --backing-chain /path/from-domblklist

qemu-img info 只用于读取镜像元数据，但不能把示例路径直接复制到生产环境。对于 LVM 逻辑卷或独立块设备，应沿着 lsblk、lvs 和挂载关系继续核对。不要在未确认设备归属的情况下执行格式化、分区、挂载或修复操作。

在客户机内部，确认它实际看到的设备和文件系统：

lsblk -f
findmnt
df -hT

需要重点关注：

• 客户机的 /dev/vda 是否对应宿主机独立文件或逻辑卷；
• 是否存在多个客户机共用同一块可写块设备；
• 是否通过 virtiofs、9p 等方式挂载了宿主机目录；
• qcow2 是否存在 backing file 或快照链；
• 存储池是否为 thin provisioning，实际可用空间如何计算。

第二步：核对 Docker 数据根目录和挂载源

查看 Docker 数据根目录：

docker info --format '{{.DockerRootDir}}'

查看容器实际挂载关系：

docker inspect -f '{{range .Mounts}}{{println .Type .Source "->" .Destination "rw=" .RW}}{{end}}' container-name

再对宿主机中的实际路径执行：

findmnt -T /path/from-docker-inspect
df -hT /path/from-docker-inspect
df -ih /path/from-docker-inspect

需要分别核对以下情况：

• 容器使用的是匿名层、Docker volume 还是 bind mount；
• bind mount 的源目录是否位于 KVM 镜像所在文件系统；
• Docker volume 是否与其他容器共用；
• 容器是否获得了宿主机设备或敏感目录；
• volume 所在文件系统是否设置了容量或 inode 限制；
• Docker 数据目录是否和系统日志、KVM 镜像争用同一个存储池。

不要直接修改 Docker 数据根目录下的 overlay 层或 volume 文件来“验证”内容。Docker 管理的目录结构可能随存储驱动和版本变化，人工修改容易破坏元数据。应通过容器挂载点、Docker inspect 和受控测试目录验证。

第三步：使用专用测试文件确认可见范围

需要验证数据边界时，可以在专用测试卷或临时目录中创建一个带唯一标识的文件，例如：

isolation-check-20250308-a17f

测试逻辑应当是：

1. 在专用 Docker volume 中写入标识；
2. 确认同一容器能够读取；
3. 确认未被授权的容器和 KVM 客户机无法读取；
4. 在 KVM 客户机的专用测试目录写入另一个标识；
5. 确认 Docker 容器无法读取该标识；
6. 如果设计上存在共享目录，则明确记录“能够读取”是预期结果。

这类写入应只在专用测试目录中进行，不要在生产数据库目录、KVM 镜像目录或正在使用的业务 volume 中操作。测试完成后的清理属于删除操作，需先确认没有业务文件、保留必要备份，并按照变更流程执行；不要为了清理而直接删除未知路径。

宿主机能够看到 Docker bind mount 中的测试文件，通常是预期现象，因为 bind mount 本来就是宿主机目录映射。真正需要判断的是：容器是否还能访问未授权的其他宿主机路径，KVM 客户机是否能访问不应共享的宿主机目录，以及是否有共享设备或共享文件系统被遗漏。

第四步：验证存储资源是否存在硬限制

数据不可见不等于 IO 不互相影响。可以在业务低峰期采集基线：

iostat -xz 1 5
vmstat 1 5
pidstat -d 1 5

查看 KVM 虚拟磁盘统计：

virsh domblkstat vm-name vda --human

查看容器当前资源统计：

docker stats --no-stream

如果需要判断 Docker 是否配置了块设备读写速率或 IOPS 限制，可以查看容器配置中的相关字段：

docker inspect -f '{{json .HostConfig.BlkioDeviceReadBps}} {{json .HostConfig.BlkioDeviceWriteBps}} {{json .HostConfig.BlkioDeviceReadIOps}} {{json .HostConfig.BlkioDeviceWriteIOps}}' container-name

这些命令本身主要用于读取状态，但结果需要结合内核和 Docker 版本解释。先确认系统是否使用 cgroup v2：

stat -fc %T /sys/fs/cgroup

如果输出为 cgroup2fs，再结合实际 cgroup 控制器、systemd slice 或容器运行时配置判断限制是否生效。不能仅凭 Docker 配置中存在某个字段，就断言底层存储已经提供了严格的 IOPS 隔离。

一个可操作的验收思路是：在不影响生产数据的测试路径上对 Docker volume 和 KVM 虚拟磁盘分别施加受控读写负载，同时观察 await、利用率、队列长度、客户机 IO 延迟和容器业务延迟。如果一方负载升高时另一方明显抖动，只能说明两者存在底层资源争用；要确认是否有硬限制，还需要进一步核对 cgroup、虚拟磁盘限速和存储池策略。

一份可复用的验收顺序

为了避免“网络已测但存储未测”或“容器能访问服务就误判隔离成立”，可以按以下顺序进行：

1. 记录部署类型：Docker 在物理宿主机上，还是在 KVM 客户机内部。
2. 绘制接口关系：物理网卡、KVM 网桥、vnet、Docker 网桥和 veth。
3. 记录每个虚拟机、容器和宿主机管理服务的 IPv4、IPv6、监听端口和路由。
4. 对允许路径执行连接测试，对禁止路径执行定向拒绝测试。
5. 用短时抓包确认测试流量经过了预期接口和防火墙路径。
6. 使用 virsh domblklist、lsblk 和 qemu-img info 核对 KVM 虚拟磁盘。
7. 使用 docker inspect 和 findmnt 核对容器 volume、bind mount 和 Docker 数据根目录。
8. 在专用测试目录进行双向文件可见性测试。
9. 在低风险窗口采集磁盘和网络争用指标。
10. 将接口清单、挂载清单、测试时间、预期结果和实际结果保存下来，在修改网桥、Docker 网络、虚拟磁盘或防火墙后重新验证。

最终可以形成类似这样的判断记录：

适用限制与判断边界

如果 Docker 运行在 KVM 客户机内部，客户机管理员可以较完整地验证 Docker 内部的网络和存储关系，但不能仅靠客户机命令验证物理宿主机上的邻居虚拟机、底层存储阵列或上游网络策略。涉及 A5IDC 或其他服务商提供的 KVM 虚拟服务器时，服务商的宿主机隔离、底层存储共享和机房网络属于客户机之外的边界，需要结合服务商提供的产品架构、网络策略和资源说明进行确认。

如果 Docker 直接运行在物理宿主机上，宿主机 root 或等效管理权限通常可以读取 KVM 虚拟磁盘、查看容器目录并改变网络规则。因此，这种架构的“隔离”主要是面向普通进程和低权限运维账号，而不是面向宿主机管理员本身。

还需要注意，网络测试只能证明测试时刻、测试端口和测试地址的连通性；存储测试只能证明当前挂载和权限关系。Docker 重建网络、libvirt 修改网卡、IPv6 配置变化、挂载变更、防火墙重载或内核升级，都可能改变结果。对于需要长期稳定的混合部署，应把接口映射、挂载关系、特权配置和关键放行规则纳入变更审查，并在变更后重复验证。

因此，KVM 与 Docker 共用香港服务器时，比较准确的判断不是“完全隔离”或“完全共享”，而是分别回答三个问题：网络上是否经过了预期的接口和策略，数据上是否存在未声明的挂载或设备共享，性能上是否有明确的资源边界。只有这三类证据都与设计目标一致，才能确认实际隔离边界与规划相符。