nova live-migration --block-migrate
虛擬機熱遷移的作用
每個讀者都可能會問這樣一個問題，虛擬機用的好好的，爲啥要遷移呀？也就是遷移的價值和目的在哪裏。在數據中心的日常運維中，常常要處理下面幾種場景和需求，瞭解了這些需求，這個問題也就有了答案。 需求 1：物理機器硬件系統的維護，故障修復和升級(upgrade)，但運行在這臺物理機器上的虛擬機不能關機，因爲用戶重要的服務跑在上面。 需求 2：物理機器軟件系統升級，打補丁(patch)，爲了不影響上面跑的虛擬機，在升級和打補丁之前，需要把虛擬機遷移到別的物理機器上。 需求 3：一個物理機器上的負載太重，需要減少一些虛擬機來釋放資源。 需求 4：在一個 cluster 裏，有的物理機上的虛擬機太多，有的物理機上虛擬機太少，需要做一下資源平衡。
除了上面四個主要的需求，從服務的角度來看，Live migration 有下面兩個好處： 好處 1：軟件和硬件系統的維護升級，不會影響用戶的關鍵服務，提高了服務的高可用性和 用戶的滿意度。 好處 2：系統管理員不用加班加點，在大半夜進行系統升級了，在正常的工作時間就可以完成這項工作，減少了公司的維護費用。
有這四個需求和兩個好處，所以動態遷移值得一作。
基本概念
在瞭解動態遷移之前，必須瞭解鏡像文件的格式 QCOW2。Qcow2 是 QEMU 目前推薦的鏡像格式，它支持稀疏文件以節省存儲空間，支持加密以提高鏡像文件的安全性，支持基於 zlib 的壓縮。Qcow2 鏡像可以用來保存另一個鏡像文件的變化，它並不去修改原始鏡像文件，原始鏡像文件也叫後端鏡像(backing_file)。只記錄與原始鏡像文件的不同部分的鏡像文件，這種鏡像文件就叫做 copy-on-write 鏡像，它雖然是一個單獨的鏡像文件，但它的大部分數據都來自原始鏡像，只有基於原始鏡像文件的增量部分纔會被記錄下來。本文提及的虛擬機都是 OpenStack 用 Qcow2 格式的鏡像文件建立的，如圖所示，包含兩部分。 1.後端鏡像(libvirt base) 2.虛擬機單獨的增量鏡像文件(libvirt instance disks)，copy-on-write 鏡像
[root@NFJD-TESTN-COMPUTE-1 ~]# cd /var/lib/nova/instances/ [root@NFJD-TESTN-COMPUTE-1 ~]# tree ├── b9530e7b-2309-4eb5-bec3-180241c1e3a2 │ ├── console.log │ ├── disk │ ├── disk.config │ ├── disk.info │ └── libvirt.xml ├── ... ├── _base │ ├── 0522bc602608d45758d815b01a6899ff3e1e3e27 │ ├── 05252f6d26980b56fbf93a14c5e70910f18b412c │ ├── ...
用 qemu-img 查看虛擬機單獨的增量鏡像文件的信息，我們可以看到他的 backing file 是_base 目錄下的鏡像文件
[root@NFJD-TESTN-COMPUTE-1 ~]# cd /var/lib/nova/instances/
[root@NFJD-TESTN-COMPUTE-1 instances]# cd 852e1a26-bd49-4149-bd24-552eb4b37034
[root@NFJD-TESTN-COMPUTE-1 852e1a26-bd49-4149-bd24-552eb4b37034]# ls
console.log disk disk.config disk.info libvirt.xml
[root@NFJD-TESTN-COMPUTE-1 852e1a26-bd49-4149-bd24-552eb4b37034]# qemu-img info disk
image: disk
file format: qcow2
virtual size: 20G (21474836480 bytes)
disk size: 281M
cluster_size: 65536
backing file: /var/lib/nova/instances/_base/731d527f50917ff3364203ebbcf8d4c22dc7919c
Format specific information:
compat: 1.1
lazy refcounts: false
refcount bits: 16
corrupt: false費了這麼多篇幅介紹 QCOW2，您會奇怪，目的何在？其實上面介紹的後端鏡像(libvirt Base)，虛擬機單獨的增量鏡像文件(libvirt instance disks)，它們就是要被遷移的數據。動態遷移的最終目標就是把它們完整地從源物理主機遷移到目標物理主機。除了他們兩個之外，還有一個需要遷移的對象就是內存裏運行的虛擬機的數據。
數據的轉移就涉及數據的傳輸，數據的傳輸需要通過網絡，本文介紹使用 TCP 網路協議完實現動態遷移。Libvirt 默認情況下不支持 TCP 協議，需要對 libvirt 的配置做修改，使 libvirt 能夠支持 TCP 協議，後面的章節會詳細的介紹如何配置。 在遷移的過程中，運行在目的物理主機（Dest Host）中的 libvirtd 進程要根據 address 和 port 創建一個 URI，URI 是目的物理主機用來接收數據和發回數據到源物理主機（Source Host）的 libvirtd 進程的。
在目的物理主機和源物理主機，只要下面的命令能夠執行，就說明能夠傳輸數據了。 在 compute01 上執行：
[root@compute01]# virsh -c qemu+tcp://nova@compute02/system
在 compute02 上執行：
[root@compute01]# virsh -c qemu+tcp://nova@compute01/system
如：
[root@NFJD-TESTN-COMPUTE-1 instances]# virsh -c qemu+tcp://nova@NFJD-TESTN-COMPUTE-2/system
歡迎使用 virsh，虛擬化的交互式終端。
輸入：'help' 來獲得命令的幫助信息
'quit' 退出
virsh # ^C
[root@NFJD-TESTN-COMPUTE-1 instances]# virsh -c qemu+tcp://nova@NFJD-TESTN-COMPUTE-2/system
歡迎使用 virsh，虛擬化的交互式終端。
輸入：'help' 來獲得命令的幫助信息
'quit' 退出
virsh # list
Id 名稱 狀態
----------------------------------------------------
9 instance-000057c2 暫停
10 instance-000057c6 running
24 instance-0000581a 暫停
25 instance-0000581f running
31 instance-00005833 running
...遷移的步驟
遷移的基本概念弄清楚了，下面我們繼續介紹遷移的步驟。OpenStack 做動態遷移一個正常的流程主要包括四部分：遷移前的條件檢查、遷移前的預處理、遷移、遷移後的處理。
遷移前的條件檢查
動態遷移要成功執行，一些條件必須滿足，所以在執行遷移前必須做一些條件檢查。 1.權限檢查，執行遷移的用戶是否有足夠的權限執行動態遷移。 2.參數檢查，傳遞給 API 的參數是否足夠和正確，如是否指定了 block-migrate 參數。 3.檢查目標物理主機是否存在。 4.檢查被遷移的虛擬機是否是 running 狀態。 5.檢查源和目的物理主機上的 nova-compute service 是否正常運行。 6.檢查目的物理主機和源物理主機是否是同一臺機器。 7.檢查目的物理主機是否有足夠的內存(memory)。 8.檢查目的和源物理主機器 hypervisor 和 hypervisor 的版本是否相同。
遷移前的預處理
在真正執行遷移前，必須做一下熱身，做一些準備工作。 1.在目的物理主機上獲得和準備虛擬機掛載的塊設備(volume)。 2.在目的物理主機上設置虛擬機的網絡(networks)。 3.目的物理主機上設置虛擬機的防火牆(fireware)。
遷移
條件滿足並且做完了預處理工作後，就可以執行動態遷移了。主要步驟如下：
1.調用 libvirt python 接口 migrateToURI，來把源主機遷移到目的主機。
- dom.migrateToURI(CONF.live_migration_uri % dest,logical_sum,None,CONF.live_migration_bandwidth)
- live_migration_uri：這個 URI 就是在 3.2.2 裏介紹的 libvirtd 進程定義的。
- live_migration_bandwidth：這個參數定義了遷移過程中所使用的最大的帶寬。
2.以一定的時間間隔（0.5）循環調用 wait_for_live_migration 方法，來檢測虛擬機遷移 的狀態，一直到虛擬機成功遷移爲止。
遷移後的處理
當虛擬機遷移完成後，要做一些善後工作。 1.在源物理主機上 detach volume。 2.在源物理主機上釋放 security group ingress rule。 3.在目的物理主機上更新數據庫裏虛擬機的狀態。 4.在源物理主機上刪除虛擬機。 上面四步正常完成後，虛擬機就成功的從源物理主機成功地遷移到了目的物理主機了。系統管理員就可以執行第二章所列的哪些管理任務了。
動態遷移的配置
本節列出了支持動態遷移的配置，必須確保所有物理主機上配置真確，動態遷移才能成功完成。
Libvirt
libvirt 默認情況下支持遠程連接的 TLS 協議，不支持 TCP 協議，因此將 listen_tls=0 listen_tcp=1 使 libvirt 能夠支持 TCP 協議。 1.修改/etc/sysconfig/libvirtd 文件。
LIBVIRTD_ARGS="--listen"
2.在/etc/libvirt/libvirtd.conf 文件中做如下配置。
listen_tls=0 listen_tcp=1 auth_tcp="none"
3.重啓 libvirtd 服務
防火牆
配置/etc/sysconfig/iptables，打開 TCP 端口 16509。
-A INPUT -p tcp -m multiport --ports 16509 -m comment --comment "libvirt" -j ACCEPT
OpenStack Nova
在/etc/nova/nova.conf 文件裏配置 live_migration 標記。
live_migration_flag=VIR_MIGRATE_UNDEFINE_SOURCE,VIR_MIGRATE_PEER2PEER,VIR_MIGRATE_LIVE