vMotion的實現原理是怎樣的？

12-27

對vMotion將正在運行的虛擬機從一台物理伺服器移動至另一台物理伺服器的技術比較驚訝，我能理解普通文件、系統鏡像的遷移和增量遷移，但是系統運行時的內存信息還有CPU的寄存器信息怎麼同步複製呢？畢竟網路的延時最快也在1000ns這個級別，而CPU Cache的延時只有1ns的水平。

下髮指令後開始增量複製, 複製完了把A暫停，拷一份執行狀態到B，再啟動。

不是完全無影響的，有2-3秒的中斷，你在vmo的時候ping一下看看就知道了。

這種文檔里有寫的問題就別問啦……自己查比別人講學的多

虛擬機啊，所以必然寄存器里什麼值也都知道的才對啊。這是跟延遲也沒關係啊，反正遷移不是瞬時的。

xen和kvm是採取迭代拷貝，先拷一份全量，當然由於vm一直運行中又會有臟頁產生，第二次迭代把上一輪中產生的臟頁再拷走，如此循環多次，直到臟頁很少時pause住虛擬機最後一次把剩下的都拷走，這樣基本上虛擬機只會停止零點幾秒，大多數用戶是無感知的。

曾經搞過vMotion，答兩句。

嫌我寫得亂的話直接看下面鏈接的第五頁：https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/vmware-vmotion-performance-vsphere5.pdf

vMotion其實原理上很簡單，跟vm check pointing或者vm suspend resume沒有本質區別。都是保存vCPU的狀態，設備的狀態，虛擬磁碟的狀態和內存狀態，並再次讀取。區別是何時保存運行狀態，保存到哪裡，在哪裡resume execution。vMotion就是將運行狀態保存在另外一台物理機上，然後在另一個物理機上resume。

vCPU狀態和設備狀態很容易理解，只要結構化的將各種狀態保存，並發送到目標機上。

內存狀態也並不複雜。首先write protect每個page，然後從page 0開始把每個page都發送到目標機上。因為有write protection，當某個page被修改後，可以用一個bitmap記錄哪些page需要重新發送。在發送過程中，虛擬機是一直在原始的機器上繼續運行的。當第一輪發送結束之後，根據bitmap，再發送之前發生過變化的page。發送過程中仍然維護這個bitmap。每輪發送後，檢查bitmap，決定是否繼續下一輪發送。當bitmap里剩下的page數收斂到一個值，停止發送。此時在原始機上暫停VM執行，把剩下的page發過去，把設備和CPU的狀態也發過去，就可以在目標機上resume了。當然，write protection對VM執行是有性能損耗的，因為每次寫一個頁面都會造成VMExit，所以也有利用EPT的dirty bit來做的，高級些設置可以用page modification log。但是這些優化意義並不大，因為在vMotion過程中，我們是希望VM執行「稍慢」一些的，這樣有利於減小最後一輪發送的page數。

內存之所以要做這個迭代主要目的是儘可能減少最後那一次暫停執行的時間，但這仍不可能是瞬間。VM內存的大小和當前的負載很大程度上決定了這個暫停的時間。

在線遷移不是說不停機器，機器還是會短暫的被paused。