企业官网建设流程全解析

简介：《FusionCompute实验手册1》是华为HCIP-Cloud Computing V4.0认证的配套实验指导材料，适合准备考取该认证的学员，以及希望系统掌握FusionCompute服务器虚拟化平台的运维人员。整个资源包体积约10.53MB，共1个Word文档，内容集中，便于直接阅读和随实验进度查阅。手册围绕7个实验展开，分为四大部分：一是基于KVM嵌套环境安装CNA与VRM，完成FusionCompute环境搭建；二是计算、存储、网络三类虚拟化资源池管理；三是虚拟机创建、Tools安装、模板封装、快照管理、规格调整、HA、热迁移、安全组等发放与业务运维操作；四是用户管理、数据备份、时间管理等常见运维工作。当前已有227人浏览学习。读者按手册逐步操作，既能理解FusionCompute的架构原理，也能获得从环境部署到日常维护的完整实战经验，为后续运维华为虚拟化平台或桌面云打下基础。

1. 有人考完了 HCIP-Cloud Computing V4.0 笔试，却被这本 FusionCompute 实验手册卡住

很多人在刷 HCIP-Cloud Computing V4.0 的题时，把精力都放在 FusionCompute 的概念和架构上，真拿到《FusionCompute实验手册1》开始动手，才发现从 CNA 安装到模板封装每一步都能翻车。这份手册对应 HCIP-Cloud Computing V4.0 认证中 FusionCompute 部分的完整实验路线，七个实验按四段推进：环境搭建、计算/存储/网络三类虚拟化资源管理、虚拟机发放与运维、日常管理。它模拟某企业采购两台物理服务器做 FusionCompute 可行性验证的场景，让你在 KVM 嵌套虚拟化环境里独立装完 CNA 和 VRM，再验证 HA、热迁移、模板发放这些核心功能。适合准备考试但没摸过真实环境的学员，也适合要在测试环境里评估 FusionCompute 落地边界、提前趟一遍坑的工程师。

2. 环境搭建：从 KVM 嵌套到 CNA、VRM 的完整落地步骤

2.1 实验拓扑与网络规划：管理网和存储网为什么要分开

手册的实验环境不是一台虚拟机搞定，而是模拟某企业采购两台物理服务器作为计算节点，再加额外的存储设备。整套拓扑里有两个关键节点：CNA 是计算节点代理，承担虚拟机的实际运行；VRM 是虚拟资源管理节点，负责集群、存储、网络的统一调度。实验用的是 FusionCompute 6.5.0 版本，安装包分为 Installer 和 VRM 两个压缩包，底层依赖 KVM 嵌套虚拟化。

网络规划是这套实验最先要理清楚的部分。管理网负责 CNA、VRM 之间的控制面通信，存储网单独划一个 VLAN 承载 IP-SAN 存储流量。把存储流量和管理流量隔开，是为了避免业务 IO 高峰时存储流量挤占管理面带宽，导致主机掉线、HA 误判。实验里的 VLAN 规划如下：

存储设备同时接了管理网和存储网，意味着你既能走管理 IP 做配置，也能走存储网络提供存储 IO。VRM 本身也是一台虚拟机，挂在 CNA 上，所以它只需要管理 IP。做实验时别把这三段 IP 混在一起，否则后面加主机、扫存储都会出现「能看到但连不上」的玄学问题。

2.2 安装 CNA：两个节点别一上来就改错管理口

CNA 的安装过程不算复杂，但有两个地方最容易出错：一是引导介质，二是管理口选择。先把 FusionCompute 6.5.0_Installer.zip 解压，把里面的 ISO 镜像挂载到物理服务器的虚拟光驱上，或者做成启动 U 盘。开机引导后选择安装 CNA，按提示设置 root 密码，然后配置管理网口 IP，CNA01 填 192.168.201.101，掩码 24 位，网关指向 192.168.201.1 这条链路上的实际网关。

这里有个容易被新手忽略的点：物理服务器通常有多个网口，安装界面里列出的网卡顺序和你在交换机上插的端口不一定对应。我一般会先拔掉其他网线只留管理口那一根，再根据界面里 UP 状态的网卡确认该选哪一块，避免装完发现管理 IP 配在了一块没插线的网卡上。CNA02 用同样的方式装，IP 换成 192.168.201.102，其余参数保持一致。

装完后不要急着装 VRM，先把两个 CNA 节点的连通性确认好：

# 从你的运维终端分别ping两个CNA的管理IP ping -c 3 192.168.201.101 ping -c 3 192.168.201.102 # SSH登录CNA01，确认主机名和网卡状态 ssh root@192.168.201.101 ip addr show eth0 # 检查CNA核心进程是否在跑 ps -ef | grep uvp | head -10

这段检查里，ping 通只代表二层三层网络是通的，SSH 能登上去才说明系统引导正常、sshd 服务可用。ps 查看 uvp 相关进程是为了确认 CNA 的虚拟化底座真的起来了，这个进程起不来，后面创建虚拟机一定失败。

2.3 安装 VRM：单节点部署时的关键参数

VRM 安装是整套实验里最像「产品交付」的环节。先在一台 CNA 上创建一台空白虚拟机，规格给 4 核 CPU 和 8 GB 内存足够，把 FusionCompute 6.5.0_VRM.zip 解压出来的 ISO 挂到虚拟光驱，然后启动虚拟机进入 VRM 部署向导。

部署向导里需要重点确认几个参数。部署模式选单节点，管理 IP 填 192.168.201.100，浮动 IP 和管理 IP 可以保持一致，数据存储选择 CNA 本地磁盘即可，因为实验环境的 VRM 数据量很小。VRM 的管理界面默认走 HTTPS，端口是 8443，部署完成后用浏览器或者 curl 验证一下：

# 验证VRM Web界面是否已经起来 curl -k https://192.168.201.100:8443/ -o /dev/null -w "%{http_code}\n" # 登录VRM节点查看VRM进程状态 ssh root@192.168.201.100 ps -ef | grep vrm | head -10

curl 的 -k 参数是跳过证书校验，因为 FusionCompute 默认使用自签名证书，第一次访问浏览器也会报不受信任，直接放行即可。-w 输出 HTTP 状态码，看到 200 或者 302 都说明 Web 服务已经起来了。如果返回 000，说明端口没监听或者防火墙拦截，去检查 VRM 虚拟机是否正常运行。

2.4 安装阶段三个翻车点

现象一：安装 CNA 时报错 CPU 不支持虚拟化。原因：宿主机 BIOS 里的 VT-x 或 AMD-V 没开启，嵌套虚拟化环境里尤其常见。 解决：进宿主机 BIOS 打开 CPU 虚拟化开关；如果是跑在虚拟机里的嵌套环境，还要确认宿主机的 CPU 型号支持并把嵌套虚拟化功能透传给这台虚拟机。

现象二：VRM 部署完成后 Web 界面一直打不开。原因：VRM 虚拟机没起来，或者管理 IP 配置时写错了网段。 解决：先回到 CNA 的 Web 管理界面看 VRM 虚拟机状态，再通过 VNC 登进 VRM 系统里核对 IP 配置。不要反复重装，先看 console。

现象三：两个 CNA 都装完，跨节点 ping 管理 IP 不通。原因：两台 CNA 的管理口接在了不同的物理交换机上，中间 VLAN 没放通，或者安装时选错了网卡。 解决：在交换机侧确认 VLAN 201 在两个端口上都放行，并回到 CNA 上核对 ip addr 输出里管理 IP 所在的网卡是否就是插线的那一块。血泪经验：先把网线物理连通确认明白，再折腾软件配置。

3. 计算与存储：集群策略、IP-SAN 与磁盘创建的联动配置

3.1 创建集群与添加主机：先集群后主机的顺序逻辑

FusionCompute 的资源管理逻辑是从集群开始的。集群是计算资源池的载体，也是 HA、DRS 这些策略的作用范围。做这一步时，顺序很重要：先创建集群，再把 CNA 主机加进集群。反过来先加了主机再建集群，主机的配置项会一直停留在未纳管状态，很多策略选项是灰的。

登录 VRM 的 Web 界面，进入资源池视图，创建集群，填写集群名称后，先把 CPU 和内存的复用参数定下来。实验环境建议 CPU 复用比设为中等，内存复用暂时打开，因为后面要领多台虚拟机验证模板发放，资源不够会很被动。集群创建完成后立即添加主机，输入 CNA01 的 root 账号密码，VRM 会向 CNA 发起纳管握手，中间需要确认主机的证书指纹。

添加主机时如果提示「主机不可管理」，最常见的原因是 CNA 节点和 VRM 节点时间不同步，证书校验直接失败。实验环境里时间偏差稍微大一点，握手就会失败。后面 5.6 节会专门讲时间同步的排查，这里先记住一个粗糙的规律：Web 界面上所有莫名其妙的报错，先对时。

3.2 集群策略：HA 与 DRS 的参数边界

集群建好后，要理解 HA 和 DRS 各自管什么。HA 是主机故障时把虚拟机在其他主机上重新拉起，DRS 是负载不均衡时自动迁移虚拟机。实验手册里这部分操作不复杂，但参数边界经常让人困惑。

HA 策略里有两个参数需要确认。一个是槽位预留，你需要在集群级别预留一部分 CPU 和内存资源供 HA 使用，如果预留不够，主机故障后其他主机根本没有余量接住故障虚拟机。另一个是心跳网络，CNA 之间通过管理网互相发心跳，管理网断了，整个集群会认为所有主机都失联，触发脑子分裂，所以生产环境会把心跳单独放一张网。实验环境就按手册默认配置，但你要知道这个限制存在。

DRS 策略的核心是迁移阈值，阈值设得越激进，系统越容易迁移虚拟机，实验环境里建议保持默认，不要为了看效果调到最激进。我见过有人把阈值拉到最低，两台主机之间虚拟机来回飘，存储流量被打满，业务直接抖动。做实验的目的是理解机制，不是刻意制造负载。

3.3 存储接口与 IP-SAN：启动器号、端口绑定与扫描

存储部分第一步是配置主机的存储接口。CNA01 和 CNA02 各需要一块网卡加入存储网络 VLAN 202，分别配置 192.168.202.101 和 192.168.202.102。这里不改默认网卡的 IP，而是新增存储接口，这样管理面和存储面在系统层面就是分离的。

接着是修改主机的 iSCSI 启动器号。两台 CNA 如果用默认的启动器号，连接到同一个存储设备时会发生冲突，表现为扫描存储设备时只有一台主机能看到。SSH 登录 CNA，查看启动器文件：

# 查看并修改iSCSI启动器号 ssh root@192.168.201.101 cat /etc/iscsi/initiatorname.iscsi # 修改为带主机编号的唯一名称 # 例如 InitiatorName=iqn.2024.fusioncompute:cna01 vi /etc/iscsi/initiatorname.iscsi systemctl restart iscsid

iSCSI 启动器号是存储设备识别主机的唯一标识，两台主机必须使用不同的名称。修改后重启 iscsid 服务让配置生效。这一步做完再去 Web 界面添加存储资源，把存储设备的 IP 填成 192.168.202.11，协议选 IP-SAN，然后执行扫描。扫描到存储设备后，把存储设备添加为数据存储，数据存储是后续虚拟机磁盘落盘的地方。

如果扫描不到设备，排查顺序是：先 ping 存储 IP 确认网络通，再确认启动器号不冲突，最后看存储设备侧是否做了 LUN 映射，没映射的 LUN 在 FusionCompute 侧永远扫不到。

3.4 创建磁盘：普通精简磁盘的参数与回收边界

数据存储就绪后，创建磁盘的操作本身不复杂，但磁盘类型的选择会影响后面几十个实验步骤。手册里创建的是普通精简磁盘，这种磁盘按需分配空间，创建时只记录虚拟容量，实际写入多少才占用多少存储。另一类普通磁盘是创建时就全额分配空间，性能更稳定但浪费容量。

实验环境选择精简磁盘是合理的，因为嵌套虚拟化环境本身磁盘空间有限，几台虚拟机加几个快照，普通磁盘立刻把宿主机磁盘撑爆。但要知道精简磁盘的回收逻辑：虚拟机内删除文件，不会自动把空间归还给数据存储，需要通过 Web 界面执行存储回收或者依赖底层存储的回收机制。遇到数据存储空间越用越少，不一定是磁盘泄漏，可能是精简磁盘长时间没有回收。

磁盘创建界面里还有磁盘属性和总线类型选项，SCSI 是默认选择，兼容性最好。后续制作模板时，模板里的磁盘类型会继承到所有部署出来的虚拟机上，所以这一步选定后尽量不要频繁改动。

4. 网络与虚拟机发放：分布式交换机、模板与 Tools 的完整链路

4.1 分布式交换机：上行链路、VLAN 池与端口组

网络资源管理的入口是分布式交换机。FusionCompute 的分布式交换机可以理解成一个跨主机的虚拟二层交换设备，CNA01 和 CNA02 上的虚拟机可以通过它通信，即使两台虚拟机落在不同物理主机上。创建分布式交换机时，先绑定上行链路，把每台 CNA 上的一块物理网卡加入交换机；再添加 VLAN 池，给端口组划分可用的 VLAN 范围；最后添加端口组，虚拟机接入端口组就能获得网络连通性。

实验手册里的操作顺序是创建交换机、添加上行链路、添加 VLAN 池、添加端口组。这里的关键是 VLAN 池的规划，实验环境里把业务 VLAN 和存储 VLAN 分开，端口组需要明确指定所属 VLAN。如果端口组的 VLAN 没配好，虚拟机启动后 DHCP 拿不到地址，手动配 IP 也 ping 不通网关，这时候检查的不是虚拟机网卡，而是端口组和上行链路。

4.2 Windows 虚拟机：发放、Tools 与模板封装

虚拟机发放实验分 Windows 和 CentOS 两个场景。Windows 场景的流程是：在 Web 界面上创建空虚拟机，挂载 Windows 10 x86_64 的镜像，VNC 连进去手动安装操作系统，然后安装 Tools。Tools 是 FusionCompute 的增强组件，没有它，虚拟机只能做基础运行，热迁移、HA 这些高级功能全部不可用。

Tools 安装完成后，下一步是制作模板。制作模板的核心操作是「封装」，Windows 虚拟机封装时会执行类似系统准备的操作，清除 SID、重置激活信息，这样从模板部署出来的虚拟机才不会出现 SID 冲突和激活失败。封装通常在虚拟机开机状态下发起，封装完成后虚拟机会自动关机，然后转换为模板。转换完成后，再从模板批量部署虚拟机。

实验手册里这一步用的是模板导入和按模板部署的组合：先把一个现成的模板导入环境，部署几台虚拟机出来，再挑一台做封装制作新模板。这套流程在生产环境里很常见，导入模板相当于拿到了一个经过验证的基线，直接部署虚拟机省去重复装系统的时间。

4.3 Linux 模板的封装与清理

CentOS 7 场景的流程和 Windows 类似，但 Linux 模板封装前需要手动清理一些系统痕迹。如果不清理，同一模板部署出来的多台虚拟机会有相同的 machine-id 和网卡规则，可能导致 DHCP 地址冲突和网络服务异常。封装前在虚拟机里执行清理：

# 清理网卡持久化规则 rm -rf /etc/udev/rules.d/70-persistent-net.rules rm -f /etc/machine-id # 清理SSH主机密钥（可选，部署后会自动重新生成） rm -rf /etc/ssh/ssh_host_* # 关闭NetworkManager的持久化连接文件 rm -rf /etc/sysconfig/network-scripts/ifcfg-eth0.bak

清理完成后关机，在 Web 界面执行转换为模板。这里的参数坑在于：封装后再启动虚拟机会重新生成 machine-id，所以清理操作必须在关机封装之前执行。如果顺序反了，模板做出来再部署，还是会带着源虚拟机的身份信息。

CentOS 的 Tools 安装和 Windows 不同，Windows 是双击安装包，Linux 一般需要挂载 Tools 镜像后执行安装脚本。Tools 版本和内核版本不匹配时，安装过程可能报错或者装完不生效，我一般会先看内核版本再选 Tools 版本，实验环境直接用手册配套的版本即可。

4.4 快照、规格调整与热迁移的边界

虚拟机发放完之后，实验手册还覆盖了快照、规格调整、热迁移这些运维动作。快照相当于虚拟机的后悔药，做模板前我会习惯性地先打一个快照，封装失败直接回滚，不用重新部署一台虚拟机。要注意快照不是越多越好，每个快照都会占用存储空间，实验环境磁盘紧张时，快照累积会让数据存储迅速膨胀。

规格调整分在线和离线两种边界。CPU 和内存的调整在虚拟机开机状态下部分支持，但内存的热添加要求虚拟机使用特定配置；磁盘扩容有些可以在线完成，磁盘缩小则通常不支持。做规格调整前，先去 Web 界面看虚拟机当前状态，再决定是否需要关机操作。

热迁移是把虚拟机在不停机的情况下从一个 CNA 移到另一个 CNA。实验手册里安排了热迁移验证，运行中的虚拟机从 CNA01 迁到 CNA02，业务不断。但热迁移有前提条件：虚拟机必须安装 Tools，两台 CNA 的 CPU 型号需要兼容，虚拟机不能挂载直通设备。实验环境里条件都满足，迁移应该能顺利执行；生产环境里遇到迁移失败，先对照这三个前提排查。

5. 避坑专章：FusionCompute 实验里最常见的五个现场故障

5.1 模板部署后虚拟机蓝屏或网络异常

现象：从 Windows 模板批量部署几台虚拟机，部分虚拟机开机蓝屏，或者能进系统但网络不通、SID 相同。 原因：模板制作时封装步骤没有真正完成，或者封装时虚拟机还有外部设备未移除，系统准备没有执行干净。 解决：回到模板制作的原始虚拟机，确认 Tools 版本正常，重新发起一次封装操作，等待封装进度走到「已关机」状态，再执行转换为模板。部署出来的虚拟机如果网络异常，在虚拟机内手动执行系统重新封装或重配网卡，不要继续沿用一个有问题的模板。

5.2 热迁移一直排队或失败

现象：发起热迁移后任务一直排队，或者执行到一半报错失败。 原因：最常见的是虚拟机没有安装 Tools，导致 FusionCompute 无法在目标主机上重建相同配置；其次是源和目标主机的 CPU 指令集不兼容。 解决：先检查虚拟机的 Tools 状态是否为已安装，再确认两台 CNA 的 CPU 型号是否一致。实验环境的嵌套虚拟化场景里，如果宿主机 CPU 透传配置不对，也会导致迁移失败，重启 CNA 后重新发起迁移即可。

5.3 HA 触发后虚拟机没有在备机拉起

现象：手动模拟主机故障后，故障主机上的虚拟机没有在其他 CNA 上启动。 原因：集群的 HA 槽位预留不足，其他主机剩余资源不够承载故障虚拟机；或者 CNA 之间的心跳中断，导致集群无法正确判断故障范围。 解决：在集群属性里调大 HA 预留的 CPU 和内存资源。另外检查管理网 VLAN 是否放通，确保 CNA01 和 CNA02 的管理 IP 能互相 ping 通。实验环境中我遇到过管理网交换机端口配置了风暴控制，直接把心跳报文丢弃，导致 HA 一直不触发。

5.4 数据存储扫描不到设备或频繁离线

现象：添加 IP-SAN 存储时扫描不到 LUN，或者数据存储添加后偶尔显示离线。 原因：两台 CNA 的 iSCSI 启动器号冲突，或者存储设备侧的多路径策略配置不对；也可能是存储网络 VLAN 202 在交换机上没有放通。 解决：先按 3.3 节的步骤确认每台主机的启动器号唯一，再排查存储网络连通性，ping 192.168.202.11 必须通。如果数据存储频繁离线，检查 CNA 到存储交换机之间的链路是否为聚合模式，单链路抖动会让存储设备在多个路径之间切换困难。

5.5 删除集群提示主机仍然存在

现象：想删除一个不再使用的集群，系统提示集群内仍有主机，无法删除。 原因：FusionCompute 不允许直接删除有主机的集群，这是安全机制，防止误操作导致业务虚拟机失联。 解决：先把集群内所有主机移出集群。移出前主机上的虚拟机需要先迁移或关机，然后执行主机维护模式，把主机从集群中移除，再删除集群。习惯上我会把主机维护模式这个动作当成标准前置操作，很多删除类的操作都要求先进入这个状态。

5.6 用日志、时间轴和维护模式定位复杂问题

前面五个故障如果按现象排查还解决不了，就要进入日志环节。FusionCompute 的 CNA 节点基于 Linux，SSH 登录后看 /var/log/messages；VRM 节点的日志集中在 /var/log 目录下，Web 界面的管理平面也会记录事件。定位问题时先把时间轴对齐：把故障发生时间和日志窗口时间段对应上，再去翻那个时间段的报错，效率比漫无目的地翻日志高很多。

时间同步是所有日志排查的前提。CNA、VRM 之间的时间偏差超过 5 分钟，证书校验、HA 心跳判断都会出问题。建议实验环境的每台节点都配置 NTP，统一对时：

# 在CNA或VRM节点上查看当前时间和时间同步状态 ssh root@192.168.201.101 date chronyc tracking | grep -E "System time|Leap status"

看到 System time 后的偏差值很大，就说明时间同步没有生效。配置 NTP 后再观察 Web 界面上的主机状态，很多之前看似诡异的问题会自动消失。时间不同步在 FusionCompute 里不是小问题，它会导致 HA 误判、证书失效、日志时间错乱，排查问题时时间轴对不上，你会觉得整套系统像个黑匣子。

6. 验证你的环境：三条路径确认 FusionCompute 真的能用

环境搭完不能只看 Web 界面全绿就结束。我习惯把验证拆成三条路径，每条路径覆盖不同的层面，全部走通才算真的可以把这套环境交给业务方。

第一条路径是 Web 界面巡检。进入资源池视图，看集群健康状态、每台 CNA 的计算资源和存储资源是否正常，数据存储是否在线。重点看一眼事件列表，把有告警的条目逐条处理，不要留不确定性的告警到后面。

第二条路径是命令行快速体检。登录 CNA 和 VRM 节点，检查核心进程、磁盘空间和网络连通性：

# 从VRM节点发起全面连通性检查 curl -k https://192.168.201.100:8443/ -o /dev/null -w "%{http_code}\n" ping -c 3 192.168.201.101 ping -c 3 192.168.201.102 # 检查CNA和VRM节点的磁盘空间 ssh root@192.168.201.101 df -h /var/log ps -ef | grep uvp | head -10

curl 返回 200 或 302 说明 Web 管理面正常，两个 CNA ping 通说明管理网络稳定，df -h 确认日志分区没写满，ps 检查进程存活。任何一步异常都值得深挖，别抱着「应该没问题」的心态跳过。

第三条路径是端到端功能演练。从模板部署一台新虚拟机，打一个快照，在线调整一次 CPU 规格，然后执行热迁移到另一台 CNA，最后模拟主机故障验证 HA。这套动作覆盖了实验手册里虚拟机管理部分的核心功能，每一个环节成功，才说明这套环境的计算、存储、网络是联动的。

我曾在一个模拟项目里把环境搭完就直接删了测试虚拟机，结果后面演示时才发现热迁移一直失败，原因是最初那台模板机没有装 Tools。从那以后我每次搭完 FusionCompute 环境，都会强制把三条验证路径完整走一遍，尤其是关一台主机看 HA 响应的那一步，过程虽然繁琐，但能让你在后面几十个小时的实验里少踩一半的坑。希望帮到你。

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