云轴科技ZStack 每周整理近期客户在使用过程中提出的高频问题，集中作答后向全量用户同步。这不是一份文档更新通知，而是一次真实问题的还原——提问的是你们，整理的是我们，希望答案对更多人有用。
本周共整理了 4 个话题、12 个具体问题，覆盖存储容量异常、安全加固翻车、云主机性能与迁移、网络变更导致集群失联。如有问题未被覆盖，欢迎通过支持渠道继续提交。
1. 主存储还剩 20%，云主机却创建失败了？
90% 的容量问题都不是"真的满了"
Q1、存储没满，业务为什么无法正常运行？
云平台的容量不是一个大池子，而是多个独立空间叠加运行。总量显示 80% 使用率，不等于每个子空间都安全——某一块到顶，对应操作就会失败。
| 空间类型 | 常见误区 |
|---|---|
| 主存储总量 | 以为没到 100% 就安全 |
| 可分配容量（availableCapacity） | 这个值是 0 时，创建就会失败 |
| 镜像缓存池 | 创建云主机都会先占用这里 |
| 系统盘 + 日志目录 | 经常被忽略，却是工单重灾区 |
| 备份 / 快照周转空间 | 备份任务失败，往往是这里先爆 |
遇到"明明有空间但创建失败"，先跑这两条：
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、云主机能用，为什么性能一直不对？
"能用"和"用得顺"之间，差的是运行优化。三个最常见的性能杀手：
| 问题 | 典型表现 | 排查方向 |
|---|---|---|
| Guest Tools 未安装 / 安装不完整 | 监控数据不准、性能比预期差 | 检查是否使用了平台推荐的安装方式 |
| 磁盘模式未按推荐配置 | IO 延迟高、磁盘性能上不去 | 确认是否使用了 virtio-scsi 或推荐模式 |
| 关键配置修改后未规范重启 | 改完参数后问题依旧 | 通过平台界面完成规范重启，不是直接重启系统 |
小提示：云主机安装完 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 | 两端是否一致？新增 VLAN 时 trunk allowed 是否同步放通？ |
| 聚合模式 | LACP 协商是否正常？ |
| 上联链路 | 是否有链路聚合？是否配置了冗余路径？ |
| 交换协议 | STP / RSTP 状态是否正常？ |
在接入交换机新增 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 策略不一致导致的负载不均问题
- • 近期有网络变更计划？先安排一轮小范围验证再动生产环境
如果变更后已经出现多节点同时异常、存储网络和管理面同时波动、无法判断问题在交换机侧还是主机侧——请勿重复尝试操作，避免扩大影响，联系支持团队协助定位。
