VMware克隆Ubuntu 18.04后虚拟机断网？排查思路与完整修复

遇到 VMware 克隆 Ubuntu 18.04 后虚拟机没网，而宿主 Windows 10 还连着一块无线网卡，很多人的第一反应是回头看路由器、检查网线、重启调制解调器，结果折腾半天发现方向完全错了。这个问题的本质其实非常单一：克隆出来的系统和原系统共享了同一套“网络身份”，而新虚拟机已经不再属于这个身份了。

这篇文章我会把整个排查思路和完整修复步骤一次性讲清楚。它适合三类人看：一是刚把 Ubuntu 18.04 模板机克隆分发给同事、结果大家集体断网的运维；二是自己电脑上跑 VMware Workstation、用无线网卡做宿主的开发；三是所有在虚拟机里折腾 Ubuntu 但被“无网络”问题劝退过的新手。内容不绕弯子，直接给能落地的命令和配置。

1. 为什么克隆完虚拟机就断网了：网络身份彻底错位

先说明一个容易误解的事：VMware 克隆虚拟机，不是在“新装一台电脑”，而是把原虚拟机的整块虚拟磁盘照抄一份。原系统里的网卡配置、机器标识、SSH 密钥、主机名，全部被复制了过来。但 VMware 给克隆后的虚拟机分配的新硬件，和原虚拟机并不完全一样，最典型的就是网卡的 MAC 地址和 PCI 槽位发生了变化。

1.1 克隆系统是“复制硬盘”，不是“新建系统”

我在实际处理过的问题里，见过最多的场景是这样的：源虚拟机用 ens33 这个网卡名，配置文件 /etc/netplan/01-netcfg.yaml 里面写着 ens33 的静态 IP，甚至有些模板机还会在配置里绑定原来的 MAC 地址。克隆出来后，VMware 给新虚拟机重新生成了网卡或者调整了硬件槽位，结果系统里网卡变成了 ens37，或者 eth0、eth1。

一旦网卡名对不上，netplan 加载配置时就会把这个网卡标记为“不存在的设备”，自然就不会去申请 IP。你打开终端跑一下 ip addr，看到的永远是只有 lo 回环地址，或者网卡没有 IPv4 地址。这时候第一反应是“网卡坏了”，其实网卡驱动和工作状态完全正常，只是配置没有落到它头上。

1.2 网卡 MAC 和系统配置的错位

再补充一个更隐蔽的坑。如果克隆的时候，VMware 让你选择是否重新生成 MAC 地址，而你选了“不重新生成”，那克隆出来的两台虚拟机的 MAC 是完全一样的。在 NAT 模式下，虚拟机通过 vmnet8 这个虚拟交换机做 DHCP 获取 IP，两个相同 MAC 的虚拟机同时开着，DHCP 服务会认为它们是同一台机器，分配出同一个 IP，结果两台机器相互“抢地址”，表现出来就是一会儿能通一会儿断，或者干脆谁都上不了网。

反过来，如果 VMware 在克隆时帮你重新生成了 MAC 地址，但 Ubuntu 里的 netplan 配置还绑定着旧 MAC，那网卡虽然存在，系统也会“看不见”它，配置无效。这种错位是克隆后无网络的头号原因。

1.3 Win10 无线网为什么让这个问题更难发现

宿主机用无线网络，会让整个排查过程变得更有迷惑性。很多人的思路是这样的：我在 Windows 10 里能看到 Wi-Fi 已连接，浏览器也能上网，说明网络是通的，那虚拟机为什么会没网？

问题在于，虚拟机和宿主的“上网通道”是两个层面。虚拟机走的是 VMware 虚拟出来的 NAT 网关（vmnet8），这是在你电脑内部“凭空造出来”的一台路由器。宿主的无线网卡连接的是你家里的路由器，而 vmnet8 这个虚拟路由器再通过 Windows 的网络共享把流量转发到无线网卡出去。两者中间隔了好几层，Wi-Fi 信号好不好、家里路由器通不通，跟虚拟机能不能拿到 IP 没有直接关系。

所以遇到克隆后断网，先不要去检查无线网卡，也不要怀疑路由器。先把视角拉到虚拟机内部的网卡状态和 VMware 的虚拟网络服务上，这才是症结所在。

2. 动手修之前的三步诊断

很多人一上来就改配置，改完没用又改回来，来回折腾。我建议先花 10 分钟做三个诊断步骤，把问题的层次定位清楚。网络问题分物理链路、IP 配置、路由、DNS 四层，克隆场景下绝大多数是 IP 配置这一层出了问题，但你得先确认这一点。

2.1 在虚拟机里先确认网卡是不是“活着”

打开虚拟机，先别管图形界面，直接进终端执行：

bash复制ip link show
ip addr show

第一条命令看网卡是否存在，第二条看网卡有没有拿到 IP。如果输出里能看到类似 ens33、ens37、eth0 这样的网卡，并且状态是 UP 或 LOWER_UP，说明驱动没问题，网卡是活的。这时候再看 ip addr 里这个网卡下面有没有 inet 192.168.x.x/24 这样的地址。

常见的三种情况分别是：

• 网卡存在，但没有任何 IP：说明网卡没配好，重点看 netplan；
• 网卡名和你配置文件里的网卡名不一致：说明槽位变了，要改配置里的网卡名；
• 网卡完全不存在，只有一个 lo：说明 VMware 虚拟机可能只配了虚拟网卡，但 Ubuntu 的驱动没加载，需要检查 VMware Tools 或 VMXNET3 驱动。

这一步输出非常关键，后面写 netplan 时要完全按照这里显示的真实网卡名来写，不能照搬模板。

2.2 在 Windows 宿主确认 vmnet8 的 NAT 状态

然后切到 Windows 10 系统，打开 VMware Workstation 的“编辑 -> 虚拟网络编辑器”，看一下 vmnet8 是不是 NAT 模式，子网 IP 是什么网段的。默认情况下，vmnet8 的网段通常是 192.168.x.0，子网掩码 255.255.255.0。如果这里被改过，或者 NAT 设置里的网关地址不对，虚拟机就算拿到了 IP，也出不了外网。

同时检查 Windows 服务。按 Win + R，输入 services.msc，回车，在服务列表里找两个服务：

• VMware NAT Service
• VMware DHCP Service

这两个服务必须处于“正在运行”状态，启动类型是“自动”。我用无线网络时遇到过这种情况：睡眠唤醒之后，VMware NAT Service 卡死了，虚拟机里的系统瞬间变成“有 IP 但 ping 不通外网”的状态。把服务重启一次就恢复。Windows 10 的无线网卡在切换网络、睡眠唤醒时，VMware 的虚拟网络服务偶尔会在 Windows 网络栈重配时出现异常，这是无线网络特有的坑。

2.3 用 ping 定位断在哪个环节

接下来从虚拟机里做几组 ping 测试，按顺序来：

1. ping 192.168.x.1：vmnet8 的网关，通了说明虚拟机到 NAT 网关这段没问题；
2. ping 223.5.5.5：公共 DNS 的 IP，通了说明 NAT 转发和外部网络是通的；
3. ping www.baidu.com：通了说明 DNS 解析正常。

如果第 1 步就不通，说明虚拟机的 IP 和网关配置就有问题；第 1 步通而第 2 步不通，问题在 VMware NAT 服务或 Windows 的共享转发；前两步都通而第 3 步不通，那就只剩 DNS 的问题了。

把这三种情况整理成一张表，带着结果去修，比盲目试命令高效得多。

3. 完整修复流程：从网卡配置到系统标识重建

诊断做完，下面进入正式修复。这里给出一套完整的流程，覆盖克隆后最常见的所有问题点。不要跳步，每一步都有它的意义。

3.1 备份旧配置，移除历史残留

先以管理员身份在虚拟机里执行下面这条命令，把现有的 netplan 配置文件备份一份：

bash复制sudo cp /etc/netplan/01-netcfg.yaml /etc/netplan/01-netcfg.yaml.bak.$(date +%F)

备份的意义在于，万一改错了，还能快速回滚。然后看一下 /etc/netplan 目录下到底有哪些文件：

bash复制ls -l /etc/netplan/

Ubuntu 18.04 默认使用 netplan 管理网络，文件名可能是 01-netcfg.yaml、01-network-manager-all.yaml 或者 50-cloud-init.yaml。克隆出的系统，尤其是从云镜像模板克隆的，很可能存在多个配置文件，而且不同文件优先级不同，导致配置互相覆盖。

如果存在多个文件，我建议只保留一个生效的配置文件，把其他的都改掉后缀或移出目录：

bash复制sudo mkdir -p /etc/netplan/disabled
sudo mv /etc/netplan/01-network-manager-all.yaml /etc/netplan/disabled/ 2>/dev/null
sudo mv /etc/netplan/50-cloud-init.yaml /etc/netplan/disabled/ 2>/dev/null

把 cloud-init 生成的配置禁用掉，这一步非常关键。因为 Ubuntu 18.04 Server 版默认装了 cloud-init，如果克隆的源镜像当年是云镜像，cloud-init 会在启动时尝试通过元数据服务获取网络配置，元数据拿不到时它会直接把网络配置覆盖成空值，造成“无论你怎么改 netplan，重启后都没网”的诡异现象。如果你是云镜像转虚拟机，还需要执行：

bash复制sudo cloud-init clean
sudo rm -rf /var/lib/cloud/instance

3.2 根据真实网卡名重写 netplan 配置

现在写新的 netplan 配置。注意一点：网卡名必须以你刚才在 ip link 里看到的真实名称为准，我这里有台克隆机显示的是 ens37，那配置里的 ens37 就写 ens37；如果显示 ens33，就写 ens33。千万别照抄网上示例导致二次踩坑。

先看桌面版比较常用的 NetworkManager 渲染方式。新建或编辑 /etc/netplan/01-netcfg.yaml，内容如下：

yaml复制network:
  version: 2
  renderer: NetworkManager
  ethernets:
    ens37:
      dhcp4: true
      dhcp6: true
      optional: true

如果你用的是 Ubuntu Server（没有安装桌面环境），那就别用 NetworkManager，改成 networkd 渲染，写法和上面类似，只是 renderer 换成 networkd。对于服务器场景，我一般建议直接用静态 IP，避免 DHCP 分配的地址经常变动导致各种服务配置失效。静态 IP 示例：

yaml复制network:
  version: 2
  renderer: networkd
  ethernets:
    ens37:
      dhcp4: false
      addresses:
        - 192.168.88.10/24
      routes:
        - to: default
          via: 192.168.88.2
      nameservers:
        addresses:
          - 223.5.5.5
          - 114.114.114.114

这里的网关地址 192.168.88.2 是从哪里来的？打开 VMware“虚拟网络编辑器”，选中 VMnet8，点“NAT 设置”，里面能看到网关 IP，默认一般是 192.168.x.2。你的虚拟机网段必须和 vmnet8 的网段一致，网关也不能瞎写。我处理过一个用户的例子，他把网关写成了无线网卡的网关 192.168.1.1，结果虚拟机 ping 网关直接不通，因为 192.168.1.1 是宿主无线局域网里的路由器，不在 vmnet8 这个虚拟网络里。

保存文件后应用：

bash复制sudo netplan --debug apply

用 --debug 模式很重要，它能打印出 netplan 到底做了什么、加载了哪个文件。如果输出里出现类似 Cannot call openvswitch: ... 或 failed to rename 的报错，多半是网卡名不对或者有多余配置残留。应用完成后再次执行 ip addr show 确认 IP 是否已经落到网卡上。

3.3 重新生成 machine-id 并清理网络缓存

配置好 netplan 只是第一步。克隆系统还有一个很容易被忽视的问题：/etc/machine-id。这个文件是 Ubuntu 系统的唯一机器标识，克隆出来的两台机器如果 machine-id 完全一样，DHCP 服务工作在极端情况下会把它们视作同一个客户端，造成地址分配异常。

建议把 machine-id 删掉并重新生成：

bash复制sudo rm -f /etc/machine-id
sudo systemd-machine-id-setup

再清理 DHCP 客户端的旧租约文件，避免网卡拿着旧租约去申请 IP 时出现冲突：

bash复制sudo rm -f /var/lib/dhcp/dhclient.*.leases
sudo systemctl restart systemd-networkd 2>/dev/null

如果你使用的是 NetworkManager 渲染方式，还需要额外处理 NetworkManager 的连接记录。克隆系统时，NetworkManager 的连接配置也会被复制过来，它可能还记录着旧网卡和旧的 UUID。可以重置一下：

bash复制sudo systemctl stop NetworkManager
sudo rm -rf /etc/NetworkManager/system-connections/*
sudo systemctl start NetworkManager

这里要注意，如果你的 netplan 里是 networkd 渲染，上面和 NetworkManager 相关的命令都不用执行，它们之间是会互相干扰的。简单判断方式：桌面环境普遍用 NetworkManager，服务器环境更推荐 networkd。二选一，不要混用。

3.4 重启虚拟机并验证连通性

配置全部改完后，重启虚拟机，让所有网络服务以新配置重新加载：

bash复制sudo reboot

重启后按顺序验证：

bash复制ip addr show
ping -c 3 192.168.88.2
ping -c 3 223.5.5.5
ping -c 3 www.baidu.com

第一项确认 IP 和网卡名对应，第二项确认网关，第三项确认外部网络，第四项确认 DNS。如果 IP 地址有了，但 ping 外网 IP 不通，请回到第 2.2 节检查 VMware NAT 服务；如果 ping 外网 IP 通而域名不通，检查 /etc/resolv.conf 的内容，Ubuntu 18.04 默认由 systemd-resolved 管理 DNS，可以执行：

bash复制systemd-resolve --status

看到当前连接的网络接口下面有 DNS Servers 配置，说明正常。如果 DNS 为空，回到 netplan 配置里把 nameservers 加上，再 netplan apply 一次。

4. 常见问题与排查记录

修复流程走完，大部分情况都能解决。但克隆断网这个题目，水比较深，我还遇到过一些相对少见的问题，集中记录在这里，给你一个速查。

4.1 网卡名一会儿 ens33 一会儿 ens37，规则文件在作怪

有些 Ubuntu 老版本（16.04 及更早）会通过 /etc/udev/rules.d/70-persistent-net.rules 固定网卡名和 MAC 地址的对应关系。克隆后新网卡的 MAC 变了，规则文件还写着旧 MAC，系统就会给新网卡分配一个奇怪的名字。Ubuntu 18.04 虽然默认没有这个文件，但如果你的模板机是从 16.04 升级上来的，可能残留这个问题。

处理方法很简单，直接删除规则文件并重启：

bash复制sudo rm -f /etc/udev/rules.d/70-persistent-net.rules /lib/udev/rules.d/70-persistent-net.rules
sudo reboot

重启后网卡名会恢复到系统默认的命名方式。我之前处理过一个案例，克隆后网卡名一直叫 ck0（自定义的名字），netplan 里怎么改都报错，删除规则文件后一切都正常了。

4.2 machine-id 重复导致的诡异间歇性断网

有一类问题很难排查：克隆出来的两台机器单独用都能上网，但同时开机时，其中一台每隔几分钟就断一次网，然后又自动恢复。这种间歇性问题的原因很可能是 machine-id 相同，systemd-networkd 在 DHCP 时被服务端识别成了同一个客户端，地址租约互相“踢掉”。

这个问题在 VMware NAT 的 DHCP 服务里尤其容易出现。解决方法和 3.3 节里一样，删除 /etc/machine-id 并重新生成，确保每个克隆 VM 的 machine-id 都是唯一的。克隆分发时如果能在关机前就把 machine-id 清掉，后面几台都能少踩这个坑。

4.3 VMware Tools（vmtools）的年代感问题

Ubuntu 18.04 属于比较早的版本了，如果你在虚拟机里安装的还是老的 VMware Tools 而不是 open-vm-tools，克隆后网卡驱动可能出现异常。VMware 官方早就推荐在 Linux 虚拟机里使用开源的 open-vm-tools，功能和原版 vmtools 一致，还更稳定。

建议直接安装：

bash复制sudo apt update
sudo apt install -y open-vm-tools open-vm-tools-desktop
sudo reboot

另外，网卡类型在 VMware 里默认可能是 e1000 或 VMXNET3。e1000 是模拟的 Intel 千兆网卡，兼容性最好；VMXNET3 是 VMware 的半虚拟化网卡，性能更好，但需要驱动支持。Ubuntu 18.04 自带 VMXNET3 驱动，如果你在 VMware 虚拟机设置里看到网卡类型是 VMXNET3，系统也能正常识别，那就不用改。如果克隆后系统识别不到网卡，优先考虑把网卡类型改成 e1000e 或 e1000，等系统能上网后再换回 VMXNET3。

4.4 Win10 无线网络切换后虚拟机突然失联

这个场景很有代表性：笔记本连着 Wi-Fi，虚拟机本来一切正常，但从会议室回到工位，自动连接了另一个 Wi-Fi，然后虚拟机就失联了。如果你按照第 2.2 节检查了 NAT 服务，服务正常运行，但虚拟机还是上不了网，这时候需要看 Windows 的网络桥接或者 hyper-v 虚拟网卡是否与 VMware 冲突。

Windows 10 开启 Hyper-V 或者 WSL2 之后，会在系统里添加一个虚拟网卡，这个网卡有时会占用和 vmnet8 冲突的网段。打开 Windows 的“网络连接”窗口，看是否有名为 vEthernet (WSL) 或 vEthernet (Default Switch) 的虚拟网卡，它们可能和 VMnet8 子网有重叠。如果真的冲突，最简单的办法是在“虚拟网络编辑器”里把 VMnet8 的子网 IP 改到不冲突的网段，比如从 192.168.88.0 改成 192.168.99.0，然后回到虚拟机里同步修改 netplan 的静态 IP 和网关。

4.5 顺带回答一下“克隆后开机蓝屏”“客户机操作系统已禁用CPU”等问题

热搜词里还有两个相关度很高的问题。一个是 Windows 10 系统做克隆后开机蓝屏，另一个是打开虚拟机时提示“客户机操作系统已禁用 CPU”。克隆系统的本质问题不只是 Ubuntu 独有，Windows 克隆后蓝屏通常是磁盘控制器驱动失配导致的，解决办法是在新虚拟机上把磁盘类型改成和原系统兼容的类型，或者进安全模式重新加载驱动。至于 CPU 被禁用，多半是虚拟机的 CPU 设置勾选了不兼容的选项，进入虚拟机设置里把“虚拟化 Intel VT-x/AMD-V”或者 CPU 型号从“主机直通”改回“自动”即可。这类问题说到底还是克隆后硬件配置和系统预期不一致，和网络问题的思路一脉相承。

5. 治本：从“修好一次”到“以后再也不踩”

如果你只是需要救急，看到第 3 章就可以解决了。但如果你是在做虚拟化模板分发，比如要给部门十几个人做开发环境，我更建议你换一个思路：把“克隆后修网络”变成一个自动化、规范化的流程。

5.1 模板机清理清单

在制作模板机时，提前执行下面的清理步骤，再做快照或者关机克隆，之后分发出去的每一台机器都不会再出现类似的网络问题。我的习惯是先把网络配置写好、确认能上网，然后执行清理：

bash复制# 重新生成 machine-id
sudo rm -f /etc/machine-id
sudo systemd-machine-id-setup

# 重新生成 SSH host key，避免所有克隆机指纹相同
sudo rm -f /etc/ssh/ssh_host_*
sudo dpkg-reconfigure openssh-server

# 清理 cloud-init 痕迹（如果有）
sudo cloud-init clean
sudo rm -rf /var/lib/cloud/instance

# 清理系统里的临时网络缓存
sudo rm -f /var/lib/dhcp/dhclient.*.leases

# 清理日志和临时文件
sudo apt clean
sudo rm -rf /var/log/journal/*

然后关机克隆。克隆完开机后第一件事不是连网络，而是先把主机名改掉：

bash复制sudo hostnamectl set-hostname ubuntu-node-01

同时检查 /etc/hosts 里有没有残留的旧主机名映射，有的话一起改掉。这样每一台克隆机都拥有独立的 machine-id、SSH 密钥和主机名，网络模块不会被各种“重复身份”干扰，断网概率直接从根源上降下来。

5.2 我对克隆这件事的几点体会

踩过几次坑之后，我的标准操作已经固化了。现在的经验是：克隆不是“复制文件”，而是“复制身份”。VMware 复制的是磁盘上的数据，但系统启动时不仅看磁盘，还会看硬件信息、机器 ID、SSH 密钥。只要把“身份”相关的东西全部重置一遍，90% 以上的克隆后异常都能避免，不只是网络问题。

修网络时也要有层次感。先别急着瞎改，先 ip addr 看网卡状态，再沿着“IP -> 网关 -> 外网 -> DNS”的顺序一层层测，问题在哪一层就解决哪一层。特别是宿主用无线的情况，一定要记住虚拟机走的是 vmnet8 这个虚拟 NAT，和宿主 Wi-Fi 没有直接关系，不要把时间浪费在检查无线路由上。

最后再分享一个小技巧：在虚拟机里改任何网络配置之前，先用 sudo netplan --debug apply 看一下实际生成的内容。netplan 会把 YAML 配置转换成 systemd-networkd 或 NetworkManager 的底层配置，--debug 模式会直接打印出转换结果和报错原因。很多时候，看着像是“网卡没驱动”的问题，实际上只是网卡名对不上，看一次 debug 输出就能找到答案。这个习惯帮我省下了不少排查时间，也分享给你。