qcow二、raw、vmdk等鏡像格式

qcow二、raw、vmdk等鏡像格式

 來源 http://www.cnblogs.com/feisky/archive/2012/07/03/2575167.html

雲計算用一個朋友的話來講:」作雲計算最苦逼的就是得時時刻刻爲一些可能一生都碰不到的事作好準備。更苦逼的就是剛覺得一個問題不會遇到，馬上就發生了。。。「。這個還真的沒有辦法，誰讓哥我是搞雲計算的呢，簡單一個虛擬化就搞的你蛋疼，你還能想其它的嗎？一直糾結在作虛擬化使用什麼鏡像格式，剛剛開始用了raw的file，後來發現LVM的不少特性對於虛擬化仍是有比較理想的能力，並且性能也很不錯就用了LVM。後來被VMware騙了跑去搞Esxi接觸了VMDK，最近研究openstack發現了qcow2格式，貌似如今很流行呀。也說不上分析這些鏡像格式的能力，就簡單說說本身的一些使用心得。

目前主要有那些格式來做爲虛擬機的鏡像：
raw
(default) the raw format is a plain binary image of the disc image, and is very portable. On filesystems that support sparse files, images in this format only use the space actually used by the data recorded in them.
老牌的格式了，用一個字來講就是裸，也就是赤裸裸，你隨便dd一個file就模擬了一個raw格式的鏡像。因爲裸的完全，性能上來講的話仍是不錯的。目前來看，KVM和XEN默認的格式好像仍是這個格式。由於其原始，有不少原生的特性，例如直接掛載也是一件簡單的事情。
裸的好處還有就是簡單，支持轉換成其它格式的虛擬機鏡像對裸露的它來講仍是很簡單的（若是其它格式須要轉換，有時候仍是須要它作爲中間格式），空間使用來看，這個很像磁盤，使用多少就是多少（du -h看到的大小就是使用大小），但若是你要把整塊磁盤都拿走的話得全盤拿了（copy鏡像的時候），會比較消耗網絡帶寬和I/O。接下來還有個有趣的問題，若是那天你的硬盤用着用着不夠用了，你咋辦，在買一塊盤。但raw格式的就比較犀利了，能夠在原來的盤上追加空間：
dd if=/dev/zero of=zeros.raw bs=1024k count=4096（先建立4G的空間）
cat foresight.img zeros.raw > new-foresight.img（追加到原有的鏡像以後）
固然，好東西是吹出來的，誰用誰知道，仍是有挺多問題的。因爲原生的裸格式，不支持snapshot也是很正常的。傳說有朋友用版本管理軟件對raw格式的文件作版本管理從而達到snapshot的能力，估計可行，但沒試過，這裏也不妄加評論。但若是你使用LVM的裸設備，那就另當別論。說到LVM仍是十分的犀利的，當年用LVM作虛擬機的鏡像，那性能槓槓的。並且如今好多兄弟用虛擬化都採用LVM來作的。在LVM上作了不少的優化，國外據說也有朋友在LVM增量備份方面作了不少的工做。目前來LVM的snapshot、性能、可擴展性方面都仍是有至關的效果的。目前來看的話，備份的話也問題不大。就是在虛擬機遷移方面仍是有很大的限制。但目前虛擬化的現狀來看，真正須要熱遷移的狀況目前需求還不是是否的強烈。雖然使用LVM作虛擬機鏡像的相關公開資料比較少，但目前來看犧牲一點靈活性，換取性能和便於管理仍是不錯的選擇。

對於LVM相關的特性及使用能夠參考以下連接：

http://www.ibm.com/developerworks/linux/library/l-lvm2/index.html

cow
copy-on-write format, supported for historical reasons only and not available to QEMU on Windows
曾經qemu的寫時拷貝的鏡像格式，目前因爲歷史遺留緣由不支持窗口模式。從某種意義上來講是個棄嬰，還沒得它成熟就死在腹中，後來被qcow格式所取代。

qcow
the old QEMU copy-on-write format, supported for historical reasons and superseded by qcow2

一代的qemu的cow格式，剛剛出現的時候有比較好的特性，但其性能和raw格式對比仍是有很大的差距，目前已經被新版本的qcow2取代。其性能能夠查看以下連接：
http://www.linux-kvm.org/page/Qcow2

qcow2
QEMU copy-on-write format with a range of special features, including the ability to take multiple snapshots, smaller images on filesystems that don’t support sparse files, optional AES encryption, and optional zlib compression
如今比較主流的一種虛擬化鏡像格式，通過一代的優化，目前qcow2的性能上接近raw裸格式的性能，這個也算是redhat的官方渠道了，哈哈，但願有朋友能拍他們磚：

https://fedoraproject.org/wiki/Features/KVM_qcow2_Performance

對於qcow2的格式，幾點仍是比較突出的，qcow2的snapshot，能夠在鏡像上作N多個快照：

• 更小的存儲空間，即便是不支持holes的文件系統也能夠（這下du -h和ls -lh看到的就同樣了）
• Copy-on-write support, where the image only represents changes made to an underlying disk image（這個特性SUN ZFS表現的淋漓盡致）
• 支持多個snapshot，對歷史snapshot進行管理
• 支持zlib的磁盤壓縮
• 支持AES的加密

vmdk 
VMware 3 & 4, or 6 image format, for exchanging images with that product
VMware的格式，這個格式說的蛋疼一點就有點牛X，本來VMware就是作虛擬化起家，本身作了一個集羣的VMDK的pool，作了本身的虛擬機鏡像格式。又拉着一些公司搞了一個OVF的統一封包。從性能和功能上來講，vmdk應該算最出色的，因爲vmdk結合了VMware的不少能力，目前來看，KVM和XEN使用這種格式的狀況不是太多。但就VMware的Esxi來看，它的穩定性和各方面的能力仍是可圈可點。

vdi
VirtualBox 1.1 compatible image format, for exchanging images with VirtualBox.
SUN收購了VirtualBox，Oracle又收購了SUN，這麼說呢，vdi也算虛擬化這方面的一朵奇葩，惋惜的是入主的兩家公司。SUN太專一於技術（能夠說是IT技術最前端也不爲過），Oracle又是開源殺手（mysql的沒落）。單純從能力上來講vdi在VirtualBox上的表現仍是不錯的。也是不錯的workstation級別的產品。

說了這麼多虛擬機鏡像格式，這麼多虛擬化，作雲計算的傷不起呀，得爲長期發展考慮，也有朋友對鏡像的轉換作了不少事情，簡單看看幾種鏡像的轉化：

VMDK–>qcow2:

kevin@kevin:~# qemu-img convert -f vmdk -O qcow2 SLES11SP1-single.vmdk SLES11SP1-single.img

http://www.ibm.com/developerworks/cn/linux/l-cn-mgrtvm3/index.html

qcow2–>raw:

kevin@kevin:~$ qemu-img convert -O qcow2 image-raw.raw image-raw-converted.qcow

 

ova轉ovf

ovftool --lax Centos6.6-lamp.ova Centos6.6-lamp.ovf
ovftool --overwrite --shaAlgorithm=sha1 --lax Centos6.6-lamp.ova Centos6.6-lamp.ovf

修改.ovf文件，將
<vssd:VirtualSystemType>virtualbox-2.2</vssd:VirtualSystemType>
修改成
<vssd:VirtualSystemType>vmx-07</vssd:VirtualSystemType>

修改mf文件的sha1
echo sha1(file_get_contents('xxx.mf'))

 

================= End