Selection of Virtual Machine hard disk formats: qcow2, raw, etc.

Selection of Virtual Machine hard disk formats: qcow2, raw, etc.
There was a time when I was confused about the format of Virtual Machine hard disk. In 2009, I finally came to some conclusions (the following ideas are basically applicable to other virtual machines)
After searching, we found that qcow2 is used as the virtual hard disk by default for most qemu or KVM instances, but qemu uses raw by default.
The following describes two formats of qemu wiki:
Raw
Raw disk image format (default ). this format has the advantage of being simple and easily exportable to all other emulators. if your file system supports holes (for example in ext2 or ext3 on Linux or NTFS on Windows), then only the written sectors will reserve space. use qemu-IMG info to know the real size used by the image or LS-ls on Unix/Linux.
Qcow2
Qemu image format, the most versatile format. use it to have smaller images (useful if your filesystem does not supports holes, for example on Windows), optional AES encryption, zlib based compression and support of multiple VM snapshots.
Raw advantages (there are too few materials available, and I don't know if it is correct ):
1. Simple and can be exported as virtual hard disk formats of other virtual machines
2. Use space based on actual usage, instead of the previously set maximum value (for example, set the maximum value of 20 GB, but actually only use 3 GB ). -- The host partition must support hole (for example, ext2 ext3 NTFs)
3. In the future, the maximum space value can be changed (increase the maximum value of 20 GB to 200 GB, and qcow2 can also be changed, but convert it to raw)
4. data transmission between the host and the virtual machine can be directly mounted by the host machine without enabling the Virtual Machine (Note: do not enable the virtual machine at this time)
Qcow2 advantages:
1. Smaller virtual hard disk space (especially when the host partition does not support hole)
2. Optional AES encryption, zlib based compression and support of multiple VM snapshots.
In addition, according to the Wiki of fedora12, the test result is that raw has better performance than qcow2, even the new version of qcow2. Http://fedoraproject.org/wiki/Featur...w2_Performance
If you rely solely on this information, raw seems to be more advantageous and more convenient. (Raw supports snapshot ???)
So, why do we all use qcow2 by default? Why?
Similarly, what are the advantages and disadvantages of Virtual Machine hard disk formats such as vmdk VDI?
The raw format is a "Direct Read and direct write" format, which has no special features. That is to say, qcow2 has the two AES encryption, zlib based compression, and raw does not.
Kqemu is the kernel acceleration module of qemu, not KVM. In wiki, The qemu and KVM are divided into two parts, which are two different kernel acceleration modules.
Qemu runs 98, me, and XP very slowly, but Win95 and win2000 are fast, especially win2000 (nnd, win2000 seems to be the slowest in general computers ). 98. Me is fast. You can use customized windows, which is called lite.
However, looking back today, we found that raw is actually better:
Raw lacks four features compared to qcow2, but it can be solved in other ways:
1. encryption function: encrypt raw files as normal files.
2. snapshot function: Add raw to the version management directory. The specific settings may be slightly higher.
3. The host machine does not support the On-Demand punching mode (hole): This allows you to expand the maximum raw value based on your usage.
4. Hard disk compression: Just compress files on a common computer.
Raw has a function comparable to qcow2:
1. Higher efficiency than qcow2
2. Directly Reading and Writing the files in the Virtual Machine hard disk is "violent", but since it can be so violent, it is not afraid of any problems in the virtual machine.
3. good versatility. It is a general intermediate format that is converted to the format of other virtual machines, so you don't have to worry about converting the Virtual Machine System.
========================================================== ======================================
Supplement 1:
How to enable KVM and other virtual systems to obtain the original graphics acceleration function of local hardware:
Playfish mentioned on linuxsir that KVM can achieve native-level graphics acceleration performance.
I am still not familiar with SPICE. I feel like a virtual machine with a uniform backend/front-end graphical interface, but this can be achieved using remote desktop? (The two are different. Spice should be: Remote Desktop + Remote resource local ing)
I have just read the English introduction:
Hardware acceleration:
1. "client" 2D uses common Cairo Rendering
2. Use GDI in "client" windows and OpenGL in Linux
3. Use the "client" GPU to replace CPU rendering: This allows efficient rendering and improves the CPU usage of virtual machines.
4. "server" uses OpenGL for rendering
PS: This is very fun. No matter what type of virtual machine is, you can use local hardware based on the configuration of your computer. In this case, the same virtual machine, different computers have different effects.
========================================================== ======================================
Supplement 2:
What partitioning method should I use for the host machine partition where the virtual hard disk is located?
The key to the problem may be how many DDH partition formats are retained by the virtual hard disk of the virtual machine. For example, if the host uses ext3 and the virtual machine uses ext4, what is the performance of the virtual machine? Is ext3 performance or ext4 performance? -- I think the performance of ext3 should be the upper limit of the virtual machine, but there will be no improvement in ext4.
Maximum disk performance> maximum performance available for specific partition formats and systems> maximum performance available for Virtual Machine Virtual Disks> maximum performance available for operating systems and partition formats in virtual machines
After such multi-layer weakening, it is estimated that it is necessary to have a partition format specifically designed for virtual machines, such as LVM, to achieve higher performance.
In virtual machines, Linux swap still needs to be enabled, because you cannot be sure that you will use a lot of memory (especially for servers) one day, so that the memory you originally provided is not enough, so we need to reserve these spaces. With this buffer time, it is estimated that the problem can be solved online.
However, it is slow after swap is mounted. As I mentioned above, the hard disk performance of a VM can only reach the upper limit of the host's hard disk performance, rather than exceed it.
========================================================== ======================
Supplement 3:
Why is raw so good in the production environment?
This is not the case, because the four raw files listed above can be implemented in other ways. In fact, there is a premise that they can be shut down at any time. (You can do it without shutting down the server, but this is because it has not been verified much, and the security and stability are doubtful .)
Raw has many advantages, such as direct mounting.
These are all conditions that cannot be met in the production environment. Most of the requirements in the production environment are: Online Implementation/shutdown can be done (even underlying operations such as hard disk partitioning, so it will develop things like LVM ).
That is to say, raw may not be a good choice if you want to have more advanced hard drive features, stability, or guaranteed quality online.

 

Selection of Virtual Machine hard disk formats: qcow2, raw, etc.