Qcow2, raw, vmdk, and other image formats

Cloud computing uses the words of a friend :"The hardest thing to do with cloud computing is to always be prepared for something that may not be reached for the rest of your life. What is even harder is to think that a problem will not happen immediately...". There is really no way to do this. Who asked me to engage in cloud computing? A simple virtualization will hurt you. Can you think about anything else? I have been struggling with the image format used for virtualization. I just started to use raw files. Later I found that many features of LVM still have ideal capabilities for virtualization, LVM is also used for good performance. Later, VMWare cheated and ran to engage in esxi to access vmdk. Recently, openstack found the qcow2 format, which seems to be very popular now. Without analyzing the capabilities of these image formats, I would like to briefly talk about some of my usage experiences.

Currently, the following formats are used as Virtual Machine images:
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.
The old format is bare, that is, naked. You can simulate an image in raw format by dd a file. The performance is good because it is bare and thorough. Currently, the default formats of KVM and xen seem to be the same. Because of its original nature, there are many native features, such as direct mounting is also a simple task.
The advantage of Bare is that it is simple. It is very easy to convert Virtual Machine images in other formats to bare ones (if other formats need to be converted, sometimes they need to be used as intermediate formats ), in terms of space usage, this is similar to a disk, and the amount used is (the size seen by Du-H is the size used ), however, if you want to take the entire disk away, it will consume network bandwidth and I/O. Next, there will be an interesting question. If your hard disk is not enough to be used that day, what should you do? Buy a disk. However, the raw format is sharp. You can append space to the original disk:
Dd If =/dev/Zero of = zeros. Raw BS = 1024 k count = 4096 (create 4g space first)
Cat foresight. img zeros. raw> new-foresight.img (append to the original image)
Of course, there are still a lot of problems with who knows the good stuff. The native bare format does not support snapshot. It is said that a friend has used the version management software to manage raw files to achieve the snapshot capability. It is estimated that it is feasible, but he has not tried it. I will not comment on it here. However, if you are using a bare LVM device, it should be different. Speaking of LVM, it is still very sharp. When LVM was used as a virtual machine image, the performance was superb. Now many of our brothers use LVM for virtualization. I have made a lot of optimizations on LVM, and I have heard that some friends have done a lot of work on LVM Incremental backup. At present, the snapshot, performance, and scalability of LVM are still quite effective. Currently, backup is not a problem. There are still many restrictions on Virtual Machine migration. However, from the current status of virtualization, the demand for hot migration is not strong yet. Although there is little public information on using LVM for Virtual Machine images, it is a good choice to sacrifice a little flexibility in exchange for performance and ease of management.

For LVM-related features and usage, refer to the following link:

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
The image format copied when qemu was written. Currently, the window mode is not supported due to historical reasons. In a sense, it was an abandoned baby. Before it became mature, it died in the belly and was later replaced by the qcow format.

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

The cow format of the first generation of qemu has good features when it first appeared, but its performance is still quite different from that of the raw format. It has been replaced by the new version of qcow2. For more information about its performance, see the following link:
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
Currently, the mainstream virtualization image format has been optimized by a generation. Currently, qcow2 is similar to raw bare format, which is also the official redhat channel. Haha, I hope some friends can make their photos:

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

For the qcow2 format, there are still some outstanding points. For the qcow2 snapshot, you can create N multiple snapshots on the image:

• Smaller storage space, even if not supportedHolesThe file system can also be (the same as that seen by Du-H and LS-lH)
• Copy-on-write support, where the image only represents changes made to an underlying disk image (this feature is best performed by Sun ZFS)
• Supports multiple snapshots to manage historical snapshots.
• Supports zlib disk compression
• Support for AES Encryption

Vmdk
VMware 3 & 4, or 6 image format, for exchanging images with that product
The VMware format is a bit cool. VMware started from virtualization and made a cluster VMDK pool and its own virtual machine image format. Some companies have built an OVF uniform package. In terms of performance and functionality, vmdk should be the most outstanding. Because vmdk integrates many capabilities of VMware, at present, KVM and XEN use this format is not much. However, from the perspective of VMware Esxi, its stability and capabilities in various aspects are still commendable.

VDI
VirtualBox 1.1 compatible image format, for exchanging images with VirtualBox.
SUN acquired VirtualBox, and Oracle acquired SUN. In this case, vdi is also a wonderful thing in virtualization. Unfortunately, it is the two companies that have joined the company. SUN is too focused on technology (it can be said that it technology is not the frontend), Oracle is an open source killer (The decline of MySQL). In terms of capabilities, vdi is still doing well in VirtualBox. It is also a good workstation-level product.

After talking about so many virtual machine image formats and so many Virtualization Technologies, cloud computing cannot afford to hurt. for long-term development consideration, some friends have done a lot to convert images, let's take a look at the conversion of several images:

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

This article from: http://blog.prajnagarden.com /? P = 248