前言

ZStack 从1.8版本开机就支持了vCenter的纳管，并不断丰富其运维、租户、运营等方面的能力。加之国产化浪潮的推动，从纳管到迁移几乎是一串顺其自然的需求，迁移中客户主要面临两个困难，一是部分业务连续不中断或者尽量降低中断时间，再则免费工具的复杂程度以及兼容性所存在的问题，导致客户不得不够买一些第三方的迁移服务。这就使得属于ZStack云原生的迁移服务模块, 在ZStack3.0版本中应运而生。

在ZStack接管VMware的基础上，迁移服务轻松帮助用户将vCenter上的云主机迁移至ZStack平台，过程全UI界面操作，IP级细粒度属性自定义，已支持主流Windows、Linux系统的云主机的迁移。

ZStack V2V介绍

ZStack中有一个高级模块叫迁移服务，可将不同平台的云主机系统及数据完整迁移至当前云平台。迁移服务除了可以将VMware的虚拟机迁移到ZStack，在3.6.0的版本中也支持将任何基于KVM的平台（源平台包括ZStack）迁移到ZStack。同时满足在线迁移、离线迁移、并发迁移、指定迁移网络、预修改云主机配置等多种特性。本文重点以VMware虚拟机迁移至ZStack展开。

场景设定

假定用户已部署一套vCenter环境和一套最新的ZStack私有云环境，并已将vCenter接管到ZStack私有云云平台。由于业务需要，现要将已接管的vCenter云主机迁移至当前的KVM云平台中。

V2V迁移需要指定目标集群内的物理机作为迁移服务器。本场景下，假定用户已提前准备好1台存储服务器，并将该存储服务器添加到目标集群内作为计算节点，用户将使用这台计算节点作为迁移服务器。

用户的源端和目标端信息如下：

具体实践流程如下：

1.添加迁移服务器

2.创建迁移任务

a) 创建V2V迁移任务的第一步，除了填写一些基本信息，需要指定源平台上待迁移的云主机。若此处选择多台源云主机，将批量创建相应的迁移任务，最多可以同时指定50台。

b) 第二步配置目标平台的资源，也就是ZStack端的配置。对于计算和存储资源可以根据当时的资源池情况给出参考数据。然后选择刚才添加的迁移服务器。最后还有一个“压缩模式”的选项，可以根据存储类型和带宽情况选择是否先压缩成qcow2的格式再传输，当然压缩本身也是需要占用整个迁移时间的。

c) 迁移任务的第三步，也是最复杂的一步。用户通常是希望整个业务不中断，或者中断时间尽量缩短的，因此目标平台上可能提前做好了相应的网络规划。ZStack给出了每个网卡的源vCenter网络与目标网络的对应关系，可以细粒度到每个IP和mac地址。如果对业务的私网地址没有严格要求，可以直接以网段的形式做出映射即可。

3. 确认提交后，4台vCenter云主机创建出4个独立的迁移任务，如图所示已成功迁移至当前KVM云平台。

4. 小结，整个过程使用下来比第三方的迁移工具的体验流畅很多，全UI操作的同时保留了云主机属性的自定义能力，但需要先接管的要求对于某些场景可能有所限制。

后记

在笔者来看，未来几年企业上多云是大的趋势，有趣的是大家对“混合云”的定义也越来越宽泛。随着不同云平台间迁移的需求愈发旺盛，各家云厂商原生的迁移工具也会逐渐丰富，对客户来说云的迁入成本会逐步降低。对云厂商来说，迁移技术的积累一方面可以转化为灾备能力，另一方面也可以补充自动化运维的场景。也许有一天客户真的会对“混合云”的弹性买单。