VDI轉換成KVM可用之VMDK

早期我常使用的虛擬機器環境為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，就是本篇的主要重點囉。

必須註明的是，只有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

如果指令正確的話，就會看到下面出現「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/」。

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

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

小結：KVM也需要Virtual Appliance

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

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

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

繼今天(實際上是昨天)下午寫的用救援模式暫時進入原本系統的研究，之後在救援模式用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)

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

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

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

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

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

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

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」選項喔，不然會確認按到累死。

看到以下訊息，就知道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大小，修復大概也要快兩個小時有吧。總之請耐心等待。

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

重開機看看，這次就能夠正常運作囉！

小結：能在維護模式下用fsck修復嗎？

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

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

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

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

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

我這邊使用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)

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

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

救援模式設定

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

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

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

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

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

掛載原本系統

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

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

進入原本系統

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

雖然系統沒有回應，但現在你已經是以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來修復看看，目前仍在跑，但我覺得成功機率應該不大。

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