1、无论是vMotion还是Storage vMotion都需要专用的VMkernel网络来迁移虚拟机，所以需要在各ESXi主机上为vMotion配置专用的网络，并且考虑到性能的问题，最好为vMotion网络绑定专用的网卡。vMotion要求网络带宽至少为千兆，并且要求源主机和目标主机具有相同的网络配置，包括网络类型和网络标签都要一致。

2、检查服务器间的网络连接。 迁移依赖网络连接，因此源/目的服务器之间的任何连接问题都能轻易影响迁移活动。最直接的方法是ping源/目的服务器之间的网络连接。如果ping成功了，证明源、目的服务器之间的lan通讯正常。如果不成功，源、目的服务器上的网卡(nic)可能存在连接问题或不兼容性。 一个常见的兼容性问题是使用超长帧。例如，如果一个服务器的nic配置了支持超长帧，另外一个没有，那么这两个服务器不会正常通信，工作负载迁移不会成功，除非两个nic的配置完全相同。使用目标服务器的主机名ping时，会发生另一个常见的问题。如果主机名ping失败了，但是ip地址ping正常，说明主机名解析出问题了，解决这个问题会对解决连接问题有帮助。

3、如果某一集群使用了独立的DVS分布式虚机交换机，其集群中的虚拟机将不能迁移到其他集群。可以把集群中的物理主机加入到总的更大的vdc下的分布式虚拟交换机，才可以把该集群中的虚拟机迁移到其他集群。

4、习惯上，vmotion需要考虑主机和虚拟机的计算资源的平衡。检查目的服务器上的计算资源很重要，如果目的服务器上没有足够的计算资源，工作负载迁移也会失败。当目的服务器缺少足够的处理核心、内存空间、nic端口或者存储时，就不能储备新的工作负载。随着物理服务器数量下降和工作负载整合水平的提升，这已经变成越来越普遍的问题。 例如，如果目标服务器已经从从其他系统接受额外的工作负载失败，这时就会发生资源短缺。另外，如果目的服务器上已有的工作负载已经获得了额外的计算资源，以满足用户活动增加所引起的更的的资源需求，这种情况下，资源短缺也会发生。试着将工作负载迁移到其他有足够计算资源的系统(比如闲置或备用的服务器)，或者在有需求的服务器上执行工作负载平衡。

5、vmotion迁移如果不考虑网络的可用性，有时会导致将虚拟机放置或迁移到已经网络饱和的主机上。 如果应用碰巧对网络敏感，这可能会对虚机产生一些性能影响。

6、在进行vmotion迁移时，虚机内存过大的会迁移比较慢，因为内存动态的同步会耗费较多时间。

7、在进行vmotion迁移时，要注意硬件兼容性。检查服务器硬件的兼容性和设备相关性。 虚拟化的服务器专门用来将底层的硬件从上层的工作负载抽离——抽离让工作负载迁移变得可能——但是有小部分情况可能会导致源、目的服务器的硬件不兼容，导致迁移失败。 排错的第一步是评估服务器硬件和配置。举个简单的例子，源/目的服务器需要使用完全相同处理器来进行工作负载迁移。每个系统bios的处理或者i/o虚拟化设置稍微有所不同也会引起硬件问题。 当vm依赖目的服务器上不可用的硬件时，也会导致迁移失败。比如，像vmware esx/esxi等hypervisor允许vm连接到物理磁盘。如果vm依赖与源服务器连接的物理磁盘——而目的服务器上没有——迁移就出问题了。安全断开任何本地物理磁盘或者源服务器vm上的客户端设备，然后再重新进行迁移。

8、因虚机版本不同造成的迁移问题，注意高版本不能向低版本迁移。

9、分区表格式。这是一个很严重的问题，很多迁移工具不支持GPT格式的系统迁移，只支持MBR格式的系统迁移，在选择工具之前需要格外注意一下。

10、迁移之后磁盘不能成功挂载原系统的磁盘分区，系统不能成功启动。出现这种情况，一种很大的可能就是在原系统使用的是设备名称挂载的方式挂载的，在两个虚拟化环境中硬盘接口发生了变化，比如由原来的IDE接口变成了virtio接口，这样的话设备名称是会变的，设备名称会由原来的sda变为vda，这就需要修改fstab了（光盘引导，进入救急模式）。如果是通过UUID挂载的，一般来说不会出现这种问题。