VMware Workstation部署FusionCompute VRM完整指南：嵌套虚拟化实践

做融合虚拟化项目的人，基本都遇到过类似困境：客户验收要演示FusionCompute，实验环境要用FusionCompute，但手头没有华为的服务器，又不想为了个测试把现网生产设备拿来做试验。我当时的做法比较直接，在笔记本的VMware Workstation里开嵌套虚拟化，硬是把FusionCompute 6.5.1的VRM装了起来。这个方案不只解决了演示环境的问题，还让我把整个安装、配置、排错流程跑了个遍。这篇文章就把从创建虚拟机到VRM部署完成的完整过程拆给你看，聚焦6.5.1这个版本，记录每一步的配置依据，包括那些报错信息背后最真实的原因。如果你正准备在实验环境里部署华为的虚拟化管理节点，又没有物理服务器可用的条件，这篇东西应该能帮你少走很多弯路。

1. 装VRM之前，先弄明白FusionCompute的角色分工

1.1 CNA与VRM：一个集群的两条腿

很多人刚开始接触FusionCompute，分不清CNA和VRM到底各自干嘛。实际上对部署来说，这是最需要先搞清楚的问题。

FusionCompute的架构可以理解为“管理面”和“计算面”两部分。计算面由CNA承担，CNA全称是Computing Node Agent，它运行在每个计算节点上，负责管理所在服务器的CPU、内存、存储和网络资源，同时承载用户业务的虚拟机。管理面的核心则是VRM，全称Virtual Resource Management，它负责整个集群的资源调度、HA策略、虚拟机生命周期管理、模板管理、权限控制这些偏大脑的工作。一台服务器上只装CNA，它只是孤立的计算资源；只有VRM正常工作了，这些CNA才能被组织成集群对外提供云主机服务。

从产品演进看，6.5.1版本的VRM既支持以虚拟机方式部署，也支持独立物理机部署。前者适合小型站点，后者适合大规模生产环境。在VMware Workstation里做实验，我们天然选虚拟机部署方式，也就是把VRM安装在一台虚拟机里，后续再通过Web界面纳管CNA计算节点。

1.2 为什么考虑在VMware Workstation里装VRM

你可能会问：FusionCompute不是建议装在自己的服务器上吗？在Workstation里跑嵌套虚拟化，性能会不会有问题，能不能稳定运行？

这些问题我都在实际使用中验证过。先说结论：作为测试和功能验证环境，完全够用。

原因有几方面。第一，VRM本身不是一个资源消耗大户，它主要提供管理服务和API接口，正常运行时CPU和内存占用都不算高，官方推荐的虚拟配置是2到4个vCPU、8GB内存，这在笔记本上完全跑得动。第二，VRM对CPU的硬件虚拟化能力依赖并不像计算节点那么敏感，因为这台虚拟机上一般不会承载业务虚拟机，只是做管理控制，所以CPU虚拟化的性能开销对最终体验影响很小。第三，Workstation在Windows主机上运行比较稳定，只要会创建虚拟机、会配网卡，整个环境就能搭起来，比专门找一台服务器来做实验门槛低得多。

不过要提醒一点：6.5.1发布已经有年头了，对虚拟硬件的兼容性设计比较保守，反而是件好事——它对虚拟机的CPU型号、网卡型号都没有特殊要求，默认配置就能装。这是版本老的一个隐藏优势。

1.3 这套实验环境能做什么、不能做什么

把话说清楚。在Workstation里装好VRM后，你至少能做到以下几件事：

• 完整走一遍VRM虚拟机的安装、配置、启动流程
• 登录FusionCompute的管理Portal，查看版本、License状态、集群管理界面
• 如果再加几台配置了嵌套虚拟化的CNA虚拟机，可以组建一个实验集群，体验创建虚拟化主机、创建集群、划分存储、发放云主机的全过程

做不到的事情也需要提前知道：

• 无法测试VRM HA功能，因为HA依赖多VRM节点，实验环境通常只部署一台
• 无法验证生产级别的性能指标，因为所有能力都经过VMware Workstation这一层翻译，损耗客观存在
• 某些依赖专用硬件的能力，比如PCI直通、SR-IOV等，在Workstation里会被屏蔽

实验环境的定位就是验证功能和流程，别指望它替代生产集群的性能评估。搞清楚了边界，后面操作就不会产生“为什么这里和文档描述不一样”的困惑了。

2. 环境准备清单：镜像、宿主机和虚拟机参数

2.1 镜像准备：FusionCompute 6.5.1安装ISO

装VRM之前，先把手里的安装镜像好好核一遍。官方发布的FusionCompute 6.5.1安装介质中，比较常见的是一个ISO文件，里面包含了VRM/CNA的安装引导程序和各种组件安装包，文件名类似FusionCompute_Install_6.5.1_xxx.iso。

ISO镜像有可能是通过华为企业业务官网或者技术支持平台获取的，一般发布时会附带一个MD5/SHA256校验文件。拿到镜像后，建议第一步就是做校验，避免下载过程中文件损坏导致安装中途莫名失败。Windows下可以用PowerShell的命令Get-FileHash命令，计算完和官方给的哈希值比对一下，确认一致再继续。我见过有人因为镜像不完整，安装到一半报错“rpm包校验失败”，折腾半天最后查出来是镜像下载出了问题。

还需要确认ISO里具体包含哪些子安装文件。可以用压缩软件打开ISO，如果无法直接看到，可以临时挂载到磁盘上查看。重点确认是否存在vrm相关的安装目录，因为部分单独的VRM软件包也可能以独立ISO形式发布。如果是单独的VRM包，安装引导方式和合盘版本会略有不同，但也只是选择入口的区别，核心流程不变。

2.2 宿主机要求与VMware版本确认

宿主机这里讲两个维度。

硬件层面，我建议至少有16GB物理内存，因为后面跑起VRM虚拟机至少要占用4到6GB，加上Windows系统本身、VMware Workstation进程和自己日常开着的浏览器应用，低于16GB会非常吃紧。推荐32GB，这样后面如果想额外创建CNA实验节点，内存也不至于捉襟见肘。CPU方面基本不挑，Intel或者AMD近几年的产品都支持硬件辅助虚拟化，关键是进BIOS确认开启了VT-x或AMD-V。

软件层面，VMware Workstation建议使用15.x及以上版本，我自己用的是Workstation 17 Pro，整个安装过程没有遇到兼容性问题。旧版本比如12或14，可能会在虚拟机启动时对固件类型和CPU特性支持不够，增加不必要的麻烦。嵌套虚拟化在Workstation中已经是非常成熟的功能，基本上官方版本都可以正常开启，只要系统设置正确。

2.3 创建VRM虚拟机时的关键参数

创建虚拟机之前，先把参数表拉出来。这是我在多台机器上反复验证过的经验值：

内存这里多说一句。VRM安装完成后，系统内会跑着数据库、消息队列、Web服务、运维Agent等一整套进程，实测空闲状态下物理内存占用就在4GB左右，所以给8GB是比较舒服的值，不至于刚开始操作就频繁触发swap导致页面卡顿。

磁盘类型这里，SATA控制器对安装程序的识别兼容性最好。近几年的Workstation版本默认推荐NVMe，但旧版系统的安装引导可能没有NVMe驱动，为了避免引导阶段就找不到硬盘，稳妥起见直接在“自定义硬件”里把磁盘控制器指定为SATA，别图省事用默认值。

网络模式选择桥接还是NAT，取决于你后续从哪台机器访问VRM的Web界面。如果宿主机的IP网段和管理网络是同一个，用桥接最合理，VRM直接获得和宿主机同网段的IP，从任何机器都能访问。如果只是本机自测，用NAT模式也够用，但后面纳管CNA节点时，因为CNA虚拟机通常也在同一个Workstation里，NAT网段下所有虚拟机在同一个虚拟网络内，也能互通，只是外部机器访问需要额外做端口转发，麻烦一些。我建议直接选桥接，一步到位。

3. 嵌套虚拟化：最容易挡路的配置点

3.1 VMware Workstation中的处理器设置

嵌套虚拟化是整个实验环境能否跑起来的前置条件。如果这里没有配置好，后边安装FusionCompute时会遇到各种莫名其妙的警告或报错，甚至系统安装完成但VRM服务起不来的情况。

操作路径是这样的：编辑虚拟机设置，在“处理器”页面，展开“虚拟化引擎”，然后勾选“虚拟化Intel VT-x/EPT或AMD-V/RVI”。这个选项在Workstation 15及以后版本的默认状态下是关闭的，目的为了避免在普通虚拟机上出现硬件虚拟化指令透传。勾选后，虚拟机内部的CPU指令集才会包含vmx或svm特性，也就是才有资格安装对虚拟化有要求的软件。

有个容易忽略的细节：勾选嵌套虚拟化后，虚拟机内部的CPU型号才会真正透传宿主机的虚拟化特性。只是勾选选项还不够，客户机系统里的CPU数量也需要合理设置。部分Linux安装程序会依据CPU数量和特性加载不同模块，单核环境下某些服务会被抑制启动，所以前面参数表里写了4核，这也是原因之一。

3.2 宿主机BIOS中的VT-x设置

Workstation里的选项只是一个开关，底层依赖是宿主机CPU必须开启硬件虚拟化。

开机进入BIOS的方法因主板型号不同有差异，常见的是开机时按F2、Del、F10等按键。进入后找“Intel Virtualization Technology”或者“SVM Mode”这类选项，它们通常位于高级设置里，将状态设为Enabled。注意修改后需要保存并重启，重启完成后建议先确认一下Windows系统任务管理器中“性能”标签页里“虚拟化”这一栏显示“已启用”。

这块经常有人栽坑：主板BIOS里默认关闭了虚拟化，而Windows本身又允许在不开启VT-x的情况下运行一些基础虚拟机功能，导致大家误以为CPU虚拟化是可用的，结果一开Workstation里的嵌套虚拟化选项就跑不起来。如果任务管理器中虚拟化状态显示“已禁用”，那问题基本出在BIOS层面，和Workstation配置无关。

3.3 验证虚拟机内虚拟化是否可用

嵌套虚拟化配置好后，强烈建议在安装FusionCompute之前，先启动虚拟机，确认系统内部能看到虚拟化特性。

如果VMware Workstation已经安装好客户机系统（可以临时装一个CentOS或Ubuntu验证），执行以下命令：

grep -E -c '(vmx|svm)' /proc/cpuinfo

统计出的数字大于0，说明虚拟化特性已经传递到虚拟机内部了。也可以执行：

lscpu | grep -i virtualization

如果输出包含“VT-x”或“AMD-V”，同样表示环境已就绪。

确认这个步骤小事一桩，但能避免后边安装时的无效反复。我一开始没有做这个验证，直接开始装FusionCompute，安装程序弹了个提示“当前环境无法满足虚拟化要求”，我一度以为是安装介质的问题，实际上就是Workstation里那个“虚拟化引擎”选项没勾上。所以这个小验证还是值得做的。

4. ISO引导与安装流程逐屏记录

4.1 挂载ISO并调整启动顺序

虚拟机的硬件配置确认无误后，可以开始安装流程。

在Workstation中，双击虚拟机名称打开设置，找到CD/DVD选项，选择“使用ISO映像文件”，浏览定位到FusionCompute 6.5.1的安装ISO。接下来进入“虚拟机设置 -> 硬件 -> 高级”，确保“启动时连接”是勾选状态。

启动顺序这里需要处理一下。默认情况下，Workstation创建的虚拟机启动顺序是“可移动设备 -> 硬盘 -> 网络”，因为ISO已经以光盘形式挂载，启动时会自动优先从光盘引导，一般不需要额外修改BIOS顺序。但如果你的虚拟机之前已经装过系统，或者硬盘上有其他引导记录，就需要进入BIOS把光驱提到第一位。开机时快速按F2进入固件设置，在“Boot”菜单中调整Boot Priority，将CD-ROM Drive移到首位。可以在屏幕上快速按Enter，有些人没反应，多试试，这是Workstation的一个经典交互点。

4.2 安装引导菜单的选择与含义

ISO引导正常后，会进入FusionCompute的安装引导界面。6.5.1版本的引导界面是简易文本菜单，不用惊慌选错，因为往前推进前它都会给你返回确认的机会。

引导界面主要有两个路径可选：

• 安装VRM
• 安装CNA

在实验环境里，自然选择“Install VRM”。这里有个小细节，6.5.1的菜单可能不是上下方向键直接选择，而是输入数字或者首字母，具体以屏幕提示为准。

另外，引导菜单中还可能存在“Advanced options”这样的子项，用于指定自定义安装源、配置网络参数或者其他高级安装选项。默认情况下我们不需要进入，直接选择安装VRM即可。

4.3 VRM安装向导的核心输入项

确认选择安装VRM后，系统会进入交互式安装向导。这个向导虽然界面朴素，但每一段输入都会影响后续系统的IP配置、密码策略和网络接入，需要仔细对待。

主要需要提供的输入项包括：

• 主机名：默认为localhost，建议改为有业务含义的主机名，比如vrm01
• 管理IP地址：必须是当前网络中没有冲突的地址，建议和宿主机在同一网段
• 子网掩码：按实际网络填写，例如255.255.255.0
• 默认网关：指向管理网络的网关
• DNS服务器地址：按实际环境填写，没有可以直接填管理网关地址，也可以留空，但有些版本留空时会警告
• root密码：这个密码就是VRM节点操作系统的管理密码，也是后续通过SSH登录排查问题的主要凭据，建议设置复杂一些并做好记录
• 确认root密码：避免输入错误

有些版本会在配置完IP后提示“是否启用IPv6”或者“是否启用DHCP”，实验环境下都选No或关闭即可。IPv6这里千万注意不要误选Enabled，否则后续访问Web界面时容易碰到地址优先级问题，打开页面会非常慢。

安装向导还会进入磁盘分区确认步骤。这里直接选择自动分区并确认，除非你对Linux分区有自己的安排，否则自动分区对VRM来说是最稳妥的选择。它会自动分出系统分区和数据分区，后续升级和运维都方便。

4.4 安装过程中系统自动完成的工作

向导输入完成后，安装程序进入全自动阶段。整个自动化过程大致分为四步。

第一步是初始化安装环境，包括复制安装包、检查依赖关系、准备Yum源等。这个过程可能界面长时间不动，不要急着重启虚拟机，耐心等进度条变化即可。

第二步是安装基础操作系统。VRM的底层系统还是基于Linux定制的，这个阶段会安装内核、系统库、基础工具链，时间相对较长，主要受磁盘性能影响。建议把SSD留给这台虚拟机，用机械硬盘的话安装时间可能翻倍。

第三步是部署VRM相关的组件和服务。包括关系型数据库、消息队列、管理系统Web服务、资产管理服务、告警服务等。这个过程是自动的，正常情况不需要干预。

第四步是进行系统配置和状态初始化，比如设置开机自启动服务、初始化数据库表、配置本地防火墙规则等。

4.5 安装完成后的第一轮验证

整个安装过程顺利的话，系统会提示安装完成，并询问是否重启虚拟机。这时候确认重启即可。

重启完成后，进入VRM系统命令行，先用刚才设置的root账号登录。登录成功后，第一件事不是急着访问Web界面，而是在命令行里做一些基础健康检查：

ip addr

确认管理IP是否已经正确配置并处于UP状态。

ps -ef | grep -E "vrm|tomcat|nginx" | grep -v grep

检查关键进程是否都在运行。VRM的Web服务正常情况下会监听在8443端口，所以继续执行：

netstat -tlnp | grep 8443

如果看到8443端口处于LISTEN状态，说明管理服务已正常起来。如果这里没有进程也没有端口，大概率是内存不足导致的启动失败，需要回过去把虚拟机内存调到8GB再重启服务试试。

5. 常见搜索关键词背后的真问题

5.1 “模块hv启动失败”：嵌套虚拟化没开

网上搜索VMware和FusionCompute相关内容时，经常会看到“在此主机上不支持嵌套虚拟化。模块‘hv’启动失败”这类报错。这个问题几乎都是在Workstation中启动虚拟机时出现的，出错原因也非常典型：虚拟机设置里的“虚拟化引擎”选项没有勾选，或者宿主机的VT-x未开启。

报错名字里的“hv”指的是Hyper-V相关模块，在Workstation中启动启用了嵌套虚拟化的虚拟机时，宿主机会尝试创建hypervisor层的虚拟化环境，如果硬件虚拟化能力不足或没有透传，Workstation就拒绝启动这个虚拟机。

碰到这个提示，按顺序排查三件事：

1. 确认宿主机BIOS里VT-x/AMD-V已开启
2. 确认Windows任务管理器里“虚拟化”是否显示“已启用”
3. 确认当前虚拟机设置里“虚拟化Intel VT-x/EPT或AMD-V/RVI”已勾选

如果这三项都正确仍然报错，还可能是Windows自身的Hyper-V组件被启用了，导致Workstation无法直接访问硬件虚拟化层。解决路径就是关闭Windows功能里的Hyper-V、Windows虚拟机监控程序平台和内存完整性功能，然后重启宿主机。这个冲突在Windows 10和11上都存在，属于Workstation嵌套虚拟化的经典坑。

5.2 安装要挂多张网卡，别把管理口和业务口搞混

FusionCompute的部署设计里，VRM和CNA节点通常都有多个网络平面：管理网络、业务网络、存储网络等。在6.5.1的实验部署中，你没有必要真的创建三张网卡，但要理解不同网络平面在管理界面里的意义，否则后边纳管主机时会觉得概念混乱。

简单说，VRM需要管理网络与CNA通信，业务网络用于承载云主机流量。实验环境只要保证管理IP能够被CNA访问到，其他网络都可以暂时不配置或者复用同一张网卡。在实际生产项目中，千兆管理网和万兆业务网是严格分开的，实验环境下则可以合二为一，把问题留在解决“功能”层面，不要去纠结“架构”层面。

但即便合并，也建议在Workstation中给这台VRM虚拟机只配置一张网卡，不要默认去添加多张网卡又都配置在同一个交换机端口，那样容易造成路由混乱，反而是自己给自己挖坑。

5.3 安装界面黑屏或卡住时先别重启

FusionCompute安装过程中最容易让人误判的现象是“界面卡住不动”。比如在引导界面选择完安装VRM后，屏幕长时间黑着，或者进度条停在一个位置一分钟没反应，很多人第一反应是重启虚拟机重来。

我的经验是：先弄清楚当前是IO等待还是真的死锁。可以按一下Enter键，看看有没有终端提示返回；也可以注意虚拟机的CPU占用情况，如果CPU利用率持续波动，说明安装程序正在进行大量计算或写入操作，界面只是没刷新出来而已。如果彻底没有活动，并且10分钟以上没有任何变化，才可以考虑重启重来。

安装时卡住的黑屏场景还有一个常见诱因是虚拟机内存不足，系统在初始化内核时崩溃，然后又尝试重启，表现为反复的黑屏和自动重启循环。这种时候别继续等了，直接把虚拟机关机，调高内存配置，再重新安装。

6. 安装完成后的VRM初始体验

6.1 通过Web界面上传License

VRM安装完成、服务正常运行后，就可以通过浏览器访问管理Portal了。访问地址一般为：

https://<VRM管理IP>:8443

第一次访问时浏览器大概率会提示证书不受信任，这是正常的，因为VRM默认使用的是自签名证书。继续访问即可，不必紧张。

登录界面会要求输入用户名和密码。初始用户名通常是admin，密码安装过程中没有直接设置过的话需要参考发布说明中的默认初始密码，首次登录后系统会强制要求修改密码。

登录后映入眼帘的是FusionCompute的管理首页。首页上区域、集群、主机、虚拟机等资源维度都还没有数据，因为目前环境中还没有纳管任何CNA节点。这时候首先需要处理的是License状态。在管理界面的“系统”菜单下会有License管理入口，试验环境没有正式License时，可以申请华为官方的临时试用License，也可以查看当前License的过期时间。没有有效License会限制部分功能的使用，但Portal本身的浏览和一些基础操作还是可以进行的。

6.2 创建集群时最常见的卡点

有了VRM和License，就可以尝试创建集群了。在FusionCompute的界面逻辑里，先创建站点区域（Region），再在区域下创建集群（Cluster）。创建集群时要选定CPU类型等参数，此时需要注意：如果后续计划纳管CNA节点，集群内的CNA和VRM之间必须网络互通，而且时钟需要同步。时钟不同步是实验环境里很常见的坑，表现为CNA纳管后状态始终是“正常但不可用”或者告警一堆。

当时我做实验时，没有NTP服务器可以同步，就在VRM和CNA虚拟机上都手动把系统时间调整为一致的状态，然后通过命令行使用ntpdate手动同步一次。在实验环境中，手动同步一次能满足后续长时间的功能验证，但如果是持续运行的状态，建议找一个可访问的NTP源。

创建集群顺利后，下一步就是添加CNA主机。这个过程需要CNA服务器的管理IP和密码。如果你的环境里还没有装CNA虚拟机，先回头准备一台或两台嵌套虚拟化配置好的虚拟机，按前面装VRM的方式把CNA装好，然后回到VRM界面进行“添加主机”操作。主机添加成功，才标志着FusionCompute管理面的全链路搭建完毕。

6.3 后续可以在实验环境里继续做的事

VRM装完只是起点，这个实验环境能延伸出不少有价值的操作练习。

首先是存储管理。FusionCompute支持虚拟化存储、非虚拟化存储等模式，实验环境下如果准备了额外的磁盘或初始化了共享存储，可以练习创建存储池、划分数据存储，并观察虚拟机在数据存储上的部署策略。

其次是虚拟机发放。通过VRM Portal创建虚拟机模板、配置CPU/内存规格、发放一台云主机实例。你会直观感受到FusionCompute作为虚拟化平台管理海量虚机的核心逻辑，虽然实验环境只有一两台CNA支撑，但几十个并发虚拟机发放的体验还是可以完整模拟的。

再进一步，有条件的话可以加上VRM高可用测试。在一台VRM已正常运行的前提下，部署第二个VRM节点组成VRM集群，再通过Workstation的“挂起”功能模拟单节点故障，观察VRM漂移的过程。虽然需要更高的资源投入，但这是理解FusionCompute生产级高可用的最好路径。

我自己走完这一轮后最大的感受是：实验环境的核心价值不在环境本身有多大、多像生产，而在于把每一步操作背后的约束条件都体验一遍。比如装VRM时对内存、嵌套虚拟化的要求，纳管CNA时对网络、时间的依赖，这些在官方文档上都是几行字，可一旦自己从头搭一轮，每个细节都变成了记忆深刻的教训。最后再分享一个实用的经验：虚拟机的虚拟化引擎选项和内存大小是决定这套环境成败的两位主力，先把这两项配置调对，后面的安装成功率能提高八成以上。