企业官网建设流程全解析

简介：《FusionCompute实验手册1》是华为HCIP-Cloud Computing V4.0认证培训的配套教程，面向备考该认证的学员及希望系统掌握FusionCompute服务器虚拟化平台运营与运维能力的读者。手册围绕从环境搭建到日常运维的完整链路，编排了7个实验并划分成四大部分：依托KVM嵌套环境安装CNA与VRM，从底层理解FusionCompute架构；通过计算、存储、网络资源管理实验，熟悉计算虚拟化、存储虚拟化和网络虚拟化三大核心功能；在虚拟机发放及管理部分，覆盖虚拟机创建、Tools安装、模板封装、快照管理、规格调整、HA、热迁移、安全组与规则组配置等业务运维场景；最后以用户管理、管理数据备份与时间管理收尾，锻炼日常运维能力。资源为单个docx文档，约10.53MB，方便离线研读与对照操作，目前已有227人学习使用。借助手册中的实验步骤与拓扑说明，读者既能夯实FusionCompute理论，也能积累华为虚拟化平台和桌面云的实际搭建与排障经验，为通过HCIP-Cloud Computing认证及企业级项目实施奠定基础。

1. FusionCompute实验手册：从“看得懂”到“玩得转”的那道坎

很多刚接触某虚拟化平台的管理员，第一反应是翻官方文档。但文档讲的是“功能是什么”，实验手册解决的是“这一步到底怎么点、点错了怎么办”。FusionCompute作为一套典型的云操作系统，南向管理物理资源池，北向提供计算、存储、网络服务，它的学习曲线不在概念，而在实操：CNA节点装完之后为什么主机显示“异常”？存储挂载成功后存储资源为什么还是灰色？模板部署虚拟机失败，日志里到底哪一行才是关键？这篇笔记不打算复刻官方实验指导书的目录结构，而是把我在多个模拟项目X里反复做过、也反复踩过的实验路径，拆成可复现的操作顺序和排错思路。它适合两类人：一类是要拿实验环境交付结果的实施工程师，另一类是刚开始接触虚拟化、想在实验环境里把逻辑链路理清楚的学习者。读完你会有能力独立从零初始化一套环境，并且知道每一步失败时该看哪个日志、查哪张表。

2. FusionCompute实验环境准备：内存、网络和那个最容易忽略的CNA存储

2.1 实验环境的角色划分与硬件最低要求

FusionCompute的实验环境和生产环境最大的区别在于：生产环境讲究冗余和性能，实验环境只需要把逻辑链路跑通。一套最小可用环境通常包含一个管理节点、两个计算节点（也就是CNA节点）和一个共享存储（实验里常用虚拟化的存储）。管理节点负责提供Web界面、资源调度和运维监控；CNA节点是真正承载虚拟机运行的物理主机；共享存储则承载虚拟机的磁盘文件，有些实验里还需要独立的一块存储作为系统卷。

硬件规划上，我一般建议管理节点分配4核CPU和8GB内存起步，CNA节点至少6核CPU和16GB内存，每个节点至少两块物理网卡，一块负责业务平面，一块负责存储平面。特别要注意的是，实验环境里如果只有一个物理存储，那么管理节点和CNA节点之间的存储链路就不能再复用业务网络的带宽，否则创建虚拟机时很容易出现“存储卷挂载超时”的报错。磁盘方面，CNA节点的本地磁盘建议至少预留100GB用于安装系统，还有一个容易被忽略的点：本地磁盘的分区表格式必须是主引导记录或GUID分区表的标准格式，不能存在LVM遗留卷组，否则安装过程会直接中断。

2.2 管理节点安装选择的两个关键参数

安装管理节点时，安装介质会要求你输入两个关键的部署参数：管理节点IP地址和主机名称。这里的IP地址必须是规划好的内网地址，而且要和CNA节点、存储设备在同一个二层网络内。主机名称则需要注意字符限制，只能包含字母、数字和中横线，不能用下划线，否则后续添加主机时解析会失败。

# 以root身份登录后，先确认安装介质是否被正确识别 lsblk # 如果看到类似 sda 的磁盘设备，且没有分区表，直接开始安装 # 安装完成后，验证管理节点网络配置是否生效 ip addr show # 预期输出里应该包含你规划的IP地址，且状态为UP

这里的逻辑是：lsblk是为了确认安装程序能看到目标磁盘，避免装到了USB设备上还没察觉。ip addr show则是安装完以后的第一道自检，如果IP地址没生效，后面所有操作都无从谈起。我习惯在管理节点安装完成后再执行一次ping 网关地址，确认三层连通性，只有网络通了，Web界面才能登录。

2.3 安装CNA节点前必须先改掉的两项BIOS设置

CNA节点的安装过程比管理节点要敏感得多。根据我自己的实验血泪经验，安装CNA前必须确认BIOS里的两项设置：CPU虚拟化功能已开启，以及内存映射I/O（Memory Mapped I/O）没有被禁用。前者是承载虚拟机的必要条件，后者影响PCIe设备与虚拟机内存之间的直接数据通路。

# 安装过程中，选择从光驱或U盘引导 # 进入安装界面后，选择“Install CNA”而非默认的“Install Management Node” # 关键交互节点：选择磁盘时，务必手动选中本地系统盘，不要全选

CNA安装介质里实际上包含两种角色的安装选项，很多初学者在这里就选错了。选择“Install CNA”以后，安装脚本会要求输入管理节点的IP地址，这个地址用来建立计算节点与管理节点之间的心跳通信。选错磁盘这个问题也很隐蔽：如果服务器上还挂了其他数据盘，安装程序默认可能把所有盘都纳入逻辑卷，导致后续CNA节点在加入集群时因为磁盘异常而失败。正确做法是只选系统盘，其余数据盘等系统装好以后通过存储管理界面单独添加。

2.4 VRM与CNA之间的发现机制：第一次联调要看什么日志

管理节点安装完成后，计算节点第一次加入集群时，会有一个“被发现”的过程。管理节点的Web界面里，“主机管理”页面会周期性扫面二层网络内的CNA节点。这个扫描依赖CNA节点上运行的代理进程定时向管理节点上报心跳。如果CNA节点已经安装完成，但Web界面里始终看不到它，最常见的排查路径是登录到CNA节点的本地控制台，查看心跳进程的状态。

# 在CNA节点上执行 ps -ef | grep -i hostagent # 正常情况下会看到一个常驻进程，进程名包含 hostagent # 如果进程不存在，手动尝试拉起服务并观察报错 service hostagent start # 然后查看日志 tail -f /var/log/hostagent.log

日志里如果出现connect to VRM failed，基本可以断定是网络不通或者管理节点IP配置错误。这时候检查CNA节点的管理网口是否链接正常，以及route -n里有没有到管理节点网段的路由。另一个容易忽略的点是CNA节点的系统时间必须和管理节点保持同步，时间偏差超过5分钟，心跳会被安全策略直接丢弃，现象就是主机状态在“异常”和“离线”之间反复横跳。处理方法是配置NTP同步，实验环境里直接把CNA节点的NTP服务器指向管理节点IP即可。

3. 集群创建与存储对接：FusionCompute资源池化的第一个分水岭

3.1 创建集群时的“聚合”概念与其真实含义

在FusionCompute的Web界面左侧导航里，“集群”是资源池化的第一层容器。一个集群把多台CNA节点聚合在一起，统一分配计算资源，支撑VMware风格的高可用和动态资源调度功能。创建集群时需要填写集群名称、高可用级别和资源调度策略。高可用级别一般选“虚拟机HA”而不是“主机HA”，因为实验环境里通常只有两台计算节点，主机HA要求故障主机上的虚拟机在其他主机上重新启动，这依赖共享存储；而虚拟机HA只是把虚拟机进程在主机的HA代理上注册，触发条件更宽泛，更容易在实验环境里观察效果。

资源调度策略里的“负载均衡”和“电源管理”这两个选项，实验环境里都建议保持默认。负载均衡策略会周期性检测集群内主机的CPU和内存占用率，然后通过虚拟机迁移调整负载。如果实验环境里只有两台相同配置的CNA节点，负载均衡带来的实际收益不大，反而可能因为迁移触发额外的网络开销，干扰你对资源使用的判断。

3.2 添加CNA节点到集群的完整操作与状态验证

集群创建完之后，接下来是把CNA节点加入集群。在Web界面的“集群”详情页里选择“添加主机”，系统会列出已经发现但尚未加入集群的计算节点。选择目标主机后，界面会让你确认主机的管理IP和资源池名称。

# 添加成功后，登录CNA节点验证主机状态 fusionrm -i # 预期输出中，该CNA节点的状态字段为 normal # 如果状态是 degraded，需要查看底层虚拟化服务是否正常 service vrmd status

fusionrm -i是一个很实用的命令行工具，可以在CNA节点本地直接查看该节点在集群里的健康状态。状态为degraded通常意味着该CNA节点上的虚拟化内核没有正常加载，最常见的原因是CPU虚拟化功能没有被正确透传给上层服务。此时去BIOS里确认虚拟化开关，如果已经开启，就检查宿主机的内核模块是否加载，执行lsmod | grep kvm，没有输出就说明模块没加载，需要重启节点后再看。

3.3 存储设备对接：创建存储池与数据存储的边界条件

这一步是整个实验手册里最容易出状况的环节。FusionCompute里的存储分为“存储设备”和“数据存储”两层。存储设备是物理存储的抽象，比如某台存储服务器的逻辑单元；数据存储则建立在存储设备之上，是真正给虚拟机放置磁盘文件的地方。实验环境里，强推用iSCSI存储模拟共享存储，成本低且逻辑链路完整。

# 在存储节点上创建iSCSI target（以linux-iscsi为例） targetcli cd /backstores/block create disk1 /dev/sdb1 cd /iscsi create iqn.2025-01.example:storage1 cd iqn.2025-01.example:storage1/tpg1/luns create /backstores/block/disk1

这里每一步都有意义：/backstores/block/disk1把物理分区包装成块设备，iqn.2025-01.example:storage1是iSCSI目标的唯一标识，后续FusionCompute添加存储设备时需要完全匹配这个标识。用的IQN名称建议带上日期和域名片段，这样在多套实验环境并存时不会混淆。创建好target之后，还需要设置访问控制，只允许CNA节点的IP地址发起连接，否则存储设备被无关主机发现会带来安全隐患。

3.4 存储资源扫描：为什么“刷新”以后存储还是灰色

在FusionCompute的“存储”页面，添加存储设备后需要执行“扫描”操作，让管理节点发现存储设备上的逻辑单元。很多人在这一步明明存储设备显示已连接，但底下“数据存储”的创建按钮却是灰色的。这个问题的根源通常在于CNA节点和存储设备之间的连通性还没有完全打通。

# 在CNA节点上确认能看到iSCSI磁盘 iscsiadm -m session # 预期输出里有一个session条目，对应存储target的IP和IQN # 如果session不存在，执行 iscsiadm -m discovery -t st -p <存储IP>

FusionCompute的扫描动作实际上会下发到每一台CNA节点上，由CNA节点去探测存储设备。如果CNA节点没有主动发起iSCSI连接，管理节点就算配置了存储设备信息也没有用。执行iscsiadm -m session看到有效会话后，回到Web界面再次点击“扫描”，数据存储创建按钮就会变成可选状态。这一步的经验是：改完CNA节点的网络配置或者存储配置以后，一定要在每台CNA节点上重新执行一次iSCSI发现命令，不要只依赖Web界面的刷新按钮。

4. 虚拟机生命周期管理：模板、发放与迁移的落地点

4.1 模板制作与规范：最小化模板有两个隐形要求

模板是FusionCompute里提升虚拟机部署效率的核心工具。制作模板的常规路径是：先安装一台干净的虚拟机，然后把它转换成模板。这里有两个比较容易踩的坑，一个和磁盘接口有关，一个和网络配置有关。

磁盘接口在虚拟机创建时一旦确定，后续转换模板不会改变。如果模板的磁盘接口是virtio类型，那么发放出来的虚拟机在启动阶段如果没有加载对应驱动，系统就会直接蓝屏或内核崩溃。规范做法是在模板虚拟机里提前装入对应虚拟化驱动包。另一个要求是主机名必须设置为localhost.localdomain这类通用名，并且网卡配置不能绑定固定IP，而是使用DHCP或保持未配置状态。这样模板发放给多台虚拟机时，就不会因为重复IP地址导致网络冲突。

4.2 虚拟机发放时的资源分配逻辑与“超配”边界

从模板发放虚拟机时，Web界面会让你填写计算资源配额：CPU个数、内存大小、磁盘容量。这里涉及“超配”的隐含逻辑。FusionCompute允许CPU超配，即所有虚拟机CPU核数之和可以大于物理CPU核数，但不允许内存超配（在默认配置下）。如果集群内所有虚拟机内存总量超过物理内存，部分虚拟机启动时会报“内存资源不足”，即使另一些虚拟机已关机，系统也不会把这部分内存释放给新的虚拟机，因为关机虚拟机占用的内存页并未被完全回收。

# 在CNA节点上查看内存超配现状 free -g # 观察used总量是否大于总物理内存的70%以上 # 如果发现可用内存吃紧，检查是否有虚拟机处于异常状态 virsh list --all

实验环境里，我建议CPU超配比例控制在2:1以内，内存不做超配。virsh list --all能看到底层虚拟机进程的真实状态。有些虚拟机的操作系统已经内部关机，但FusionCompute层面的“关机”操作没有同步到底层，这部分内存实际上是泄漏的，发现以后执行界面上的“强制关机”可以回收。

4.3 虚拟机迁移的两种模式：冷迁移与在线迁移的适用场景

实验手册里一定会包含迁移实验。FusionCompute提供两种迁移模式：冷迁移（需要先关机）和在线迁移（虚拟机不中断）。在线迁移的实验效果更直观，但它对运行条件有硬性要求：源主机和目标主机必须都能访问同一份虚拟机磁盘存储。也就是说，如果虚拟机磁盘存放在本地数据存储上，在线迁移会直接置灰不可用。

# 在Web界面的“虚拟机”列表中选择一台运行中的虚拟机 # 点击“迁移”，选择目标CNA节点 # 迁移过程中，可以使用以下命令在源CNA节点上观察进程变化 ps -ef | grep qemu

ps -ef | grep qemu是用来观察源节点上虚拟机进程是否退出。整个迁移过程分为三个阶段：内存复制、迭代复制、切换执行。切换执行的那一瞬间，源节点上的qemu进程会退出，目标节点上的qemu进程随即接管。如果在迁移过程中出现网络抖动，迁移任务会进入“重试”状态，此时不要手动取消，等待自动重试完成即可；如果手动取消，虚拟机有概率进入暂停状态，需要手动恢复运行。

4.4 快照功能与恢复：实验环境里最好用的“后悔药”

FusionCompute的快照功能相当于虚拟机磁盘在某一个时间点的完整副本。在做系统配置变更或软件升级前，给虚拟机打一个快照，是实验环境里最可靠的回滚手段。快照创建过程本身也会触发一次存储I/O暂停，所以不要在业务高峰期做这个操作。

# 创建快照后，快照链会生成一个新的磁盘差异文件 # 在CNA节点上查看快照文件 ls /vmfs/volumes/<数据存储名称>/<虚拟机目录> # 看到类似 vmname-000001.vmdk 的文件即为快照差异盘

需要特别说明的是，快照不是备份。快照文件基于原磁盘做差异记录，一旦原磁盘文件损坏，快照也无法独立恢复。实验环境里如果需要长期保留某个状态，正确做法是“快照+导出”。把虚拟机导出为其他格式的文件，存储到独立位置，才能保证万无一失。

5. 避坑指南：FusionCompute实验里最常翻车的5个瞬间

这一章里列出的每个问题，都是我实际遇到过、并且用上面章节里的方法成功解决过的案例。每一条都按“现象→原因→解决”的顺序写，方便你在实验现场快速对照排查。

5.1 网页登录管理界面，页面一直跳转登录页

现象：输入正确的管理员账号密码，点击登录后页面刷新一下又回到了登录页，没有任何报错提示。

原因：用户会话无法建立。绝大多数情况下，这是浏览器缓存了旧的会话Cookie，或者系统时间与服务器时间不同步导致会话令牌校验失败。

解决：先清除浏览器缓存和Cookie，更换一个无痕窗口重新登录。如果问题依旧，去管理节点上执行date命令查看系统时间，确定时间已与NTP服务器同步。另外，管理节点的服务监听在8443端口，实验环境里不要修改默认端口，否则Web服务会重建，而你实际访问的还是旧端口。

5.2 创建虚拟机时，提示“主机CPU不兼容”

现象：在集群内发放虚拟机，选择目标CNA节点时，部分节点不可选，鼠标悬停提示“CPU不兼容”。

原因：CNA节点的物理CPU型号不同，或者BIOS里开启了不同的CPU特性集。FusionCompute的虚拟机迁移要求源和目标主机CPU特性一致。

解决：在集群设置里开启“CPU兼容模式”。开启后，系统会把主机的CPU指令集收敛到一个公共子集，所有虚拟机能运行的指令都被限制在这个子集内。代价是虚拟机性能会略有下降，但实验环境里感知不到。另一种做法是全部节点统一使用同型号CPU，这在实验环境里靠采购解决，不在配置层面讨论。

5.3 iSCSI存储添加成功，但是创建数据存储时无法选择该设备

现象：存储设备列表里能看到iSCSI target，但创建数据存储时下拉列表为空，找不到具体的逻辑单元。

原因：CNA节点的iSCSI客户端没有和目标建立会话。Web界面的“添加存储设备”只是把存储信息写入管理节点的数据库，CNA节点并没有主动发现逻辑单元。

解决：登录每一台CNA节点，确认initiator名称和store网络的路由是通的。执行iscsiadm -m discovery -t st -p <存储IP>重新发现，然后执行iscsiadm -m login。全部节点都login成功以后，回到Web界面重新扫描数据存储。

5.4 模板发放的虚拟机无法获取IP地址

现象：虚拟机启动正常，系统也起来了，但网卡没有IP地址，手动配置IP后也ping不通网关。

原因：模板制作时网卡没有设置成“分布式交换机端口组”，或者发放时选择的网络不对。FusionCompute里虚拟机的网络必须连接到一个“端口组”，端口组定义了VLAN和网卡绑定方式，如果端口组对应的物理网络没有正确连接到CNA节点，虚拟机网卡就是断的。

解决：在Web界面的“网络”页面检查端口组配置，确认其所在网络已绑定到正确的物理网卡。在CNA节点上执行vlanconfig命令（如果有这个工具）查看物理网卡的VLAN标签是否匹配。最常见的根源是模板制作阶段把网卡设成了“直接连接物理网络”模式，发放后与端口组的VLAN策略冲突，重新制作模板并选择正确的网络类型即可根治。

5.5 在线迁移虚拟机，迁移长时间卡在99%

现象：迁移进度条走到99%就停住了，持续几分钟没有变化，虚拟机界面无响应。

原因：内存迭代复制阶段结束后，源主机需要把虚拟机的最终状态切换到目标主机，这个切换动作需要短暂的CPU暂停。如果虚拟机CPU负载很高，或者目标主机的存储响应变慢，切换阶段会反复失败，导致进度停在99%。

解决：观察迁移任务的详情，如果显示“等待切换”，不要操作任何按钮。直接登录目标CNA节点，执行iotop观察存储I/O占用，确认存储没有因为其他任务抢占而超时。如果等待5分钟后仍无进展，在Web界面上“取消迁移”，虚拟机通常会回退到源节点并恢复运行。此时建议先把虚拟机重启一次压低负载，再重新发起迁移。

6. 从实验手册到实战手感：性能诊断与自动化两大进阶点

这一章聊两个实验手册里很少展开、但实战里马上用得上的方向：性能瓶颈定位和命令行批量操作。这两个能力能帮你从“会点界面”进化到“能判断环境健康状况”。

先说说性能诊断。虚拟机的性能问题，大部分根源在存储I/O和CPU调度等待。登录CNA节点，执行top命令并按1键查看每个CPU核心的使用率，如果整体利用率不高但某个单独核心跑满，说明虚拟机是单线程密集型负载，加CPU核数没有用。存储方面，在CNA节点上执行iostat -x 1，观察await字段，这个值表示I/O请求的平均等待时间（毫秒），正常应该在10以下，如果超过50，说明存储链路已经不堪重负。这时去检查存储服务器上的网卡流量和磁盘健康状态，而不是盲目增加虚拟机磁盘大小。

再说自动化操作。实验环境里偶尔需要批量创建多台虚拟机做压力测试，用命令行操作比在Web界面一个个点高效得多。FusionCompute的底层管理接口支持通过命令行工具调用API执行创建、删除、迁移等操作。

# 批量创建虚拟机的示例脚本框架 #!/bin/bash for i in $(seq 1 5); do fusioncompute --create-vm \ --name "test-vm-$i" \ --cluster "Cluster1" \ --template "centos-template" \ --cpu 2 --memory 4096 --disk 40 done

脚本里的--name参数使用了循环变量，每台虚拟机名称唯一。--template指定了用于创建的模板名，后续实验里如果调整了模板，所有创建的虚拟机都会体现变更结果。这个执行方式最大的好处是可重复，你可以把整套实验环境的搭建过程写成一个脚本存放起来，环境被折腾坏了之后，运行一次脚本就能恢复基础状态。我在自己的实验环境里，已经把CNA节点的iSCSI连接、存储扫描和集群状态检查都编成了脚本，每次开工前跑一遍，环境健康度一目了然。

一个来自实际排障的教训：有一次我发现某个模拟项目X里的虚拟机都慢得异常，在CNA节点上排查了很久，最后发现是存储服务器的网卡协商成了百兆模式。换上正确网线、重新协商为千兆后，虚拟机的磁盘性能立刻恢复正常。这件事给我养成的习惯就是：碰到性能问题，先查物理链路，再看虚拟化层指标。链路不通或者降速，上层调多少参数都是空转。希望这篇手册能帮你少走几步弯路，也欢迎你把实验里遇到的其他疑难场景记在笔记里，回头对照着看，会比单纯追求点击成功更有收获。

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