目前主要有那些格式來作爲虛擬機的鏡像：
raw
(default) the raw
format is a plain binary p_w_picpath of the disc p_w_picpath, and is very portable.
On filesystems that support sparse files, p_w_picpaths 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 p_w_picpaths 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 p_w_picpath only represents changes made to an underlying disk p_w_picpath（這個特性SUN ZFS表現的淋漓盡致）
支持多個snapshot，對歷史snapshot進行管理
支持zlib的磁盤壓縮
支持AES的加密
vmdk
VMware 3 & 4, or 6 p_w_picpath format, for exchanging p_w_picpaths with that product
VMware
的格式，這個格式說的蛋疼一點就有點牛X，原本VMware就是做虛擬化起家，自己做了一個集羣的VMDK的pool，做了自己的虛擬機鏡像格式。又拉着
一些公司搞了一個OVF的統一封包。從性能和功能上來說，vmdk應該算最出色的，由於vmdk結合了VMware的很多能力，目前來看，KVM和XEN
使用這種格式的情況不是太多。但就VMware的Esxi來看，它的穩定性和各方面的能力還是可圈可點。
vdi
VirtualBox 1.1 compatible p_w_picpath format, for exchanging p_w_picpaths 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 p_w_picpath-raw.raw p_w_picpath-raw-converted.qcow