从虚拟化平台迁移到混合云解决方案：实战经验

许多公司正在从传统的虚拟化平台过渡到混合云解决方案。最近，一群红帽工程师完成了从红帽虚拟化到红帽 OpenShift 的大规模迁移，过程中用到了虚拟化迁移工具包，这是一款用于将工作负载迁移到 OpenShift 的高级工具。

十多年来，我们的红帽虚拟化环境成功运行了数百个虚拟机（VM），其中一些供工程师用于开发和测试目的，另一些则用于生产工作负载。然而，随着红帽虚拟化生命周期的临近，我们决定是时候将虚拟机迁移到 OpenShift 了。

考虑到在红帽虚拟化中运行的虚拟机的性质，以及我们希望尽量减少对最终用户的干扰，我们选择使用 OpenShift 虚拟化，继续在 OpenShift 上的虚拟机内运行工作负载。为实现这一目标，迁移中使用了虚拟化迁移工具包 2.4，这是当时最新的版本，具有增强的迁移功能。

从红帽虚拟化迁移到 OpenShift 的整个过程中，我们面临诸多挑战，包括我们自己和用户所经历的各种挑战。本文的其余部分将介绍我们是如何解决这些问题的，并提供我们从经验中获得的其他见解。

准备和规划

周密的规划对于成功迁移至关重要。当我们开始规划迁移时，我们意识到面临着几个挑战。

首先，我们必须确保目标 OpenShift 集群具有足够的资源来处理迁移的工作负载。为此，我们先要确定最近未在红帽虚拟化中使用的虚拟机，以及所有者要求不要迁移到新 OpenShift 环境的虚拟机。这些虚拟机都未包含在迁移中。然后，我们要确保 OpenShift 中有足够的存储空间用于计划迁移的虚拟机磁盘。我们还要确保有足够的 IP 地址分配给 OpenShift 中目标 VLAN 中计划迁移的虚拟机。

其次，我们意识到需要在红帽虚拟化中使用的置备模式和 OpenShift 虚拟化环境中使用的置备模式之间架起桥梁。在红帽虚拟化中，由管理员为用户分配新的虚拟机。而在 OpenShift 虚拟化中，由管理员将用户分配到项目，用户可以自行在项目中创建虚拟机。

再者，在虚拟化迁移工具包中，来源提供程序和目标提供程序都使用用户凭据进行设置。这样，用户可以定义来源提供程序（从中迁移用户有权访问的虚拟机）和目标提供程序（代表用户在其上创建虚拟机）。在我们的迁移中，我们倾向于一次迁移所有虚拟机，而不是要求每个用户迁移自己的虚拟机。因此，我们必须让在两个平台上都具有管理员特权的用户操作，允许他们访问红帽虚拟化中的所有虚拟机，并在 OpenShift 中的所有项目中创建虚拟机。

我们发现，要了解最近使用过的虚拟机（在我们的情况中为过去一年）及其磁盘大小以确定目标 OpenShift 集群是否具有足够的存储容量，并不是一项简单的任务。此外，为了让红帽虚拟化中虚拟机的所有者在 OpenShift 中创建对应的项目，以桥接不同的置备模式，也需要额外的工作。我们通过实施 Python 脚本解决了这些挑战。

第一组脚本使用 oVirt SDK 从红帽虚拟化收集数据。根据这些数据，我们确定了最近一次使用虚拟机的时间，并过滤掉了过去一年未使用的虚拟机。在获得要迁移的虚拟机的最终列表后，我们收集了有关其磁盘大小和所有者的详细信息。我们从红帽虚拟化获得的数据显示，OpenShift 集群中没有足够的存储空间来存储要迁移的虚拟机数据。为解决这个问题，我们通过添加新的存储类来增加 OpenShift 集群上的存储。

第二组脚本使用 Kubernetes API 在 OpenShift 集群上准备项目。利用从第一组脚本中获得的数据，我们确定了每个要迁移的虚拟机的所有者。对于每一组所有者，我们在 OpenShift 集群中创建了一个项目，并通过授予具有管理员权限的 ClusterRole，将项目分配给这些所有者。

为说明这一点，我们以一个名为 shared_vm 的虚拟机为例，该虚拟机的所有者是两个红帽虚拟化用户（Alice 和 Bob）。在 OpenShift 中，我们创建一个名为 alice-bob-ns 的项目，Alice 和 Bob 都拥有该项目的权限。然后，我们将虚拟机 shared_vm 迁移到 alice_bob_ns 项目。红帽虚拟化中由 Alice 和 Bob 所有的其他虚拟机也可以迁移到同一项目 alice_bob_ns 中。可以将 Alice 和 Bob 分配到使用了红帽虚拟化中的虚拟机的其他项目，这些虚拟机由他们单独所有或与其他用户共同所有。这种方法使我们能够解决红帽虚拟化和 OpenShift 环境中的不同置备模式问题。

解决了这个问题后，我们开始迁移虚拟机。

执行

迁移本身由几个步骤组成：

1. 在我们要迁移到的 OpenShift 集群上，部署虚拟化迁移工具包。虚拟化迁移工具包可以将虚拟机迁移到工具包所在的 OpenShift 集群，或者迁移到添加为目标提供程序的远程 OpenShift 集群。在我们的迁移中，所有虚拟机都迁移到单个 OpenShift 集群，因此我们在该集群上安装了虚拟化迁移工具包 Operator。
2. 在 OpenShift Web 控制台中，我们使用管理员用户通过以下方式为迁移配置 OpenShift 集群：
   1. 创建用于此次迁移的管理项目。
   2. 在管理项目中，创建红帽虚拟化来源提供程序、本地 OpenShift 集群（作为目标提供程序）以及存储和网络映射 。
3. 由于需要大量迁移计划才能迁移到目标项目，因此我们使用以管理员特权运行的脚本来自动创建和执行这些计划。这些脚本执行了以下操作：
   1. 为每个目标项目创建冷迁移计划。我们之所以选择冷迁移，是因为我们不关心虚拟机的停机时间，而且冷迁移通常比热迁移更快。
   2. 创建逐个迁移 计划，以触发各个迁移计划。

大多数虚拟机迁移计划都成功完成，但我们在虚拟机迁移过程中遇到了两个有趣的挑战。

首先，在等待第一次虚拟机迁移完成时，我们注意到迁移用时比预期要长。这是同时执行大量迁移计划的结果。

在虚拟化迁移工具包中，我们可以限制作为迁移计划一部分并行执行的虚拟机迁移数量，但无法限制在不同迁移计划中执行的虚拟机迁移数量。因此，由于同时运行许多迁移计划，我们耗尽了网络带宽，导致虚拟机迁移速度变慢。

在我们的迁移中，完成所有迁移计划所花费的时间比每个迁移的虚拟机的停机时间更重要，而且迁移的总时间不受此选择的影响。但是，当迁移的总时间受到网络带宽耗尽的影响时（虚拟机迁移超时或每个虚拟机的停机时间需要最小化时），可能需要逐步实施迁移计划或执行热迁移。

其次，120 台虚拟机中有 3 台迁移失败。我们对这些失败的迁移进行调查后发现，失败原因是我们的代码库中存在错误。我们快速修复了这个错误，并使用修复版本的虚拟化迁移工具包成功迁移了所有虚拟机。虚拟化迁移工具包 2.5 中包含对此问题的修复。

通过这些调整，我们成功将所有虚拟机迁移到 OpenShift。

在 OpenShift 上验证虚拟机

使用虚拟化迁移工具包成功完成所有迁移后，我们对 OpenShift 虚拟化上随机选择的多个虚拟机执行了完整性检查，每个被选到的虚拟机都成功通过了检查。然后，我们等待虚拟机所有者提供更多反馈。总体而言，用户对 OpenShift 虚拟化中迁移的虚拟机给予了积极反馈，但也报告了一些问题。

其中一个问题涉及一些虚拟机无法启动，显示“未找到操作系统”消息。我们进行了调查，发现只有具有多个磁盘的虚拟机才会出现这种情况，并且只有在选择了错误的磁盘进行启动时才会出现这种情况。我们通过手动修改虚拟机的启动顺序解决了这个问题，确保虚拟机从可启动磁盘启动。此问题已在虚拟化迁移工具包 2.5 中正确修复。

此外，用户还报告了一些服务中断情况。在迁移过程中，由于基础架构限制，虚拟机更改了 VLAN，并且这些虚拟机中的一些工作负载和服务在启动时无法访问。这是因为 DNS 记录在新的 VLAN 上配置了不同的完全限定域名（FQDN）和 IP 地址。此问题已通过指示用户将工作负载和外部客户端调整为新的 FQDN 设置得到解决。

经验与心得

从传统数据中心过渡到混合云解决方案并非易事。有多种方法可供选择，并由不同的工具提供支持，用户可以根据需求选择。在本文中，我们介绍了红帽内部将虚拟机从红帽虚拟化迁移到 OpenShift 的过程。

这种迁移需要仔细、全面的规划，并与企业中的所有利益相关者进行明确的沟通。虽然虚拟化迁移工具包提供了促进迁移到 OpenShift 虚拟化的工具，但它并不总是涵盖所需的每个技术步骤。

在本文中，对于不由虚拟化迁移工具包处理的操作，我们分享了如何将虚拟化迁移工具包与相应的脚本搭配使用。这些脚本存放在 GitHub 上。借助这些工具，我们成功迁移了 120 个虚拟机和 12 TB 数据，现已在 OpenShift 上成功运行。

随着红帽虚拟化的生命周期接近尾声，我们预计许多企业都会考虑进行类似的迁移。希望我们的经验和工具能够方便您使用虚拟化迁移工具包将虚拟机迁移到 OpenShift，新版本的工具包已修复了本文中提到的问题，并引入了许多其他改进。