如图，VMware做P2V迁移时，出现了常规系统错误 ssl exception

无论你多么小心地为迁移做准备工作，迁移有时还是会失败。失败就可能发生在迁移过程中的不同阶段；具体哪个阶段是基于任务栏百分比估计值出来的。建立目标虚拟机(VM)(0%-5%)准备克隆磁盘(5%-6%)克隆过程(6%-95%)克隆工作结束以后(95%-97%)定制或重新配置(97%-99%)安装工具或启动(99%-100%)虽然在任何迁移阶段都可能会失败，但如果要是失败的话，它通常会在97%处失败。在迁移过程中，Converter创建了一个详细的日志文件，此文件会包含确切的错误信息以及有关转换失败的原因。此日志文件被存放在你正在被迁移的服务器上，此服务器运行着Converter代理，通常日志被命名为vmware-converter-0log，存放位置在C:\Windows\temp\vmware-temp目录下。打开该日志文件和滚动到文件底部，寻找失败信息。一旦这次迁移过程失败，Converter会将它自动创建的虚拟机删除。确定哪个阶段会失败的一个线索是进度条如何快速地达到了97%。如果它迅速地跳跃到97%并且失败，这通常表明问题出在以下几个方面：网络端口、DNS解析或是需要的Windows服务没有运行。下面有几个步骤可以帮你试图解决这类问题。如果你使用主机名称来选择你的VC/ESX目的服务器，请确保你可以在你的源服务器上解析到这些主机名称的IP地址。在源服务器上，确保Workstation、Server，TCP/IPNetBIOSHelper和VMwareConverterservices这几个服务正在运行。在WindowsXP和2003服务器上，确保VolumeShadowCopyservice服务不是禁用状态，在默认情况下，应该是设置为手动状态。这项服务并不需要在转换过程中一直处于运行状态。使用Telnet命令，看看你是否可以连接到在VC或ESX服务器上所需要的端口。从源服务器“Telnet902”。你应该可以从VC/ESX服务器得到回应，在端口443上也要这样做。尝试重新启动源服务器，对于WindowsNT和2000服务器来说，这是一个必须的要求。如果需要很长的一段时间才能达到97%，那么通常是在数据克隆或克隆后期过程中克隆失败。造成这种失败的一些可能的原因是，在服务器之间网络连接丢失了，网络错误和源服务器磁盘问题。下面有几个步骤可以帮你试图解决这类问题。验证网络速度/双工设置，你的源服务器的网卡和被连接的物理交换机的端口是否符合。如果你启用 *** 作系统镜像，那么删除这个镜像。清理你的Bootini文件，并确保它是正确的。确保你使用的是最新版本的Converter。如果源服务器有动态磁盘旧版转换程序就会失败。在源服务器上运行chkdsk，以验证文件系统的完整性。确保在源服务器的系统盘上你有至少200MB可用磁盘。如果你的源服务器已有超过两个串口（COM）的端口，打开注册表，并寻找到HKLM\HARDWARE\DEVICEMAP\SERIALCOM子键，移除在串口端口2以上的任何端口。在做这个之前，你可以导出此键值，如果需要的话，转换完成后就可以重新导入。最后，如果你的转换成功完成，但你的服务器无法启动（或者出现蓝屏），你可以尝试使用以下的步骤来进行修复。在新创建的虚拟机上编辑Bootini，以确保磁盘的顺序是正确的。有时开机磁盘将不会被列为第一分区。要做到这一点，只需使用一个可用的虚拟机作为工作助手，将迁移后的磁盘以增加一个虚拟硬盘的方式添加到此台虚拟机上。这样就可以浏览到新创建的磁盘文件内容。然后，你就可以浏览该磁盘和编辑Bootini文件。完成后，从这台虚拟机删除此虚拟磁盘。另外，你也可以尝试再次运行Converter并选择“配置机器”，选择你新创建的虚拟机。通过向导程序，（当完成时）尝试再次启动它。对于虚拟磁盘（BusLogic或LSILogic）来说，确认你使用的是合适的SCSI控制器。在安全模式下启动虚拟机，看看是否特定的服务器硬件或驱动程序已经被载入。加强新虚拟机的服务器性能当你的转换完成后，你应该做以下几个步骤，对你的新虚拟机进行清理，以便它有更好的性能。编辑虚拟机的硬件。移除所有不必要的硬件，包括软盘驱动器和串行，并行和USB端口。你应该分配给VM的内存和它需求的一样多。如果可以就尽量减少它。当使用一个vCPU时，大多数的虚拟机会运行地更好，所以如果ESX主机服务器是一个SMP（对称多处理）的物理服务器，那么应该考虑减少虚拟CPU的数量。启动VM，等待几分钟，让它发现所有的新硬件，然后重新启动它。检查服务器的HAL，如果它来自一个多CPU的物理服务器，但现在只有一个单一虚拟CPU的虚拟机，那么你需要打开设备管理器并编辑CPU（计算机）。选择更新驱动程序，不要选择通过WindowsUpdate来更新，而是选择从列表中安装，选择Don'tSearch，并选择ACPIUniprocessor取代ACPIMultiprocessor驱动。移除任何硬件的特定应用程序和驱动。最后，我要强调：删除所有目前不使用的硬件驱动。有些硬件设备已从系统中删除，但相应的驱动还没有被卸载，这是迁移后的遗留问题。那些不再是系统中存在的物理硬件的驱动程序，但Windows对待它们，就像它们存在一样，并将系统资源分配给它们。并且当你试图给新的网络适配器配置的IP地址与源服务器上的地址相同的时候，它们也会导致冲突。这个问题的原因是，旧NIC仍然存在，这个IP地址被不存在的硬件占用着。迁移后会有大量的不存在的硬件设备的驱动被保留着。要删除所有的只需打开一个命令提示符CMD并键入SETDEVMGR_SHOW_NONPRESENT_DEVICES=1。然后在同样的命令窗口里输入Devmgmtmsc，然后，当设备管理器窗口打开的时候，选择显示隐藏的设备。当你每个硬件类，你会看到大量的不存在的硬件的驱动，它们所显示出的图标为灰色。右键单击并选择卸载。当你删除它们后应马上重新启动。总结使用VMwareConverter的这一系列文章。希望文章中的这些信息，将帮助你完成物理服务器到虚拟服务器的转换。转载，仅供参考，祝你愉快，。

1、首先输入邮件服务器地址。这里使用网易邮箱为例进行示范，其他的邮箱服务都是类似的。

2、进入页面，点击右上角的“帮助”的链接，跳转到帮助界面。

3、搜索框输入关键字。可以在搜索框输入关键字：比如smtp关键字进行搜索。

4、查看查询结果，根据查询结果，找到需要查看的内容，比如这次查看smtp协议相关的信息，可以点击smtp相关的连接。

5、进入smtp说明界面，通过帮助文档可以看到我们需要的协议地址以及端口号信息。

6、第二种方式：通过官网提供的菜单，定位查询到服务地址及端口

7、通过菜单项快速定位到需要查看的系统内容。这就是163服务器的地址已经端口号。

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

---