适用场景

• 产品：ZCF
• 组件：ZStack Cloud
• 版本：4.8.x、5.4.x、4.18.x
• 当前版本：
• Cloud 4.8.x
• Libvirt 8.0.x
• Qemu 6.2.x
• Kernel 4.18.0-425...
• 目标版本：
• Cloud 5.4.x
• qemu-kvm-6.2.x
• libvirt-8.0.x
• Kernel 4.18.0-553.69.1.13...
• 部署形态：双管理节点、SAN 存储

问题现象

• 当前平台与虚拟化组件版本较旧。
• 需要提升平台版本、qemu/libvirt 版本，以及主机内核版本。
• 同时希望在物理机 crash 时获取更有效的故障日志。

判断方法

1. 升级前通过升级检查脚本确认环境健康。
2. 升级后检查平台、Agent、虚拟化组件和内核版本均符合目标值。
3. 检查业务与云主机网络运行正常。

原因说明

本次属于综合升级场景，包含平台升级、物理机 crash 参数配置以及物理机内核升级，因此需要分阶段执行并逐台验证。

解决方案

1. 物理机一键配置 crash 参数
2. 使用 config_crashdump.sh 脚本配置 crashdump。

• 作用：在物理机 crash 时输出更多有效日志。
• 生效条件：需要重启物理机。

2. 验证步骤：

   systemctl status kdump
   dmesg | grep -i crash

• 高风险测试：

     echo 1 > /proc/sys/kernel/sysrq
     echo c > /proc/sysrq-trigger

• 重启后检查：

     ls -l /var/crash/

• 预期结果：kdump 与 crash 保留机制配置正确。

2. 升级云平台到 5.4.x
3. 使用 zstack-upgrade-check-master 做升级自检。

• 预期结果：环境健康、升级风险点明确。

2. 关闭全局高可用。
3. 申请 1 台非核心业务物理机用于提前重连校验。
4. 双管理节点上传 ISO、升级脚本、HA 组件和 bin 文件，并校验 md5 / commit。
5. 调整 CLI 全局配置：

   enable.multipath=ignore
   connect.timeout=1200
   update.os.parallelismDegree cluster=5/10
   update.os.parallelismDegree host=10

6. 停止所有云平台备份任务。
7. 双管理分别备份数据库：

   zstack-ctl dump_mysql --file-name 4.x-mn1
   zstack-ctl dump_mysql --file-name 4.x-mn2

8. 两个管理节点更新源。
9. 查询 VIP 节点，解压 HA 包、赋权并停止 MN 服务。
10. 在 VIP 节点执行：

    ./zsha2 upgrade-ha -gencfg=true
    zsha2 upgrade-mn -grayscale -yes -db-root-pw $mysql_root_password -peerpass $peer_root_password $zstack_bin

11. 升级后检查：

    zstack-ctl status
    zsha2 status

12. 登录 UI 检查资源状态。
13. 先对一台非核心业务物理机手动重连，检查 kvmagent、云主机运行和业务情况。
14. 检查 Agent 版本：

    zstack-cli QueryAgentVersion

15. 若为 SharedBlock / SAN 环境，还要检查：

• vgs
• lsblk
• multipath
• /var/log/messages 中 I/O error
• dmesg

16. 若无异常，依次重连其他物理机。
17. 全局升级完成后关闭灰度变量：

    UpdateGlobalConfig name=grayscaleUpgrade category=upgradeControl value=false

18. 开启全局高可用。

• 预期结果：平台升级完成且业务稳定。

3. 升级虚拟化组件
4. 单台或集群升级以下组件：

• qemu-storage-daemon
• qemu-kvm
• glib2
• libvirt

2. 使用 QueryLongJob 查询升级进度。
3. 使用 SSH 批量检查版本。
4. 使用：

   virsh qemu-monitor-command $VMuuid --hmp info version

检查 VM 实际 qemu 版本。

5. ：qemu 升级完成后，对云主机做重启或迁移，才能生效新版本。

• 预期结果：虚拟化组件升级生效。

4. 把物理机内核升级到 553
5. 登录云平台检查环境无异常。
6. 关闭全局高可用，并在两个管理节点备份数据库。
7. 确认待升级物理机上的云主机已迁空：

   virsh list

4. 将物理机置为维护模式。
5. 解压内核升级包：

   tar -xvzf upgrade_kernel_bcache.tar.gz

6. 执行升级：

   cd upgrade_kernel_bcache/
   bash upgrade_kernel.sh <host_ip>

7. 升级后重启物理机，使新内核生效。
8. 内核包 MD5：

   b327d608fd85d5afd27d906b09fb89ca

9. 重启后检查内核版本。
10. 确认无误后，依次对剩余节点升级。
11. 云平台正常后，重新打开全局高可用。

• 预期结果：所有目标主机完成 553 内核升级。

验证方法

• 检查平台版本、Agent 版本、qemu/libvirt/glib2 版本和内核版本均符合目标值。
• 检查 SAN / SharedBlock 侧状态正常。
• 检查云主机网络和业务正常。

风险与回滚

• 风险：物理机内核升级需要重启，会影响兼容性和业务连续性，但升级节点应先隔离出来。
• 风险：qemu 升级后若不对云主机做重启或迁移，云主机仍运行在旧 qemu 上。
• 风险等级：中。
• 回滚：无完整回退步骤，要求严格按分阶段验证方式执行以降低风险。