為了追趕上VMware虛擬化霸主的腳步，微軟從Hyper-V 2.0開始支持物理機與虛擬機之間的動態遷移。動態遷移對于實驗室來說，需求可能并不高；但對于企業來說，這卻是虛擬化成熟度的一個分水嶺。

　　在開始之前，需要明確一個概念。

　　動態遷移（Hyper-V Live Migration）并非故障狀態下的非計劃宕機。

　　該應用場景僅用于升級、硬件更換等計劃宕機。

　　動態遷移步驟：

　　• 在源和目標計算機之間建議連接

　　• 傳送虛擬機配置及設備信息

　　• 傳送虛擬機內存

　　• 暫停（掛起）源虛擬機并傳送狀態

　　• 恢復目標虛擬機

一、在源和目標計算機之間建議連接

　　該部分的通信涉及到兩個WMI對群集中兩個dll的調用：

　　clusres.dll

　　群集資源管理dll（基本的網絡、存儲、WINS、DHCP、腳本。。）

　　vmclusres.dll

　　虛擬機群集資源管理dll

　　Live Migration從本質上來說還是群集的一種實現方式。

　　通信的速度與效率與源服務器和目標服務器的負載有關。

　　在源服務器或目標服務器負載過高情況下會出現WMI調用clusres.dll超時失敗的情況。

　　該場景出現在PRO調用Live Migration過程中，將會造成第4步，即暫停（掛起）源虛擬機并傳送狀態卡死，導致虛擬機長時間處于掛起狀態。

　　錯誤信息如下：

　　錯誤 (12711)

　　由于出現錯誤 [MSCluster_Resource.Name="SCVMM XXX01 Configuration"] ，找不到元素，VMM 無法在服務器 HOST01.contoso.com 上完成 WMI 操作。

　　詳細信息 (找不到元素(0x490))

　　微軟提供的相關的補丁，需要在所有節點上部署：

　　http://support.microsoft.com/kb/974930

　　二、傳送虛擬機配置及設備信息

　　這里值得注意的是，該部分傳送的并非虛擬機目錄中的XML配置文件，僅僅是注冊表中的信息。

　　以上兩步完成的是遷移的準備工作，告知了目標服務器虛擬機所需的資源，并分配所需資源。

　　三、傳送虛擬機內存

　　該部分是遷移的核心技術部分。不論是VMware還是Hyper-V來做遷移，都是無法逃避的問題。

　　那些銷售所謂的服務不會斷線，不過是傳說。從技術的角度來說只是斷線的時間由秒這個級別降低到了毫秒級而已。

　　我們來詳細描述一下內存傳送的過程：

　　1、鎖定Guest主機內存，并將該部分的信息傳送到目標服務器。

　　2、Guest主機繼續運行，在Host主機中開啟一個新的內存分區為Guest主機提供服務。該區域僅保存變更的內容。

　　3、新內存分區將繼續分片鎖定，并傳送。

　　4、重復2~3，保證原HOST服務器與目標HOST服務器變更內存的差異在一個極小的時鐘周期之內，直至操作1中的內存傳送完成。

四、暫停（掛起）源虛擬機并傳送狀態

　　這部分包含3個操作：

　　1、掛起源虛擬機

　　2、傳送***的源虛擬機內存變更片段

　　3、通知存儲，將存儲掛載至目標服務器

　　第四步是遷移時間消耗的關鍵。

　　而關鍵的關鍵是實時內存狀態的保存。

　　在Hyper-V 1.0中Quick Migration采取的方式是掛起源虛擬機，再處理內存的方式。

　　所以在遷移過程中會發現宕機的時間與虛擬機所消耗的內存量成正比。

　　而在Live Migration中，宕機時間不再由所遷移虛擬機消耗的內存來決定。

　　決定宕機時間的關鍵點內存大小是一個相對較小的變更內存片段。

　　根據實測，在Live Migration操作中，ping包監視根據系統負載不同在丟包為2~6之間。

　　完全可以滿足一般企業高可用的需求。

　　五、恢復目標虛擬機

　　這個部分與普通的恢復相同。不做詳細說明。