vSphere 下虚拟机迁移的多种方式

迁移场景

在不同场景下，用户对于迁移的需求并不相同，此处列举几个常见的场景：

硬件维护：这是最常见的一种迁移场景，虚拟化有个好处是可以抽象底层硬件，让上层业务 OS 和底层硬件松耦合，这种架构下当硬件故障或者需要维护时，可以直接把整个 VM “搬”到另一台主机上，整个过程 OS 不会有感知，也可以不停机，对于 IT 运维来说是个很实用的特性；
虚拟机位置变更：出于各种原因，需要对 VM 所在位置发生改动，比如将 VM 的存储从 DatastoreA 移动到 DatastoreB，或者将 VM 从 A 集群迁移到 B 集群；
数据中心搬迁：因业务需要或者扩容，需要将已有虚拟机迁移到新建的数据中心中；
环境升级：在虚拟化软硬件更替时，为了避免对已有业务的影响，或者方便回退，建立新的集群，将已有的虚拟机迁移到新的环境中来逐渐完成环境升级；
架构变更：因技术路线变化，可能需要使用新的 Infra 架构，此时可能会使用全新的硬件构建全新的架构，再讲已有虚拟机迁移到新环境中。

对于以上所有场景，迁移方式多种多样，实际应用时需要结合业务实时性需求以及其他限制条件，来选择最合适的迁移方式。

业务实时性需求

业务实时性需求决定了在迁移过程中业务能否停机，以及可以停机多久，这会直接决定大的技术路线是什么。

比如业务如果要求无停机，那必须使用热迁移，保证在迁移过程中业务始终可以对外提供服务。热迁移的方式对底层网络、软硬件版本等都会有一定要求，具体下个章节再详细介绍。

又如业务是多节点分布式部署，或者可以停机，那一般可以通过冷迁移的方式执行。冷迁移相比热迁移，对于底层架构的要求可能低一些。

限制条件

迁移网络

现在很多迁移都会通过以太网来执行，大的层面会存在两种限制条件：

连通性：源端和目标端的迁移网络需要打通，而在复杂的网络中不同区域之间通常会有防火墙，也需要放行相应的端口；
带宽：迁移带宽会决定迁移用时；热迁移对于带宽也会有一些最低要求。

业务网络

如果要尽可能地减少业务中断时间，需要在源和目标都预先准备好大二层网络，保证虚拟机无论在任何位置网络均可达。这时候 NSX 之类的大二层方案可能就比较重要，尤其是在多中心的情况下。

如果业务实时性不高，也可以不需要大二层网络，分别在源和目标配置两套一样，但不冲突的网络（比如源和目标的 VLAN ID 一致，网关 IP 一致，但是目标端网关处于 shutdown 状态），业务关机进行迁移，迁移完成后，再在源端 shutdown 网关，目标端开启网关。

OS 兼容性

通常迁移时也需要关注目标 ESXi 是否兼容操作系统，通常在 ESXi 上运行很老版本的操作系统不会有什么问题，但谨慎起见还是要遵照兼容性列表：

https://www.vmware.com/resources/compatibility/pdf/VMware_GOS_Compatibility_Guide.pdf

迁移时间

不同的迁移方式会决定迁移时间的不同

常见的迁移方式

接着，从技术角度看一下迁移方式。

冷迁移：虚拟机在迁移过程中需要关机或处于暂停状态，此时虚拟机无法对外提供服务。冷迁移有个好处是对硬件依赖度低，比如关机状态下
热迁移：虚拟机在开机状态下进行迁移，此时虚拟机可以对外正常服务
转换：转换通常是在 OS 层面通过 Agent 将整个操作系统及里面的数据都迁移到另一种架构中，比如裸金属迁移到 vSphere，或者 KVM 迁移到 vSphere 等。此处也可能有一些其它工具可以做到不同虚拟化的虚拟磁盘格式间的转换，但这种转换通常有一些限制和兼容性要求。

迁移类型：

题外话：关于容器迁移

现在容器在有些行业里比较火，早期经常会有一些文章来讲述容器和 VM 的对比，尤其是容器比 VM 轻量快捷，替换 VM 有很多优势之类的，这句话其实不完全正确，容器和 VM 的最终服务对象都是业务，所以以能跑业务为关注点，确实容器相比 VM 有一些优势，但从基础架构层看，两者还是有很大区别。

虚拟化：可以实现硬件抽象化，屏蔽底层硬件的差异，使得上层 OS 无需关心底层，包括兼容性、驱动、硬件变动这些。如果上层 OS 升级，通常不会对底层有什么特殊需求，而底层硬件或者虚拟化层的升级，通常也不会影响上层 OS。

容器：没有硬件抽象化，Host OS 来适配底层硬件，需要考虑兼容性、驱动等内容。如果在裸金属上运行容器，其实相当于把兼容性等东西从虚拟层又拿到了 OS 层，因此 OS 的重要性变得和以前虚拟层一样重要，而 OS 对于硬件的适配、商业支持、资源隔离性并不如虚拟化优秀。另外，Host OS 也用来跑容器，需要安装容器运行时，提供容器隔离、网络等功能，业务潜移默化的又与 Host OS 有了一定的依赖关系。这带来的潜在问题是牵一发动全身，比如 OS 升级，上层需要考虑是否兼容已有的容器运行时，下层要考虑硬件兼容性、驱动等，即使 Kubernetes 环境下支持节点滚动升级，但这并不能降低升级的复杂性和升级时间。

虚拟化：可迁移性强，虚拟化下，应用和数据通常固化在一起，这种架构可以很轻松实现应用到哪里，数据也到哪里，使用已有的 vMotion/Replication 技术就可以快速实现。

容器：可迁移性弱，容器下二进制应用程序和其数据是分离的，依靠 K8s 等平台进行编排调度，如果因为某些原因要做容器+数据的迁移，会发现很难，要去解决数据 PV 的迁移、PVC 以及容器的映射关系等一系列问题。最终发现容器迁移最简单的实现方式只有备份恢复，而这些手段并不会像曾经的虚拟化那样简单直接。另外容器环境下也可以通过应用层面来进行数据转移，但这又得应用配合，并不是一种经济以及通用的迁移方式。

这里谈这些，并不是说容器有多不好，而是想借此提醒下，在部署一些有持久性数据的服务时，需要考虑下未来的可运维性，这就包括升级、迁移之类的，从长久来去考虑平台建设。

关于 EVC

EVC 产生的原因

HCX

ESXi 5.1 之后支持跨存储迁移