我正在研究 Citrix 的 XenServer，并与 2 位同事一起将其与 VMware ESX 和 Microsoft HyperV 进行比较。
在我们的测试中，Xen 的实时迁移似乎比 VMware 的 ESX 占用更少的资源，我想知道为什么会这样。我发现了一篇去年的文章，其中引用了 2005 年的一篇论文，解释了实时迁移过程中页面/内存的实际情况。
这是摘录文章关于内存传输：
推送阶段 - 源 VM 继续运行，同时某些页面通过网络推送到新目标。为确保一致性，必须重新发送在此过程中修改的页面。
停止和复制阶段源 VM 停止，页面复制到目标 VM，然后启动新 VM。
拉取阶段新的 VM 执行，如果它访问尚未复制的页面，则该页面会通过网络从源 VM 中错误地传入（“拉取”）。
我想知道内存传输是否仍然以与四年前相同的方式进行。
答案1
我不是 Xen 迁移方面的专家，我使用的是开源 Xen 服务器。根据我的经验，只要您的存储层速度快，Xen 服务器在迁移方面就非常高效——根据我们的经验，ocfs2 卷或（但愿不会）NFS 挂载上的文件磁盘映像比 NFS 挂载上的共享锁定卷的 SAN 上的块设备慢得多。我们没有遇到磁盘损坏的问题，但为了确保万无一失，我们在非常活跃的系统上开始迁移之前往往会对事物（LVM2 和 VM 状态）进行快照。
根据 Matthews、Dow 等人撰写的《运行 Xen：虚拟化艺术实用指南》（Prentice Hall 2008 年第 484 页），
Xen 实时迁移的实施涉及一种新颖的迭代多通道算法，该算法以连续步骤传输虚拟机客户机内存。在源 VM 和目标 VM 首先协商以确保接收机器上的资源充足之后，将对客户机内存进行初始传递，并将每个页面传输到目标。在每次连续迭代中，仅发送在此期间被弄脏的客户机内存。此过程一直执行到剩余脏页数量足够少（原文如此）以至于可以快速传输剩余页面或每次传递中剩余要传输的脏页数量没有减少为止。此时，系统实际上处于静止状态，最终状态发送到新主机，控制权转移到新物理机完成。
这看起来与您上面描述的步骤列表类似，但增加了迭代次数。请注意，在当前实时迁移状态下，机器可能在两个地方执行 I/O。
与 VMWare 和 HyperV 不同，XenServer 的优点在于，从周日开始，有大量用户在非常严重的生产环境中运行它并尽最大努力以十种方式破解它。实时迁移对我们来说是新事物，我们还没有在生产环境中进行，因为我们有冗余问题（由于我们的共享数据分区在 ocfs2 卷上，因此目前很难扩展到 n 台机器），但在我们的测试环境中，我们一直在到处弹跳机器，这很有趣。