如何解决VMware Converter P2V迁移失败问题

如何解决VMwareConverterP2V迁移；在你使用VMwareConverter将物理机迁；这一系列的第一部分中，我们已经谈论了准备步骤，以；无论你多么小心地为迁移做准备工作，迁移有时还是会；1.建立目标虚拟机(VM)(0%-5%)；2.准备克隆磁盘(5%-6%)；3.克隆过程(6%-95%)；4.克隆工作结束以后(95%-97%)；5.定制或重新配

如何解决VMware Converter P2V迁移失败问题？

在你使用VMware Converter将物理机迁移到虚拟机以后，下一步是什么呢？如果迁移失败该怎么办？

这一系列的第一部分中，我们已经谈论了准备步骤，以确保迁移成功，还有操作迁移向导的过程。在这一系列的第二篇文章中，我们将继续讨论一些在迁移以后的工作，并给出故障排除的方法和解决失败迁移的思路。

无论你多么小心地为迁移做准备工作，迁移有时还是会失败。失败就可能发生在迁移过程中的不同阶段；具体哪个阶段是基于任务栏百分比估计值出来的。

1. 建立目标虚拟机(VM) (0%-5%)

2. 准备克隆磁盘(5%-6%)

3. 克隆过程(6%-95%)

4. 克隆工作结束以后(95%-97%)

5. 定制或重新配置(97%-99%)

6. 安装工具或启动(99%-100%)

虽然在任何迁移阶段都可能会失败，但如果要是失败的话，它通常会在97%处失败。在迁移过程中，Converter创建了一个详细的日志文件，此文件会包含确切的错误信息以及有关转换失败的原因。此日志文件被存放在你正在被迁移的服务器上，此服务器运行着Converter代理，通常日志被命名为vmware-converter-0.log，存放位置在

C:\Windows\temp\vmware-temp目录下。打开该日志文件和滚动到文件底部，寻找失败信息。一旦这次迁移过程失败，Converter会将它自动创建的虚拟机删除。

确定哪个阶段会失败的一个线索是进度条如何快速地达到了97%。如果它迅速地跳跃到97%并且失败，这通常表明问题出在以下几个方面：网络端口、DNS解析或是需要的Windows服务没有运行。下面有几个步骤可以帮你试图解决这类问题。

1. 如果你使用主机名称来选择你的VC/ESX目的服务器，请确保你可以在

你的源服务器上解析到这些主机名称的IP地址。还有尝试使用服务器的

FQDN（全称域名），而不是短域名。

2. 在源服务器上，确保Workstation、Server，TCP/IP NetBIOS Helper和

VMware Converter services这几个服务正在运行。在Windows XP和2003

服务器上，确保Volume Shadow Copy service服务不是禁用状态，在默

认情况下，应该是设置为手动状态。这项服务并不需要在转换过程中一

直处于运行状态。

3. 使用Telnet命令，看看你是否可以连接到在VC或ESX服务器上所需要

的端口。从源服务器“Telnet 902”。你应该可以从VC / ESX服务器得到

回应，在端口443上也要这样做。

4. 尝试重新启动源服务器，对于Windows NT和2000服务器来说，这是一

个必须的要求。

如果需要很长的一段时间才能达到97%，那么通常是在数据克隆或克隆后期过程中克隆失败。造成这种失败的一些可能的原因是，在服务器之间网络连接丢失了，网络错误和源服务器磁盘问题。下面有几个步骤可以帮你试图解决这类问题。

1. 验证网络速度/双工设置，你的源服务器的网卡和被连接的物理交换机的

端口是否符合。

2. 如果你启用操作系统镜像，那么删除这个镜像。

3. 清理你的Boot.ini文件，并确保它是正确的。

4. 确保你使用的是最新版本的Converter。如果源服务器有动态磁盘旧版转

换程序就会失败。

5. 在源服务器上运行chkdsk，以验证文件系统的完整性。

6. 确保在源服务器的系统盘上你有至少200 MB可用磁盘。

7. 如果你的源服务器已有超过两个串口（ COM ）的端口，打开注册表，

并寻找到HKLM\HARDWARE\DEVICEMAP\SERIALCOM子键，移除

在串口端口2以上的任何端口。在做这个之前，你可以导出此键值，如

果需要的话，转换完成后就可以重新导入。

最后，如果你的转换成功完成，但你的服务器无法启动（或者出现蓝屏），你可以尝试使用以下的步骤来进行修复。

1. 在新创建的虚拟机上编辑Boot.ini，以确保磁盘的顺序是正确的。有时

开机磁盘将不会被列为第一分区。要做到这一点，只需使用一个可用的

虚拟机作为工作助手，将迁移后的磁盘以增加一个虚拟硬盘的方式添加

到此台虚拟机上。这样就可以浏览到新创建的磁盘文件内容。然后，你

就可以浏览该磁盘和编辑Boot.ini文件。完成后，从这台虚拟机删除此

虚拟磁盘。另外，你也可以尝试再次运行Converter并选择“配置机器”，

选择你新创建的虚拟机。通过向导程序，（当完成时）尝试再次启动它。

2. 对于虚拟磁盘（ BusLogic或LSI Logic）来说，确认你使用的是合适的

SCSI控制器。

3. 在安全模式下启动虚拟机，看看是否特定的服务器硬件或驱动程序已经

被载入。

加强新虚拟机的服务器性能

当你的转换完成后，你应该做以下几个步骤，对你的新虚拟机进行清理，以便它有更好的性能。

1. 编辑虚拟机的硬件。移除所有不必要的硬件，包括软盘驱动器和串行，

并行和USB端口。你应该分配给VM的内存和它需求的一样多。如果

可以就尽量减少它。当使用一个vCPU时，大多数的虚拟机会运行地更

好，所以如果ESX主机服务器是一个SMP（对称多处理）的物理服务

器，那么应该考虑减少虚拟CPU的数量。

2. 启动VM，等待几分钟，让它发现所有的新硬件，然后重新启动它。

3. 检查服务器的HAL ，如果它来自一个多CPU的物理服务器，但现在只

有一个单一虚拟CPU的虚拟机，那么你需要打开设备管理器并编辑CPU

（计算机）。选择更新驱动程序，不要选择通过Windows Update来更新，

而是选择从列表中安装，选择Dont Search，并选择ACPI Uniprocessor

取代ACPI Multiprocessor驱动。

4. 移除任何硬件的特定应用程序和驱动。

5. 最后，我要强调：删除所有目前不使用的硬件驱动。有些硬件设备已从

系统中删除，但相应的驱动还没有被卸载，这是迁移后的遗留问题。那

些不再是系统中存在的物理硬件的驱动程序，但Windows对待它们，就

像它们存在一样，并将系统资源分配给它们。并且当你试图给新的网络

适配器配置的IP地址与源服务器上的地址相同的时候，它们也会导致冲

突。

这个问题的原因是，旧NIC仍然存在，这个IP地址被不存在的硬件占用着。迁移后会有大量的不存在的硬件设备的驱动被保留着。要删除所有的只需打开一个命令提示符CMD并键入SET DEVMGR_SHOW_NONPRESENT_DEVICES=1。然后在同样的命令窗口里输入Devmgmt.msc ，然后，当设备管理器窗口打开的时候，选择显示隐藏的设备。当你展开每个硬件类，你会看到大量的不存在的硬件的驱动，它们所显示出的图标为灰色。右键单击并选择卸载。当你删除它们后应马上重新启动。

总结使用VMware Converter的这一系列文章。希望文章中的这些信息，将帮助你完成物理服务器到虚拟服务器的转换。

要点一、检查迁移设置或者重新连接主机服务器 在服务器之间进行vm迁移首先要求两个服务器启用迁移功能。例如，使用vmware esx或者esxi的两个服务器必须启用vmotion。如果是hyper-v服务器进行vm迁移，一定要确定两台服务器的动态迁移功能可用。vmware esx或esxi服务器上，在配置选项卡为特定的vsphere客户端启用vmotion，所以it管理员必须使用与每个hypervisor匹配的文档并在每个服务器上启用迁移功能。 在某些情况下，hypervisor的软件问题会导致迁移失败，这时需要在其中(或者两个)受影响的服务器上不断地切换迁移设置。例如，这个问题在vmware esx/esxi 4.0升级到update 2过程中会发生，技术人员不得不不断切换迁移设置。启用设置在每个主机的vsphere配置选项卡上。在esx/esxi 4.0 update 2或之后版本上就可以解决这个问题了。要点二、检查服务器硬件的兼容性和设备相关性 虚拟化的服务器专门用来将底层的硬件从上层的工作负载抽离——抽离让工作负载迁移变得可能——但是有小部分情况可能会导致源、目的服务器的硬件不兼容，导致迁移失败。 排错的第一步是评估服务器硬件和配置。举个简单的例子，源/目的服务器需要使用完全相同处理器来进行工作负载迁移。每个系统bios的处理或者i/o虚拟化设置稍微有所不同也会引起硬件问题。 当vm依赖目的服务器上不可用的硬件时，也会导致迁移失败。比如，像vmware esx/esxi等hypervisor允许vm连接到物理磁盘。如果vm依赖与源服务器连接的物理磁盘——而目的服务器上没有——迁移就出问题了。安全断开任何本地物理磁盘或者源服务器vm上的客户端设备，然后再重新进行迁移。要点三、检查服务器间的网络连接 迁移依赖网络连接，因此源/目的服务器之间的任何连接问题都能轻易影响迁移活动。最直接的方法是ping源/目的服务器之间的网络连接。例如，vmware的vmkping可以在源服务器上使用命令shell ping 目的服务器。进入到主机名称或者目的服务器的ip地址，查看成功的ping反馈，如：vmkping 192.168.1.1 还可以通过windows命令提示或者linux命令行使用标准的ping命令执行该过程。如果ping成功了，证明源、目的服务器之间的lan通讯正常。如果不成功，源、目的服务器上的网卡(nic)可能存在不兼容性。 一个常见的兼容性问题是使用超长帧。例如，如果一个服务器的nic配置了支持超长帧，另外一个没有，那么这两个服务器不会正常通信，工作负载迁移不会成功，除非两个nic的配置完全相同。使用目标服务器的主机名ping时，会发生另一个常见的问题。如果主机名ping失败了，但是ip地址ping正常，说明主机名解析出问题了，解决这个问题会对解决连接问题有帮助。 要点四、检查目的服务器上的计算资源 如果目的服务器上没有足够的计算资源，工作负载迁移也会失败。当目的服务器缺少足够的处理核心、内存空间、nic端口或者存储时，就不能储备新的工作负载。随着物理服务器数量下降和工作负载整合水平的提升，这已经变成越来越普遍的问题。 例如，如果目标服务器已经从从其他系统接受额外的工作负载失败，这时就会发生资源短缺。另外，如果目的服务器上已有的工作负载已经获得了额外的计算资源，以满足用户活动增加所引起的更的的资源需求，这种情况下，资源短缺也会发生。试着将工作负载迁移到其他有足够计算资源的系统(比如闲置或备用的服务器)，或者在有需求的服务器上执行工作负载平衡。

---