我一直认为vMotion是VMware公司最伟大的发明，没有之一。我记得VMware的一位工程师一篇文章，说是由创始人最早在2002年冬季做了演示，当时成功迁移了一台windows 98；我是在2009年底有幸，用32位CPU的两台IBM X235服务器实现这个功能，当时esx的版本是32位的3.5，现在用的esxi还没有被发明，演示的时候我和客户都被vMotion震撼了，从此我世界中应用和硬件不再紧耦合，应用可以在硬件间流动。

        最近遇到的3个项目都牵扯大批虚拟机迁移，迁移的虚拟机数量从数十台到几百台，其中一个大型医院，将其主要业务从旧院区迁移到新院区，客户的环境经过多年的建设，比较复杂，vSphere的版本从6.5到7.0都有，服务器的CPU从Bradwell,Skylake,Cascade lake都有，环境中有vSAN，第三方超融合HPE Simplivity, 也有传统FC存储，经过大家的努力，最终还是用最小的停机时间，完成了迁移，我想将这些经验和大家分享。

        这次分享不是讨论vMotion的一些基本要求，比如配置vmkernel网卡，需要能ping通；或者虚拟机绑了个数据存储的光盘，这些基本要求，是说一些架构方面的问题。

        再说一个插曲，我第一次到客户现场时，客户和我说的要求是去安装Replication，因为是其的一个集成商给他的建议，用Replicaiton将业务从旧院区迁移到新院区，大概当时集成商觉得两边隶属不同vCenter，所以只能用这种方法，当我了解清楚了客户最终目的，客户在两个院区间已经有万兆的网络连接后，我劝说客户改为用vMotion的办法，这个对比如下：

 最能打动客户就是这个停机，近百个业务，如果需要停机，需要通知有关部门，安排停机时间，将是个头痛的大问题。

        那么出现了些什么问题，又是如何解决的呢，下面我列出来
1.两个独立的vCenter，互不隶属
好比有A,B两个环境,我们要将A环境的业务迁移到B环境，可以将环境A中某台esxi主机，简称为跳板机，先将要迁移的业务，迁移到跳板机上，再将跳板机从vCenter A中断开，让vCenter B进行接管，这时要迁移的业务已经在环境B中，只要迁移到B环境的其主机和上，就完成了迁移。

2.从高版本的分布式交换机到低版本的分布式交换机，或者要从分布式交换机到标准交换机
这种情况，有个先决条件，就是原来的网络设计中必须是冗余的，解决的思路，都是先拆开原来交换机上一个物理网卡，用这种网卡创建一个临时的标准交换机，创建业务用的标准交换机port group, 手工将业务改成用这个标准交换机port group，这样就可以成功迁移了。

3.从高版本的CPU到低版本的CPU
这种是本项目中唯一遇到的需要停业务的情形，具体操作，类似于1.中情形，临时将一个跳板机独立出来，带着需要迁移的业务，临时做个跳板集群，将跳板机放到这个集群下，选择合适时间停业务，启动合适版本的EVC，再启动业务，就可以成功进行迁移了。

4.迁移巨大存储的虚拟机
这次迁移过程中耽误时间最长的是一个磁盘有11TB的虚拟机，花了两周时间尝试了6次才最终成功，出现了多次类似这样的错误。

Connection closed by remote host, possibly due to timeout。vMotion migration [-1062722765:6030828150563210389] timed out while waiting for disk 0's queue count to drop below the maximum limit of 32768 blocks. This could indicate either network or storage problems preventing proper block transfer. vMotion migration [-1062722765:6030828150563210389] timed out while waiting for disk 0's queue count to drop below the maximum limit of 32768 blocks. This could indicate either network or storage problems preventing proper block transfer. vMotion migration [-1062722765:6030828150563210389] timed out while waiting for disk 0's queue count to drop below the maximum limit of 32768 blocks. This could indicate either network or storage problems preventing proper block transfer. vMotion migration [-1062722765:6030828150563210389] timed out while waiting for disk 0's queue count to drop below the maximum limit of 32768 blocks. This could indicate either network or storage problems preventing proper block transfer.

        这种多半是因为迁移这样巨大的虚拟机，需要网络的稳定，后来将网络改成在一个网段，不经过路由，才成功。

        期间看日志，看得头昏眼花，做了多种尝试，包括升级了esxi，甚至升级了vCenter, 最后看，问题还是网络质量，所以迁移这种巨大的虚拟机，一定要准备好高速可靠的网络，网络上的扰动，就可以轻易将费时费力的迁移夭折。

        类似的迁移我还记得是帮助一个学校客户从5.5的环境迁移到7.0，是将客户5.5环境中的vCenter升级到6.5，其中一台 esxi做跳板机，也升级到6.5，就成功实现了vMotion，这也算是个经验，大家可以借鉴。

        另外两个客户都是我设计，部署和维护的，所以维持了一致的标准，所以迁移只是时间的问题，无需任何调整，几乎是百分之百成功，所以vMotion也是设计中的一个重要组成，好的vMotion是设计出来的。

        不停机是vMotion最大的魅力，这是任何一个管理员难以拒绝的诱惑；在很多环境中，你可能面对不同vCenter,  不同版本交换机，不同虚拟机硬件版本，不同版本的CPU,乍一看似乎无法实现，但其实只要做些分析，进行些调整，就可以成功vMotion，这是迁移首先的方法！