:::

VDI轉換成KVM可用之VMDK

VDI轉換成KVM可用之VMDK

image

早期我常使用的虛擬機器環境為VirtualBox,但是因為效能不彰、管理不易,之後我開始使用Proxmox VE平台來取代,並獲得不錯的成果。

要讓VirtualBox使用的VDI檔案能在Proxmox VE平台中的KVM虛擬機器中運作,必須先將之轉換成KVM可用之VMDK。奇怪的是,這並不能夠用VirtualBox GUI介面中的「匯出」功能,而必須要用「VBoxManage.exe」直接轉換VDI才行。

以下簡單說明作法。


虛擬機器使用的硬碟映像檔

本文所用的平台轉換方式是將VirtualBox使用的硬碟放到Proxmox VE的KVM中使用,你可以單純地想像成實體電腦中硬碟換到另一台插上去的感覺。只是VirtualBox用的VDI跟KVM支援的VMDK這兩者格式上有所不同,在實作前有必要先介紹一下。

VDI:虛擬硬碟映像檔

VDI是VirtualBox使用的虛擬硬碟映像檔,全名為Virtual Disk Image。他可以在最大2TB的檔案大小之間動態地佔用實際上需要的檔案數量。

舉例來說,設定一個大小為2TB、但內容並沒有檔案的硬碟,在Host端看起來該檔案大概只有幾MB而已。隨著VDI內容檔案的增加,VDI的檔案大小也會隨之增加。以一個CentOS來說,VDI大概會高達10GB左右。

VDI似乎並不會壓縮檔案。實際上內容用了多少、外面看起來就是說大。我之前用7-Zip壓縮VDI檔案的時候,可以將26GB的VDI壓縮到3GB左右的大小。當然,壓縮的時間也是非常地久就是了。

VMDK:虛擬機器硬碟

VMDK是VMware虛擬機器使用的映像檔,全名為Virtual Machine Disk。作為虛擬機器市場第一把交椅,各種虛擬機器都將支援VMware作為噱頭,而VMDK格式映像檔也在VirtualBox跟KVM的支援範圍之內。因此,將VirtualBox使用的VDI檔案轉換成KVM也支援的VMDK,就是本篇的主要重點囉。

2012-04-24_062535 vmdk 2012-04-24_064813 oracle vm

必須註明的是,只有VirtualBox 2.1.2之後的版本,也就是後期的Sun VirtualBox跟Orcale VirtualBox才有支援VMDK格式。早期的xVM VirtualBox跟更早的Inno Tek VirtualBox都沒有支援喔。關於VirtualBox的歷史請看新聞頁面

VMDK格式似乎會稍微壓縮資料,讓硬碟實際使用量不會太過暴增。VirtualBox支援匯出功能的時候,也會將硬碟檔案直接匯出成VMDK,而不是早期的VDI。但是透過匯出功能匯出的VMDK並無法讓KVM使用,這點真是令人匪夷所思。

VirtualBox將VDI轉換成VMDK指令

VirtualBox 2.1.2之後支援VMDK虛擬機器硬碟格式,可以使用內建的工具VboxManage來轉換。操作時必須以指令列的方式執行,Windows中就必須先叫出命令提示字元。

其指令為:

VBoxManage.exe clonehd source.vdi target.vmdk --format vmdk

舉例來說,我的VirtualBox裝在「D:\Program Files\Oracle\VirtualBox\」路徑底下,而我要將dspace-dlll.vdi轉換成dspace-dlll.vmdk的話,那麼指令要這樣下:

"D:\Program Files\Oracle\VirtualBox\VBoxManage.exe" clonehd dspace-dlll.vdi dspace-dlll.vmdk --form vmdk

2012-04-24_065054 cmd

如果指令正確的話,就會看到下面出現「0%…」的訊息。進度每隔10%都會顯示一次,你也可以看到目錄底下的「dspace-dlll.vmdk」逐漸變大。

因為VMDK會稍微壓縮資料的樣子,轉換完成之後,原本26.5GB的VDI居然只剩下11.4GB的VMDK。這對硬碟空間老是抓襟見肘的我們來說,真是件好事。

Proxmox VE執行VMDK結果

接著將轉換完成的dspace-dlll.vmdk放到Proxmox VE上執行看看。

基於Proxmox VE特殊的目錄架構,你必須先將硬碟檔案透過網路上傳到指令目錄底下。舉例來說,我現在要建立的KVM虛擬機器是VMID 103,名稱「test-dspace-dlll」。那麼vmdk檔名就要改成「vm-103-disk-1.vmdk」,並上傳到目錄「/var/lib/vz/images/103/」。

2012-04-24_182234 proxmox

至於建立KVM虛擬機器與掛載vm-103-disk-1.vmdk這些細節我就不說明了。

2012-04-24_065449 on kvm

設定好之後就能夠直接運作,上圖就是正常開啟的成果囉。


小結:KVM也需要Virtual Appliance

既然KVM支援VMDK,那麼也應該可以支援VMware大力推廣的虛擬應用(Virtual Appliance)吧?我之前介紹過Proxmox VE內建的OpenVZ系列虛擬應用樣板,以及最近發現的Turnkey Linux ,而KVM的虛擬應用就比較少。儘管Proxmox VE都已經進入第二版,但是這部份並沒有什麼加強就是了。

透過上述的轉換工具,各種虛擬機器之間的隔閡越來越低。下一步就是對各種虛擬機器的整合管理,根據機器負載需求即時地遷移需要的資源。這個議題已經有不少計畫進行中,許多工具也放在網路上等我去研究。可惜近期內我應該沒什麼時間好好摸索就是了。

(more...)

光碟救援模式(rescue mode)用fsck修復無法啟動的CentOS

光碟救援模式(rescue mode)用fsck修復無法啟動的CentOS

2012-04-23_154621 光碟畫面

繼今天(實際上是昨天)下午寫的用救援模式暫時進入原本系統的研究,之後在救援模式用fsck花了許多時間修復檔案系統之後,居然順利讓我修復完成並且正常啟動了!

以下就記錄修復的過程。


問題敘述

這個作業系統是CentOS 5 final,提供DSpace服務。

前一篇一樣,我要處理的問題都是開機過程「Checking filesystems」時出現「e2fsck: aborted [FAILED]」 錯誤,然後Linux指示以下訊息:

*** An error occurred during the file system check.
*** Dropping you to a shell; the system will reboot
*** when you leave the shell.
Give root password for maintenance
(or type Control-D to continue): _

也許可以在維護模式(maintenance)中進行修復,但我摸了一陣子搞不太定。倒是利用CentOS 5 Final的救援模式,用fsck順利修復了系統本身。

從光碟進入救援模式 (rescue mode)

2012-04-23_234849 linux rescue

用光碟開機之後,輸入「linux rescue」就可以進入救援模式。上圖是按下<F5>之後對救援模式的說明。

接著要設定語系、鍵盤與網路。

2012-04-23_235030 continue

最後要決定是否掛載原本的系統。因為我們是要修復原本壞掉的系統,所以這邊要選擇「Continue」。

2012-04-23_235123 chroot hint

掛載完成,原本的系統被掛載到「/mnt/sysimage/」。

2012-04-23_235214 cmd   

接著會進入指令列模式,可以輸入指令進行操作。

請輸入以下指令,將原本的檔案系統視為根目錄:

sh-3.1# chroot /mnt/sysimage/

試著查詢一下現在的目錄看看吧:

sh-3.1# ls
bin dev halt lost+found mnt pgdb sbin sys var
boot dspace home media net proc selinux tmp
core.15890 etc lib misc opt root srv usr

其他的細節請看前一篇的「從光碟進入救援模式(rescue)」。

利用fsck修復檔案系統

在使用fsck修復之前,必須要先卸載要修復的檔案系統,否則會造成檔案系統毀損。

透過「mount」指令,可以知道要修復的檔案系統「/dev/VolGroup00/LogVol00」掛載在「/」根目錄。現在我們使用「umount」卸載檔案系統:

sh-3.1# umount /

接著就能用「fsck」來修復檔案系統囉,指令如下:

sh-3.1# fsck -y /dev/VolGroup00/LogVol00

記得要加上「-y」選項喔,不然會確認按到累死。

image

看到以下訊息,就知道fsck開始修復動作了:

fsck 1.39 (29-May-2006)
e2fsck 1.39 (29-May-2006)
/dev/VolGroup00/LogVol00 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes

修復的過程非常久。我的硬碟有2T大小,修復大概也要快兩個小時有吧。總之請耐心等待。

2012-04-24_052701 finish

修復完成之後會看到上圖的訊息。

image

重開機看看,這次就能夠正常運作囉!


小結:能在維護模式下用fsck修復嗎?

雖然透過光碟的救援模式(rescue mode)使用fsck的確能修復檔案系統,但畢竟這還是要片光碟,比較麻煩。不知道能不能在維護模式(maintenance)中就直接使用fsck修復呢?

2012-04-24_004010 maintenance

當然,直接用上述的作法來做,只會收到以下錯誤訊息:

Error allocating icount link information: Memory allocation failed
e2fsck: aborted

到這邊我就不知道該怎麼做才好了。因為時間的限制,我也沒有繼續找下去。未來有機會再繼續研究吧。

(more...)

用光碟救援模式進入壞掉的CentOS系統

用光碟救援模式進入壞掉的CentOS系統

2012-04-23_154456 dspace 虛擬機器無法開啟

我這邊使用VirtualBox架設CentOS的時候,時常遇到開機程序無法順利進行的問題。雖然可以進入單機維護模式,但卻不能透過網路將檔案拿出來。後來發現可以用CentOS光碟的Linux救援模式來開機,並順利進入原本應該是壞掉的系統中,而且居然還可以順利開啟網頁服務來使用,就像是在原本的系統一樣。

當然,這並不是完整的解決方案,而只是我還在研究如何修復中的一個發現的筆記而已。


問題敘述

上述的問題都是在開機過程中進入到「Checking filesystems」的步驟時出現「e2fsck: aborted [FAILED]」 的錯誤訊息,然後出現以下訊息:

*** An error occurred during the file system check.
*** Dropping you to a shell; the system will reboot
*** when you leave the shell.
Give root password for maintenance
(or type Control-D to continue): _

雖然可以輸入root密碼進入維護模式,但是因為不能用網路,所以還要找其他的方法來取出檔案,對我來說是比較麻煩的。

於是我嘗試使用CentOS 5 Final的光碟來修復看看。

從光碟進入救援模式(rescue)

2012-04-23_154621 光碟畫面

從CentOS 5 Final光碟中看到的畫面如上。如果要進入救援模式(rescue mode),我們可以先按 <F5>看一下說明。

2012-04-23_154647 救援模式說明

簡單來說,輸入「linux rescue」並按下 <ENTER>就可以進入救援模式。

 2012-04-23_154722 linux rescue

救援模式設定

進入救援模式之後,會有幾項設定需要確認:

2012-04-23_154812 語言

操作語言。用英文最穩啦,沒有亂碼問題。

2012-04-23_154835 鍵盤

鍵盤配置。台灣通常都是用美規的「us」。

 2012-04-23_154904 網路

是否要啟動網路,選擇「Yes」。

2012-04-23_154925 網路設定

網路的相關配置。按<TAB>切換操作項目,移到「OK」進入下一步。

2012-04-23_154949 讀取模式

掛載原本系統

是否掛載原本的檔案系統到「/mnt/sysimage」。選擇「Continue」吧。

2012-04-23_155045 chroot

掛載完成之後,你就可以用「chroot /mnt/sysimage」指令進入原本的root環境。

進入原本系統

2012-04-23_155125 cmd

接著進入到了指令列,輸入「chroot /mnt/sysimage」 吧。

2012-04-23_155152 輸入之後

雖然系統沒有回應,但現在你已經是以root身分進入原本的系統中,而各種服務都可以正常使用。

啟動DSpace服務

以我在實驗室常用的DSpace來說,你可以透過以下指令來啟動DSpace:

sh-3.1# export JAVA_HOME=/usr/java/jdk1.6.0_06
sh-3.1# /opt/apache-tomcat-6.0.16/bin/startup.sh
sh-3.1# /etc/init.d/postgresql start

同理,要啟動SSH也可以輸入以下指令:

sh-3.1# service sshd start

就跟在原本系統一樣操作。


小結:救援模式只是應急的技巧

儘管用這種方式可以啟動網頁服務,至少大致上看起來是沒問題,不過畢竟不是長久之道。

我本來想試著用upgrade升級原本系統,可是失敗了。現在試著在救援模式中用fsck –y /dec/VolGroup00/LogVol00來修復看看,目前仍在跑,但我覺得成功機率應該不大。

最後的方法就是先在救援模式中取出必要的檔案,然後再架一台同樣環境但可以正常運作的機器,把檔案復原回去吧。

(more...)