遠程管理 KVM 虛機
![upload-ueditor-p_w_picpath-20160308-1457443987]()
上一節我們通過 virt-manager 在本地主機上創建並管理 KVM 虛機。其實 virt-manager 也可以管理其他宿主機上的虛機。只需要簡單的將宿主機添加進來
填入宿主機的相關信息，確定即可。
接下來，我們就可以像管理本地虛機一樣去管理遠程宿主機上的虛機了。
這裏其實有一個要配置的地方。 因爲 KVM（準確說是 Libvirt）默認不接受遠程管理，需要按下面的內容配置被管理宿主機中的兩個文件
/etc/default/libvirt-bin
startlibvirtd="yes"
libvirtdopts="-d -l"
/etc/libvirt/libvirtd.conf
listentls = 0
listentcp = 1
unixsockgroup = "libvirtd"
unixsockroperms = "0777"
unixsock_rwperms = "0770"
authunixro = "none"
authunixrw = "none"
authtcp = "none"
然後重啓 Libvirtd 服務就可以遠程管理了。
service libvirt-bin restart
CPU 和內存虛擬化原理
前面我們成功地把 KVM 跑起來了，有了些感性認識，這個對於初學者非常重要。不過還不夠，我們多少得了解一些 KVM 的實現機制，這對以後的工作會有幫助。
CPU 虛擬化
KVM 的虛擬化是需要 CPU 硬件支持的。還記得我們在前面的章節講過用命令來查看 CPU 是否支持KVM虛擬化嗎？
root@ubuntu:~# egrep -o '(vmx|svm)' /proc/cpuinfo
vmx
如果有輸出 vmx 或者 svm，就說明當前的 CPU 支持 KVM。CPU 廠商 Intel 和 AMD 都支持虛擬化了，除非是非常老的 CPU。
一個 KVM 虛機在宿主機中其實是一個 qemu-kvm 進程，與其他 Linux 進程一樣被調度。 比如在我的實驗機上運行的虛機 kvm1 在宿主機中 ps 能看到相應的進程。
虛機中的每一個虛擬 vCPU 則對應 qemu-kvm 進程中的一個線程。看下圖
在這個例子中，宿主機有兩個物理 CPU，上面起了兩個虛機 VM1 和 VM2。 VM1 有兩個 vCPU，VM2 有 4 個 vCPU。可以看到 VM1 和 VM2 分別有兩個和 4 個線程在兩個物理 CPU 上調度。
這裏也演示了另一個知識點，即虛機的 vCPU 總數可以超過物理 CPU 數量，這個叫 CPU overcommit（超配）。 KVM 允許 overcommit，這個特性使得虛機能夠充分利用宿主機的 CPU 資源，但前提是在同一時刻，不是所有的虛機都滿負荷運行。 當然，如果每個虛機都很忙，反而會影響整體性能，所以在使用 overcommit 的時候，需要對虛機的負載情況有所瞭解，需要測試。
內存虛擬化
KVM 通過內存虛擬化共享物理系統內存，動態分配給虛擬機。看下圖
爲了在一臺機器上運行多個虛擬機，KVM 需要實現 VA（虛擬內存） -> PA（物理內存） -> MA（機器內存）直接的地址轉換。虛機 OS 控制虛擬地址到客戶內存物理地址的映射 （VA -> PA），但是虛機 OS 不能直接訪問實際機器內存，因此 KVM 需要負責映射客戶物理內存到實際機器內存 （PA -> MA）。具體的實現就不做過多介紹了，大家有興趣可以查查資料。
還有一點提醒大家，內存也是可以 overcommit 的，即所有虛機的內存之和可以超過宿
KVM 存儲虛擬化
KVM 的存儲虛擬化是通過存儲池（Storage Pool）和卷（Volume）來管理的。 Storage Pool 是宿主機上可以看到的一片存儲空間，可以是多種類型，後面會詳細討論。Volume 是在 Storage Pool 中劃分出的一塊空間，宿主機將 Volume 分配給虛擬機，Volume 在虛擬機中看到的就是一塊硬盤。 下面我們學習不同類型的 Storage Pool 目錄類型的 Storage Pool 文件目錄是最常用的 Storage Pool 類型。 那麼 Volume 是什麼呢？ 大家是否還記得我們之前創建第一個虛機 kvm1 的時候，就是將鏡像文件 cirros-0.3.3-x8664-disk.img 放到了這個目錄下。文件 cirros-0.3.3-x8664-disk.img 也就是Volume，對於 kvm1 來說，就是它的啓動磁盤了。
那 KVM 是怎麼知道要把 /var/lib/libvirt/p_w_picpaths 這個目錄當做默認 Storage Pool 的呢？ 實際上 KVM 所有可以使用的 Storage Pool 都定義在宿主機的 /etc/libvirt/storage 目錄下，每個 Pool 一個 xml 文件，默認有一個 default.xml，其內容如下：
注意：Storage Pool 的類型是 “dir”，目錄的路徑就是 /var/lib/libvirt/p_w_picpaths 下面我們爲虛機 kvm1 添加一個新的磁盤，看看有什麼變化。 在 virt-manager 中打開 kvm1 的配置頁面，右鍵添加新硬件
在默認 Pool 中創建一個 8G 的卷。
點擊 “Finish”，可以看到新磁盤的信息。
在 /var/lib/libvirt/p_w_picpaths/ 下多了一個 8G 的文件 kvm1.img root@ubuntu:~# ls -l /var/lib/libvirt/p_w_picpaths/ -rw-r--r-- 1 root root 14417920 Sep 4 11:24 cirros-0.3.3-x86_64-disk.img -rw------- 1 root root 8589934592 Sep 4 21:39 kvm1.img 使用文件做 Volume 有很多優點：存儲方便、移植性好、可複製、可遠程訪問。 前面幾個優點都很好理解，這裏對“可遠程訪問”多解釋一下。 遠程訪問的意思是鏡像文件不一定都放置到宿主機本地文件系統中，也可以存儲在通過網絡連接的遠程文件系統，比如 NFS，或者是分佈式文件系統中，比如 GlusterFS。 這樣鏡像文件就可以在多個宿主機之間共享，便於虛機在不同宿主機之間做 Live Migration；如果是分佈式文件系統，多副本的特性還可以保證鏡像文件的高可用。 KVM 支持多種 Volume 文件格式，在添加 Volume 時可以選擇
raw 是默認格式，即原始磁盤鏡像格式，移植性好，性能好，但大小固定，不能節省磁盤空間。 qcow2 是推薦使用的格式，cow 表示 copy on write，能夠節省磁盤空間，支持 AES 加密，支持 zlib 壓縮，支持多快照，功能很多。 vmdk 是 VMWare 的虛擬磁盤格式，也就是說 VMWare 虛機可以直接在 KVM上 運行。
|
LVM 類型的 Storage Pool
LVM 類型的 Storage Pool
不僅一個文件可以分配給客戶機作爲虛擬磁盤，宿主機上 VG 中的 LV 也可以作爲虛擬磁盤分配給虛擬機使用。
不過，LV 由於沒有磁盤的 MBR 引導記錄，不能作爲虛擬機的啓動盤，只能作爲數據盤使用。
這種配置下，宿主機上的 VG 就是一個 Storage Pool，VG 中的 LV 就是 Volume。 LV 的優點是有較好的性能；不足的地方是管理和移動性方面不如鏡像文件，而且不能通過網絡遠程使用。
下面舉個例子。
首先，在宿主機上創建了一個容量爲 10G 的 VG，命名爲 HostVG。
然後創建了一個 Storage Pool 的定義文件 /etc/libvirt/storage/HostVG.xml，內容爲
然後通過 virsh 命令創建新的 Storage Pool “HostVG”
並啓用這個 HostVG
現在我們可以在 virt-manager 中爲虛機 kvm1 添加 LV 的虛擬磁盤了。
點擊 Browse
可以看到 HostVG 已經在 Stroage Pool 的列表中了，選擇 HostVG
爲 volume 命名爲 newlv 並設置大小 100MB
點擊 Finish，newlv 創建成功
點擊 Choose Volume
點擊 Finish 確認將 newlv 作爲 volume 添加到 kvm1
新 volume 添加成功 在宿主機上則多了一個命名爲newlv的LV
其他類型的Storage Pool
KVM 還支持 iSCSI，Ceph 等多種類型的 Storage Pool，這裏就不一一介紹了，最常用