1. 检查libvirtd服务状态与日志
systemctl status libvirtd
journalctl -u libvirtd -f --since "2 hours ago"
2. 检查网络与防火墙
- 确认管理网络连通性。
- 检查防火墙是否阻断libvirtd相关端口（默认16509/tcp, 16514/tcp）。
3. 检查存储与资源
df -h
virsh list --all
确认存储空间充足，无残留虚拟机锁文件。
4. 检查Workspace管理服务
systemctl status workspace-manager
journalctl -u workspace-manager -f
重点查看与CVM通信的HTTP接口报错。
可能原因：管理服务（workspace-manager）与CVM的HTTP通信因网络、防火墙或服务启动顺序问题暂时中断，导致virsh代理命令卡住。两小时后自动恢复可能是服务重连机制生效。
建议：检查上述服务的启动顺序依赖，确保网络就绪后再启动libvirtd及管理服务。
结合你提到的“退出维护模式失败”和“HTTP接口调用失败”这两个信息，问题很可能指向了存储连接异常导致的底层虚拟化组件假死。
要彻底解决这个问题，关键在于找到导致卡住的根本原因。以下是几个最主要的排查方向，可以根据你的环境情况按优先级尝试：
优先排查：存储连接与心跳
服务器重启后，存储连接没有及时恢复或存在间歇性中断，是导致virsh和CAS API（fsm_core服务）卡住的最常见原因。
检查存储多路径状态：
multipath -ll。检查是否有路径失效（failed/faulty），以及活动路径数是否符合预期。检查共享存储文件系统：
mount | grep ocfs2。检查共享存储挂载点状态，如/vms。查看/var/log/ocfs2/*日志中是否有I/O错误或心跳超时（heartbeat timeout）。检查存储网络连通性：
ping <存储IP>和iscsiadm -m session。确认存储网络（如心跳网络）是否畅通，iSCSI会话是否正常建立。
如果存储检查没有发现问题，或者想更全面地诊断，可以按以下顺序排查：
查看系统日志，定位错误源头
核心虚拟化日志：
tail -n 200 /var/log/libvirt/libvirtd.log，查找error、timeout、failed等关键字。系统消息日志：
tail -n 200 /var/log/messages | grep -iE 'virt|kvm|libvirt|error|fail|timeout'。内核日志：
dmesg -T | tail -n 100，查看是否有I/O错误、存储连接错误、OOM（内存溢出）等记录。CAS平台日志：
tail -n 200 /var/log/tomcat*/cas.log，搜索HTTP request error或interface call failed。
检查资源与进程状态
资源使用情况：
top -bn1 | head -20，检查CPU使用率，关注是否有异常高的%wa（I/O等待）或%sy（内核占用）。僵尸进程与假死进程：
ps aux | awk '$8=="Z" {print}'和ps aux | grep -E 'D|T'。Z表示僵尸进程，D表示不可中断睡眠（常由I/O问题导致），T表示暂停状态。强制清理卡住的虚拟机：
virsh list --all定位虚拟机ID，如果virsh destroy <VM_ID>命令也卡住，可尝试kill -9 <KVM进程PID>。注意：强制清理前需确保业务已受影响，操作前建议备份重要配置。
检查关键服务状态
核心CAS服务：
systemctl status fsm_core nfa nagios tomcat mysql。确保这些服务状态是active (running)，这是平台正常工作的基础。VRM代理服务：
systemctl status cvrm。这是管理节点与主机通信的关键代理，若异常，可尝试systemctl restart cvrm。
解决方案
立即恢复：强制终止卡住进程
如果急需恢复业务，可以强制终止virsh或kvm进程。查找虚拟机对应的KVM进程：ps -ef | grep <虚拟机名称>，然后kill -9 <PID>。尝试恢复：重启相关服务
如果平台服务异常，可尝试重启，但需注意风险。完全重启法（适用于可接受业务中断的环境）：按顺序重启服务器，以彻底清除所有不稳定状态。
逐步重启法（适用于需尽量保持业务在线的环境）：按以下顺序重启服务：
tomcat->mysql->fsm_core->nagios->nfa，并每次检查服务状态和virsh list是否恢复。
长期规避：升级与补丁
如果问题反复出现，且排除了存储和网络因素，很可能是软件层面的Bug。强烈建议联系H3C官方技术支持，获取针对Workspace E1009版本的官方补丁或升级建议。自行升级存在风险，需在H3C工程师指导下进行。临时规避：脚本化恢复
在获得官方补丁前，可以编写一个简单的脚本，通过crontab定时检查（如每小时一次），当virsh list命令超时时，自动执行重启libvirtd服务的操作。这可以作为一个临时的规避方案，但不能替代根本性的修复。
暂无评论
virsh list / start / shutdown等命令卡住、无响应systemctl restart libvirtd无效（服务 active 但不干活）- 平台 Web 退出维护模式失败：接口调用失败 / HTTP 请求出错
- 等待数小时后 “自己好” → 是内部超时 / 重试机制恢复
一、根本原因（E1009 单节点必现）
- CVM 与 CVK 共机，服务强依赖
- CVM（云管理）、CVK（虚拟化）、ONEStor（存储）、MySQL、RabbitMQ、Nginx、libvirtd 全部在同一台
- 重启后 启动顺序错乱、依赖死锁：
- libvirtd 等待 CVM/ONEStor 初始化
- CVM 等待 libvirtd 就绪
- 互相等待 → 全阻塞
- 单节点无仲裁，维护模式锁死
- 单节点进入维护模式后，重启会导致：
- 集群状态异常、主机锁标记残留
- CVM 认为 “集群不完整、有主机故障”
- 拒绝执行退出维护、拒绝响应 libvirt 请求
- 单节点进入维护模式后，重启会导致：
- libvirt 与 ONEStor 存储池死锁
- 重启时 存储池未正常卸载 / 挂载
- libvirtd 阻塞在
storage_probe/pool-start - 表现：
virsh命令卡住、ps aux | grep virsh处于 D 状态（不可中断）
二、10 分钟快速恢复（不用等 2 小时）
1. 强制解锁维护模式（最关键）
# 1. 登录CVM后台（SSH/物理终端）
# 2. 清除维护模式锁（E1009单节点专用）
rm -rf /var/run/h3c/cvm/host_maintenance.lock
rm -rf /var/run/h3c/cvm/cluster_state.lock
rm -rf /var/lib/libvirt/qemu/save/*.lock
# 3. 强制重置CVM主机状态
/opt/h3c/cvm/server/bin/cvm-cli host reset-state --uuid `cat /etc/uuid`
/opt/h3c/cvm/server/bin/cvm-cli host exit-maintenance --force
2. 重启所有服务（按顺序）
# 1. 先停所有
systemctl stop fsm smb onestor-libvirtd libvirtd
systemctl stop cvm cvm-agent rabbitmq-server mysql nginx
# 2. 清理libvirt僵尸进程
kill -9 `ps aux | grep libvirtd | grep -v grep | awk '{print $2}'`
kill -9 `ps aux | grep qemu | grep -v grep | awk '{print $2}'`
rm -rf /var/run/libvirtd.pid /var/run/qemu/*.pid
# 3. 按依赖启动（顺序不能错）
systemctl start mysql
sleep 10
systemctl start rabbitmq-server
sleep 15
systemctl start cvm
sleep 30
systemctl start libvirtd onestor-libvirtd
sleep 20
systemctl start fsm smb
3. 修复 libvirt 与存储池
# 1. 重建libvirt连接
virsh -c qemu:///system connect
virsh -c qemu:///system pool-list --all
# 2. 异常存储池强制重启（通常是isopool/default）
virsh pool-destroy isopool
virsh pool-start isopool
virsh pool-autostart isopool
# 3. 验证virsh恢复
virsh list --all # 正常出虚拟机列表
virsh nodeinfo # 正常返回
4. Web 平台验证
- 进入 数据中心 → 主机
- 确认 维护模式：否
- 虚拟机 正常启动 / 管理
三、永久根治（避免重启再卡）
1. 关闭自动维护模式
- Web：系统 → 高级设置 → 主机维护
- 关闭 重启自动进入维护模式
2. E1009 单节点优化（必做）
# 1. 关闭集群仲裁检查（单节点无用）
echo "cluster.ha.enable=false" >> /opt/h3c/cvm/server/conf/cvm.properties
echo "cluster.maintenance.force_exit=true" >> /opt/h3c/cvm/server/conf/cvm.properties
# 2. libvirt超时优化（避免无限阻塞）
echo "libvirt.timeout=30" >> /opt/h3c/cvm/server/conf/cvm.properties
echo "libvirt.connection.retry=3" >> /opt/h3c/cvm/server/conf/cvm.properties
# 3. 重启CVM生效
systemctl restart cvm
3. 升级补丁（官方修复）
- E1009 E1009P03/E1009P04 补丁修复此问题
- 升级步骤：
- 备份 CVM 数据库
- 上传补丁 → 系统 → 软件升级
- 重启主机
四、故障排查日志（定位用）
# CVM平台日志
tail -f /opt/h3c/cvm/server/logs/cvm-core.log
# 关键字：maintenance、HTTP请求失败、libvirt connect failed
# libvirt日志
tail -f /var/log/libvirt/libvirtd.log
# 关键字：storage pool、timeout、cannot connect
# 存储服务日志
tail -f /var/log/fsm/fsm_core.log
# 关键字：pool-start、symlink、deadlock
五、结论
- 单节点 E1009 重启必现：CVM/CVK/ 存储互相依赖死锁
- 不用等 2 小时：删锁 + 按序重启服务即可立即恢复
- 永久解决：关闭自动维护模式 + 升级 E1009P03 + 补丁
暂无评论
编辑答案
亲~登录后才可以操作哦!
确定你的邮箱还未认证，请认证邮箱或绑定手机后进行当前操作
举报
×
侵犯我的权益
×
侵犯了我企业的权益
×
- 1. 您举报的内容是什么？（请在邮件中列出您举报的内容和链接地址）
- 2. 您是谁？（身份证明材料，可以是身份证或护照等证件）
- 3. 是哪家企业？（营业执照，单位登记证明等证件）
- 4. 您与该企业的关系是？（您是企业法人或被授权人，需提供企业委托授权书）
抄袭了我的内容
×
原文链接或出处
诽谤我
×
- 1. 您举报的内容以及侵犯了您什么权益？（请在邮件中列出您举报的内容、链接地址，并给出简短的说明）
- 2. 您是谁？（身份证明材料，可以是身份证或护照等证件）
对根叔社区有害的内容
×
不规范转载
×
举报说明
暂无评论