h3ccloud 云桌面.从 broker 获取虚拟机列表数据失败

可以看看服务是否异常：systemctl status h3c-cloud-broker # 或 service h3c-cloud-broker status

“从 Broker 获取虚拟机列表数据失败”这个报错，核心问题是云桌面管理平台（Broker）与虚拟机内的客户端代理（Agent）之间的通信出现了故障。

根据你的描述（3台虚拟化服务器），问题可能出在网络、服务或配置上。可以按照下面的流程来排查，通常能找到原因。

核心排查路径：Broker与Agent通信链路

这个问题的根源在于Broker无法从虚拟机Agent处获取到信息。因此，排查的重点就是检查这条通信链路。

1. 检查虚拟机侧：Agent服务状态与配置

• 检查Agent服务是否运行：登录出问题的虚拟机，检查 H3CDAgent 或 VdiAgent 服务是否已启动。如果服务未运行，手动启动它。

• 核对Broker服务器地址：在虚拟机内，检查Agent配置文件中的Broker服务器地址是否正确。

  • 路径参考：C:\Program Files (x86)\H3C\VdiAgent\conf\grpc_config.cfg。

  • 操作：确认文件中的服务器IP指向了正确的Broker服务器地址。如果地址错误或已变更，需要修改或重装Agent工具。

• 检查虚拟机操作系统状态：通过虚拟化平台的管理控制台，确认虚拟机是否处于死机、蓝屏或其他异常状态。

2. 检查网络连通性：确保通信无阻

• 测试基本网络连通性：从Broker服务器上，尝试 ping 虚拟机的IP地址，确保三层网络是通的。

• 测试关键端口连通性：Broker与Agent的通信依赖于特定端口。

  • 关键端口：检查 TCP 8860 端口是否可达。

  • 测试方法：可以在Broker服务器上使用 telnet <虚拟机IP> 8860 命令来测试。如果端口不通，需要检查中间网络设备（如防火墙）的访问控制策略。

3. 检查平台侧：核心服务与联动状态

• 重启核心服务（临时措施）：如果问题影响范围很大，可以尝试重启Broker或Controller服务，这有时能临时解决服务异常问题。

  • 参考命令（需在后台执行）：service H3CDServer restart 或 service controller restart。

• 检查与CAS平台的联动：你的环境有3台虚拟化服务器，管理平台需要与CAS正常联动。

  • 可能原因：CAS的账号密码在管理平台中配置错误，或者被修改过，会导致平台“查询cas主机失败”，从而无法获取虚拟机列表。

  • 解决方法：在管理平台的“系统管理” -> “系统维护” -> “通信信息维护”中，重新配置与CAS/UIS平台的通信账号密码，然后等待几分钟再刷新页面。

H3Cloud Workspace 提示「从 broker 获取虚拟机列表数据失败」完整排障（3 台 CAS 虚拟化集群）
故障核心原理
Broker 是云桌面调度核心服务，客户端 / 管理页面加载虚拟机列表时，会调用h3c-cloud-broker服务拉取 CAS 平台虚拟机资源；报错代表Broker 服务异常、Broker 与 CAS 通信中断、数据库 / 消息队列异常、集群注册失效四类问题，按从简到繁顺序排查。
一、第一步：检查 Broker 服务状态（最高发）
登录云桌面管理节点（Workspace 管理服务器，一般单独一台或部署在 CAS 管理节点），执行 Linux 命令：
bash
运行
# 查看broker服务运行状态
systemctl status h3c-cloud-broker
场景 1：服务未启动 / 崩溃
bash
运行
# 启动服务
systemctl start h3c-cloud-broker
# 设置开机自启
systemctl enable h3c-cloud-broker
# 查看实时日志定位报错
tail -f /var/log/h3c-cloud/broker.log
场景 2：服务 running 但查询报错
直接重启 Broker 刷新缓存：
bash
运行
systemctl restart h3c-cloud-broker
二、第二步：检查 Broker 依赖中间件（Broker 依赖才会拉取不到列表）
Broker 正常运行依赖 3 个基础服务，缺一不可：
RabbitMQ 消息队列（集群通信）
bash
运行
systemctl status rabbitmq-server
异常处理：systemctl restart rabbitmq-server
2. MySQL 数据库（存储桌面、虚拟机元数据）
bash
运行
systemctl status mysqld
异常处理：重启数据库，核对库表是否损坏
3. CAS 平台对接服务（cloud-api）
Broker 从 CAS 拉取虚拟机数据，cloud-api 异常会直接列表为空
bash
运行
systemctl status h3c-cloud-api
systemctl restart h3c-cloud-api
三、第三步：网络连通性排查（3 台 CAS 集群场景重点）
1. Broker ↔ CAS 管理节点互通
在 Workspace 服务器 ping 三台 CAS 主机管理 IP，测试端口：
CAS API 端口：8080
Broker 通信端口：5672（RabbitMQ）、3306（MySQL）
bash
运行
telnet CAS管理IP 8080
不通排查点：
服务器防火墙 /iptables 拦截端口，临时关闭测试：setenforce 0 && systemctl stop firewalld
三层交换机、防火墙策略阻断业务网段
CAS 集群管理 IP 漂移、CAS 主机离线告警（登录 CAS 平台查看主机状态）
2. CAS 集群状态校验
登录 CAS 管理页面：
查看集群主机：3 台虚拟化服务器是否全部在线、无存储 / CPU 内存告警
查看API 网关：CAS API 服务是否正常，无接口 500 报错
存储池是否正常，无磁盘离线、只读故障（存储异常会导致虚拟机元数据无法读取）
四、第四步：平台对接配置校验（Broker 读取 CAS 虚拟机授权 / 地址错误）
进入 Workspace 云桌面管理平台 → 系统配置 → 虚拟化平台对接
确认 CAS 集群地址、管理员账号密码填写正确，点击【测试连通性】
测试失败：修改正确 CAS 账号，重新保存对接配置，重启 Broker
核对资源池授权：CAS 平台已授权该 Workspace 读取虚拟机权限，未授权会返回空列表
五、第五步：日志精准定位（Broker 日志关键词）
bash
运行
# 过滤报错日志
grep -i error /var/log/h3c-cloud/broker.log
grep -i failed /var/log/h3c-cloud/broker.log
常见日志报错对应根因：
connect CAS api timeout：Broker 到 CAS 8080 网络不通
mysql connection refused：数据库未启动 / 账号密码错误
rabbitmq unreachable：消息队列服务宕机
query vm list empty：CAS 对接账号无虚拟机查看权限
service crash out of memory：服务器内存不足，Broker 进程被 OOM 杀死
六、第六步：集群 / 资源异常兜底修复
CAS 主机资源过载
3 台服务器 CPU / 内存 100% 占用，CAS API 响应超时，Broker 拉取列表失败；迁移虚拟机释放资源后重试。
磁盘满导致服务异常
bash
运行
df -h
/var、/ 分区占用 100% 会导致 Broker 无法写缓存、数据库宕机，清理日志扩容磁盘。
3. 版本不匹配
Workspace Broker 版本与 CAS 版本跨大版本不兼容，核对配套版本，升级补丁包。
七、快速应急操作顺序（现场直接执行）
登录 Workspace 管理节点，重启全套依赖服务
bash
运行
systemctl restart rabbitmq-server mysqld h3c-cloud-api h3c-cloud-broker
测试 Workspace 到三台 CAS 8080 端口连通性，放行防火墙端口
登录 CAS 确认 3 台虚拟化主机全部在线、存储无告警
云桌面后台重新保存 CAS 对接配置，刷新页面查看虚拟机列表
补充区分故障范围
所有客户端 / 后台都提示获取列表失败：Broker 服务 / CAS 集群全局故障（上面步骤全部适用）
仅单个终端报错，后台正常：终端本地网络、Workspace 客户端缓存问题，重装客户端即可