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