课程库

外观

第 7 课 一分钟复制实验室：虚拟机克隆、黄金模板与 cloud-init 身份去重

复制页面

约 10779 字大约 36 分钟

虚拟化克隆黄金模板cloud-init

2026-08-17

项目目标

在前面的课程中，你已经掌握了通过图形界面（virt-manager）与命令行工具（virsh / virt-install）独立安装和管理单台 Ubuntu Server 虚拟机。然而在企业级云计算平台、多节点分布式集群与自动化测试运维环境中，如果每台虚拟机都从 ISO 光盘镜像逐步点击安装，不仅重复耗费大量的计算时间与存储算力，而且极易导致各个节点环境配置漂移。 通过本课的实训与深入剖析，你将达成以下目标：

  1. 掌握 virt-clone 完整克隆底层机制：牢固掌握关机安全门禁，使用 virt-clone 执行自动化完整克隆，深入理解写时复制（COW）与 backing file 依赖链，并通过 qemu-img info --backing-chain 验证底层 QCOW2 磁盘 100% 独立无依赖；
  2. 透视多重身份体系与三大冲突灾难：理清宿主侧（Domain 名称、libvirt UUID、磁盘路径、MAC 地址）与来宾内部（hostname、/etc/machine-id、IP / Netplan）的边界，深度推导未经清理直接克隆导致的 Kubernetes 节点互踢、journald 日志污染与 DHCP DUID 抢占三大分布式灾难；
  3. 拆解 cloud-init 四阶段流水线与黄金模板铁律：剖析 cloud-init 四阶段执行流水线架构（Generator -> Network -> Config -> Final），在候选虚拟机内执行 sudo cloud-init clean --machine-id 彻底抹除实例运行痕迹与旧 ID，牢固树立黄金模板五项运维铁律；
  4. 极速派生实例与 NoCloud 企业级自动化：从黄金模板秒级派生目标虚拟机 lab01，掌握首次启动（First Boot）去泛化激活机制，了解 NoCloud cidata.iso 自动化注入方案，完成全套身份独立性验收。

将配置完善的 Ubuntu Server 固化为黄金模板并批量派生身份独立的实验虚拟机

7.1 任务一：快速复制虚拟机——virt-clone 完整克隆实操

在日常运维中，当我们需要多台环境完全一致的服务器时，最直接的方式就是复制已经配置完善的基准机。在 KVM/libvirt 体系中，virt-clone 是专门用于克隆虚拟机的核心工具。

操作环境与前置准备

  • 操作终端：本任务的所有命令默认在 Ubuntu 宿主机终端（Host） 执行，请勿在虚拟机内部执行。
  • 管理权限：命令默认连接 qemu:///system 系统级实例。如果普通用户执行提示权限不足，请在命令前添加 sudo。
  • 源虚拟机确认：本任务以第 6 课已创建并安装好的 Ubuntu Server 虚拟机 svr01 为克隆源母本。可先执行 virsh list --all 确认列表中存在 svr01。
  • 磁盘容量：完整克隆会复制整块虚拟磁盘的物理占用（约 2~4GB），开始前请确保宿主机存储池目录 /var/lib/libvirt/images 拥有至少 20GB 以上的剩余空间。

【动手做】检查状态并执行完整克隆

在宿主机终端中依次执行以下步骤，完成从源机 svr01 到候选模板 ubuntu-lab-template 的克隆与磁盘链验证：

# 1. 检查宿主机存储空间与源虚拟机 svr01 运行状态
df -h /var/lib/libvirt/images
virsh domstate svr01

# 2. 若 svr01 处于 running 状态，必须先发送优雅关机指令
virsh shutdown svr01

# 注意：关机需要几秒钟时间，请重复执行下面这条命令，直到状态确认为 shut off
virsh domstate svr01

# 3. 状态变为 shut off 后，执行 virt-clone 完整克隆，创建候选模板虚拟机
virt-clone \
  --original svr01 \
  --name ubuntu-lab-template \
  --auto-clone

# 4. 验证新模板的虚拟磁盘路径与 backing-chain 独立性
virsh domblklist ubuntu-lab-template --details
qemu-img info --backing-chain /var/lib/libvirt/images/ubuntu-lab-template.qcow2

参数拆解说明

  • --original svr01：指定作为克隆母本的源虚拟机名称。
  • --name ubuntu-lab-template：指定新克隆出的虚拟机 Domain 名称。
  • --auto-clone：指示 libvirt 自动生成全新的虚拟磁盘文件名（默认存放在同一存储池中，命名为 ubuntu-lab-template.qcow2）。

【看现象】输出观察

执行上述命令后，观察终端中的关键回显：

  1. virt-clone 执行过程输出：

    Allocating 'ubuntu-lab-template.qcow2'       |  20 GB  00:00:12
Clone 'ubuntu-lab-template' created successfully.

    观察要点：virt-clone 自动在存储池中分配了全新的 ubuntu-lab-template.qcow2 镜像文件，并在十几秒内完成了全量块数据的物理复制。

  2. qemu-img info --backing-chain 输出：

    image: /var/lib/libvirt/images/ubuntu-lab-template.qcow2
file format: qcow2
virtual size: 20 GiB (21474836480 bytes)
disk size: 2.85 GiB
cluster_size: 65536
Format specific information:
    compat: 1.1
    compression type: zstd

    观察要点：输出中没有任何 backing file 行，证明该 QCOW2 磁盘是一块 100% 独立的磁盘，与 svr01.qcow2 彻底解耦，即使后续修改或删除了 svr01，该模板镜像也不会受到任何影响。

通俗解析：什么是 backing file（母盘差量依赖）？

在 QCOW2 虚拟磁盘格式中，backing file 就像是在“原版教科书（母盘）”上盖了一张“透明硫酸纸（差量盘）”。你在差量盘上做的所有写操作都记在硫酸纸上，但读取内容时需要透过硫酸纸看底下的原版书。虽然这种“链接克隆”极度节省磁盘空间，但只要底下的原版书被不小心撕毁或涂改，所有硫酸纸上的笔记就会彻底失效报废。

而 virt-clone 执行的完整克隆，则是通过复印机整本复印出一本完全相同的新书（独立副本）。因此在 qemu-img info 中不会出现任何 backing file 行，代表两本教材各自独立、互不相欠，安全性与容错性最高。

【学原理与拓展】交付机制、COW 写时复制与克隆底层数据流

1. 虚拟机三大交付方式多维对比

在虚拟化与云计算体系中，从零部署虚拟机的常见方式对比如下：

交付方式操作流程与数据流交付耗时优势核心缺陷与风险适用场景
全新 ISO 安装挂载光盘镜像 ➔ 交互式选择语言、分区、账号 ➔ 逐包解压写入15 ~ 30 分钟身份天然干净独立，无历史包袱速度慢、重复算力消耗大、不同时期安装易导致软件版本配置漂移制作最初始的基准种子系统
直接完整克隆关机 ➔ virt-clone 物理复制 QCOW2 与 XML 配置10 ~ 30 秒秒级交付，软件包与环境 100% 相同来宾内部身份原样复制，直接运行会导致严重的局域网与集群冲突单机离线备份或故障副本暂存
黄金模板派生标准系统 ➔ 去泛化清理（cloud-init clean） ➔ 固化模板 ➔ 克隆派生10 ~ 30 秒既拥有秒级交付速度，又能在开机时自动生成全新独立身份需要严格遵守模板只读与维护规范企业私有云、生产集群批量部署

2. 完整克隆（Full Clone）vs 链接克隆（Linked Clone）底层数据流与 COW 机制

在 QEMU/KVM 底层，虚拟磁盘的克隆主要分为两类截然不同的实现方式：

  • 完整克隆（Full Clone）的数据流与底层结构：
    • virt-clone 在执行时，调用底层的块设备复制接口，将源镜像文件中的所有已分配簇（Clusters）进行逐块物理复制（Block-by-Block Copy）；
    • 新生成的 QCOW2 文件拥有完全独立的 Header、L1/L2 查找表以及独立分配的数据簇；
    • 独立性：克隆完成后，克隆机与母机在物理存储上彻底切断联系，源盘的损坏或删除绝不会影响新虚拟机。
  • 链接克隆（Linked Clone）的 COW（Copy-on-Write，写时复制）机制：
    • 链接克隆通过 qemu-img create -f qcow2 -F qcow2 -b Base.qcow2 Overlay.qcow2 创建；
    • 读取流程：当虚拟机尝试读取某个扇区时，QEMU 首先查询 Overlay 盘的 L2 表。如果该扇区在 Overlay 中已写入（已修改），则直接从 Overlay 读取；如果尚未被修改，则沿着 backing_file 指针回溯到 Base 基础镜像中读取原始数据；
    • 写入流程（COW）：当虚拟机首次向某个扇区写入新数据时，QEMU 不会修改 Base 镜像（Base 保持只读），而是在 Overlay 盘中临时分配一个新的 Cluster（通常为 64KB），将修改后的数据写入 Overlay，并在 Overlay 的 L2 表中建立新映射。后续针对该位置的读写都直接在 Overlay 上进行。

下表总结了两种克隆模式的多维度对比：

对比维度完整克隆（Full Clone）链接克隆（Linked Clone）
物理存储占用每次克隆占用源机全部实际数据量（约 2~4GB/台）极小，初期每台差量盘仅几百 KB ~ 几十 MB
创建耗时取决于磁盘大小与 I/O 速度，通常 10 ~ 30 秒瞬间完成（毫秒级创建 Overlay 文件）
母盘容错隔离性100% 独立解耦，母盘删除或修改无任何影响强依赖，母盘一旦损坏或被误修改，所有子机全部崩溃
I/O 链条深度单层直读直写，性能稳定损耗小读操作可能经历多层回溯，随差量膨胀存在轻微 I/O 开销
生产适用场景生产服务器、长期运行的独立业务 VM、模板固化自动化 CI/CD 测试流水线、学生短期实验沙箱、VDI 桌面云

3. 关键技术辨析：禁止直接使用 Linux cp 命令拷贝虚拟磁盘的底层原理

很多初学者可能会产生疑问：“虚拟磁盘在 Linux 宿主机上就是一个 .qcow2 文件，为什么不能直接在宿主机执行 cp svr01.qcow2 clone.qcow2 呢？”

在虚拟化架构中，直接使用 cp 拷贝存在三大严重缺陷与风险：

  1. QEMU 文件锁与元数据破坏风险： 当虚拟机处于运行状态时，QEMU 进程会对 QCOW2 文件持有排他文件锁（File Lock），并且内存中有大量尚未落盘的脏页（Dirty Pages）。此时直接用 cp 拷贝出来的文件处于元数据不一致状态，极易导致克隆出来的镜像在开机引导时出现文件系统损坏（Kernel Panic 或 Emergency Mode）。
  2. 稀疏文件（Sparse File）与空洞（Hole）膨胀问题： QCOW2 和 RAW 磁盘通常包含大量未分配的空洞（Holes）。普通的 cp 命令如果没有带特殊参数（如 --sparse=always），在读取空洞时会将其填充为实际的二进制零并写入磁盘，导致原本仅占用 2.8GB 的精简置备镜像在复制后物理空间瞬间膨胀为完整的 20GB，大量挤占宿主机存储。
  3. libvirt Domain XML 身份缺失与冲突： 虚拟机的完整定义由“虚拟磁盘文件”与“Domain XML 配置文件”共同构成。直接 cp 磁盘文件并没有在 libvirt 中注册新的虚拟机对象；如果管理员手动复制 XML 文件并导入，又会导致虚拟机名称（Name）、硬件 UUID、网卡 MAC 地址与原虚拟机完全重名与冲突。 而 virt-clone 不仅安全地复制磁盘数据，还会自动为新虚拟机生成独立的 Domain XML、分配全新的 UUID 与 MAC 地址，并在 libvirt 体系中完成注册。

4. 关机门禁铁律与数据一致性保护

正如前面所述，QEMU 在运行期间维护着活跃的文件系统事务。因此，在执行克隆前必须确认源虚拟机处于 shut off 状态，这是保证克隆镜像数据完整性与文件系统一致性的安全铁律。

7.2 任务二：探寻身份冲突——宿主侧与来宾侧多重身份解密

通过 virt-clone 成功克隆出虚拟机后，很多初学者会误以为“两台机器已经完全独立，可以直接并网运行了”。为了看清隐藏在系统内部的隐患，我们需要同时启动两台虚拟机进行对比实验。

实用操作技巧：如何登录来宾控制台并返回宿主机？

在宿主机终端执行 virsh console <虚拟机名> 即可连接来宾系统的文本控制台：

  • 激活提示符：连接后若屏幕暂时静止无回显，敲击一次回车键即可唤出 login: 登录提示符；
  • 用户登录：输入在第 6 课安装系统时设置的管理员用户名与密码；
  • 安全退出：完成内部命令操作后，按下快捷键 Ctrl + ]（macOS 用户按 Control + ]），即可立即脱离虚拟机控制台，安全返回宿主机终端。

【动手做】同时开机并对比多重身份

在宿主机终端与虚拟机内部执行以下操作，复现身份冲突现象：

# 1. 在宿主机终端同时启动两台虚拟机
virsh start svr01
virsh start ubuntu-lab-template

# 2. 在宿主机终端比对两台虚拟机的宿主侧身份（Domain、UUID、MAC、磁盘）
for vm in svr01 ubuntu-lab-template; do
  echo "==================== Domain: $vm ===================="
  virsh dominfo $vm | grep -E "Name|UUID|State"
  virsh domiflist $vm
  virsh domblklist $vm --details
done

分别通过 virsh console（或 SSH）登录到 svr01 与 ubuntu-lab-template 虚拟机内部，执行以下内部身份查询命令：

# 在虚拟机内部执行（分别登录 svr01 与 ubuntu-lab-template 运行）
echo "Hostname: $(hostnamectl --static)"
echo "Machine ID: $(cat /etc/machine-id)"
ip -4 -br addr show scope global

观察完毕后，按下 Ctrl + ] 返回宿主机终端，安全关闭源机 svr01，保持其作为基准不被改动：

# 在宿主机终端安全关闭 svr01
virsh shutdown svr01

【看现象】输出观察与对比

两台虚拟机运行后的宿主侧与来宾侧各项关键身份对比如下表所示：

身份指标所在层级源机 svr01克隆机 ubuntu-lab-template对比结果
Domain 名称宿主 Hypervisorsvr01ubuntu-lab-template完全独立（libvirt 虚拟机外壳唯一标识）
libvirt UUID宿主硬件层a1b2c3d4-e5f6-...f8e7d6c5-b4a3-...完全独立（硬件 UUID 重新随机生成）
磁盘镜像路径宿主存储层/var/lib/.../svr01.qcow2/var/lib/.../ubuntu-lab-template.qcow2完全独立（物理上完全解耦的独立文件）
虚拟网卡 MAC宿主网络层52:54:00:12:34:5652:54:00:ab:cd:ef完全独立（二层物理地址重新随机生成）
主机名 Hostname来宾系统内部svr01svr01严重重复！（完全继承源机）
systemd machine-id来宾系统内部e4d3c2b1...e4d3c2b1...严重冲突！（32位全局唯一标识完全相同）
IP / Netplan 配置来宾网络协议栈192.168.122.101192.168.122.188 (DHCP)依赖 DHCP 时暂不相同，若为静态 IP 则冲突

【学原理与拓展】身份体系拆解与三大分布式冲突灾难推导

1. 宿主侧 vs 来宾内部的 Hypervisor 隔离屏障

virt-clone 是一个纯粹运行在宿主机用户态的管理工具。它通过调用 libvirt API 复制 XML 配置文件与磁盘镜像文件，并为宿主侧所关心的 Domain 名称、硬件 UUID、虚拟网卡 MAC 地址自动生成新的随机值。

但是，Hypervisor 与虚拟磁盘内部的文件系统之间存在天然的隔离屏障。virt-clone 无法也不会被允许去挂载虚拟机的根文件系统并擅自修改 /etc/hostname 或 /etc/machine-id。

2. /etc/machine-id 的核心作用与三大企业级冲突灾难

/etc/machine-id 是现代 Linux（systemd）操作系统中至关重要的 32 位十六进制全局唯一标识符（由 128 位随机数生成）。它是整个操作系统实例在分布式网络中的“数字身份证”。一旦多台克隆机器带着相同的 machine-id 在同一网络中运行，将引发以下三大破坏性灾难：

灾难一：Kubernetes 集群节点注册覆盖与 Pod 震荡灾难
  • 触发机制：在 Kubernetes 集群中，工作节点上的 kubelet 守护进程启动时，会读取 /etc/machine-id（结合 DMI UUID）作为该 Node 对象的唯一物理标识（Node UID）。
  • 破坏后果：当运维人员利用未清理的模板克隆出 Node2 并加入集群时，由于 Node2 与既有的 Node1 具有相同的 machine-id，Kubernetes API Server 会将 Node2 判定为“Node1 重新上线并上报了新的状态”。API Server 会将 Node1 的状态覆盖为 Node2 的 IP，随后发现 Node1 原有的心跳中断，判定 Node1 为 NotReady，并在整个集群中发起 Pod 驱逐；紧接着 Node1 的 kubelet 再次上报心跳，又将 Node2 覆盖掉。两台物理节点在控制平面互相踢掉对方，导致集群调度器混乱，业务 Pod 在两台机器之间疯狂漂移和重启。
灾难二：systemd-journald 集中式日志追踪失效与交叉污染
  • 触发机制：systemd-journald 服务将本地二进制系统日志写入 /var/log/journal/<machine-id>/ 目录中。而在现代企业级可观测性体系（如 Promtail -> Loki、Filebeat -> Elasticsearch、Vector）中，日志采集 Agent 通常直接以 /etc/machine-id 作为主机的唯一索引标识。
  • 破坏后果：由于多台虚拟机的 machine-id 完全相同，日志收集服务端会将来自不同业务节点（例如一台跑数据库、一台跑 Web）的日志混合写入同一个时间流中。由于时钟微秒级差异，日志时间戳严重错乱，数据库的错误日志与 Web 服务的访问日志混杂在一起，导致监控告警误报、根本原因定位彻底失效。
灾难三：DHCP DUID 抢占与网络断连震荡灾难
  • 触发机制：在现代 Linux（使用 systemd-networkd 或 NetworkManager 的 Ubuntu 系统）中，DHCP 客户端向网络中的 DHCP 服务器申请 IP 地址时，默认不再仅仅使用网卡 MAC 地址，而是生成 RFC 3315 / RFC 8415 规定的 DUID（DHCP Unique Identifier）。默认的 DUID-UUID 算法直接强依赖 /etc/machine-id。
  • 破坏后果：虽然两台虚拟机的虚拟网卡 MAC 地址在宿主机层面不同，但向 DHCP 服务器发送 DHCPREQUEST 时出示的 DUID 却完全相同。DHCP 服务器判定“这是同一台设备更换了网卡接口”，于是将原本分配给 A 机的 IP 强行收回并改发给 B 机；A 机检测到 IP 冲突或租约异常后再次发起请求，又把 IP 抢回。两台虚拟机在局域网内疯狂争抢同一个 IP 地址，引发周期性网络丢包与断连震荡。

通俗解析：三大灾难的生动生活比喻

为了彻底理解为什么底层 machine-id 绝不能重复，我们可以用三个生活化场景来类比：

  1. Kubernetes 节点覆盖（共用身份证打卡）：两个人拿着同一张身份证去公司考勤机打卡，A 刚刷完进门，B 接着刷同一张卡，系统误以为“A 换了个工位”，主管以为 A 旷工把 A 的办公桌清空搬走；A 再次打卡又把 B 顶替，两人在办公室疯狂抢工位！
  2. 日志交叉污染（混装日记本）：财务小张与厨师老李各自写工作日记，但封面都印着同一个身份证号，档案管理员把两本日记撕开混装在同一个档案袋里。审计员翻开一看，上一页是“收到货款 10 万元”，下一页紧接着“买白菜花费 20 元”，账目彻底陷入逻辑崩溃！
  3. DHCP DUID 抢占（临时工牌与身份证）：MAC 地址好比员工佩戴的临时出入证，而 /etc/machine-id 生成的 DUID 好比法定身份证。如果两台克隆机戴着不同的临时工牌（MAC 不同），但向门卫登记时出示的是同一张身份证，门卫就会误以为“这是同一个人换了件外套又来办业务”，把同一把办公室钥匙在两人手中来回抢夺，导致两人轮流被关在门外断网！

为了直观体验多重身份在未清理与修复状态下的对比，请操作以下交互式动画：

六大身份解密

虚拟机克隆身份体系：宿主 vs 来宾内部边界透视

对比 Domain 名称、UUID、磁盘路径、MAC 地址（宿主侧自动处理）与 hostname、/etc/machine-id、IP 地址（来宾内部需清理）的独立性与冲突机制。

步骤 1 / 5
当前观察点

基准源机：svr01 身份档案

Standard Source Machine Baseline

标准源虚拟机 svr01 已经安装完毕并处于 shut off 关机状态，拥有完整的宿主侧硬件参数和来宾系统内部配置。

🖥️
标准源机 (Source)

svr01

shut off
2 vCPU / 2048 MiBUbuntu 26.04 Server
virt-clone
➔
直接克隆未清理
📋
克隆副本 (Raw Clone)

ubuntu-lab-template

running (存在隐患)
继承源机配置内部 ID 冲突

虚拟机六大身份独立性与冲突核验表

当前模式：未清理冲突模式
宿主侧Domain 名称
源机 svr01:svr01
克隆目标:ubuntu-lab-template
✓ 独立

virt-clone 自动赋予新名称，宿主侧唯一

宿主侧libvirt UUID
源机 svr01:a1b2c3d4-e5f6-7890-abcd-111111111111
克隆目标:f8e7d6c5-b4a3-2109-fedc-222222222222
✓ 独立

virt-clone 随机生成新 UUID，宿主唯一

宿主侧虚拟磁盘路径
源机 svr01:/var/lib/libvirt/images/svr01.qcow2
克隆目标:/var/lib/libvirt/images/ubuntu-lab-template.qcow2
✓ 独立

100% 独立磁盘文件，无 backing file 依赖

宿主侧网卡 MAC 地址
源机 svr01:52:54:00:12:34:56
克隆目标:52:54:00:ab:cd:ef
✓ 独立

libvirt 分配全新随机 MAC，二层隔离

来宾内部主机名 (Hostname)
源机 svr01:svr01
克隆目标:svr01
✕ 冲突踩踏

完全照搬源机！多台实例在局域网内名字完全混淆

来宾内部systemd machine-id
源机 svr01:e4d3c2b1000000000000000000000001
克隆目标:e4d3c2b1000000000000000000000001 (重复!)
✕ 冲突踩踏

致命冲突！/etc/machine-id 相同导致 journald 日志/DHCP 踩踏

来宾内部IP 地址 (DHCP/静态)
源机 svr01:192.168.122.101
克隆目标:192.168.122.101 (若静态则冲突)
✕ 冲突踩踏

若源机配置静态 IP 则发生 IP 抢占断网；DHCP 因相同 DUID 易冲突

关键避坑与原理洞察源机基准的重要性

虚拟机包含两层身份体系：一层由宿主机 Hypervisor（libvirt/QEMU）管理，另一层存在于 Guest 操作系统磁盘内部。

7.3 任务三：制作黄金模板——cloud-init 状态清理与系统去重

为了彻底根除克隆带来的内部身份冲突，虚拟化运维的标准流程是制作黄金模板（Golden Template）。我们需要在模板虚拟机内部执行“去泛化（Generalization）”操作，清除所有旧实例的痕迹。

【动手做】执行 cloud-init 清理与黄金模板固化

通过 virsh console ubuntu-lab-template 登录到 ubuntu-lab-template 虚拟机内部，执行主机名重置、cloud-init 清理与安全关机：

# 【以下命令均在 ubuntu-lab-template 虚拟机内部执行】

# 1. 将主机名设置为通用的模板维护标识
sudo hostnamectl set-hostname ubuntu-lab-template

# 2. 执行 cloud-init clean 清理实例缓存并重置 machine-id 为未初始化状态
sudo cloud-init clean --machine-id

# 3. 立即执行安全关机，完成模板固化（严禁在此刻重启！）
sudo systemctl poweroff

关键避坑指南：清理后严禁重启，必须立即 poweroff 关机！

在虚拟机内部执行 sudo cloud-init clean --machine-id 之后，千万不要执行 reboot 重启！ 如果执行了重启，系统在引导启动阶段会自动探测到 machine-id 为空，并立即生成一个新的 machine-id 和 cloud-init 缓存，刚才所做的去泛化清理将瞬间前功尽弃！ 因此，清理完成后必须紧接着执行 sudo systemctl poweroff 立即关机固化，让模板保持在纯净的“出厂封存状态”。

虚拟机完全断电后，控制台会自动断开返回宿主机。在宿主机终端验证模板是否已经处于安全的关机状态：

# 【在宿主机终端执行】
# 4. 验证 ubuntu-lab-template 已完全关机
virsh domstate ubuntu-lab-template

【看现象】输出观察

  1. sudo cloud-init clean --machine-id 执行现象： 命令执行后，终端静默返回或打印清理日志。此时若查看 /etc/machine-id 文件：

    ls -l /etc/machine-id
cat /etc/machine-id

    观察要点：/etc/machine-id 文件大小变为 0 字节（或内容被替换为 uninitialized 标志）。同时，/var/lib/cloud/instances/ 下的历史实例目录被全部清除。

  2. 宿主机端状态确认： virsh domstate ubuntu-lab-template 明确返回 shut off。

【学原理与拓展】cloud-init 四阶段流水线与黄金模板五项运维铁律

1. cloud-init 四阶段执行流水线架构（4-Stage Pipeline）深度剖析

Ubuntu Server 默认深度集成了 cloud-init 作为其云原生初始化引擎。理解 cloud-init 的执行生命周期，是掌握现代操作系统自动化配置的关键。cloud-init 在系统开机时被划分为清晰的四个执行阶段：

  • Stage 1: Local 阶段（cloud-init-local.service）：
    • 运行条件：在根文件系统挂载后、网络启动前极早阶段执行。
    • 职责：扫描本地即插即用数据源（如 NoCloud、ConfigDrive、内核 cmdline）。如果找到了网络配置定义，在此阶段直接生成 /etc/netplan/ 配置文件，使得后续网络服务能直接读取并拉起网络。
  • Stage 2: Network 阶段（cloud-init.service）：
    • 运行条件：在网络服务（network.target）完全就绪后执行。
    • 职责：通过网络请求远程元数据服务（如 AWS IMDS、OpenStack Metadata）或解析本地完整配置；根据配置设定系统的主机名（Hostname），并自动将其与 127.0.1.1 的映射写入 /etc/hosts。
  • Stage 3: Config 阶段（cloud-config.service）：
    • 运行条件：在绝大多数核心系统服务启动期间运行。
    • 职责：执行各种具体的配置模块（cc_* 模块），例如调用 growpart 自动扩展根分区并调整文件系统大小、在目标用户目录下写入 ~/.ssh/authorized_keys 注入管理员公钥、配置 APT 国内镜像软件源等。
  • Stage 4: Final 阶段（cloud-final.service）：
    • 运行条件：在操作系统几乎全部启动完成、进入 multi-user.target 的最后时刻执行。
    • 职责：执行耗时较长的定制任务，例如自动下载并安装软件包列表（packages 字段）、执行管理员编写的 runcmd / bootcmd Shell 脚本，最后在 /var/lib/cloud/instance/boot-finished 写入标记文件，向外部发送启动完成信号。

通俗解析：cloud-init 四阶段流水线就像“新房精装交付四步走”

为了轻松记住这四个阶段的先后顺序与底层逻辑，可以将其类比为房屋交付流程：

  1. Stage 1: Local 本地阶段（毛坯水电管线预埋）：此时系统还没通外网，先根据本地施工图纸（本地数据源）把基础管线（Netplan 网络配置文件）在通网前铺好；
  2. Stage 2: Network 网络阶段（接通外网与钉门牌号）：外部网络接通，联网获取业主数据，正式挂上专属门牌号（Hostname），并登记在小区名录（/etc/hosts）上；
  3. Stage 3: Config 配置阶段（搬入家具与配大门钥匙）：基础系统就绪，自动把房间按需扩建（磁盘 growpart 自动扩容）、配发业主大门钥匙（注入 SSH 公钥）、创建家庭成员账号（创建用户）；
  4. Stage 4: Final 交付阶段（全屋保洁与交付剪彩）：系统即将完全就绪，安装指定应用软件（packages 列表）、执行业主特别吩咐的入住脚本（runcmd），最后在门口贴上“验收合格竣工证”（写入 boot-finished 标记）。

2. cloud-init clean --machine-id 底层清除清单剖析

当我们执行 sudo cloud-init clean --machine-id 时，系统底层完成了以下高精度的清理操作：

  1. 截断 machine-id：清空 /etc/machine-id 与 /var/lib/dbus/machine-id，将其重置为 0 字节或 uninitialized 标志；
  2. 清除实例元数据缓存：递归删除 /var/lib/cloud/data/、/var/lib/cloud/instance/ 与 /var/lib/cloud/instances/*，使 cloud-init 彻底忘记曾经运行过的实例身份；
  3. 重置执行信号量：清空 /var/lib/cloud/sem/ 状态锁，确保下一次开机时，cloud-init 的全部四个阶段与所有配置模块能够重新按全新实例被触发；
  4. 清除网络临时租约：清除 DHCP 客户端的临时租约记录，确保下次开机向网络发起全新的初始广播。

通俗解析：什么是“去泛化（Generalization）”？

“去泛化”就像智能手机出厂前的“恢复出厂设置并封盒入库”：

  1. 抹掉上一任测试员的所有操作痕迹和实例缓存；
  2. 将手机序列号标记为“未激活”；
  3. 封盒关机（固化为 Golden Template）。

当这台手机被下一位使用者首次通电开机（First Boot）时，系统才会像新手机激活向导一样，自动为它生成全新的专属身份！

3. 黄金模板（Golden Template）五项运维铁律

制作完成的黄金模板是整个机房与集群的“母盘”，所有运维人员必须严格恪守以下五项运维铁律：

黄金模板五项运维铁律

  1. 无残留静态配置：网络配置必须保留为干净的 DHCP 动态模式，严禁硬编码静态 IP、固定网关或私有 DNS；
  2. 无个人密钥与认证痕迹：清空 /root/.ssh/ 与普通用户的 authorized_keys，清空 ~/.bash_history 与临时认证 Token；
  3. 无历史日志与系统缓存：清空 /var/log 下的历史归档日志，执行 sudo apt-get clean 清除软件包缓存；
  4. 状态去泛化固化：在关机前必须标准执行 sudo cloud-init clean --machine-id，将系统置于去泛化的就绪状态；
  5. 常年保持 shut off 关机：黄金模板只用于作为 virt-clone 的克隆源，平时必须常年保持关机状态，严禁直接开机运行任何业务。

我们可以通过以下流水线动画，完整回顾从源机制作黄金模板再到批量派生的全生命周期：

流水线全景

虚拟机模板化生产流水线：从源机到黄金模板与批量派生

动态演示 svr01 安全关机 ➔ 制作候选模板 ➔ cloud-init clean 去重 ➔ 固化黄金模板 ➔ 极速派生 lab01 ➔ 首次启动自动新生 的 6 大标准工序。

工序 1 / 6
工序 1📍 Host (宿主机终端)
svr01: shut off

源机准备：ACPI 优雅关机

克隆的第一道安全门禁：必须确保源虚拟机已平滑关机。未刷盘缓存写入 QCOW2 镜像并释放文件锁，杜绝磁盘数据损坏与元数据撕裂。

执行命令与关键输出
virsh shutdown svr01
virsh domstate svr01 # 确认输出: shut off
💾底层虚拟磁盘与镜像状态映射
svr01.qcow2 (一致性锁解除，干净就绪)
架构深度洞察为什么严禁开机时直接克隆？

若虚拟机在运行中被克隆，内存中的脏页未写入磁盘，克隆出的镜像相当于经历了一次断电崩溃，极易发生根分区损坏。

7.4 任务四：从模板极速派生——批量交付 lab01 与 NoCloud 企业级自动化

黄金模板固化后，我们就可以利用它在十几秒内极速派生出全新的、且内部身份完全独立的业务虚拟机 lab01。

交付规格参数表

虚拟机名称来源母本vCPU / 内存虚拟磁盘镜像路径预期 Hostname预期 Machine-ID网络模式
lab01ubuntu-lab-template2 核 / 2048 MiB/var/lib/libvirt/images/lab01.qcow2lab01开机自动生成全新 32 位 IDdefault (NAT) 独立 DHCP

【动手做】派生 lab01 并验收身份独立性

在宿主机终端中执行派生命令并启动 lab01：

# 1. 在宿主机终端从黄金模板派生出 lab01
virt-clone \
  --original ubuntu-lab-template \
  --name lab01 \
  --auto-clone

# 2. 启动全新派生的 lab01 虚拟机
virsh start lab01

登录到 lab01 虚拟机内部（在宿主机执行 virsh console lab01，按回车激活并输入登录账号密码），执行首次启动身份配置与验证：

为什么需要为派生机配置专属主机名？

从黄金模板克隆出的新虚拟机 lab01 首次开机时，systemd 会自动为其生成全新的 machine-id，但其内部主机名仍会继承模板名 ubuntu-lab-template。为了在多节点网络环境中准确区分业务节点，我们在首次登录后执行 sudo hostnamectl set-hostname lab01 将其修改为专属主机名。

# 【以下命令在 lab01 虚拟机内部执行】

# 3. 验证 machine-id 是否已由 systemd 自动新生
cat /etc/machine-id

# 4. 设置 lab01 专属业务主机名
sudo hostnamectl set-hostname lab01

# 5. 验证网络接口与 DHCP 获取到的独立 IP 地址
ip -4 -br addr show scope global

查看完毕后，按下 Ctrl + ] 返回宿主机终端，运行全量巡检脚本，比对三台虚拟机的各项身份指标：

# 【在宿主机终端执行】
# 6. 执行跨机器全量身份比对
for vm in svr01 ubuntu-lab-template lab01; do
  echo "==================== Domain: $vm ===================="
  virsh domstate $vm
  virsh domuuid $vm
  virsh domiflist $vm
  virsh domblklist $vm --details
done

【看现象】输出观察与验收结论

  1. lab01 内部 machine-id 验证： 在 lab01 内执行 cat /etc/machine-id，输出为一个与 svr01 截然不同的全新哈希值（例如 9f8e7d6c5b4a3210fedcba9876543210），证明 cloud-init 与 systemd 的首次启动重生机制完美生效！
  2. 全量身份独立性验收：
    • svr01、ubuntu-lab-template 与 lab01 的 Domain 名称、UUID、磁盘路径、MAC 地址 100% 互不相同；
    • lab01 的主机名为 lab01，与 svr01 互不干扰；
    • lab01 的 machine-id 唯一且独立；
    • lab01 通过 DHCP 成功获取到了专属的局域网 IP 地址，网络通信正常。

【学原理与拓展】First Boot 重生机制与 NoCloud 企业级全自动交付

1. First Boot（首次启动）去泛化激活机制闭环

当以黄金模板为基础派生出的 lab01 第一次通电引导时，系统在启动早期阶段依次完成以下自动化闭环：

  1. 内核与 systemd 初始化：Linux 内核完成硬件自检，启动 systemd（PID 1）；
  2. 熵池采集与 ID 新生：systemd-machine-id-setup 探测到 /etc/machine-id 为空（或标记为 uninitialized），立即从内核熵池（KVM VirtIO-RNG 随机数发生器）读取 128 位硬件熵，计算生成全新的 32 位十六进制 UUID 并固化写入 /etc/machine-id；
  3. 网络与协议栈就绪：systemd-networkd 与 DHCP 客户端基于全新的 machine-id 动态计算生成专属的 DUID，向网关申请独立的 IP 租约；
  4. cloud-init 激活初始化：cloud-init 检测到新的实例环境，重新执行全生命周期配置。

2. 企业级拓展：NoCloud 数据源与 cidata.iso 无人值守自动化注入

在大型公有云或私有云平台中，运维工程师通常不需要手动登录每台虚拟机去执行 hostnamectl 或配置用户。cloud-init 支持一种非常强大的轻量级本地数据源——NoCloud 数据源。

通过在宿主机制作一张包含了 meta-data 和 user-data 的极小 ISO 光盘镜像（卷标必须为 cidata），并挂载给新虚拟机，虚拟机开机时 cloud-init 的 Local 阶段就会自动读取该光盘，在 5 秒内全自动完成主机名、网络、用户与 SSH 密钥的注入。

通俗解析：什么是 NoCloud cidata.iso？

它就像给新电脑开箱时附赠的“自运行配网 U 盘”： 只要把包含配置说明书（meta-data 实例元数据和 user-data 初始化配置）的极小虚拟光盘插入虚拟机光驱，虚拟机在首次开机通电的 5 秒内，就会全自动把主机名、网络、用户账号与 SSH 密钥全部配置就绪，运维工程师甚至不需要敲击一行键盘！

（1）meta-data 配置文件语法

meta-data 主要用于描述实例的基础元数据：

# meta-data 文件内容示例
instance-id: lab01-instance-001
local-hostname: lab01
（2）user-data 配置文件语法（cloud-config）

user-data 遵循 #cloud-config 规范，用于定义用户、认证与自定义执行脚本：

#cloud-config
# user-data 文件内容示例
users:
  - name: ubuntu
    sudo: ALL=(ALL) NOPASSWD:ALL
    shell: /bin/bash
    ssh_authorized_keys:
      - ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... admin@company.com

# 自动扩展根文件系统
growpart:
  mode: auto
  devices: ['/']

# 自定义开机执行命令
runcmd:
  - echo "Instance lab01 initialized successfully at $(date)" > /etc/motd
（3）生成 cidata.iso 并挂载启动的完整自动化流水线

在宿主机中，可通过 genisoimage 或 cloud-localds 工具生成 ISO 并挂载：

# 在宿主机制作 cidata.iso 并挂载给虚拟机的操作流程示例（供拓展阅读）
# 1. 创建包含配置的 ISO 镜像（卷标必须为 cidata）
genisoimage -output cidata-lab01.iso -volid cidata -joliet -rock meta-data user-data

# 2. 将 cidata.iso 作为虚拟光驱挂载并启动虚拟机
virt-install \
  --name lab01 \
  --memory 2048 \
  --vcpus 2 \
  --disk path=/var/lib/libvirt/images/lab01.qcow2,bus=virtio \
  --disk path=/var/lib/libvirt/images/cidata-lab01.iso,device=cdrom \
  --osinfo detect=on,require=off \
  --network network=default,model=virtio \
  --import --noautoconsole

虚拟机首次启动时，cloud-init 会自动从 cidata.iso 读取配置，完成全自动初始化。

3. 批量交付进阶：Shell 循环秒级派生集群

掌握了黄金模板克隆技术后，若需要为班级或测试团队交付 5 台服务器（lab01 ~ lab05），只需在宿主机编写几行简单的 Shell 循环即可实现全自动化秒级交付：

# 批量极速派生 5 台独立实验机示例（在宿主机终端执行）
for i in $(seq -w 1 5); do
  echo "正在派生 lab$i..."
  virt-clone --original ubuntu-lab-template --name "lab$i" --auto-clone
  virsh start "lab$i"
done

7.5 常见问题排错矩阵 (Ubuntu 26.04 专属排错)

在 Ubuntu 26.04 LTS（libvirt 12.0+、QEMU 9.0+、cloud-init）环境下进行克隆与模板实训时，常见故障与排错方案如下：

故障现象根因分析检查定位命令修复与对策
virt-clone 报错 ERROR Domain 'svr01' is still running源虚拟机未关机，libvirt 为防止磁盘数据损坏触发安全拦截virsh domstate svr01在宿主机执行 virsh shutdown svr01，等待状态确认为 shut off 后再克隆
virt-clone 报错 ERROR Domain '...' already exists宿主机已存在同名的虚拟机定义或残留 XMLvirsh dominfo <名称>更换新名称，或使用 virsh undefine <旧名称> 移除废弃虚拟机定义
克隆过程中提示 No space left on device宿主机存储池物理磁盘空间不足df -h /var/lib/libvirt/images清理宿主机无用的大文件或快照，确保存储目录有至少 20GB 以上可用空间
连接 virsh console 控制台后屏幕卡住无任何反应控制台尚未激活串行 TTY 通信观察屏幕终端敲击一次回车键即可唤出 login: 登录提示符；若想退出按快捷键 Ctrl + ]
lab01 启动后 machine-id 依然与 svr01 一模一样模板制作时遗漏了 cloud-init clean --machine-id 或清理后又开机运行了业务在来宾内部执行 cat /etc/machine-id在 ubuntu-lab-template 内重新执行 sudo cloud-init clean --machine-id 并立即关机，重新克隆派生
两台虚拟机 MAC 地址不同但获取到了相同的 IP 地址源机内部残留了写死的静态 IP 配置，或静态网络文件未改为 DHCP来宾内部执行 ip -4 -br addr，检查 /etc/netplan/*.yaml编辑 Netplan 配置文件，将网卡设置为 dhcp4: true，执行 sudo netplan apply
登录 lab01 控制台时卡在 cloud-init 等待界面cloud-init 正在首次启动尝试连接数据源或检索网络元数据cloud-init status --long属于正常网络探测现象，稍等 10~15 秒即可自动跳过进入登录提示符
qemu-img info 检查发现存在 backing file 行误使用了 qemu-img create -b 差量方式而非 virt-clone 完整克隆qemu-img info --backing-chain <磁盘路径>若需要完全独立镜像，使用 qemu-img convert -O qcow2 <差量盘> <新独立盘> 进行合并固化

7.6 提交内容

完成本课实训后，请提交以下 3 张核心终端验收截图：

  • 截图 1：virt-clone 完整克隆与独立磁盘验证
    • 在宿主机执行 virt-clone --original svr01 --name ubuntu-lab-template --auto-clone 成功创建；
    • 紧接着执行 qemu-img info --backing-chain /var/lib/libvirt/images/ubuntu-lab-template.qcow2，截图中清晰展示 file format: qcow2 且无 backing file 依赖。
  • 截图 2：身份冲突复现与黄金模板去重固化
    • 同时启动两台机器，内部执行 cat /etc/machine-id 证实两台机器拥有完全相同的 32 位 ID（复现冲突）；
    • 随后在 ubuntu-lab-template 内部执行 sudo cloud-init clean --machine-id 并安全关机，宿主机执行 virsh domstate ubuntu-lab-template 显示 shut off。
  • 截图 3：lab01 首次启动新生 ID 与三节点全量巡检
    • 在 lab01 内部执行 cat /etc/machine-id（显示新生的唯一 ID）与 hostnamectl（显示 lab01）；
    • 在宿主机终端执行 for 循环巡检脚本，截图中清晰展示 svr01、ubuntu-lab-template、lab01 三台虚拟机的 Domain 名称、UUID、MAC 与磁盘路径完全独立。

本章小结

在本课中，我们从单台虚拟机的繁琐安装演进到了工业级的“黄金模板 + 极速克隆”自动化交付体系：

  1. 掌握了 virt-clone 完整克隆与底层数据流：理解了完整克隆（Full Clone）在物理存储上的独立性，对比了与链接克隆（Linked Clone）及 COW 写时复制机制的本质区别，剖析了不可直接使用 cp 拷贝磁盘的底层原因，严格恪守了源机必须处于 shut off 关机状态的安全门禁，学会使用 qemu-img info --backing-chain 验证磁盘独立性；
  2. 看清了虚拟机多重身份体系与三大灾难：深刻认识到 Hypervisor 隔离屏障的存在——宿主侧身份（Domain、UUID、磁盘、MAC）由 virt-clone 自动处理，而内部身份（hostname、/etc/machine-id、IP / Netplan）必须由运维人员主动介入去重；深度推导了 machine-id 冲突引发的 Kubernetes 节点互踢、journald 日志污染与 DHCP DUID 抢占三大分布式灾难；
  3. 拆解了 cloud-init 四阶段流水线与黄金模板铁律：深入理解了 cloud-init 从 Generator、Network、Config 到 Final 的 4-Stage 执行架构，掌握了 sudo cloud-init clean --machine-id 的底层清理细节，牢固树立了黄金模板五项运维铁律；
  4. 达成了秒级实例批量交付与自动化拓展：体验了从黄金模板到 lab01 的极速派生，见证了 systemd 在 First Boot 阶段自动新生 machine-id 的全过程，探索了 NoCloud cidata.iso 企业级全自动无人值守交付方案，完成了 100% 独立性的闭环验收。

在下一课中，我们将基于本课交付的多台独立虚拟机，学习搭建隔离虚拟网络与 Linux 虚拟交换机（Linux Bridge），探索虚拟机在不同网络拓扑下的互联与二层隔离！