Xen live motion 中的記憶體是如何傳輸的？
我正在研究 Citrix 的 XenServer，並（與 2 位同事）將它與 VMware ESX 和 Microsoft HyperV 進行比較。
在我們的測試中，Xen 的實時遷移使用的資源似乎比 VMware 的 ESX 少，我想知道為什麼會這樣。我發現去年的一篇文章引用了 2005 年的一篇論文，解釋了實時遷移期間頁面/記憶體的實際情況。
這是那篇關於記憶體傳輸的文章的摘錄：
推送階段 - 源 VM 繼續執行，同時某些頁面通過網路推送到新目標。為確保一致性，在此過程中修改的頁面必須重新發送。
停止和複製階段 停止源 VM，將頁面複製到目標 VM，然後啟動新 VM。
拉取階段 新的 VM 執行，如果它訪問一個尚未被複製的頁面，則該頁面在源 VM 的網路中出現故障（“拉取”）。
我想知道記憶體轉移是否仍然以與 4 年前相同的方式發生。
我不是 Xen 遷移方面的專家，我使用的是開源 Xen 伺服器。根據我的經驗，只要您的儲存層速度很快，Xen 伺服器的遷移效率就非常高——根據我們的經驗，磁碟映像作為 ocfs2 卷上的文件或（上帝保佑）NFS 掛載比 SAN 上的塊設備慢得多NFS 掛載上的共享鎖定卷。我們沒有遇到磁碟損壞的問題，但是為了確保安全，在我們開始在非常活躍的系統上遷移之前，我們確實傾向於對事物（LVM2 和 VM 狀態）進行快照。
根據 Matthews, Dow 等人的“Running Xen: A Hands On Guide to the Art of Virtualization”，Prentice Hall 2008，第 484 頁，
Xen 的實時遷移的實現涉及到迭代多通道算法的新穎使用，該算法在連續的步驟中傳輸虛擬機客戶記憶體。在源 VM 和目標 VM 第一次協商以確保接收機器上有足夠的資源後，將執行訪客記憶體的初始傳遞，並將每個頁面傳輸到目標。在每個連續的迭代中，只發送臨時被弄髒的客戶記憶體。執行此過程，直到剩餘的髒頁數量足夠小（原文如此）以使剩餘的頁面可以快速傳輸，或者在每次傳遞中剩餘的待傳輸的髒頁數量沒有減少。在那時候，
看起來這類似於您上面描述的步驟列表，但添加了迭代。請注意，目前狀態為實時遷移的機器可能在兩個地方進行 I/O。
與 VMWare 和 HyperV 不同，XenServer 的好處在於，從周日開始，有很多人一直在執行它，並在非常嚴肅的生產環境中竭盡全力以十種方式破解它。實時遷移對我們來說是新事物，我們還沒有在生產環境中這樣做，因為我們有冗餘問題（由於我們在 ocfs2 卷上擁有共享數據分區，此時擴展到 n 台機器並非易事），但在我們的測試環境，我們一直在到處玩彈跳機器。