ZStack 每周整理近期客户在使用过程中提出的高频问题，集中作答后向全量用户同步。这不是一份文档更新通知，而是一次真实问题的还原——提问的是你们，整理的是我们，希望答案对更多人有用。

本周共整理了 4 个话题、12 个具体问题，覆盖 存储容量异常、安全加固翻车、云主机性能与迁移、网络变更导致集群失联。如有问题未被覆盖，欢迎通过支持渠道继续提交。

1. 主存储还剩 20%，云主机却创建失败了？

90% 的容量问题都不是"真的满了"

Q1、存储没满，业务为什么无法正常运行？

云平台的容量不是一个大池子，而是多个独立空间叠加运行。总量显示 80% 使用率，不等于每个子空间都安全——某一块到顶，对应操作就会失败。

遇到"明明有空间但创建失败"，先跑这两条：

1 # 看逻辑卷状态


2 pvs && vgs


3


4 # 看各分区实际使用率


5 df -
Th

Q2、想快速过一遍容量风险，点位在哪？

按顺序查，5 分钟心里有数：

1.  管理节点磁盘： df -h +  du -h / --max-depth=1 --exclude=/proc | grep G
2.  存储池总量 vs 可分配量：重点看  availableCapacity 是否为 0
3.  日志盘：日志堆积等是最常见的占用来源
4.  告警阈值：阈值设置太宽松，等告警响的时候已经晚了

Q3、什么情况下该扩容，而不是继续清理？

出现以下任意一种，请及时走扩容流程：

• • 主存储长期处于 80%+ 高水位，清理只能撑一周
• • 克隆、备份、快照任务开始频繁失败
• • 业务增长是可预期的趋势，不是短期波动
• • 巡检报告已经连续 3 个月提示容量风险

记住：清理解决的是历史包袱，扩容解决的是未来问题。等迁移、升级撞上容量红线，变更窗口会更难排。

立即行动

• • 跑一遍  df -Th，看系统盘 / 备份盘 / 日志盘是否在高位
• • 查存储池的  availableCapacity，确认可分配空间充足
• • 清理 90 天未操作的快照、废弃镜像、可疑日志
• • 确认关键节点已配置有效容量告警阈值

如果空间清理后问题依旧，或者容量已经逼近红线，欢迎联系支持团队做进一步诊断。

2. 安全加固后平台反而出现异常了？

动作做了，边界没看清——三个高频踩坑一次说清

Q1、加固完平台就异常，哪里最容易踩雷？

三个高危区，逐一拆解：

① 端口收紧，误伤了集群内部通信

平台内部节点之间有大量必须通信的端口，一旦被收口：集群心跳断了 HA 开始误判；存储面和管理面失联任务全部卡住；证书验证失败部分调度判断直接跳过。

如果你用的是  chronyd 做时间同步，加固时别直接封 123/udp。时间同步异常，证书、HA、调度判断都会受影响。

② 禁用登录方式，影响了管理面服务

为了"更安全"直接禁用某些认证路径，结果可能是管理控制台无法正常登录、API 调不通、节点加入集群失败。

③ 直接手工改配置，没用经过验证的加固方法

不同版本、不同环境，加固方案不能照搬。先在测试环境验证测试，再上生产。

Q2、忘记控制台密码，或者改完密码平台失联了怎么办？

云主机控制台密码重置：

1. 进入云主机 → 更多操作 → 系统配置
2. 找到"设置控制台密码"，先取消，再重新设置
3. 重启云主机生效

建议放在维护窗口做，别在业务高峰期临时操作。

Q3、哪些加固动作推荐做，哪些不建议直接硬改？

推荐坚持做：强密码策略 + 定期轮换；控制台密码、数据库密码规范化；敏感操作有审计记录；用户权限分级。

不建议在生产环境直接硬改：未核验影响就收紧集群内部通信端口；未确认兼容性就禁用关键登录方式；底层root密码改了但平台侧配置没同步；在业务高峰期执行安全变更。

立即行动

• • 确认当前加固方案是否经过测试环境验证
• • 检查集群内部通信端口是否仍然可达（尤其 22/SSH、443/API、2379/etcd 相关）
• • 核对控制台密码、数据库密码是否存在"底层改了但平台未同步"
• • 把后续安全变更统一排进低峰期维护窗口

如果加固后已经出现服务异常、HA 失效或管理面报错，请勿重复尝试操作，避免扩大影响——联系支持团队做一次系统性诊断。

03. 云主机装好了，为什么性能还是差、迁移失败？

Guest Tools、Virtio、CPU 模式——三个最容易忽视的底层配置

Q1、云主机能用，为什么性能一直不对？

"能用"和"用得顺"之间，差的是运行优化。三个最常见的性能杀手：

小提示：云主机安装完 VMTools 后，网卡可能会从 e1000 变成 virtio。如果是云主机系统内配置了静态 IP，云主机重启后 IP 会丢失，需要重新配置静态IP。

Q2、热迁移总失败，为什么通常不是网络问题？

热迁移失败最常被误判为"网络问题"或"平台偶发"，但实际上  80% 以上和 CPU 模式与兼容性有关。

典型踩坑场景：

1.  跨 CPU 型号迁移：源物理机和目标物理机 CPU 能力不一致，直通模式迁移云主机会直接报错
2.  选了直通又想要迁移灵活性：高性能和跨节点迁移在某些场景下是矛盾的
3.  业务高峰期强行迁移：内存脏页 + 磁盘 IO + 网络波动叠加，迁移窗口根本不够用

实操案例：一台云主机迁移时提示"区域内没有目标物理机"，最后排查发现是 CPU 直通模式 + 源集群 CPU 型号不一致。把 CPU 模式改成  none 后迁移成功。

如果你需要的是"稳定的跨节点迁移能力"，建议优先选  none 或更通用的 CPU 模式；如果追求更高性能且不需要迁移，再考虑直通模式。

Q3、新购云主机或做模板前，最值得先做什么？

重复工单里，很大一部分问题其实在模板阶段就埋下了。建议模板制作前完成这 4 件事：

1.  统一 Guest Tools 安装规范：不要每次现装现配
2.  确认磁盘模式和驱动符合推荐做法：尤其是 Windows 模板
3.  有迁移需求的业务，提前确认 CPU 模式：避免迁移失败后再回溯调整

Windows 老系统迁移特别提示：从 Windows 2003 或更老系统迁移过来，安装性能优化工具经常遇到异常。推荐处理顺序：① 停止目标端云主机 → ② 先做快照再回滚 → ③ 检查是否挂载了 ISO，必要时先卸载 → ④ 在系统内执行工具挂载命令，重启后重装优化工具。

立即行动

• • 抽查 3-5 台关键业务云主机，确认 Guest Tools 安装状态
• • 对近期有性能异常或迁移失败的云主机，核查磁盘模式和 CPU 模式
• • 确认当前 CPU 模式是否与业务迁移需求匹配
• • Windows 模板用户：检查驱动和 Guest Tools 安装流程是否已标准化
• • 近期有大规模新建或迁移计划：先做小范围验证

如果同类云主机反复迁移失败、驱动调整后问题依旧、跨节点性能差异明显——联系支持团队做兼容性评估。

04. 改完交换机配置，整个集群都失联了？

网络变更前必须确认的 3 件事

Q1、为何仅调整一台交换机，便引发大范围业务异常？

因为云平台的网络天然具有放大效应。几个典型场景：

• • 物理机上的 bond 配置了多个 VLAN，但不同 VLAN 共用了同一个 MAC 地址 → MAC 漂移，全网不通
• • 存储网络和管理网络混用同一个物理链路 → 一旦链路抖动，平台管理和存储 IO 同时受影响
• • 上联口 trunk 没有放通新 VLAN → 以为只影响新业务，实际旧业务也断了

关键认知：网络变更后故障范围多大，不取决于你"改了多少"，而取决于有没有动到关键链路上的共享资源。

Q2、网络变更前，最该先确认什么？

按这个顺序过一遍，至少降低 80% 的异常风险：

①  确认四类网络用途边界
先把管理网络（集群内部通信）、业务网络（租户 workload）、迁移网络（热迁移）、存储网络（数据盘 IO）各自的用途、承载设备和物理路径理清楚。不要在没有边界图的情况下直接改配置。

②  交换机侧和主机侧配置一致性

在接入交换机新增 VLAN 时，记得同步放通上联口 trunk，例如： switchport trunk allowed vlan add 136

Q3、改完后接口消失了，或者服务起不来，如何排查？

两个高频场景，对号入座：

场景 1：NetworkManager 和平台网卡管理冲突（麒麟系统）

物理机网桥上的 VLAN 接口莫名丢失，关也关不掉。解法：在真实网卡、bond、br_bond 的配置文件中都加上  NM_CONTROLLED=no，这样 NetworkManager 就不会和平台侧抢控制权。

场景 2：网卡配置写了 DHCP，现场根本没有 DHCP 服务器

物理机重装后 bond 网卡起不来，根因不是 bond 坏了，而是配置里全是 DHCP 模式，但机房根本没有 DHCP 服务——等请求超时才发现问题。解法：改成静态 IP 配置，重启网络服务。

立即行动

• • 梳理当前环境中管理网络、存储网络、业务网络的物理边界
• • 核对交换机侧和主机侧的 VLAN、聚合模式、上联配置是否一致
• • 确认关键地址（管理 IP、存储 IP）是否有冗余路径保障
• • 检查是否有 LACP hash 策略不一致导致的负载不均问题
• • 近期有网络变更计划？先安排一轮小范围验证再动生产环境

如果变更后已经出现多节点同时异常、存储网络和管理面同时波动、无法判断问题在交换机侧还是主机侧——请勿重复尝试操作，避免扩大影响，联系支持团队协助定位。