企业官网建设流程全解析

简介：《FusionCompute实验手册1》是华为HCIP-Cloud Computing V4.0认证的实验指导资料，面向备考学员及需要掌握FusionCompute运营运维的虚拟化工程师，手册设计了7个实验，覆盖环境搭建、虚拟资源管理、虚拟机发放与管理、常见运维四大部分。环境搭建实验从安装CNA与VRM入手，帮助读者理解FusionCompute基础架构；虚拟资源管理实验涵盖计算、存储、网络资源管理，对应三大虚拟化核心功能；虚拟机发放与管理实验涉及虚拟机创建、Tools安装、模板封装、快照、规格调整、HA、热迁移、安全组等操作；常见运维实验则包括用户管理、管理数据备份和时间管理。借助这些实验，读者既能理解虚拟化原理，也能补齐从平台部署到日常维护的实践技能，为后续构建华为虚拟化环境与桌面云打下基础；压缩包内为1个docx文档，共10.53MB，结构清晰、步骤完整，便于边学边练；目前已有227人学习，适合备考或希望深入掌握FusionCompute系统运维的读者按此手册逐步实践。

1. FusionCompute实验手册：从能装到能跑，这本手册真正解决什么

FusionCompute是华为的虚拟化平台，实验手册1这类资料的价值不在于教你怎么点界面，而在于把“装一个能用的虚拟化环境”这条路上所有的坑提前踩平。我见过太多人拿到手册后卡在第一步：ISO下下来了，部署工具也打开了，结果要么VRM起不来，要么存储域报错，要么虚拟机装完网络不通——这些都不是产品问题，是实验环境的前置条件没摆对。

这篇笔记围绕FusionCompute实验环境从零搭建来写：组网怎么规划、存储怎么接、网络怎么调、虚拟机怎么发、出了问题怎么定位。新手按步骤能跑通，老手可以跳过前半段直接看第5章的排错记录和第6章的日志定位技巧。

2. 搭一套FusionCompute实验环境：组网规划与VRM/CNA部署步骤

2.1 实验物理拓扑与对服务器的最低要求

FusionCompute的逻辑角色分两类：VRM负责管理面，CNA负责计算面。实验环境可以一台物理机跑两个角色，也可以一虚一实分开，我建议至少准备两台服务器，一台跑VRM，一台跑CNA，否则后面做虚拟机迁移实验时会发现源主机和目标主机是同一台，很多验证做不了。

实验环境最常见做法是直接套在VMware或KVM之上做嵌套虚拟化。原因很实际：FusionCompute要求CPU支持VT-x/AMD-V，服务器上开两个虚拟机，每个分配4核8G，就能撑起一个最小可用实验环境。但嵌套有个硬条件——外层VMware必须把“虚拟化CPU硬件辅助”透传给虚拟机，否则FusionCompute安装时检测CPU虚拟化特性会直接报错。

内存是第一步最容易翻车的地方。VRM的内存低于4G时，部署工具的预检查阶段直接红屏，连进入正常安装流程的机会都没有。数据盘容量同样不要抠，后续创建虚拟机、做快照、存储迁移全都依赖这个空间。

网络规划方面，实验环境至少拆三张网：管理网（VRM与CNA通信）、业务网（虚拟机对外通信）、存储网（对接NFS或者iSCSI）。真机上需要对应的物理网卡或VLAN，嵌套实验环境里用虚拟交换机端口组来模拟也行。

2.2 部署VRM与CNA：安装顺序、IP规划与关键参数

FusionCompute的部署路径是“先装CNA，后装VRM”，但实际用部署工具操作时，流程是CNA系统安装完成后，VRM通过ISO里的部署工具注册到CNA上。下面以常见部署工具的图形化操作为例。

IP规划建议预留三段独立子网：

部署参数里最容易改错的是“主机名”和“管理IP”。主机名不要带下划线，IP必须手动指定，不能依赖DHCP。DHCP分配的IP一旦在实验过程中重新续租，VRM和CNA之间的心跳就会断，后续出现一堆莫名其妙的资源异常告警。

CNA安装完成后的验证方式很简单，在浏览器输入：

# 测试CNA管理面端口是否响应 ping 192.168.100.11 curl -k https://192.168.100.11:8443

curl返回HTTP响应头就算通。VRM部署则走ISO里的部署向导，选择“安装VRM”，指定管理IP、网关、DNS（实验环境可以不填DNS）、NTP服务器（单机环境跳过即可）。

NTP这个参数容易被忽略，但如果后续要级联、要对接FusionSphere其他组件，时间不同步会导致证书校验失败。实验环境如果只有一台VRM，不配NTP问题不大；有CNA时，CNA会以VRM为时钟源。

VRM部署完成后，平台管理面的入口一般是https://VRM管理IP:8443，用默认管理员账号登录。注意：FusionCompute的管理员密码复杂度要求比较高，实验环境也要含大小写字母、数字和特殊字符中的至少三类，否则会卡在密码设置环节。

2.3 环境自检：三分钟确认管理面与计算面是否正常

部署完不要急着去建虚拟机，先花三分钟做自检。登录VRM管理面后，重点看两个位置：

• 主机管理页面里CNA是否处于“正常”状态、有没有“已连接”标记。
• 告警页面有没有“主机不可达”“存储域不可达”之类的红色告警。

命令行层面，SSH登录CNA节点，看关键进程状态：

# SSH登录CNA后检查关键进程 ps -ef | grep galax service ospsd status

galax是计算面的关键进程集，只要它在，虚拟机的基础生命周期操作就有的救。如果ps看不到galax相关进程，先别查配置文件，直接重启节点往往比反复找原因更快。这条经验来自实际踩坑：很多自检发现的进程异常，其实都是部署时网卡链路震荡造成的，重启后自动恢复。

如果管理界面上CNA状态“异常”或“离线”，优先级排查顺序是：先ping管理IP通不通，再排查VRM节点上的防火墙，最后看CNA上是否有两个管理网卡绑在同一IP上。IP冲突在嵌套实验环境里特别常见，因为外层虚拟机的MAC地址可能被克隆，导致内网出现IP地址重复分配。

3. FusionCompute存储与网络配置：把NFS和分布式虚拟交换机调对

3.1 存储接入选哪种：虚拟化存储与非虚拟化存储的取舍

FusionCompute的存储形态分两大类：虚拟化存储（FusionStorage）和非虚拟化存储（传统SAN/NAS/iSCSI）。实验环境我强烈建议选非虚拟化存储里的NFS，原因只有一条：FusionStorage要在三台以上节点上组集群，实验环境造不出这个条件。

非虚拟化存储对FusionCompute来说就是“拿来即用”的共享存储域，创建数据存储、挂载到主机、创建虚拟机，全部基于标准的文件共享协议，不依赖额外的存储集群组件。唯一要注意的是，FusionCompute要求NFS共享目录由专门的存储服务器提供，不要直接拿VRM本机目录开NFS来用——这个做法在实验环境里能被识别出来，但性能很别扭，而且日志里会有持续报错。

3.2 对接NFS存储：挂载选项、权限校验与容量规划

NFS服务器准备起来不复杂，一线最常用是拿一台CentOS或Ubuntu虚机做NFS服务端。共享目录的配置核心是权限和协议版本。

# NFS服务端配置示例（/etc/exports） /opt/fusioncompute_nfs 192.168.10.0/24(rw,sync,no_root_squash,no_subtree_check)

no_root_squash是关键项。FusionCompute的存储代理进程以root身份访问共享目录，如果NFS服务端把root映射成了nobody，存储域创建时会报“权限不足”或“目录不可写”，这是所有NFS对接问题里出现频率最高的一条。

FusionCompute侧创建数据存储时，需要填NFS服务器的IP和共享路径。挂载参数通常用默认即可，但协议版本要确认。实验环境里NFSv3比NFSv4更容易适配，因为v4的权限模型更严格，稍有不慎就会出现“挂载成功但写不进去”的玄学问题。

# NFS客户端侧验证挂载（在CNA上执行） showmount -e 192.168.10.20 mount -t nfs 192.168.10.20:/opt/fusioncompute_nfs /mnt/test

如果showmount能列出共享目录，但mount一直卡住或报Protocol not supported，多数是服务端只启用了NFSv4，FusionCompute默认尝试NFSv3导致的。解决方式是在服务端/etc/nfs.conf里显式启用vers=3。

容量规划上，实验用的NFS共享路径不要只给一个，至少分三个：一个放ISO镜像，一个放虚拟机磁盘，一个放快照。三种数据IO特性不一样，混在一起会给后续排查性能问题增加噪音。

3.3 创建分布式虚拟交换机：端口组、VLAN与绑定模式

FusionCompute的网络核心是分布式虚拟交换机（Distributed Virtual Switch），它把物理网卡抽象成上行链路，虚拟机接入到端口组，网络行为由策略统一管控。

绑定模式是实验环境最容易埋雷的地方。嵌套虚拟化环境下，外层VMware虚拟网卡的“物理链路”本质上是同一根虚拟总线，如果FusionCompute侧配置了active-active绑定，数据包会在两层虚拟化之间来回震荡，表现就是管理面断断续续、虚拟机网络时通时不通。

创建交换机时，端口组要按业务场景拆开：管理端口组、业务端口组、存储端口组各建一个。VLAN ID可以都用0（表示不打标签），但要保证这三个端口组在物理网络上确实隔离，否则实验环境里广播域太大，DHCP请求满天飞，虚拟机开机的速度都会变慢。

3.4 网络连通性验证：ping网关、跨主机迁移测试

网络配完别信界面上显示的“正常”，那只是配置下发成功，不代表数据面通了。验证分两层：

# 第一层：虚拟机内部验证（安装完系统后执行） ip addr show ping 192.168.200.1 # 业务网网关 ping 192.168.100.11 # VRM管理面 # 第二层：跨主机迁移验证（在FusionCompute界面上） # 将虚拟机从CNA1动态迁移到CNA2，观察业务是否中断

跨主机迁移是检验网络质量最狠的手段。迁移过程中虚拟机的内存页面要通过业务网拷贝到目标主机，如果有丢包，迁移要么卡在99%，要么完成后虚拟机网络不通。我在实验环境里遇到过一次典型的“迁移成功但虚拟机失联”，排查后发现是两个CNA主机的业务端口组VLAN ID不一致，迁移过去后虚拟机还在原来的VLAN里，但新主机对应的端口组已经把标签给去掉了。

这类问题在界面上看不到任何告警，因为FusionCompute认为网络配置合法。只能靠对照两个主机上的端口组配置来定位。所以实验手册里凡是涉及迁移步骤，我都会先在主机配置页面截个图，后面出问题有个对照基准。

4. 在FusionCompute上发放第一台虚拟机：模板、快照与迁移的闭环

4.1 从镜像模板到虚拟机：最小配置清单与发放流程

FusionCompute发放虚拟机的方式和多数虚拟化平台一致：要么直接建空虚拟机挂ISO安装，要么从模板克隆。实验环境我建议走“装一台→转模板→批量克隆”的路线，顺手把模板流程也练了。

最小配置清单：

发放流程中有一个细节：操作系统ISO要挂载到虚拟机的光驱里，FusionCompute的虚拟光驱支持从数据存储中的ISO文件挂载，也可以直接指定CNA主机上的ISO路径。实验环境建议把ISO上传到数据存储，然后用存储挂载方式，这样两台CNA都能访问同一份镜像，后续做迁移测试不会出现“光驱不可用”的报错。

虚拟机创建完成后，安装操作系统时的虚拟网卡型号默认是e1000，如果要追求性能可以改成virtio，但virtio要求操作系统内安装了对应的驱动。实验环境建议直接用默认型号，降低变量。

4.2 快照与备份：实验环境最容易忽略的回滚保险

做FusionCompute实验，快照是后悔药。改存储配置、调网络参数、做内核升级，任何一个步骤失败都可能让虚拟机直接起不来。快照的好处是它不依赖操作系统层面的备份工具，FusionCompute直接对虚拟机的磁盘文件做差异记录。

# 在FusionCompute界面操作快照的步骤路径 虚拟机组 -> 选中虚拟机 -> 快照 -> 创建快照

创建快照时有个参数叫“内存快照”，勾选后会把虚拟机的内存状态也保存下来。实验环境建议勾上，这样回滚后虚拟机恢复到快照时的运行状态，不用重启。但要注意：内存快照会让快照文件变大，一个2G内存的虚拟机，快照文件就会多出2G。

快照链的长度控制在3个以内。FusionCompute的快照是链式结构，每个快照依赖于前一个快照的差异数据。实验过程中反复做快照又不删旧的，快照链越来越长，最后虚拟机会变得奇慢无比。这不是平台性能问题，是快照链太深导致的IO放大。

4.3 迁移验证：动态迁移与存储迁移的边界条件

动态迁移是FusionCompute实验里最值得做的验证，因为它检验的是底层存储和网络的整体健康度。

动态迁移的前提条件是：两台CNA主机能同时访问同一个数据存储。在NFS存储方案里，只要NFS挂载参数一致，虚拟机磁盘文件能被两个主机同时识别，迁移就能启动。

存储迁移则是把虚拟机的磁盘文件从一个数据存储搬到另一个。实验环境里可以做一次“NFS-A到NFS-B”的存储迁移，验证数据拷贝链路。这里有个很实际的坑：存储迁移过程中，FusionCompute会对源磁盘做快照，然后把差异数据拷贝到目标存储。如果源NFS所在主机的磁盘空间不足，快照创建成功但写入失败，迁移任务会一直停在“正在创建快照”的状态。

# 迁移中查看任务状态的建议做法 # 在VRM管理面 -> 任务中心 -> 查看迁移任务日志 # 重点看“存储卷”和“拷贝进度”字段

迁移失败后，不要立刻重试。先把源数据存储上的临时快照删掉，清理空间，再重新发起迁移。硬重试往往会带着上一个任务的残留状态，导致第二次迁移也在同一个地方卡住。

5. FusionCompute常见问题与避坑：安装、存储、性能三类排错记录

5.1 VRM安装失败：内存校验与磁盘空间这两个隐形门槛

现象：VRM部署进度条走到30%左右就报错，错误信息提示“环境预检查失败”，但界面没有具体指向。

原因：我遇到过两种，一是VRM虚机内存分配了3G，低于系统要求的阈值；二是系统盘只有30G，分区工具给/opt目录分配的可用空间不足5G。VRM的安装包解压、组件安装、日志写入全部集中在/opt目录下，空间不够时安装进程会静默失败。

解决：把VRM虚机内存调到8G，系统盘扩到50G以上。如果初始化时分区已经固定，最简单的做法是重建虚机，不要试图手工扩分区。

5.2 NFS存储域异常：挂载选项不一致导致的数据存储漂移

现象：NFS数据存储创建成功，在主机A上显示正常，但主机B上显示“不可用”或“域离线”。重新执行扫描后，主机A和主机B上的存储状态不一致。

原因：两台CNA挂载同一个NFS路径时，挂载参数不一样，或NFS服务端把两个客户端的访问权限做了限制（no_root_squash没有覆盖全部网段）。FusionCompute要求同一数据存储在所有主机上的挂载状态一致，不一致时就会出现“存储域分裂”的表现。

解决：登录两个CNA主机，执行mount | grep nfs对比挂载参数。把/etc/exports里的权限网段改成整个实验网段，并在服务端重新exportfs -ra。

5.3 心跳与网络震荡：分布式虚拟交换机下的不稳定信号

现象：VRM管理界面上，CNA主机状态在“正常”和“离线”之间反复横跳，间隔几分钟一次，没有规律。

原因：这是嵌套实验环境下的典型问题。分布式虚拟交换机的上行链路做了网卡绑定，但外层虚拟机平台没有把两块虚拟网卡透传成真正的多队列网卡，FusionCompute的绑定检测会认为物理链路不稳定，持续触发心跳超时。

解决：实验环境不要配置网卡绑定，换成单上行链路。如果一定要练绑定功能，至少保证外层虚拟机的两块虚拟网卡连接到了不同的物理网卡或不同的虚拟交换机，不要挂在同一个虚拟交换机上。

5.4 性能翻车：CPU超配与内存复用不是越高越好

现象：虚拟机开四个应用就卡到鼠标都飘，但查看CNA主机CPU使用率只有40%。再一看集群配置，CPU超配比是1:8，内存复用比例调到3:1。

原因：CPU超配比过高导致很多虚拟机共享物理核心，FusionCompute的调度器在时间片分配上消耗大量开销；内存复用开启后，虚拟机内存页面被压缩存放，访问时要经过解压流程，IO和CPU的额外负担都很重。实验环境硬件配置本来就低，超配太高直接拖垮整体性能。

解决：把集群的CPU超配比调到1:2以内，内存复用直接关闭。实验环境里没有大量空闲虚拟机，关闭内存复用换来的是更稳定的性能表现和更容易理解的横断面。

6. 实验环境的验收技巧：用日志把请求链路从头串到尾

6.1 看日志的三个入口

FusionCompute的日志分散在三个位置，按排查优先级排序：

# 1. VRM管理日志 # 路径：VRM节点 /var/log/fusioncompute/ 下按组件分子目录 tail -f /var/log/fusioncompute/osps/*.log # 2. CNA计算日志 # 路径：CNA节点 /var/log/fusioncompute/ 下的计算相关日志 grep -i error /var/log/fusioncompute/galax/*.log # 3. 操作日志（网络和存储） # 路径：/var/log/fusioncompute/net/ 和 /var/log/fusioncompute/store/ ls -lt /var/log/fusioncompute/store/

6.2 命令行自检清单

# 检查CNA主机是否被VRM识别 # 在VRM节点执行 curl -k https://192.168.100.11:8443 -o /dev/null -w "%{http_code}" # 检查虚拟化底层是否正常 # 在CNA节点执行 qemu-kvm -version # 检查NFS挂载是否还在 # 在CNA节点执行 df -h | grep nfs

6.3 日志串连的一个有效打法

排查虚拟机创建失败时，最有效的不是看告警，而是拿虚拟机UUID或任务ID当作线索，从VRM日志一路grep到CNA日志：

# 在VRM和CNA上分别执行 grep "虚拟机UUID" /var/log/fusioncompute/*.log

日志里同一个请求会有统一的requestId，把从VRM到CNA的日志按requestId串起来，基本能把问题定位到具体组件。我过去遇到过一次虚拟机创建卡在“调度”阶段，界面上无任何提示，就是靠这种串日志的方式确认是CNA主机上的CPU资源碎片问题，清理了同主机上多余的虚拟机后就好了。

这个习惯我保留了很长时间：每次实验结束前，把当天的日志目录打个包存起来，日后再遇到类似问题直接翻旧日志对照，比重新复现省一半时间。希望这篇笔记也能帮你省下那些“明明照着教程做却还是翻车”的时间。

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