29. 系统迁移与升级

本章介绍 RHEL 9 的系统迁移与升级操作：虚拟机克隆迁移、在线与离线安全补丁升级、dnf history 事务回滚，以及内核版本管理。生产环境的迁移与升级需要严格的流程控制，本章提供可操作的标准化步骤。

29.1 前提条件

已完成第五阶段前序配置（第 27–28 章）。
通过 SecureCRT（SSH 端口 2222）以 ops 用户、密钥认证方式登录 192.168.1.100，执行 sudo -i 切换至 root 环境。
官方仓库已启用（第 7 章）；/boot 分区剩余空间 ≥ 500 MB。

操作前必做

任何迁移或升级操作前，在 VMware 中创建命名快照（格式：RHEL9-Before-<操作>-<日期>），确保有可回滚的安全锚点。

29.2 系统迁移（虚拟机克隆方式）

虚拟机克隆是将当前系统配置完整复制到新主机的最快方式，适合从实验环境迁移至预生产或生产环境。

29.2.1 克隆前准备

# 清理临时文件，减小克隆体积
dnf clean all
journalctl --vacuum-size=100M
rm -rf /tmp/* /var/tmp/*

# 记录当前系统关键配置（便于克隆后对比验证）
tee /root/pre-clone-config.txt << EOF
=== 系统基本信息 ===
$(hostnamectl)

=== 运行中的服务 ===
$(systemctl list-units --type=service --state=running)

=== 网络配置 ===
$(nmcli con show)
$(ip addr show)

=== 防火墙规则 ===
$(firewall-cmd --list-all)

=== 磁盘挂载 ===
$(df -hT)

=== 记录时间: $(date) ===
EOF

echo "克隆前配置已记录至 /root/pre-clone-config.txt"

29.2.2 VMware 克隆操作

在 VMware 中右键 linuxdc → Clone → Full Clone
新虚拟机命名为 linuxdc-target
克隆完成后启动新虚拟机

29.2.3 克隆后配置修正

登录克隆后的虚拟机，修正主机身份信息（以下操作在克隆机上执行）：

# 修改主机名
hostnamectl set-hostname linuxdc-target

# 修改静态 IP（避免与源主机 192.168.1.100 冲突）
nmcli connection modify ens33 \
  ipv4.addresses 192.168.1.101/24 \
  ipv4.gateway   192.168.1.1 \
  ipv4.dns       "8.8.8.8 8.8.4.4"
nmcli connection up ens33

# 重新生成 SSH 主机密钥（克隆后必须执行）
# 克隆机与源机共用相同主机密钥是严重安全风险
rm -f /etc/ssh/ssh_host_*
ssh-keygen -A
systemctl restart sshd

# 重新注册订阅（克隆后 UUID 冲突，需重注册）
subscription-manager unregister
subscription-manager clean
subscription-manager register \
  --username <your-redhat-account> \
  --password <your-password>

检查点

hostnamectl 显示 linuxdc-target；ip addr show ens33 显示 192.168.1.101/24；验证两台主机 SSH 主机密钥不同：md5sum /etc/ssh/ssh_host_ed25519_key.pub（两台机器输出应不同）。

29.3 安全补丁升级

29.3.1 在线安全补丁升级

# 查看可用安全更新的分类摘要
dnf updateinfo summary --security

# 查看具体安全更新列表（含 CVE 编号）
dnf updateinfo list security

# 仅安装安全补丁（不升级功能性包，变更最小）
dnf update --security -y

# 检查是否需要重启（内核或核心库更新后需重启）
needs-restarting -r
# 若有输出，表示系统需要重启方能完全生效

# 查看哪些服务使用了已更新的库（需重启服务）
needs-restarting -s

# 根据需要重启系统
reboot

生产环境补丁升级策略

推荐流程：① 在测试环境应用补丁并验证稳定运行 72 小时；② 在维护窗口开始前为生产系统创建 VMware 快照；③ 在维护窗口内执行 dnf update --security -y；④ 验证核心服务正常后关闭维护窗口。

29.3.2 离线安全补丁升级

适用于无法直接访问 Red Hat CDN 的内网隔离服务器：

# 【步骤一】在联网机器（可访问 CDN）上下载补丁包
dnf download --resolve --security \
  --destdir=/tmp/security-patches \
  $(dnf list --security --updates -q | awk 'NR>1 {print $1}')

# 查看下载的补丁包列表
ls -lh /tmp/security-patches/

通过 SecureFX 将 /tmp/security-patches/ 目录传输至目标服务器的 /tmp/patches/。

# 【步骤二】在目标服务器安装本地 RPM 包
dnf install -y /tmp/patches/*.rpm

# 验证已安装的安全更新
dnf updateinfo list security --installed | head -30

# 清理临时文件
rm -rf /tmp/patches/

29.4 回滚机制

29.4.1 使用 dnf history 回滚事务

# 查看所有 dnf 操作历史记录
dnf history

# 查看特定事务的详细信息（替换实际 ID）
dnf history info 10

# 回滚指定事务（撤销该次操作的所有包变更）
dnf history undo 10

# 验证回滚结果
dnf history

dnf history 回滚的局限性

dnf history undo 仅能回滚通过 dnf 安装的软件包，不能回滚：手动 rpm 命令安装的包；对配置文件的变更（/etc/ 目录）；内核更新（需通过 GRUB 切换，见 29.4.2）。配置文件变更的回滚需依赖备份文件或 VMware 快照。

29.4.2 内核版本回滚

# 查看已安装的所有内核版本
rpm -qa | grep '^kernel-[0-9]' | sort

# 查看 GRUB 内核列表与当前默认内核
grubby --info=ALL
grubby --default-kernel

# 将默认内核切换至指定旧版本（替换实际路径）
grubby --set-default \
  /boot/vmlinuz-5.14.0-362.24.1.el9_3.x86_64

# 验证默认内核已更改
grubby --default-kernel

# 重启使切换生效
reboot

重启后验证：

uname -r
# 应输出设置的旧内核版本号

29.4.3 VMware 快照回滚（最彻底的回滚方案）

当补丁导致严重问题时，VMware 快照回滚是最可靠的恢复手段：

打开 VMware 快照管理器（菜单 → VM → Snapshot Manager）
选择升级前创建的快照，点击 Restore to Snapshot
系统恢复至快照时刻的完整状态（内存、磁盘、配置文件全部还原）

29.5 系统升级注意事项

29.5.1 RHEL 9 次要版本升级（如 9.3 → 9.5）

# 查看当前版本
cat /etc/redhat-release

# 次要版本升级（更新所有包至最新）
dnf update -y

# 重启使内核和关键库更新生效
reboot

# 验证版本已更新
cat /etc/redhat-release
uname -r

29.5.2 跨主版本升级准备（RHEL 9 → RHEL 10）

leapp 升级路径说明

Red Hat 支持使用 leapp 工具从 RHEL 9（需 9.4 及以上）原地升级至 RHEL 10。升级前须完成预检查，解决所有 inhibitor（阻断问题）后方可执行。生产环境升级前必须在测试环境完整演练。

# 安装 leapp 升级工具
dnf install -y leapp-upgrade

# 执行预检查（不实际升级，仅生成评估报告）
leapp preupgrade

# 查看预检查报告（重点关注 inhibitor 级别问题）
cat /var/log/leapp/leapp-report.txt | less

# 解决所有 inhibitor 后执行实际升级（需在维护窗口内操作）
# leapp upgrade

29.6 常见问题与排查

问题现象	排查步骤
克隆后网络不通	检查 IP 冲突：`ping 192.168.1.101`；重新执行 `nmcli connection up ens33`
补丁安装依赖冲突	`dnf update --security --best`；`dnf deplist <package>` 查看依赖关系
内核切换后无法启动	通过 VMware 控制台在 GRUB 菜单选择可用内核；进入系统后用 `grubby` 修正默认项
`dnf history undo` 失败	查看具体报错；依赖关系复杂时使用 VMware 快照回滚更可靠

# 检查系统是否需要重启
needs-restarting -r

# 查看哪些服务使用了已更新的库
needs-restarting -s

# 查看最近的 dnf 操作历史
dnf history | head -10

29.7 实践任务

在 VMware 中克隆 linuxdc 为 linuxdc-target，修改主机名为 linuxdc-target，IP 为 192.168.1.101，重新生成 SSH 主机密钥，验证三项修正均已生效。
在 linuxdc 上执行 dnf updateinfo summary --security，查看当前可用安全更新数量和分类。
执行 dnf update --security -y，安装安全补丁，查看 dnf history 记录。
使用 grubby --info=ALL 查看已安装内核列表，记录当前默认内核路径。
执行 needs-restarting -r 判断是否需要重启，执行 needs-restarting -s 查看需要重启的服务列表。

29.8 自测问题

Q1：dnf update --security 与 dnf update 有何本质区别？

dnf update --security 只安装标记为安全修复（Security Advisory）的更新，不包含仅含功能改进或 Bug 修复的版本升级，变更范围最小，风险最低，适合对稳定性要求极高的生产环境日常维护。dnf update 安装所有可用更新（安全 + 功能 + Bug 修复），变更范围更大，适合定期维护窗口内的全量更新。生产环境推荐日常使用 --security，在季度维护窗口执行全量更新。

Q2：克隆虚拟机后为什么必须重新生成 SSH 主机密钥？

SSH 主机密钥（/etc/ssh/ssh_host_*）是服务器的唯一身份凭证，客户端通过对比 ~/.ssh/known_hosts 中记录的公钥指纹来验证连接对象是否为预期服务器（防止中间人攻击）。克隆后两台虚拟机持有完全相同的主机密钥，客户端无法区分两台主机，连接克隆机时会触发 Host key verification failed 警告，且两台主机共用相同密钥本身即为安全漏洞，可能引发密钥混淆攻击。

Q3：grubby --set-default 回滚内核与 VMware 快照回滚有何本质差异？

grubby --set-default 仅切换系统启动时加载的内核版本，所有已安装 RPM 包、配置文件变更、系统日志均保留完整；若内核与用户空间工具版本不兼容，可能仍存在问题。VMware 快照将整个虚拟机状态（磁盘文件、内存状态、所有配置）恢复至快照时刻，是最彻底的回滚手段，适合升级导致系统级故障时使用，但快照时刻之后的所有变更（包括有价值的配置改动）都会丢失，须谨慎权衡。

29.9 章节总结

本章介绍了 RHEL 9 三类关键运维操作：虚拟机克隆迁移（含克隆后必须执行的主机名、IP、SSH 密钥三项身份修正）、安全补丁升级（在线与离线两种场景，含 needs-restarting 重启判断）、以及多层次回滚机制（dnf history 事务回滚、grubby 内核版本切换、VMware 快照完整回滚）。规范的迁移与升级流程是生产环境连续性保障的基础。