FusionCompute 6.5实验手册：CNA/VRM部署与迁移运维

简介：FusionCompute实验手册1是华为HCIP-Cloud Computing V4.0认证培训的官方实验指导材料，面向备考该认证的学员，以及希望系统掌握华为服务器虚拟化平台FusionCompute运营与运维技能的工程师。手册围绕7个实验、四个部分展开：先在KVM虚拟化嵌套环境中完成从CNA到VRM的环境搭建，理解FusionCompute基础架构；再练习计算、存储、网络三类资源池管理，体会计算虚拟化、存储虚拟化与网络虚拟化的核心能力；随后进入虚拟机发放与管理，涵盖虚拟机创建、Tools安装、模板封装与导入导出、快照、规格调整、HA、热迁移、安全组与规则组等业务运维要点；最后是用户管理、管理数据备份与时间管理等常见运维实验。资源包仅含1个docx文档，约10.53MB，结构完整、实验步骤与拓扑配置说明齐备，适合对照搭建实验环境并逐项动手验证，也可作为日常运维与故障排查的参考。目前已有227人学习。

1. 两台服务器、七个实验：这套 FusionCompute 6.5 手册适合谁

机架上摆着两台刚上架的服务器，CNA 已经装完，浏览器却怎么也打不开 VRM 的 8443 登录页——这是很多人第一次接触 FusionCompute 实验手册时的真实开场。这套 HCIP-Cloud Computing V4.0 配套的 FusionCompute 实验指导手册，围绕 6.5.0 版本把内容拆成七个实验、四大部分：环境搭建、虚拟资源管理、虚拟机发放与管理、常见运维。它的价值不在于讲清虚拟化概念，而在于给你一条从 ISO 引导到资源池可用的完整路径，每一步都有界面位置和参数可对。适合三类人：准备认证考试、需要把实验环境跑通的学员；手上有一批服务器、想先在小环境验证 FusionCompute 可行性的运维；以及从其他虚拟化平台转过来、需要快速摸清 CNA 与 VRM 边界的老手。下面按我实际复现的顺序拆。

2. 从 ISO 到 8443 可登录：CNA 与 VRM 的嵌套安装链路

手册开篇给了一个很具体的场景：某企业想减少硬件投入，先拿两台服务器搭一套 FusionCompute，验证业务跑在虚拟化上的可行性。这个设定决定了实验环境不是生产部署，而是“能装、能管、能迁移”的最小闭环。整条链路是先在物理机上跑 KVM，再在 KVM 里开两台虚拟机当 CNA，最后用安装工具把 VRM 部署到其中一台 CNA 上。听起来绕，但这样做的收益很直接：环境可以快照回滚，装坏了重来只要几分钟，不用重装物理机。

我一般把这条链路拆成三个检查点：CNA 的 8443 能不能打开、VRM 安装向导能不能连上 CNA、VRM 登录后能不能看到主机。三个点任何一个不通，后面添加集群、挂存储都是白费。下面按这三个点倒推每一步的配置。

2.1 为什么用 KVM 嵌套：资源账与网络账先算清

嵌套虚拟化的第一个坑不在 FusionCompute，而在宿主机的 CPU 虚拟化暴露方式。如果 KVM 虚拟机的 CPU 模式设成qemu64这类默认模型，CNA 装完能启动，但再往下创建虚拟机时会发现硬件虚拟化指令不可用，虚拟机起不来。常见做法是把 CNA 虚拟机的 CPU 模式设成host-passthrough，让上层看到宿主机的完整指令集；退一步也要用同一代 CPU 的命名模型，保证两台 CNA 的 CPU 特性一致，否则后面做热迁移会直接报 CPU 不兼容。

资源账要提前算。实验环境里每台 CNA 我一般给 8 vCPU、16GB 内存、120GB 系统盘，VRM 给 4 vCPU、8GB 内存、80GB 磁盘。低于这个数安装过程能走完，但再开两台业务虚拟机就很紧，HA 和迁移实验会因为没有足够空闲内存而失败。磁盘不要用精简置备的宿主盘叠太多层，I/O 延迟会放大，安装过程会莫名卡在解压阶段。

网络账更容易翻车。手册给的地址规划是管理网192.168.201.0/24、存储网192.168.202.0/24，CNA01 管理192.168.201.101、存储192.168.202.101，CNA02 对应.102，VRM 管理地址192.168.201.100。在 KVM 里给每台 CNA 配两张虚拟网卡，分别桥接到两个不同的虚拟交换机；不要图省事用 NAT 模式，NAT 下 CNA 能出去，但管理 PC 主动连 CNA 的 8443 和安装向导的回程流量会被挡住，表现就是“向导一直提示连接超时”。

提示：管理 PC 的地址不要和 VRM 计划地址冲突，安装向导会在部署前做一次地址探测，冲突时提示不直观，容易被当成软件包损坏。

2.2 装 CNA：磁盘选择、管理 IP 与 root 密码的三个卡点

CNA 的安装介质是FusionCompute 6.5.0_Installer.zip里的主机 ISO。把 ISO 挂到 KVM 虚拟机的光驱，启动后选择安装，过程本身不复杂，卡点集中在三处。

第一处是磁盘选择。安装器会列出所有可用磁盘，选中即格式化，没有二次确认的机会。嵌套环境里经常给 CNA 挂了两块盘，一块系统盘一块准备做本地存储的实验盘，选错就把实验数据清了。我一般先在 KVM 层面只挂系统盘，装完再加热插盘，减少误选。

第二处是管理网络配置。主机名按CNA01、CNA02命名，管理 IP 填手册里的地址，掩码255.255.255.0，网关填管理网段的网关。DNS 在纯实验环境可以留空，但一旦后面要配时间同步或者接认证源，没有 DNS 会多绕一圈。存储平面的 IP 不在安装界面配，等进了 VRM 再做存储接口，这一点手册的实验流程里是分开的，别在安装阶段找存储 IP 的输入框。

第三处是 root 密码复杂度。FusionCompute 的密码策略要求长度、大小写、数字、特殊字符组合，且不能包含用户名。实验环境里很多人图省事设Admin@123，安装器接受，但后面添加主机到 VRM 时可能触发密码过期策略，表现是添加成功、过一会主机状态变成“离线”。我一般在实验环境也设一个符合策略且不过期的密码，省掉后面排查时间。

装完重启，拔掉 ISO，做三步验证：管理 PC 上ping 192.168.201.101通；ssh root@192.168.201.101能登录；浏览器打开https://192.168.201.101:8443能看到 CNA 本地管理页。第三步很多人会跳过，但它能提前暴露证书和端口问题，比等到 VRM 安装向导报错再回头查要省事。

注意：CNA 的 Web 管理页和 VRM 的 Web 管理页不是一个东西，CNA 的 8443 只用于单机维护，日常资源管理走 VRM 的 8443。两台设备同端口不同地址，浏览器标签别开混。

2.3 部署 VRM：Installer 向导里必须对齐的四个参数

VRM 的软件包是FusionCompute 6.5.0_VRM.zip，部署靠安装工具向导完成。向导跑在管理 PC 上，所以管理 PC 必须能同时访问 CNA 的管理 IP 和计划给 VRM 的地址。整个向导里有四个参数值得停下来核对。

第一个是目标 CNA 的管理 IP。向导会先连一台 CNA，把 VRM 虚拟机部署到这台主机上。实验环境填192.168.201.101。如果这台 CNA 之前被别的 VRM 管过，向导可能提示主机状态异常，处理办法是在 CNA 侧清理残留注册信息，或者换一台干净的 CNA 先部署。

第二个是 VRM 软件包路径。解压后的FusionCompute 6.5.0_VRM.zip不要改文件名，向导按固定命名找包，改名后可能提示“软件包格式不正确”。路径里也不要有中文和空格，Windows 管理 PC 上放在D:\fc\这类短路径最稳。

第三个是 VRM 的管理 IP、掩码和网关。填192.168.201.100、255.255.255.0、管理网网关。这个地址一旦确定，后面改起来要进 VRM 后台，实验阶段尽量一次填对。

第四个是 VRM 虚拟机的磁盘位置。如果此时还没有挂 IP-SAN，向导会把 VRM 磁盘放在 CNA 的本地存储里；等后面加了共享存储，也不建议把 VRM 迁过去做实验，VRM 自身依赖存储的链路越简单越好。

向导跑完后，浏览器打开https://192.168.201.100:8443，用默认管理员账号登录，首次登录会强制改密码。登录后先看两处：系统管理里的服务状态是否全部正常，资源池里能否看到被部署的那台 CNA。这两处正常，环境搭建实验就算闭环，可以进下一章的资源池配置。

3. 集群、IP-SAN 与精简磁盘：把计算和存储资源池化

环境搭好后，VRM 里只有一台孤零零的主机，既没有集群也没有共享存储，虚拟机只能放本地盘，HA 和迁移都做不了。手册第二部分要解决的就是把两台 CNA 组成一个集群、把 IP-SAN 挂进来、再创建一块可被集群内主机同时访问的磁盘。这一章的顺序不能反：先集群后存储，先存储接口后扫描 LUN，先数据存储后创建磁盘。顺序反了，界面上的按钮会是灰的，或者扫描结果为空。

我复现时习惯把这一章当成一次“资源池验收”：集群里两台主机状态正常、数据存储挂载成功且两台主机都能看到、创建一块精简磁盘并确认使用率不是 100%。三个条件满足，后面发放虚拟机才有意义。

3.1 建集群再加主机：CPU 兼容性决定热迁移上限

集群在 FusionCompute 里不只是个文件夹，它是资源调度和 HA 的边界。同一集群内的主机才能做虚拟机热迁移，跨集群只能关机迁移。创建路径在 VRM 的“资源池”视图，新建集群时会给几个策略开关：HA、电源管理、计算资源调度。实验环境建议先把 HA 打开，电源管理关掉，计算资源调度保持默认，等虚拟机跑起来再按需调。

添加主机时填 CNA 的管理 IP 和 root 密码，两台依次加。加第二台时如果提示“主机已被其他集群管理”，说明这台 CNA 之前注册过，先在 VRM 的主机列表里找残留记录删掉，或者在 CNA 后台重置注册状态，再重新添加。移动主机用拖拽或“移动到”都行，删除集群前必须先把集群内主机移走，否则删除按钮不可用，这是界面上的硬约束，不是 bug。

CPU 兼容性是这一节最容易被忽略的点。嵌套环境里两台 CNA 虚拟机的 CPU 模型如果一台是host-passthrough、另一台是命名模型，集群能建起来，虚拟机也能各自跑，但一做热迁移就失败，日志里提示 CPU 特性不匹配。常见做法是建集群前先统一两台 CNA 的 CPU 模型，或者把集群的 CPU 基线设成较低的那一代。这个坑在实验里不致命，在生产里就是迁移窗口打不开，血泪经验往往来自第一次做主机维护。

3.2 IP-SAN 接入三步：启动器号、端口绑定、扫描 LUN

存储接入是这套实验里操作步骤最多的一段。IP-SAN 走 iSCSI，CNA 作为 initiator，存储阵列作为 target，中间要过三关：启动器号唯一、存储接口绑定正确、阵列侧放通 initiator。

第一步是修改 iSCSI 启动器号。CNA 安装后自带一个默认 IQN，如果是克隆出来的虚拟机，两台 CNA 的 IQN 可能一模一样，阵列侧看到两个相同 initiator 会拒绝或只认一个。在 CNA 后台改启动器号文件，把名字改成带主机名后缀的唯一值，再重启 iSCSI 服务：

# 查看当前启动器名，克隆出来的 CNA 经常两台完全一样 cat /etc/iscsi/initiatorname.iscsi # 改成本机唯一的名字，后缀用主机名区分 echo "InitiatorName=iqn.2024-01.local:cna01" > /etc/iscsi/initiatorname.iscsi # 重启 iSCSI 服务让新名字生效，再确认一次 systemctl restart iscsid cat /etc/iscsi/initiatorname.iscsi

这段命令的关键在最后一行，重启后必须回读确认，服务重启失败时文件已经改了但进程还用旧值，表现就是“明明改了 IQN，阵列侧还是看不到新名字”。iqn.2024-01.local:cna01只是示例格式，实际用哪一年的命名空间不影响功能，关键是两台主机不能重复。

第二步是配置端口绑定和存储接口。在 VRM 的主机配置里找到存储接口，把存储平面的网口和 IP 绑上去，CNA01 填192.168.202.101，CNA02 填192.168.202.102。绑定完成后在 CNA 后台ping一下阵列的 iSCSI 业务地址，通不过就别往下走，先查 VLAN 和交换机端口。

第三步是添加存储资源并扫描。存储类型选 IP-SAN，填阵列的 iSCSI 目标 IP 和端口3260，CHAP 认证实验环境可以不配。扫描存储设备后应该能看到阵列上划好的 LUN，选中 LUN 添加数据存储，命名DS01，块大小保持默认。如果扫描结果为空，按顺序查三处：CNA 到阵列网络通不通、阵列侧有没有把 CNA 的 IQN 加进白名单、启动器号是不是重复。

提示：添加数据存储会对 LUN 做格式化，实验前确认这个 LUN 上没有还要保留的数据。手册里这一步写得比较轻，但它是不可逆操作。

3.3 精简磁盘不是万能：三种磁盘类型的分配与性能账

数据存储挂好后，创建磁盘这一步看似只是填容量，实际上磁盘类型决定了后面虚拟机的空间利用率和 I/O 表现。FusionCompute 6.5 里常见三种类型：普通、普通延迟置零、精简。普通磁盘创建时一次性分配并置零，创建慢但写入性能稳定；普通延迟置零创建快，首次写入时再置零，适合批量发放但对首次写入延迟敏感的场景要慎用；精简磁盘按实际使用量分配，支持超配，创建最快，但使用率上去后性能会下降，且需要监控存储剩余空间。

实验环境我一般用精简磁盘，因为要验证模板部署和快照，空间利用率高；但如果这个实验里要跑数据库或者做性能对比，就换成普通磁盘，避免把存储层的延迟算到虚拟机头上。创建时容量填 40GB、数量 1，创建完在数据存储的使用率里确认只占了几百 MB，说明精简分配生效。

4. 分布式交换机、VLAN 池与端口组：网络资源的落地顺序

计算和存储就位后，虚拟机还缺一张能跨主机漂移的网。FusionCompute 的网络模型里，分布式交换机是跨主机的逻辑交换机，端口组是虚拟机挂网卡的入口，VLAN 池负责给端口组分配 VLAN ID，上行链路把逻辑交换机接到物理网口。这四样东西的创建顺序是固定的：先交换机、再上行链路、再 VLAN 池、最后端口组。顺序乱了，端口组创建时选不到 VLAN，或者上行链路加不进去。

这一章我建议配合一次迁移实验做验证：把一台虚拟机从 CNA01 迁到 CNA02，迁移后 IP 不变、同 VLAN 能通、跨 VLAN 隔离。网络配置对不对，迁移一次比看十遍界面更直观。

4.1 DVS 与标准交换机：跨主机迁移时才见真章

FusionCompute 里每台主机可以配标准交换机，也可以接入分布式交换机。标准交换机的配置只在本机生效，虚拟机迁到另一台主机后，如果目标主机没有同名端口组和相同 VLAN，迁移会失败或者迁移后网络不通。分布式交换机的配置是跨主机共享的，端口组建一次，集群内主机都能用，虚拟机迁移时网络配置跟着走。

实验里两台 CNA，必须用分布式交换机，否则 HA 和热迁移实验做不完整。创建时名称填DVS01，模式选 VLAN 池，MTU 先保持1500。MTU 这一项后面配存储网络时会再提到，业务网络不要随手改 9000，端到端有一台设备不支持就会丢包，表现是“小包通、大包断”，排查起来很费时间。

4.2 先上行链路、再 VLAN 池、后端口组

上行链路是把 DVS 接到物理网口的那一步。每台主机至少选一个物理网口做上行链路，绑定模式实验环境用主备最稳；负载分担需要交换机侧配置匹配，配不好会出现单边流量，虚拟机时通时断。加完上行链路，在 DVS 上确认每台主机的链路状态都是“正常”，再往下走。

VLAN 池按手册规划建两个：VLAN 201 给业务管理，VLAN 202 给存储。VLAN ID 要和物理交换机 trunk 放通的列表一致，不一致时虚拟机挂端口组能成功，但流量出不去。端口组建的时候绑定 DVS、选 VLAN ID，名称建议带 VLAN 号，比如pg-business-201，后面虚拟机挂网卡时不容易选错。

4.3 管理、存储、业务三网分离的网口与 MTU 规划

手册的地址规划里管理网和存储网是分开的，这不是为了好看，而是为了避免存储流量把管理平面打满。管理网跑 VRM 和 CNA 的心跳、Web 访问，存储网跑 iSCSI 读写，业务网跑虚拟机对外服务。三张网在物理上可以是同一台交换机上的不同 VLAN，但网口和 VLAN 要分开配。

存储网的 MTU 如果要用 9000，必须从 CNA 网口、虚拟交换机、物理交换机到存储阵列逐段确认，任何一段是 1500 都会导致大包分片或丢弃。我一般先在实验环境保持 1500 把流程跑通，等存储性能成为瓶颈再动 MTU，改动前记录每段配置，改完用大包 ping 验证。管理网不要开 jumbo frame，VRM 和安装向导的流量小，开了反而增加不确定性。

5. 安装与运维的五个高频翻车点：现象、原因与处置

这套实验的步骤写得细，但真正卡人的往往不是步骤本身，而是环境差异带来的“界面能点、结果不对”。下面五条是我复现时遇到、也在别人环境里见过的翻车点，按现象、原因、解决三段写，方便对照排查。每条都对应手册里的一个实验环节，但手册不会告诉你失败时长什么样。

5.1 安装阶段：向导连不上 CNA 与添加主机失败

现象一：VRM 安装向导提示连接 CNA 失败或超时。管理 PC 能 ping 通 CNA 的管理 IP，但向导就是连不上。原因通常是管理 PC 和 CNA 不在同一网段，中间过了 NAT 或者多层路由，向导回程流量被挡住；也可能是 KVM 虚拟网卡用了 NAT 模式，CNA 出方向正常，入方向不通。解决办法是把管理 PC 的网卡改到192.168.201.0/24网段，KVM 虚拟网卡改桥接，先保证双向 ping 通，再跑向导。嵌套环境里这一条占安装失败的大半。

现象二：添加主机到集群失败，提示主机已被管理或证书校验失败。原因有两个：CNA 之前注册过别的 VRM，残留信息没清；或者 CNA 和 VRM 的时间偏差太大，证书校验过不去。解决时先在 VRM 主机列表删掉残留记录，在 CNA 后台用date看时间，偏差超过几分钟就先配 NTP 同步，再重新添加。实验环境里虚拟机挂起几天再恢复，时间漂移很常见，别一上来就怀疑密码错。

5.2 存储与网络阶段：LUN 扫不到、迁移卡住

现象三：添加 IP-SAN 存储后扫描不到 LUN。按网络、白名单、启动器号三处查。先ping阵列 iSCSI 地址，不通就查 VLAN 和存储接口绑定；通了再看阵列侧有没有把 CNA 的 IQN 加进 initiator 白名单；最后回 CNA 确认两台主机的启动器号不重复。克隆出来的 CNA 是重灾区，两台 IQN 一样时阵列侧只认一条，另一台扫描结果永远为空。

现象四：虚拟机热迁移进度卡住或直接失败。日志里常见两类提示：CPU 特性不兼容、迁移网络不通。CPU 问题按 3.1 节统一集群内主机 CPU 模型；网络问题要确认集群是否配了迁移网络，没配时迁移流量走管理网，管理网一忙就超时。实验环境可以先用关机迁移验证存储和网络通不通，再回头调热迁移。

5.3 虚拟机阶段：模板克隆后蓝屏与网卡改名

现象五：Windows 模板部署出来的虚拟机蓝屏或首次启动进不了系统。原因多是模板封装前没装 Tools、没做 sysprep，克隆出来的 SID 和驱动状态不对。正确顺序是：源虚拟机装 Tools → 确认设备管理器无异常 → 执行sysprep /generalize /shutdown→ 关机后转模板。少了 sysprep 这一步，单台测试可能正常，批量部署时就会出问题，这是最典型的“单机验证通过、批量翻车”。

Linux 模板则是另一个画风：克隆后网卡名从eth0变成eth1，IP 配不上。原因是 udev 规则按 MAC 绑定了网卡名。封装前清掉绑定规则和网卡配置里的硬件地址：

# 清掉按 MAC 绑定网卡名的规则，避免克隆后变成 eth1 rm -f /etc/udev/rules.d/70-persistent-net.rules # 去掉 ifcfg 里的 HWADDR 和 UUID，让新虚拟机重新生成 sed -i '/^HWADDR=/d' /etc/sysconfig/network-scripts/ifcfg-eth0 sed -i '/^UUID=/d' /etc/sysconfig/network-scripts/ifcfg-eth0 # 确认清理结果，再关机转模板 grep -E "HWADDR|UUID" /etc/sysconfig/network-scripts/ifcfg-eth0

这段脚本只做清理，不碰 IP、掩码、网关，所以模板里的网络配置会保留，克隆后按需改 IP 即可。CentOS 7 如果启用了可预测网卡命名，光删规则文件还不够，常见做法是在内核启动参数里加net.ifnames=0 biosdevname=0，让网卡稳定叫eth0。改完必须重启验证一次再转模板，别在没重启的情况下直接封装，规则可能没生效。

6. 把手册变成可验收的交付物：一份 10 分钟检查清单

手册的实验步骤走完，环境“看起来能用”和“真的能交付”之间还差一次验收。我习惯在关掉浏览器之前跑一遍检查清单，十分钟内能发现大部分隐患。下面这张表按检查项、检查方式、通过标准三列写，顺序就是交付前的执行顺序。

连不通的时候不用逐项猜，先跑一段连通性脚本把范围缩小：

#!/bin/bash # 交付前在管理网 PC 上执行，先确认四条链路，再打开浏览器 for ip in 192.168.201.100 192.168.201.101 192.168.201.102 192.168.202.101; do if ping -c 2 -W 1 "$ip" >/dev/null 2>&1; then echo "OK $ip" else echo "FAIL $ip" fi done # 只看 HTTP 状态码，-k 跳过自签证书校验，-o /dev/null 丢弃页面内容 curl -k -s -o /dev/null -w "VRM HTTP %{http_code}\n" https://192.168.201.100:8443

-c 2是每个地址发两个包，-W 1是单包超时一秒，实验网段里够用；-k是因为 VRM 默认自签证书，不加会直接报证书错误，看不到状态码。脚本输出里如果管理地址全通、存储地址不通，问题就锁定在存储接口或 VLAN，不用再翻安装日志。VRM 返回 200 或 302 都算正常，返回 000 说明端口没起来或者被防火墙挡了。

这套手册最大的价值是把七个实验串成一条可复现的链路，但它不会替你做环境验收。从那以后我每次交付 FusionCompute 实验环境，都强制先跑一遍这四个 ping 和 8443 状态码，再谈集群策略和迁移，顺序反了就是给自己挖坑。希望帮到你。

本文还有配套的精品资源，点击获取