企业官网建设流程全解析

这段时间一直有朋友在问我，手头那台老物理服务器到底怎么才能整体搬进 VMware ESXi 里。之前零零散散回复过不少，但始终没有一篇能直接照着做的完整说明。今天正好把一台运行着 Windows Server 2016 的物理机迁移到了新搭建的 ESXi 6.7 环境里，全程用了 VMware Converter Standalone 6.2.0，从刚开始的环境评估到最后的验证优化都走了一遍。这篇文章就把整个过程的思路、步骤和踩过的坑都整理出来，特别是那些文档里不会明说、但实际迁移时几乎一定会碰到的错误，一次性讲透。

适合的读者分两类：一是手上有一两台物理服务器或者老旧 PC，想把它变成虚拟机又不打算重装系统的运维朋友；二是被领导要求在限定时间内完成 P2V 迁移，但之前没怎么摸过 Converter 的新手。整个方案不需要企业级授权，VMware Converter 6.2.0 本身是免费工具，配合一台已经安装好的 ESXi 主机就能完成整套流程。

1. 迁移前的环境评估与工具规划

1.1 先搞清楚什么叫 P2V，以及为什么选 Converter 6.2.0

P2V 就是 Physical to Virtual，把一台物理机上运行的操作系统、应用、数据、分区信息完整复制成虚拟机镜像。相比在新虚拟机上全新安装再迁移数据，P2V 的好处是能保留原有操作系统配置、安装好的服务、数据库实例，省掉大量重新部署的时间。

VMware Converter 做这类迁移有几条明显的优势。首先是免费，虽然 vCenter Converter Standalone 从 6.2.0 之后就没怎么更新，官方甚至不再提供独立下载入口，但通过 VMware 官网依然能找到安装包，功能上也足够稳定。其次是它支持热迁移，也就说源物理机在转换过程中不需要关机，agent 会通过卷影复制（VSS）技术对磁盘做快照，基本上不会中断业务。最后就是它能直接识别物理机磁盘、分区、网络配置，自动处理驱动替换的问题，迁移完虚拟机往往直接能启动。

选 6.2.0 这个版本还有一个现实考虑：它是最后一代还能完整支持 Win7/Server 2008 R2 这类老系统的 Converter。如果你的源机器是更老的 Windows Server 2003 或者 XP，6.2.0 同样支持。反过来，如果你的源机器是 Windows 11 或者 Server 2022，那我建议你谨慎评估，因为老版本 Converter 对 Win10 之后的系统兼容性并不完美，可能出现卷影复制失败或者磁盘签名错误。

1.2 兼容性检查清单：动手之前先过一遍

很多人上来就把 agent 装到物理机上，跑到一半报错才发现源系统不受支持，整个任务作废。所以第一步永远是核对兼容性。我按实际工作经验整理了一份检查清单：

一个容易忽略的坑是磁盘分区大小。源机器明明只有 300GB 空间，但 C 盘已经用了 280GB，迁移到目标存储时如果目标存储只有 250GB 剩余空间，任务会报“目标存储空间不足”。所以在开始之前先给磁盘瘦身，清理临时文件、回收站、Windows 更新缓存，能明显降低迁移时间。

1.3 网络规划与权限准备：迁移会踩到的隐形门槛

Converter 迁移过程本质是：管理机上的 Converter Server 通过网络连接源机器，读取磁盘数据，再写入 ESXi 的数据存储。网络带宽直接决定迁移耗时。如果是 1GbE 网络，300GB 数据大概需要 40 到 60 分钟；如果是百兆网络，时间会飙升到三到四小时，而且中途断流的概率显著上升。

我的建议是，尽量让源机器和 ESXi 主机处在同一个二层网络里，不要让数据流经过防火墙或路由器。如果条件允许，可以单独给源机器接一根网线到管理交换机，保证迁移流量不占用业务带宽。

权限方面，我在实际项目中反复吃过亏。Converter Server 连接源机器时，如果源机器开启了 UAC（Windows 用户账户控制），agent 安装时以管理员身份运行也可能被拦截。更稳妥的方法是在开始迁移前，直接在源机器上关闭 UAC，或者确认你使用的账号加入了本地管理员组，并且 UAC 的策略是“从不通知”。ESXi 端则需要一个至少有虚拟机创建、数据存储操作权限的账号，不建议直接用 root 跑，遇到权限问题时反而更难定位。

2. 安装与基础配置：把工具链搭起来

2.1 两种安装模式，我推荐 Standalone 而不是插件版

VMware Converter 6.2.0 安装包解压后，有 Converter Standalone 和 vCenter Server 插件两种模式。插件版需要把 Converter 功能集成到你现有的 vCenter Server 里，适合从 vCenter Web Client 直接发起任务。但如果你只有一台独立 ESXi，没有 vCenter，那就只能选择 Standalone 版，这也是绝大多数中小型环境的使用方式。

Standalone 版安装过程不复杂，唯一要强调的是：安装目录不要选 C 盘默认位置，理由很简单，Convert 任务运行过程中会产生大量的日志和临时文件，C 盘空间不够会导致任务莫名失败。我一般会把安装目录放到数据盘，比如 D:\VMware\Converter，同时把系统临时目录也指向空间充足的分区。

安装时还可以选择“只安装本地转换”和“典型安装”。典型安装会带上 Converter Server、Agent、命令行工具，本地转换功能也能用。我建议直接用典型安装，省得后续排查问题才发现缺组件。安装完成后服务会被自动注册，名为 VMware vCenter Converter Standalone Server，默认启动状态为自动。

2.2 在源机器上安装 Agent：别跳过的关键初始化步骤

Converter 支持两种源连接方式：远程安装 agent 和无 agent 连接。远程安装就是在你创建迁移任务时，由 Converter Server 通过 445 管理共享把 agent 推送过去。听着很方便，但实际环境里经常会因为 SMB1 被禁用、防火墙规则阻挡或者共享权限问题导致 agent 安装失败。

我踩过一次典型的坑：一台 Windows Server 2008 R2 源机，在创建任务时选择源类型为“远程 Windows 机器”，输入管理员账号后，等待了一会儿报“无法连接到源机器”的错误。排查下来发现，这台机器把 SMB 签名策略给改了，Converter 的远程安装包无法通过验证。

所以我的实操习惯是：先在源机器上手动下载安装 agent。你可以从 Converter Server 安装目录下的\agent\Windows\vmware-converter-agent.exe拿到安装包，或者直接在源机器挂载安装镜像，运行其中的 agent 安装程序。装好之后 agent 服务会自动启动，名字是 VMware vCenter Converter Agent。

装 agent 这一步值得花几分钟现场确认服务状态，执行：

sc query vmware-converter-agent

如果状态是 RUNNING，再接下去创建任务，成功率会高非常多。如果中途 agent 启动失败，检查源机器的事件查看器，多半是网络服务依赖问题或者杀毒软件把 agent 服务禁掉了。

2.3 管理机、源机器、ESXi 三边连通性自测

在真正创建任务之前，我强烈建议先做一轮三边连通性测试，别等任务建到一半才报网络错误。可以用最简单的命令：

在管理机上执行：

ping 源机器IP ping ESXi管理IP Test-NetConnection 源机器IP -Port 445 Test-NetConnection ESXiIP -Port 443

这里要特别注意 443 端口。Converter 连接 ESXi 默认走 HTTPS，所以只测 ping 通没有意义，443 不通连接照样失败。如果 ESXi 使用了非默认端口，需要在 Converter 主界面的“管理 > 全局设置 > 网络”里把端口号改掉。

另外还有一个细节：如果源机器是 Windows 防火墙开启状态，445 端口大概率被默认拦截。在源机器上执行下面的命令开放必要的端口，这一条在排错时能省掉一半时间：

netsh advfirewall firewall add rule name="Converter Agent" dir=in action=allow protocol=TCP localport=9089,9040 netsh advfirewall firewall add rule name="File and Printer Sharing" dir=in action=allow protocol=TCP localport=445

9089 和 9040 是 Converter agent 与 Converter Server 通信使用的端口。如果这两个端口没放通，即使 agent 装好了，执行任务时也会在“正在连接源机器”那一步卡住。

3. 创建迁移任务与核心参数设置

3.1 在 Converter 主界面新建转换任务：逐步拆解向导

正常情况下，经过前面准备，此时打开 VMware vCenter Converter Standalone，主界面会看到“转换计算机”按钮。点击后进入向导，我按步骤拆开讲。

第一步是“源系统类型”。下拉列表里有几个选项：开启的计算机、关闭的计算机、VMware Workstation 虚拟机、备份镜像等。我们这次的场景选“开启的计算机”，然后设置源机器类型为“远程 Windows 机器”，IP 地址填物理机的 IP，用户名密码填本地管理员账号。注意，如果源机器的管理员账号没有设置密码，Windows 默认不允许远程管理连接，Converter 同样无法连。我建议提前给管理员账号设置一个临时强密码，迁移完成后再改回去。

第二步是识别信息。Converter 会连接源机器并读取它的系统版本、磁盘数量和分区情况。这一步如果卡住或报错，大部分问题都出在前面说的防火墙或 SMB 设置上。如果这里读不到磁盘信息，后面所有分区配置都无从谈起。正常情况下你会看到源机器上的磁盘 0、磁盘 1 以及每个分区的大小和文件系统格式。

3.2 目标设置：ESXi 地址、虚拟机名称与存储选择

第三步是“目标类型”，选“VMware Infrastructure 虚拟机”，然后在目标详情里填入 ESXi 主机的 IP、HTTPS 端口（默认 443）和账号密码。Converter 连接 ESXi 之后，会列出可用的宿主机和数据存储。

这里有几个选择上的讲究。

虚拟机名称尽量用业务相关的命名规则，比如 webserver-prod-p2v-01，别用默认的“Physical Machine 1”这种名字，不然后面多了根本分不清哪台对应哪个业务。

数据存储的选择要看实际使用空间和性能。如果 ESXi 上有多块磁盘，首选剩余空间大于源机器已用空间 1.5 倍的存储。这样设计是为了给磁盘格式转换和快照预留临时空间，卡着最低空间阈值去迁移，任务后半段容易因为空间不足直接失败。

目标虚拟机版本：如果你用的是 ESXi 6.5/6.7，默认生成的是虚拟机版本 13 或 14，兼容性没问题。如果是老版本 ESXi 5.5 或 6.0，需要手动选低版本，否则目标主机无法注册虚拟机。

3.3 数据卷选择：全盘拷贝还是只拷系统盘

这是迁移策略里最需要想清楚的一步。Converter 在第四步“数据复制类型”里会问你是复制“当前磁盘上的所有数据”还是“选择卷”复制。

如果只是想让系统快速跑起来，数据另行处理，只复制系统卷（通常是 C 盘）就够了，迁移时间会短很多。但如果希望虚拟机完整接管原物理机的功能，老老实实全选所有磁盘卷。有些机器有独立的 D 盘存放数据库文件，如果只拷 C 盘，数据库的路径就断裂了，后面的恢复成本比一次性全拷更大。

在选择复制哪些卷时，Converter 会为你规划目标磁盘布局。它会默认保持每个卷的大小不变，你也可以勾选“高级编辑”来修改目标磁盘的类型和大小。我建议保持默认的“保持大小”（在可能的情况下），因为源分区已经是最佳布局，手动调整大小反而容易破坏分区对齐或者引导配置。

3.4 磁盘控制器与硬件设置：虚拟机能不能起来的关键

目标机器的硬件设置界面是很多人忽略的地方，但这里恰恰是迁移后虚拟机起不来的重灾区。

Converter 默认把磁盘控制器设置为 LSI Logic SAS，这对大多数 Windows Server 系统没问题，因为系统里本身就带了 LSI 驱动。如果你的源机器非常老，用的是 IDE 盘，Windows XP 这类系统迁移后往往因为没有 LSI 驱动直接蓝屏。这种情况下建议在“编辑”里把控制器类型改为 IDE。需要注意，ESXi 6.5 之后 IDE 虚拟设备只支持最多 4 块盘，超过 4 个卷的场景就不要用 IDE 了。

网络适配器默认是 VMXNET3，性能确实好，但老系统不一定有网卡驱动。如果源机器是 Windows Server 2008 及更早版本，我建议先把网卡类型选成 E1000，等虚拟机装好 VMware Tools 之后再通过 vSphere Client 临时换回 VMXNET3。换网卡类型后系统会自动重新识别网络，不用重装系统。

内存和 CPU 也可以在迁移向导里直接指定。一种常见做法是先按源机器的配置填入，迁移完成后关机再调整到合理的规格。这里要注意，Windows 的激活机制对硬件配置敏感，CPU 核数和内存大小变动过大可能会导致系统激活失效，迁移前后尽量保持规格整体一致，至少短时间一致。

3.5 执行迁移：日志、进度与常见中断场景

所有配置完成后，向导最后一步是“摘要”，类似购物车确认页。检查一遍源、目标、数据卷和硬件配置，确认没问题就点“完成”。Converter 会把任务加入任务列表，开始在后台执行。

执行过程分几个阶段：连接源机器 — 创建目标虚拟机 — 获取源磁盘信息 — 复制数据卷 — 处理目标系统 — 移除 agent。数据复制阶段是耗时最长的，界面上会显示传输速度和百分比。

在这个阶段你会看到一个细节：如果选择了“同步更改”选项，Converter 在第一次复制完成后会做一次增量同步，抓取数据复制期间源机器上发生的变化，类似数据库的增量备份。这能大幅减少源机器停机窗口，但对网络稳定性要求更高。我的经验是，除非源机器是业务高峰期不允许中断，否则直接关闭同步更改，让迁移一次性完成，少一层风险。

任务执行过程中，如果数据复制在某个百分比反复回跳，说明源磁盘正在被大量写入，这时候可以先暂停业务系统的数据写入再重试。如果任务直接红叉，不要急着新建任务，先把任务日志导出来看一下。日志位置一般在 Converter Server 安装目录下的logs\vmware-converter-server-0.log，里面记录了每个阶段的详细输出。

4. 常见错误与排查技巧实录

4.1 “无法连接到源机器”或 agent 安装失败

这个报错是我被问得最多的问题。从排查顺序来看，先检查三件事。

第一是源机器的 Windows 远程管理是否正常。执行这句命令看远程 WMI 能不能通：

wmic /node:源机器IP /user:管理员账号 process list brief

如果 WMI 连接失败，Converter 一定无法读系统信息。此时可以在源机器上重启 Winmgmt 服务：

net stop winmgmt net start winmgmt

第二是防火墙。前面提过的 445、9089、9040 端口，还有默认的 RPC 动态端口（135）都需要放行。简单粗暴一点的做法是直接在源机器防火墙里允许“文件和打印机共享”，再把 Converter agent 的安装目录加入白名单。

第三是账号类型。使用本地管理员账号时，注意账号名称不能是“Administrator”之外的普通管理员。部分 Windows 系统对空密码账号默认禁止远程连接，这一点前面也提到过。如果确认账号没问题但仍然失败，可以先用远程桌面手动登录一次源机器，确保本地会话正常，再重试连接。

4.2 目标 ESXi 认证失败或无法创建虚拟机

连接 ESXi 时报“SOAP 错误”或者“登录失败”，最常见的原因是账号密码错误或者账号权限不足。很多人在 vCenter 环境里用了 vCenter 的 SSO 账号，却把连接地址填成 ESXi 主机的 IP，这样 SSO 账号在 ESXi 本地认证体系里是不存在的。解决办法有两种：连接地址填 vCenter 的 IP 并使用 SSO 账号；或者直接填写 root 账号连接 ESXi。

还有一种情况比较隐蔽：ESXi 启用了主动锁定模式，或者开启了 AD 域认证，但 AD 服务器暂时不可达。这种情况下用任何本地账号登录都会失败。登录 ESXi 命令行执行：

vim-cmd authsec disable

可以临时关闭认证锁定状态。注意这是临时措施，生产环境要谨慎使用，最好等 AD 恢复或者配置本地账号。

4.3 迁移后虚拟机蓝屏，报 INACCESSIBLE_BOOT_DEVICE

这是 P2V 迁移最经典的后续问题。蓝屏原因通常是磁盘控制器驱动不匹配，Windows 在启动阶段找不到磁盘。

解决方案有两种。第一种是在迁移向导里设置硬件时，根据源机器系统版本提前预判控制器类型。Windows Server 2012 及以上系统自带现代 LSI 驱动，通常用 LSI Logic SAS 就能直接启动。Windows Server 2003 / XP 这类老系统没有 SAS 驱动，必须把控制器改成 IDE，或者在迁移前给源机器手动注入 LSI 驱动。

第二种是迁移完成后如果已经蓝屏，我用的办法是 PE 工具修复。引导到 Windows PE，打开注册表编辑器挂载系统磁盘，在HKLM\SYSTEM\MountedDevices里手动给磁盘新增卷设备映射，同时修改HKLM\SYSTEM\CurrentControlSet\Control\CriticalDeviceDatabase，加入 LSI 控制器的驱动项。这个方法偏手工，属于应急路径，不建议没有注册表经验的朋友尝试。

更稳妥的操作是：在迁移之前，先下载好对应系统的 LSI 驱动，在源机器上手动安装一遍，让驱动进入系统驱动库之后再做 P2V。这样迁移后的系统天然带着 SAS 驱动，蓝屏概率会大幅下降。

4.4 网络失联：MAC 地址变化和静态 IP 冲突

迁移完成后虚拟机起来了，但发现网络不通，这种情况同样高频。原因往往不是 Converter 的问题，而是网卡类型变化导致 Windows 把网卡识别成全新硬件，原来配置的静态 IP 没被继承。

处理方法分两步。先进入虚拟机控制台，用网络适配器里的故障诊断，把网卡重新识别出来。如果系统版本比较老，需要手动在设备管理器里扫描硬件改动，然后给新网卡重新配置 IP。

然后是 MAC 地址问题。物理机的 MAC 无法被 Converter 完整保留，虚拟机生成的是新 MAC。如果你的网络有基于 IP/MAC 绑定的设置，需要把新虚拟机的 MAC 地址更新到交换机或 DHCP 绑定表里。在 vSphere Client 里，网络适配器的高级设置可以直接修改 MAC 地址，把它手动改成原物理机的 MAC 来避免绑定失效。

4.5 数据复制缓慢或卡在某个百分比

数据复制阶段卡住的情况，在我实际项目中遇到过三次。第一次源机器磁盘有坏道，复制到坏道区域时反复重试，速度掉到几十 KB/s。对策是在迁移前先用源机器的磁盘检查工具扫描一遍，或者用命令检查：

chkdsk C: /R

第二次是目标存储性能不足，ESXi 主机用的是机械盘且同时跑着多台生产虚拟机。这种情况可以降低源机器复制的并发线程数，间接减少目标存储的 I/O 压力。

第三次是 Converter Server 所在管理机的磁盘空间不足。Converter 默认会在本地创建临时文件保存源数据再上传到 ESXi，C 盘如果满了，任务会报“临时目录空间不足”错误。修改临时目录位置的方法是在安装目录下找到nvconv.ini，把[server]段里的TemporaryDirectory指向其他盘。

4.6 常见错误速查表

5. 迁移后的收尾优化与验证

5.1 移除 agent 并清理遗留服务

如果一切顺利，虚拟机已经能在 ESXi 上正常启动。第一步要检查源机器上的 Converter agent 是否已自动卸载。Converter 在迁移完成后默认会自动卸载 agent，但远程安装的 agent 有时会因为权限或者杀毒软件残留。检查方法是在虚拟机里看服务列表：

sc query vmware-converter-agent

发现服务还在，就停掉并删除：

sc stop vmware-converter-agent sc delete vmware-converter-agent

别急着把虚拟机关机，去对照一遍系统服务里面有没有被 Converter 创建的残留项，比如 VMware Converter 相关计划任务。

5.2 安装 VMware Tools：性能与稳定的基础

迁移完的虚拟机用的是半虚拟化驱动，但系统里不一定有原生工具包。不装 VMware Tools 的话，显示分辨率、时间同步、网络性能都会有问题，而且无法安全关机。在 vSphere Client 里选中虚拟机，菜单里找到“客户机操作系统”，选择“安装 VMware Tools”。系统会挂载一个 ISO，在虚拟机里打开光驱运行 setup。

注意版本匹配问题。ESXi 6.7 自带的 VMware Tools 版本对 Windows Server 2016 兼容性很好，但如果是老系统，比如 Windows Server 2008 R2，建议下载对应旧版 Tools 而不是强制用新版。新版本 Tools 在旧系统上容易在安装阶段报“Service 'VMMEMCTL' failed to start”。遇到这个问题时，在设备管理器里禁用“VMware 内存控制”设备后重装 Tools 能绕过。

装完 Tools 后重启虚拟机，就能正常调节分辨率，鼠标也不会锁死了。这一项强烈建议放进迁移后的标准操作流程。

5.3 清理磁盘快照与残余系统还原点

迁移过程中 Converter 可能自动创建了磁盘快照，或者源系统自带还原点和卷影副本。这些数据在虚拟机上属于多余占用，处理完才释放存储空间。在 vSphere Client 的虚拟机快照管理器里检查，有快照直接全部删除合并。Windows 内部则用磁盘清理把旧的系统还原点删掉：

vssadmin delete shadows /for=C: /all /quiet

这一步虽然不影响功能，但是迁移后磁盘空间往往是按存储成本计费的，多释放出来的空间就是省下的存储成本。

5.4 业务验证清单：别以为虚拟机起来就万事大吉

虚拟机正常启动只是第一步，后面还有更关键的业务验证。我给自己定的标准是因不同应用而异的清单，但几项通用检查一定会做：

• 数据库服务是否正常监听，客户端能否正常连接
• Web 服务是否响应，端口是否监听
• 文件共享的引用路径有没有因为盘符变化而失效
• 计划任务是否还在运行
• 杀毒软件和防火墙策略是否需要重新配置
• 时间同步是否正常，尤其涉及 Kerberos 认证的环境

我见过最隐蔽的问题是因为时间不同步导致域认证失败，系统起来后登录界面看着正常，但用户输密码永远等待。处理办法是在配置 VMware Tools 之前，将虚拟机的“客户机操作系统时间同步”选项打开，并手动执行一次：

w32tm /resync

如果源机器本身是域控制器，时间同步的配置更复杂，这里不展开，但一定要在验证清单里单独标记。

5.5 后续扩展：磁盘扩容、虚拟硬件升级与备份

迁移完成的虚拟机天然就拥有了虚拟化平台的弹性。如果你发现 C 盘空间不够了，不用像物理机那样拆机换盘。在 vSphere Client 里直接修改虚拟机硬盘大小，然后进入系统扩展分区：

diskpart list disk select disk 0 list volume select volume C extend

这样几分钟就能完成磁盘扩容。需要注意，如果 C 盘后面跟着一个恢复分区，扩展时可能提示空间不足，可以先删除恢复分区再扩展，或者在迁移前就把恢复分区处理掉。

虚拟硬件版本升级也是迁移布完一个值得做的步骤。如果 ESXi 版本支持虚拟机版本 15 以上，建议把虚拟机升级到对应版本，这样可以获得更现代的虚拟硬件特性，比如更大的虚拟磁盘容量、更优的 I/O 路径。升级之前，关掉虚拟机电源，并在 vSphere Client 里右键“兼容性”，选择适当的目标版本。

最后提醒一下备份策略。迁移完成后，立即为虚拟机创建一个快照或者做一次完整备份。P2V 本身就是一次大变更，备份的意义在于给你容错空间，后续调试出问题能快速回到迁移完成时的状态。等业务稳定运行一星期后，再删除这个基础备份，转入日常备份计划。

6. 经验杂谈与踩坑心得

从第一次用 Converter 迁移到现在，这个免费工具帮我处理了不下二十台物理机。它确实可靠，但也确实老旧，UI 界面停留在 Windows 7 时代的风格，部分按钮位置和多语言界面不够统一。但说实话，在不用额外花钱、不装复杂代理的前提下，它依然是中小企业做 P2V 迁移的第一选择。

我个人的习惯是，任何一次迁移都先做一次完整演练。找一台配置类似但不重要的物理机，走一遍迁移、启动、验证的完整闭环，记录下每个阶段耗时和报错信息。真正迁移生产系统时，照着演练笔记操作，心态稳很多，时间也花得少很多。这个习惯在多次紧急故障中帮了我大忙。

最后分享一个小技巧。Converter 任务日志文件vmware-converter-server-0.log里藏着的细节远超界面显示，很多界面报错原因其实在日志里写得明明白白。遇到莫名其妙的问题，别急着重试，花五分钟翻日志，往往会发现是某个服务依赖、端口占用或者空间不足的小问题，比反复撞运气效率高得多。迁移这件事，说难不难，说简单也不简单，关键就在把所有变量都提前控住，剩下的只是时间问题。