简介：这份资源是华为HCIP-Cloud Computing V4.0认证的FusionCompute实验指导手册，面向准备参加该认证考试的学员，以及需要系统掌握华为服务器虚拟化平台操作与运维的技术人员。内容围绕一个包含7个实验、分为四大部分的实训体系展开：先在KVM嵌套虚拟化环境中完成从CNA到VRM的环境搭建，再依次练习计算、存储与网络三类虚拟资源管理，随后进入虚拟机发放与管理，涉及Tools安装、模板封装、快照、规格调整、HA、热迁移与安全组配置，最后以用户管理、管理数据备份和时间管理等日常运维实验收尾，对理解FusionCompute架构与资源池管理较有帮助。资源包共1个文件，为docx格式手册，大小约10.53MB，便于打印对照或按实验分节查阅。目前已有227人学习，适合希望边做边学、补齐虚拟化实操短板的读者。

1. 两节点起步：这套实验手册真正值钱的是那张地址规划表

多数人翻到 FusionCompute 实验手册的第一反应是找"实验一 安装 CNA"那一页，然后照着截图一路点下去。我当初也是这么干的，结果在添加主机这一步卡了四十分钟——不是步骤写错了，而是手册第 6 页那张网络配置说明表被跳过了。这份 HCIP-Cloud Computing V4.0 配套的实验指导手册一共 7 个实验、四大块内容，从环境搭建、计算存储网络三大资源池管理，到虚拟机发放、模板封装、HA 与热迁移，最后落到用户管理和数据备份这类日常运维。它面向的是要动手搭一套可验证虚拟化平台的人，不是读一遍就完的概念书。而七个实验里真正决定成败的，是开头那张写着 192.168.201.x 和 192.168.202.x 的地址表——管理平面和存储平面必须分开，后面所有实验都建立在这个前提上。

2. 环境搭建：嵌套 KVM 里装 CNA 与 VRM 的六个关键选项

手册明确写了这套实验"依托 KVM 虚拟化嵌套环境实现"，这一句话背后藏着第一个门槛：CNA 是直接装在裸金属上的，它需要看到 CPU 的硬件虚拟化特性，才能在自己的上面再跑虚拟机。如果你的实验环境本身就是一台物理机上的虚拟机，宿主机不把 vmx/svm 透传下去，CNA 装完能起来，但一台虚拟机都开不出来，报错还特别含糊。

2.1 先确认嵌套虚拟化真的开了

很多人以为在 BIOS 里开了 VT-x 就完事，其实 KVM 默认是不把虚拟化指令集暴露给 guest 的，需要显式打开 nested 参数。这个检查一定要在做任何安装之前完成，装完再改就得重来。

# 1. 确认物理 CPU 支持虚拟化，返回值大于 0 才算支持 egrep -c '(vmx|svm)' /proc/cpuinfo # 2. 查看当前嵌套开关，Y 表示已开启，N 表示关闭 cat /sys/module/kvm_intel/parameters/nested # 3. 若为 N，写入模块参数并重载（AMD 平台把 kvm_intel 换成 kvm_amd） echo 'options kvm_intel nested=1' > /etc/modprobe.d/kvm-nested.conf modprobe -r kvm_intel && modprobe kvm_intel # 4. 再次确认，此时应输出 Y cat /sys/module/kvm_intel/parameters/nested

这里的逻辑是：第 3 步的配置文件保证重启后参数依然生效，modprobe -r再modprobe是一次不停机的重载。参数说明上，nested=1是唯一需要关心的值；如果你还要在 CNA 上开多台虚拟机，宿主机给这台"模拟 CNA"分配的核心数建议不少于 8 个，内存不少于 16GB，因为 VRM 本身还要占掉一部分。硬盘尽量放在 SSD 上，机械盘跑两三台虚拟机的并发安装会慢到怀疑人生。

提示：CNA 的安装镜像对磁盘大小有下限要求，给虚拟机配盘时不要卡着最小值给，留出 20% 余量，否则安装程序会直接拒绝继续。

2.2 CNA 安装时那几个不能随手填的框

CNA 安装过程是图形化向导，看起来很简单，但有四个地方一旦填错，后面全是连锁反应。手册给的规划是这样的：

四个关键选项分别是：主机名、管理口 IP 与掩码、管理口 VLAN、root 密码。主机名建议和规划表一字不差地对应，比如CNA01，因为后面添加主机、看告警、做迁移全靠这个名字定位；管理口 VLAN 如果实验交换机是 access 口就留空，是 trunk 口就必须填对，填错的直接表现是安装完成后 ping 不通网关。root 密码在两台 CNA 上保持一致会更省事，因为添加主机时要逐个输入。

安装完成后的第一件事不是打开浏览器，而是从你的操作机 ssh 上去做一次自检：

# 登录 CNA01，确认系统起来了 ssh root@192.168.201.101 # 查看两个平面的地址是否都正确落位 ip -br addr # 确认版本信息，排查后续功能差异 cat /etc/virtualization/version 2>/dev/null || rpm -qa | grep -i cna # 从 CNA01 探测 CNA02 和 VRM 规划地址，确认管理平面互通 ping -c 4 192.168.201.102 ping -c 4 192.168.201.100

ip -br addr这个命令比ifconfig直观，一屏就能看出哪个网口拿了 201 段、哪个拿了 202 段。如果发现存储口没拿到地址，别急着往下走，先回去查 VLAN 和交换机端口配置——第 3 章的端口绑定会依赖这个口，此时不通，后面一定翻车。

2.3 VRM 安装：它是虚拟机，不是裸机软件

新手最容易误解的一点：VRM 不是装在物理机上的服务，它是一个虚拟机，通过 CNA 的界面挂载 VRM 镜像来部署。所以顺序必须是先 CNA 后 VRM，而且 VRM 需要两块盘——系统盘和数据盘，规划时别只给一块。

VRM 安装过程中要填的地址比 CNA 多，因为它有管理和存储两个平面。地址按上表填，网关填管理平面的网关。安装完成后等待几分钟，用浏览器访问https://192.168.201.100:8443，8443 是 FusionCompute 管理界面的固定端口，别拿 443 去试。命令行侧可以先用 curl 探一下服务是否已经起来：

# -k 跳过自签证书校验，-I 只看响应头，能返回 200/302 就说明 Web 服务活了 curl -k -I https://192.168.201.100:8443 # 顺便确认 VRM 与两台 CNA 的时间偏差，超过几分钟会引发证书和任务异常 for h in 192.168.201.101 192.168.201.102; do ssh root@$h date "+%Y-%m-%d %H:%M:%S" done date "+%Y-%m-%d %H:%M:%S"

时间同步这条经常被忽略，但它会以非常诡异的方式表现出来：登录界面能开，点任何操作都提示"会话超时"或者干脆返回 502。血泪经验是，VRM 装完第一件事就对着 CNA 校时，别等到做实验五才发现。

3. 计算与存储资源池：集群、主机和 iSCSI 端口绑定的先后顺序

资源池管理这块，手册拆成了三个实验：计算、存储、网络。实际动手时它们的顺序不能随意调换——先建集群、再加主机、然后配存储接口、最后才是存储资源和数据存储。这个顺序不是排版习惯，而是因为存储接口是挂在主机上的，主机没加进来，你连配接口的入口都找不到。

3.1 集群与主机：为什么不能跳过集群直接加主机

FusionCompute 里主机必须归属某个集群，集群才是承载 HA、DRS 这些策略的最小单位。所以第一步永远是创建集群，命名建议按业务或机房维度来，比如Cluster-Prod、Cluster-Test，两台 CNA 都加进同一个集群。

添加主机时输入的是 CNA 的管理 IP 和 root 密码，界面上会显示连接状态。如果一直转圈然后失败，按这个顺序排查：管理平面能不能 ping 通、root 密码在 CNA 上有没有被改过、两边的系统时间差多少、管理口的防火墙有没有拦。这套实验环境里最常见的是密码问题，因为有人在装 CNA 时随手敲了个复杂密码，装完就忘了。

集群建好之后有一页策略配置，参数不多但每个都有代价：

注意：HA 的前提是虚拟机的磁盘在共享存储上。如果虚拟机用的是本地盘，HA 开了也不会生效，故障时虚拟机直接失联，这一点在做实验六的时候会体现得非常明显。

3.2 iSCSI 端口绑定：整个手册里最容易静默失败的一步

存储实验的第一段是"存储接口配置"，包含三个动作：修改主机 iSCSI 启动器名、配置端口绑定、添加存储接口。这三步任何一步做错，最后的症状都一样——扫描不到 LUN。这就是它烦人的地方，你没法从结果倒推是哪一步错了。

先看启动器名。每台 CNA 出厂会生成一个默认的 IQN 名字，形如iqn.2008-11.com.example:cna01，如果不改，两台机器的名字可能撞车，存储侧做白名单时会互相覆盖。改完之后要带着这个名字去存储侧登记，否则存储根本不认你。

# 在 CNA 上查看当前 iSCSI 启动器名 cat /etc/iscsi/initiatorname.iscsi # 查看存储平面的网口是否已就位（对应 192.168.202.x） ip -br addr show | grep 192.168.202 # 端口绑定完成后，确认 bond 的工作状态与双口是否都 up cat /proc/net/bonding/bond1

第二段命令的用意是确认存储平面的物理口真的拿到了地址，第三段是确认绑定关系成立。绑定模式通常选主备，也就是一个口工作一个口待命，存储侧如果是堆叠或者支持链路聚合，也可以选 LACP，但两边必须一致，一边主备一边聚合是典型的"看起来起来了其实不通"。

3.3 添加 IP-SAN 与扫描设备：LUN 不会自己冒出来

添加存储资源的参数不多，但每一项都要和存储侧对齐：

填完之后点"扫描存储设备"，这一步是在向存储发起 iSCSI 登录并枚举可用 LUN。扫描成功会列出 LUN 列表，此时还没结束，还要再"添加数据存储"，把 LUN 格式化成 FusionCompute 能识别的存储单元，虚拟机才能真正落在上面。

扫描不到 LUN 的时候，别在界面上反复点，直接上命令行定位：

# 从 CNA 测试到存储 3260 端口的连通性，不通就是网络或 VLAN 问题 nc -vz 192.168.202.200 3260 # 查看当前 iSCSI 会话，能不能看到 target 名称 iscsiadm -m session -P 3 | grep -i "target\|disk" # 手动发起 discovery，验证存储是否响应 iscsiadm -m discovery -t st -p 192.168.202.200:3260

nc通但iscsiadm没会话，八成是启动器名没在存储侧加白名单；nc都不通，回去看端口绑定和存储 VLAN。这个二分法能省掉大量瞎猜时间。

3.4 精简磁盘：容量可以超配，但别把超配当免费

实验里会建一块"普通精简磁盘"，精简的意思是先分配逻辑容量，实际空间按写入量增长。手动创建一个 1TB 的精简盘，在只有 500GB 的数据存储上也能建成功，因为此时只占了几 MB。问题出在写满的那一天——虚拟机磁盘写爆，整个数据存储上的所有虚拟机一起受影响。

实操上的经验值是超配比控制在 1.5 倍以内，实验环境随便玩，但你要知道这个数字在生产的含义。建盘时还有一个选项是"厚置备"，一上来就把空间占满，性能更稳定但没法超配。做实验验证功能用精简，做性能对比用厚置备，这个区分在做实验六的规格调整时很有用。

4. 网络与虚拟机发放：从 VLAN 池到模板封装的完整链路

网络这块手册只给了四个小节：创建分布式交换机、删除、添加上行链路、添加 VLAN 池、添加端口组。步骤看着少，但顺序是死的：交换机 → 上行链路 → VLAN 池 → 端口组。颠倒任何一步，界面上对应的按钮就是灰的，你还会以为是权限问题。

4.1 分布式交换机的三个层次

分布式交换机和物理交换机是对应关系，上行链路就是它连到物理交换机的那根线。创建交换机时给它起个能看懂的名字，比如DVS-Prod，然后添加上行链路，把 CNA 上真正的物理网口挂上去。两台 CNA 各挂一个口，这样虚拟机跨主机迁移时网络配置能跟着走。

VLAN 池是一个容易被当成"可选步骤"的东西，其实它是端口组的前置条件之一。规划上按手册的地址表来：

创建端口组时 VLAN ID 填错是最常见的失误，而且它不会报错，端口组照样建成功，虚拟机照样能挂上去，就是不通。这时候不要怀疑 FusionCompute，去虚拟机里做一次带 VLAN 标签的验证：

# 在 Linux 虚拟机内创建带 VLAN 203 标签的子接口 ip link add link eth0 name eth0.203 type vlan id 203 ip addr add 10.10.203.10/24 dev eth0.203 ip link set eth0.203 up # 探测同网段网关，通则说明 VLAN 通路没问题 ping -c 3 10.10.203.1 # 查看收发包计数，确认是否有去无回 ip -s link show eth0.203

如果 ping 不通但ip -s link显示 TX 有计数、RX 为 0，基本可以断定是物理交换机上联口没放通 203，或者端口组 VLAN ID 和这里填的不一致。这个判断方法比在界面上翻配置快得多。

4.2 创建虚拟机与 Tools：没有 Tools 的虚拟机是半残

手册的虚拟机发放实验分了 Windows 和 CentOS 两个场景，Windows 靠 VNC 装系统，CentOS 用模板导入。两个场景的共同点是装完系统立刻装 Tools。Tools 提供的是 virtio 驱动、网卡驱动、气球驱动和心跳，缺了它，虚拟机的磁盘和网络性能会掉一个档次，界面上也看不到内存和 CPU 的真实使用率。

CentOS 装 Tools 有个前置条件，很多人卡在这里：Tools 安装程序要现场编译内核模块，所以必须先把编译环境装好，而且kernel-devel的版本必须和uname -r完全一致，差一个小版本号都会编译失败。

# 先装编译依赖，kernel-devel 用 uname -r 锁定版本，避免装成新版 yum -y install gcc make perl kernel-devel-$(uname -r) # 确认内核头文件目录存在，不存在说明版本没对上 ls -d /usr/src/kernels/$(uname -r) # 挂载 Tools 光盘（Tools 一般挂在虚拟光驱里） mkdir -p /mnt/tools mount /dev/sr0 /mnt/tools cd /mnt/tools && ./install.sh

安装脚本跑完后会提示重启，重启前用lsmod | grep -i virtio看一眼驱动有没有加载上。如果kernel-devel那一步装的是新版内核的头文件，ls -d会失败，此时要么升级内核后重启，要么用 yum 的历史版本功能把匹配的头文件装回来。这是我在 CentOS 场景里翻得最惨的一次车，前后折腾了一个多小时。

4.3 模板封装：sysprep 与手工清理的分岔路

模板这部分手册写得很细：Windows 场景做模板导入、按模板部署、删除模板、制作模板、模板导出；CentOS 场景走模板导入、按模板部署、Tools 安装、制作 Linux 模板。核心动作就一个——把一台配置好的虚拟机制成模板，然后批量部署。但模板做不好的后果是灾难性的：批量部署出来的虚拟机主机名一样、IP 一样、网卡顺序错乱。

Windows 侧靠 sysprep 做 generalize，把 SID 和计算机名清掉。Linux 侧没有 sysprep，得手工清理，而手册里的步骤只写了"制作 Linux 模板"，具体清什么要自己补：

# 清理网卡持久化规则，不清的话克隆出来的虚拟机网卡名会变成 eth1、eth2 rm -f /etc/udev/rules.d/70-persistent-net.rules # 清空 machine-id，否则多台克隆机的 systemd 标识重复 truncate -s 0 /etc/machine-id # 清掉网络配置里的硬编码 IP 和 UUID rm -f /etc/sysconfig/network-scripts/ifcfg-eth0.bak # 清日志，减小模板体积 rm -rf /var/log/* # 关机前卸载 Tools 光盘，避免模板里绑着光驱 umount /mnt/tools

machine-id这一条尤其关键，systemd 系的系统用它做唯一标识，重复会导致日志、DHCP 客户端行为异常。清理完之后关机，在界面上执行"制作模板"，模板导出成 OVF 格式再导入到另一套环境，这套流程在两个场景里是通用的。

5. 避坑与排查：五条按「现象-原因-解决」记录的血泪账

5.1 添加主机一直失败，提示与主机通信异常

现象：输入 CNA 管理 IP 和密码后，进度条走很久最后失败，CNA 本身能 ping 通，ssh 也能登。

原因：两个方向。一是管理平面在物理交换机上没放通对应 VLAN，ICMP 能过但管理端口过不去；二是 CNA 和 VRM 系统时间差超过容忍范围，握手阶段被拒。

解决：先从操作机ssh root@192.168.201.101确认不是网络问题，再逐台比对date。时间差用 NTP 或者手工对齐，对完重新添加主机。如果时间一致仍然失败，检查物理交换机的 trunk 放通列表，别只看 ping 的结果。

5.2 扫描存储设备返回空列表

现象：添加 IP-SAN 存储时参数都填了，点"扫描存储设备"没有任何 LUN 出现，也没报错。

原因：按概率排序，第一是 iSCSI 启动器名改了但存储侧没加白名单，存储直接拒绝登录；第二是端口绑定没生效，存储平面实际走的是单口甚至不通；第三是 CHAP 认证开了但密码填错。

解决：回到 CNA 上用iscsiadm -m discovery -t st -p 192.168.202.200:3260手动发现，能列出 target 说明网络和白名单都没问题，问题在 CHAP；列不出来就查白名单和端口绑定。查绑定用cat /proc/net/bonding/bond1，看两个网口是不是都 up。

5.3 虚拟机能开，但网络不通

现象：虚拟机正常启动，系统里看网卡是 up 的，就是 ping 不通网关，同端口组的另一台虚拟机能通。

原因：最常见的是虚拟网卡类型选成了 e1000，而系统里没装对应的驱动；其次是端口组 VLAN ID 和虚拟机上配的标签不一致；还有一种是虚拟机挂的端口组被误改。

解决：先在虚拟机里确认网卡型号，lspci | grep -i ethernet看是 virtio 还是 e1000，virtio 才对。再看端口组的 VLAN ID 和虚拟机上手工配的子接口是否一致。有条件的话在端口组对应的上行链路上抓包，看报文到底有没有出去。

5.4 热迁移失败，提示资源不足或迁移超时

现象：手动发起热迁移，任务卡在某个百分比然后失败，虚拟机没受影响的继续跑着。

原因：热迁移要求虚拟机磁盘在共享存储上，本地盘直接不支持；另外两台主机的 CPU 特性不一致时，内存状态没法兼容迁移；还有一种情况是迁移网络没规划，走管理平面导致带宽不够、超时。

解决：先确认虚拟机的磁盘位置，在虚拟机详情里看存储是共享数据存储还是本地盘。CPU 特性不一致需要在集群维度开 EVC，把两台主机的 CPU 基线拉到同一代。迁移网络这块，规范做法是单独划一个 VLAN 专门跑迁移流量，别和管理平面挤在一起。

5.5 模板部署出来的虚拟机主机名和 IP 一样

现象：用模板批量部署三台虚拟机，开机后三台的主机名完全相同，IP 也冲突，网络时通时不通。

原因：制作模板前没做封装。Windows 没跑 sysprep，Linux 没清 machine-id 和网络配置，模板里带着原来那台机器的身份信息。

解决：回炉重做模板。Windows 关机前执行sysprep /generalize /oobe /shutdown，Linux 按 4.3 里那几条清理命令走一遍再关机。部署时如果是 Linux，最好配合 cloud-init 注入主机名和 IP，靠手工改在批量场景下不现实。

6. 进阶验证：HA 与热迁移能不能真跑通，看这几个动作

实验做到最后，手册里的功能按钮你都会点了，但"点成功"和"真生效"是两回事。HA 和热迁移这两个功能尤其如此，界面上显示配置成功，实际切换时可能一次都没成功过。我自己验证这两个功能有个固定套路，分享出来可以直接抄。

先做热迁移。找一台正在跑业务的虚拟机，在它内部起一个持续 ping，然后在界面上手动发起迁移，同时观察丢包情况：

# 在虚拟机内持续探测网关，每秒一次，记录时间戳 while true; do date +%T ping -c 1 -W 1 10.10.203.1 | tail -1 sleep 1 done

预期结果是迁移过程中丢 1 到 3 个包，时间窗口在几秒内，之后就恢复。如果丢包持续十几秒甚至直接断流，说明迁移走的是管理平面、带宽不够，或者存储不是共享的、走了全量内存拷贝。这个数字比任何配置截图都有说服力。

再做 HA。这个必须用"拔网线"级别的手段，在界面上关主机是不算的。做法是在 CNA 上直接断电或者断掉管理网口，然后盯着集群里那台虚拟机的状态变化。判断标准只有一条：虚拟机会不会在另一台主机上重新起来，起来之后业务能不能在几分钟内恢复。等待期间可以用一个脚本轮询状态，比手动刷界面靠谱：

这里有个前提必须反复强调：HA 生效依赖共享存储和资源预留。集群里如果没做准入控制，故障时另一台主机剩余资源不够，HA 会直接失败，界面上只留一条不痛不痒的告警。所以做这个实验之前，先把集群策略里的预留比例调出来看一眼。

从那以后我每次拿到一份新的实验手册，第一件事不是翻目录找第一步，而是先把里面的地址规划表和参数表抄到一张纸上，逐条对着自己的环境核一遍。这套 FusionCompute 的实验我按这个习惯跑了两轮，第二轮几乎没有卡壳的地方，因为所有会翻车的位置在第一轮都留下了记录。手册本身写得够细，缺的从来不是步骤，而是你对自己环境的那点确认。希望帮到你。

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