前言
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操作的同时保留了云主机属性的自定义能力，但需要先接管的要求对于某些场景可能有所限制。
后记
在笔者来看，未来几年企业上多云是大的趋势，有趣的是大家对“混合云”的定义也越来越宽泛。随着不同云平台间迁移的需求愈发旺盛，各家云厂商原生的迁移工具也会逐渐丰富，对客户来说云的迁入成本会逐步降低。对云厂商来说，迁移技术的积累一方面可以转化为灾备能力，另一方面也可以补充自动化运维的场景。也许有一天客户真的会对“混合云”的弹性买单。
免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。
