通過Linux工具管理KVM
主流服務器虛擬化技術簡單使用——KVM(一)部署了一台KVM主機,提到KVM可以通過命令行工具(virt-install、virsh)和GUI工具(virt-manager)管理虛擬機。實際上virt-install、virsh、virt-manager只是管理工具,如果部署多台KVM,並不需要每一台都安裝這些管理工具,因為它們也可以管理其它KVM。甚至於這些管理工具也不一定需要安裝在某一台KVM上,可以安裝在任意一台Linux中。
Tips:virt-install、virsh、virt-manager不單能夠管理kvm,還能管理Xen和其它支持libvirt的hypervisor。這里使用主流服務器虛擬化技術簡單使用——KVM(一)中第二種方式部署了兩台KVM,演示在其中一台KVM的virt-manager上管理另一台KVM。
特別注意:這些KVM管理工具依賴libvirtd進程,但從CentOS7.4默認源(Base)安裝的libvirt無法正常運行,推測是默認源中的libvirt版本較高,而操作系統的環境較舊,嘗試使用CentOS7.4鏡像搭建的源,能夠正常使用。
若在已安裝的操作系統(且安裝時環境未選擇這些虛擬化工具)的CentOS中部署這些工具,建議使用ISO鏡像源:
[root@localhost ~]# yum -y install virt-install libvirt-python virt-manager virt-install libvirt-client
輸入你要管理的物理機IP
如果你的環境和我主流服務器虛擬化技術簡單使用——KVM(一)相同,應該會遇到這個問題。
提示需要安裝openssh-askpass或者相似的軟件,一般通過yum安裝該軟件即可。
Tips:openssh-askpass包含用於OpenSSH的X11密碼對話框,這里它需要和virt-manager安裝在一台服務器上。
通過yum安裝好即可
[root@localhost ~]# yum -y install openssh-askpass.x86_64
安裝之后再次連接,首次登陸會有提示是否要連接(輸入yes),然后輸入密碼即可。
這樣就可以管理其他物理機(此例中為192.168.202.130)的虛擬機。
若無法訪問其它物理機上虛擬機的控制台,可能與ssh配置有關。
修改相應配置和重啟服務即可。
[root@node1 ~]# vi /etc/ssh/sshd_config
X11Forwarding no 找到該行,將no修改為yes
X11Forwarding yes
[root@node1 ~]# systemctl restart sshd
但是訪問虛擬機控制台,反復輸入密碼(我需要輸入8次)這個問題暫時不知道是什么原因。
通過web頁面管理
通過命令行管理,沒有GUI、操作不方便,數據不直觀。virt-manager雖然是GUI,但是只能安裝在Linux中。我們平常都是使用windows,這樣只能通過windows遠程Linux,但Linux由於多種原因一般是不安裝圖像界面的。現在集群管理、監控等,主流都是通過web管理,操作便捷、信息豐富,kvm也有基於web管理的工具(webvirtmgr)。
關於webvirtmgr推薦參考這個文檔,寫的比較詳細,有部署和使用教程:https://jeremy-xu.oschina.io/2016/08/%E8%AF%95%E7%94%A8webvirtmgr/#%E5%BE%85%E6%94%B9%E8%BF%9B%E7%9A%84%E5%9C%B0%E6%96%B9
參考文檔使用CentOS 6,有一些地方需要結合webvirtmgr官網改動:https://pypi.org/project/webvirtmgr/
官網中比較重要的是我用紅色圈處理的三個鏈接,其中Install WebVirtMgr介紹了各種發行版的操作系統如何部署webvirtmgr,Setup Host Server中包含一個部署KVM的腳本(寫本文時已失效),Wiki介紹如何配置webvirtmgr管理KVM。
部署webvirtmgr需要注意的幾點:
1.webvirtmgr部署在一台服務器中,讓其他KVM主機加入webvirtmgr進行管理。
webvirtmgr是個獨立的服務,可以單獨搭建在一台物理服務器中,也可以建立在某台KVM主機中,又或者某台KVM主機的虛擬機中;參考文章提到:webvirtmgr所部署的主機需考慮高可用方案,簡單處理可以將其做成docker鏡像,一旦發現該服務故障了,可以快速地在其它地方啟動起來,這種方式也比較恰當。
2.按照官方文檔在CentOS7.4部署webvirtmgr需要使用epel擴展源
$ sudo yum -y install http://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-5.noarch.rpm
if this doesn't work, use yum install epel-release
$ sudo yum -y install git python-pip libvirt-python libxml2-python python-websockify supervisor nginx
$ sudo yum -y install gcc python-devel
$ sudo pip install numpy
而且會因為依賴安裝最新版的libvirt(寫本文時CentOS7.4是Base源中是4.5),但是CentOS7.4無法運行這個版本的libvirt,將產生報錯:
[root@localhost storage-backend]# libvirtd
2018-12-26 02:56:50.419+0000: 4877: info : libvirt version: 4.5.0, package: 10.el7_6.3 (CentOS BuildSystem <http://bugs.centos.org>, 2018-11-28-20:51:39, x86-01.bsys.centos.org)
2018-12-26 02:56:50.419+0000: 4877: info : hostname: localhost.localdomain
2018-12-26 02:56:50.419+0000: 4877: error : virModuleLoadFile:53 : 內部錯誤:Failed to load module '/usr/lib64/libvirt/storage-backend/libvirt_storage_backend_rbd.so': /usr/lib64/libvirt/storage-backend/libvirt_storage_backend_rbd.so: undefined symbol: rbd_diff_iterate2
libvirt_storage_backend_rbd.so應該是連接ceph塊設備(rbd)的一個模塊,這里暫時不用連接ceph,最簡單粗暴的做法就是移除該模塊,重啟libvirtd。
[root@localhost storage-backend]# mv libvirt_storage_backend_rbd.so libvirt_storage_backend_rbd.so.bak
[root@localhost storage-backend]# systemctl restart libvirtd
其實安裝過程中,有些包是epel里面的,libvirt相關的包還是從base中安裝的,最穩妥的做法就是禁用base,使用ISO鏡像源中的libvirt相關包。這個方法我未驗證是否可行
3.webvirtmgr文檔建議使用ssh端口轉發訪問webvirtmgr,這個視自身情況而定做修改。
5.webvirtmgr要訪問虛擬機的控制台需要yum -y install novnc,並開啟kvm主機的6080端口。
6.webvirtmgr接入kvm主機有4種方式,個人最推薦的是ssh。
ssh連接kvm主機必須設置ssh秘鑰登陸,具體設置方法參考Wiki(部署目錄)中的
webvirtmgr試用
還是這篇參考文章中有試用部分:https://jeremy-xu.oschina.io/2016/08/%E8%AF%95%E7%94%A8webvirtmgr/#%E5%BE%85%E6%94%B9%E8%BF%9B%E7%9A%84%E5%9C%B0%E6%96%B9
更多管理方式
命令行工具比較適合排除故障的時候使用,virt-manager和webvirtmgr功能都差不多,主要在於C/S、B/S的區別。雖然webvirtmgr在邏輯結構、信息顯示這些方面比virt-manager好一些,但它的功能仍然比較基礎,兩者都只是將逐台管理KVM主機的工作整合到一處,只適合管理約十台KVM主機(物理服務器)的小型KVM虛擬化平台。
大型的KVM虛擬化平台,有數百台的KVM主機,需要使用rhev(rhev的開源版叫ovirt)。盡管他們表面上看起來和webvirtmgr都差不多,都是通過網頁管理這些虛擬機,但他們能夠實現監控告警,多種資源集中管理等諸多強大的功能,更適合管理大型KVM虛擬化平台。
rhev參考:
Tips:由於docker技術的迅速發展,小型虛擬化平台基本上被docker替代,像webvirtmgr最后一次更新還是在2015.1.23日。相較於服務器虛擬化,docker自身開銷更小,更加靈活。關於docker和服務器虛擬化技術的關系參考: