前言
如果是剛開始接觸虛擬機技術的話, 對上述的概念肯定會有所混淆, 傻傻的分不清. 尤其在看虛擬化技術檔案時導致理解能力下降, 所以在開始學習虛擬化技術之前對這些概念有一個整體的認識和清晰的理解, 就顯得很有必要了.
KVM
KVM(Kernel-basedVirtual Machine,基于內核的虛擬機),狹義 KVM 指的是一個嵌入到 Linux kernel 中的虛擬化功能模塊,該模塊在利用 Linux kernel 所提供的部分作業系統能力,如:任務調度、記憶體管理以及硬體設備互動的基礎上,再為其加入了虛擬化能力,使得 Linux kernel 具有了成為 Hypervisor(虛擬化管理軟體)的條件,
簡而言之,KVM 為 Linux 提供了硬體輔助虛擬化的能力,這依賴于 CPU 的硬體虛擬機支撐,
KVM 內核模塊本身只能提供 CPU 和記憶體的虛擬化,
KVM 需要在具備 Intel VT 或 AMD-V 功能的 x86 平臺上運行,所以 KVM 也被稱之為硬體輔助的虛擬化實作,
KVM 包含一個提供給 CPU 的底層虛擬化可加載核心模塊 kvm.ko(kvm-intel.ko、kvm-AMD.ko),
但一般所說的 KVM 是廣義 KVM, 即:一套 Linux 虛擬化解決方案,由于 KVM 內核模塊本身只能提供 CPU 和記憶體的虛擬化,所以 KVM 需要一些額外的虛擬化技術組件來為虛擬機提供諸如:網卡、IO 總線、顯卡等硬體的虛擬化實作,最終變成了我們所使用到的 Linux 虛擬化解決方案.
QEMU
QEMU(Quick Emulator) 是一個廣泛使用的開源計算機 仿真器和虛擬機. QEMU 作為一個獨立 Hypervisor(不同于 KVM 需要嵌入到 kernel), 能在應用程式的層面上運行虛擬機. 同時也支持兼容 Xen/KVM 模式下的虛擬化, 并且當 QEMU 運行的虛擬機架構與物理機架構相同時, 建議使用 KVM 模式下的 QEMU, 此時 QEMU 可以利用 kqemu 加速器, 為物理機和虛擬機提供更好的性能.
當 QEMU 作為仿真器時, QEMU 通過動態轉化技術(模擬)為 GuestOS 模擬出 CPU 和其他硬體資源, 讓 GuestOS 認為自身直接與硬體互動. QEMU 會將這些互動指令轉譯給真正的物理硬體之后, 再由物理硬體執行相應的操作. 由于 GuestOS 的指令都需要經過 QEMU 的模擬, 因而相比于虛擬機來說性能較差.
當 QEMU 作為一個虛擬機時, QEMU 能夠通過直接使用物理機的系統資源, 使虛擬機能夠獲得接近于物理機的性能表現.

KVM 與 QEMU
KVM 作為 Linux 的內核模塊, 需要被加載后, 才能進一步通過其他工具的輔助以實作虛擬機的創建. 但需要注意的是, KVM 作為運行于 CPU 內核態 的內核模塊, 用戶是無法直接對其進行操作的. 還必須提供一個運行于 CPU 用戶態 的對接程式來提供給用戶使用. 而這個對接程式, KVM 的開發者選擇了已經成型的開源虛擬化軟體 QEMU.
KVM 開發者在對 QEMU 稍加改造之后, QEMU 可以通過 KVM 對外暴露的 /dev/kvm 介面來進行呼叫, 官方提供的 KVM 下載有 QEMU 和 KVM 兩大部分, 包含了 KVM 模塊、QEMU 工具以及二者的合集 qemu-kvm 三個檔案.
qemu-kvm
在 Linux 全虛擬化解決方案 中, KVM 負責提供 CPU 虛擬化和記憶體虛擬化, 但是 KVM 對于一些計算機硬體設備還是無法進行完美的虛擬(如: 網卡/磁盤/ IO 設備…). 于是就引入了 QEMU, QEMU 負責提供硬體設備的虛擬化, 以此彌補來 KVM 的缺陷. 同時, 為了提高 QEMU 虛擬出來的虛擬硬體設備性能, 于是產生了 pass through 半虛擬化設備virtio_blk/virtio_net. KVM + QEMU 才能實作真正意義上虛擬化. 而 qemu-kvm 就是將兩者整合到了一起的媒介.
qemu-kvm 通過 ioctl 呼叫 KVM 的 /dev/kvm 介面, 將 KVM 內核模塊相關的 CPU 指令傳遞到內核模塊中執行.
在 RHEL6/CentOS6 系統中, qemu-kvm 存放在 /usr/libexec 目錄下, 由于 PATH 環境變數默認不包含此目錄, 所以用戶無法直接使用 qemu-kvm. 這樣做是為了防止 QEMU 替代了 KVM 作為物理機 Hypervisor 的角色. 如果希望使用 QEMU 虛擬機, 可以通過將 /usr/libexec/qemu-kvm 鏈接為 /usr/bin/qemu 來實作.
Libvirt
Libvirt 是目前使用最為廣泛的異構虛擬化管理工具及 API, 其具有一個 Libvirtd Daemon, 可供本地或遠程的 virsh 呼叫.
libvirt 由 應用程式編程介面庫、libvirtd 守護行程、virsh CLI 組成. 其中 libvirtd 守護行程負責調度管理虛擬機, 而且這個守護行程可以分為 root 權限的 libvirtd和普通用戶權限的 libvirtd 兩種. 前者權限更大, 可以虛擬出物理主機的各種設備.
開啟 root 權限 libvirtd: sudo libvirtd --daemon
Domain:虛擬機的一個運行實體
Hypervisor:指的就是虛擬化管理程式
Libvirt 本質上是一些被提供的庫函式(C語言), 用于管理物理機的虛擬機. 它參考了面向驅動的架構設計, 對所有的虛擬化技術都提供了相應的驅動和統一的介面, 所以 Libvirt 支持異構的虛擬化技術. 同時 Libvirt 提供了多種語言的編程介面, 可以通程序式呼叫這些介面來實作對虛擬機的操作. 由此可見, Libvirt 具有非常強的可擴展性, OpenStack 就與該庫聯系得相當密切.
在 KVM 中, 可以使用 virsh CLI 來呼叫 libvirtd, libvirtd 再通過呼叫 qemu-kvm 來操作虛擬機.
Libvirt的控制方式:
- 本地控制管理: Management Application 和 Domain 在同一個 Node 上

(左圖是沒有應用 Libvirt 的虛擬化架構)
遠程控制管理: Management Application 和 Domain 不再同一個 Node 上. 該模式使用了運行于遠程節點上的 libvirtd 守護行程, 當在其他節點上安裝 libvirt 時 Management Application 會自動啟動, 并且會自動確定本地虛擬機的監控程式和為虛擬機安裝驅動程式, Management Application 通過一種通用協議從本地 libvirt 連接到遠程 libvirtd,
#Libvirt 在 OpenStack 中的應用
OpenStack 原生使用 KVM 虛擬化技術, 以 KVM 作為最底層的 Hypervisor, KVM 用于虛擬化 CPU 和記憶體, 但 KVM 缺少對 網卡/磁盤/顯卡 等周邊 I/O 設備的虛擬化能力, 所以需要 qemu-kvm 的支持, 它構建于 KVM 內核模塊之上為 KVM 虛擬機提供完整的硬體設備虛擬化能力.
OpenStack 不會直接控制 qemu-kvm, 而是使用 libvirt 作為與 qemu-kvm 之間的中間件. libvirt 具有跨虛擬化平臺能力, 可以控制 VMware/Virtualbox/Xen 等多種虛擬化實作. 所以為了讓 OpenStack 具有虛擬化平臺異構能錄, OpenStack 沒有直接呼叫 qemu-kvm, 而是引入了異構層 libvirt. 除此之外, libvirt 還提供了諸如 pool/vo l管理等高級的功能.
原文鏈接:https://blog.csdn.net/Jmilk/article/details/68947277
轉載請註明出處,本文鏈接:https://www.uj5u.com/caozuo/272734.html
標籤:Linux
上一篇:c語言編譯時和運行時的問題
下一篇:cannot send list of active checks to "127.0.0.1": host [Zabbix server] not monitored
