2、方案取舍过程
方案一：继续扩容VMware
优点很直接：
但问题也很明确：
这条路更像是在“延长使用寿命”。
方案二：新建HCI（最终选择）
优势在于：
更关键的一点是：
可以把复杂度“清掉一部分”，而不是继续叠加。
最终选择新建 HCI，再通过迁移完成过渡。
3、资源与容量设计
新平台采用：
深信服 aServer-X5-2105 × 2 台
资源配置：
4、业务承载策略
一开始并没有打算“全量迁移”。
现网有效数据约27TB，如果全部迁入：
最终做了拆分：
这样处理之后，新平台负载控制在约30%~50%，同时预留了扩展空间。
5、存储模型选择
在方案设计阶段，对两种路径进行评估：
| 方案 | 优点 | 缺点 |
| 混合架构（SSD+HDD） | 容量大 | 随机IO性能不稳定 |
| 全闪SSD架构 | 高性能 | 成本较高、容量受限 |
结合实际业务：
在经验判断中，混合架构有一个明显问题：
一旦缓存命中下降，HDD会成为瓶颈，尤其是在并发访问时，延迟会放大。
最终还是选择了全闪架构，核心考虑不是“性能极致”，而是：
让性能更稳定、可预期。
6、双路径迁移模型设计
在迁移方案设计阶段，迁移方式并不是一开始就确定的，而是结合现网条件、授权情况以及迁移风险做了实际取舍。
现场主要评估了两种路径：VMware纳管迁移 和 SCMT迁移工具。
（1）VMware纳管迁移
通过HCI平台对VMware集群进行纳管后，可以直接调用生命周期管理中的迁移能力，将虚拟机从VMware侧迁移到HCI平台。
这个方式的特点很直接：
但在进一步评估时，也发现几个限制：
部分老旧虚机（尤其驱动、硬件版本较低）兼容性不稳定
（2）SCMT迁移工具
SCMT本质上是一个独立的迁移工具，支持P2V / V2V场景，可以通过Agent方式完成数据同步和业务切换。
相比纳管迁移，它的特点更偏“稳”：
在测试过程中，Windows和Linux虚机都可以正常完成迁移，启动成功率较高。
但它也有比较现实的限制：
（3）最终取舍：双路径并行
结合客户实际情况，这里做了一个比较“务实”的选择：
原因是现场未采购SCMT正式授权，同时纳管方式可以覆盖大部分标准业务
主要用于应对迁移过程中可能出现的兼容性问题或失败场景
这样形成一个比较清晰的策略：
（4）现场经验
这个决策背后，其实有一个很现实的考虑：
在多业务环境下，迁移的不确定性往往不在“工具本身”，而在：
7、迁移执行策略
所有虚拟机统一采用三阶段迁移：
在实际执行中，大多数业务中断可以控制在：
四、简要实施过程 整个实施周期控制在两周左右，没有做“大批量一次性迁移”，而是拆开执行。
1、迁移前准备
主要做了几件事：
在梳理依赖关系时，有一个比较直观的感受：
AD一旦出问题，所有系统都会受影响
所以后面迁移顺序是围绕这个来设计的。
2、HCI、SCMT环境准备
这里有个关注点：
3、迁移工具验证
在正式迁移前，单独对SCMT做了一轮验证。当时的目标很简单：
不追求快，只确认“能不能用”。
测试结果：
做到这一步，其实心里就比较有底了。
4、分批迁移策略
迁移顺序不是按“重要程度”，而是按“影响范围 + 可控性”来排的：
这里有一个取舍：
文件服务器虽然不是最核心，但用户感知最明显，所以放在中间阶段处理。
5、业务割接与回退设计
割接统一在夜间窗口执行。
流程相对固定：
回退策略做得比较保守：
整个迁移过程中，这套回退机制没有真正用上，但在现场非常关键——
有回退，执行起来心里更稳。
五、关键问题与处理这次迁移整体过程是可控的，但并不是完全“顺滑”。
真正有价值的，反而是中间遇到的这些问题。
问题一：vmtools 安装失败导致虚拟机网络异常
现象
个别虚拟机迁移完成后，系统可以正常启动，但网络始终不通。
现场第一反应是比较常见的方向：
但检查下来，配置本身没有明显问题。
排查过程
一开始的判断其实有点“惯性思维”——优先怀疑驱动兼容。
尝试过：
问题依然存在。
这时候才把关注点从“虚拟化层”往系统内部转。
继续排查vmtools安装日志，发现报错：
Error: copy file success but the file is not the same! Please retry.
Install Update module failed!
当时翻了下support故障案例，发现有个因boot分区、导致scmt客户端安装失败问题：
“对于linux要求linux的boot区分空间至少要有200M，其他分区也不要有占满的情况”，
因此接下来也尝试往这个方向排查。
根因定位
继续往系统层看，发现一个细节：
进一步分析后确认：
vmtools安装过程中需要写入引导相关文件
/boot空间不足时：
最终导致：
驱动未正确加载 → 网络异常
处理方式
处理过程反而比较简单：
处理后：
这个问题本身不复杂，但有两个点比较典型：
在后续迁移中，针对 Linux 虚机，额外增加了一步检查：
避免同类问题重复出现。
问题二：Windows 2008 R2 虚机迁移后蓝屏且无法关机/关电源
现象
在一次纳管迁移完成后，一台 Windows Server 2008 R2虚拟机启动过程中出现蓝屏。
这台机器的问题比较典型但也比较棘手，不是单次蓝屏，而是进入了自动重启循环：
现场尝试常规关机、关闭电源都没有效果，虚拟机一直在循环重启。
多次尝试后，在开机过程中按F8进入启动选项界面，才把系统“卡住”，从而完成关闭电源操作。
蓝屏信息如下：
排查与尝试
初步判断还是偏向迁移带来的兼容性问题，重点怀疑方向包括：
现场没有第一时间更换迁移方式，而是先尝试做一轮基础修复，看能不能在原路径上恢复。
由于系统无法正常启动，这里通过挂载PE的方式进入系统进行处理，主要做了几步尝试：
通过PE环境对系统盘进行修复，排除明显的文件系统异常
整体过程没有报明显错误，但修复完成后，系统依然在启动阶段蓝屏，没有实质改善。
处理方式
到这一步，其实有两个选择：
继续在系统层做更深入的修复（如驱动替换、启动项调整等）
结合当时现场情况，这里没有继续在系统层“往深挖”，而是选择切换方案：
迁移完成后再次启动，系统可以正常进入，未再出现蓝屏问题。
对比来看，SCMT在迁移过程中会对目标虚拟机进行驱动适配处理（包括磁盘控制器驱动注入），对原系统环境依赖更低，因此在老系统场景下成功率更高。
经验总结
这个问题不算复杂，但在迁移场景中比较典型，主要有几个点：
1、老系统对底层环境变化更敏感
像Windows 2008/2003这类系统，驱动体系较老，对虚拟硬件（尤其是磁盘控制器）的变化适应能力有限，一旦环境发生变化，就容易在启动阶段出问题。
2、迁移问题不一定都适合“修”
从结果来看，这台虚拟机本身是正常的，问题更多出在迁移后的环境适配。
如果一直停留在系统修复路径上，时间成本会比较高，而且结果不确定。
3、切换路径比持续修复更有效
这次处理没有在原路径上反复尝试，而是直接更换迁移方式，从结果来看效率更高，也更可控。
在多业务迁移场景中，这种方式更容易保证整体节奏，不会因为单点问题被拖住。
总结：
在类似场景中，如果出现“启动即蓝屏 + 安全模式无法进入 + 文件系统无异常”，可以优先考虑存储控制器或驱动兼容问题，而不是继续从系统损坏角度排查。
问题三：Windows Server 2008 R2启动卡在Startup Repair修复失败
现象：
在迁移完成一台Windows Server 2008 R2虚拟机后，系统启动阶段直接进入自动修复流程，界面提示：
该过程持续较长时间后，最终提示修复失败：
随后系统进入“发送错误报告 / 关闭”选项界面，但无论选择何种方式，均无法正常进入操作系统，虚拟机持续停留在修复与重启流程中。
排查过程
从现象来看，首先考虑的是磁盘或文件系统异常，因此优先按传统思路进行了验证，包括：
但排查结果：
同时，系统在修复阶段并未给出明确错误码，属于“修复过程卡住但无明确报错”的状态。
处理判断
在排除磁盘与文件系统问题后，问题开始转向迁移适配层面进行分析。
结合前期类 Windows 2008 R2虚拟机的迁移情况，判断该问题更可能与以下因素相关：
迁移后虚拟硬件环境变化（磁盘控制器 / 虚拟显卡类型）
该类问题的特点是：
处理方式
在尝试常规修复路径无效后，未继续在系统层深入排障，而是直接切换迁移方式：
迁移完成后，虚拟机启动正常，不再进入Startup Repair流程，系统可直接进入登录界面，业务恢复正常。
经验总结
该问题在现场属于“启动修复循环失败”场景，在Windows Server 2008 R2这类老版本系统中较为常见。
从处理结果来看，问题并不在于磁盘或系统文件损坏，而更偏向于：
在类似场景中，如果已经排除文件系统损坏但仍无法正常启动，继续进行系统层修复的收益较低，优先考虑通过重新迁移方式重建运行环境，往往比“修复系统”更直接有效。
问题四：部分Windows虚拟机无法在系统内调整分辨率
现象
在迁移完成后，个别Windows虚拟机（主要为 Windows Server 2008 R2、Windows 7）存在显示异常：
而同批迁移的Windows Server 2016、Windows 10虚拟机未出现该问题，可正常在系统内修改分辨率。
排查过程
初期按常规方向排查：
1、VMTools 状态检查
确认虚拟机内工具已正常安装
服务运行正常，无报错
2、设备管理器检查
显卡驱动正常识别
无未知设备或驱动异常
3、虚拟显卡类型调整
尝试更换虚拟机显示适配器类型
在Windows Server 2016 / Windows 10中调整后可生效
在Windows Server 2008 R2 / Windows 7中无变化
到这一步可以确认：
问题不在工具或驱动，而是与系统版本及底层启动方式存在关联。
根因定位
后续通过support案例检索，定位到一个关键差异：
老版本 Windows（2008 R2 / Win7）对该模式下的显示控制支持有限
在该组合下：
处理方式
针对该类虚拟机，未再从系统内部继续调整，而是直接从底层处理：
调整后：
经验总结
该问题属于典型的“系统版本 + 启动模式”兼容性问题，特点是：
新系统（Win10 / 2016 及以上）基本不受影响
在类似场景中，如果已确认：
则应优先考虑启动模式因素，而不是继续在系统或驱动层排查。
对于老版本Windows虚拟机，如采用UEFI启动，建议直接在BIOS层调整分辨率，可减少无效排障时间。
问题五：文件服务器访问延迟
现象文件服务器迁移完成后，用户反馈：
这个问题的特点是：
排查过程现场第一判断是典型三板斧：
结果比较“反直觉”：
一度怀疑是应用层问题，但对比迁移前情况，又基本可以排除。
定位过程后来把关注点放在一个细节上：
发现：
虽然资源没有打满，但在并发场景下：
就会放大延迟感知。
经验总结这个问题有一个比较典型的误区：
“监控看不出问题 ≠ 用户体验没问题”
尤其是文件服务这类场景：
在迁移后，建议优先做一轮：
六、效果验证
迁移完成后，没有立即做结论，而是观察了一段时间运行情况，再做对比。
1、平台稳定性迁移前：
迁移后：
现场最直观的反馈是：
运维侧“心理压力明显降低”
2、资源使用情况
3、平台架构变化
迁移前：
迁移后：
变化的核心不是“减少设备”，而是：
故障路径被明显缩短
4、运维侧变化
迁移前：
迁移后：
整体变化可以总结为：
七、项目价值总结
1、架构层面
完成从“多套系统叠加”到“单一平台”的收敛。
减少了：
系统结构变得更简单，也更可控。
2、稳定性
这次改造没有追求极限性能，而是优先解决不确定性：3、成本与资源
本次没有做“全量替换”，而是只迁移核心业务（约7TB）
这样做的实际效果是：
资源使用变得更“有针对性”，而不是平均分配。
4、迁移模型价值双路径迁移模型在这次项目中起到了实际作用：
相比单一方案：
这个模型在多业务环境中是可复用的。
八、项目复盘
1、双路径迁移模型更适用于复杂环境
在虚机数量多、系统类型复杂的场景中：
双路径设计的价值在于：
出现问题时，不需要“卡住”，可以直接切换路径继续推进
这次没有追求效率，而是优先控制风险：
这样做的结果是：
在这个项目中，一个比较深的体会是：
文件服务器往往比数据库更容易引发用户反馈问题。
原因在于：
迁移这类业务时：
楼主
QQ好友和群
QQ空间
腾讯微博
腾讯朋友
发表于 2026-3-30 16:32
技术员3级 
