Hello,
The introduction in the wiki page present several advantages of qcow2 [1]. But I'm a little confused. I really appreciate if any one can give me some help on this :).
(1) Currently the raw format doesn't support COW. In other words, a raw image cannot have a backing file. COW depends on the mapping table on which we it knows whether each block/cluster is present (has been modified) in the current image file. Modern file-systems like xfs/ext4/etc. provide extent/block allocation information to user-level. Like what 'filefrag' does with ioctl 'FIBMAP' and 'FIEMAP'. I guess the raw file driver (maybe block/raw-posix.c) may obtain correct 'present information about blocks. However this information may be limited to be aligned with file allocation unit size. Maybe it's just because a raw file has no space to store the "backing file name"? I don't think this could hinder the useful feature.
(2) As most popular filesystems support delay-allocation/on-demand allocation/holes, whatever, a raw image is also thin provisioned as other formats. It doesn't consume much disk space by storing useless zeros. However, I don't know if there is any concern on whether fragmented extents would become a burden of the host filesystem.
(3) For compression and encryption, I'm not an export on these topics at all but I think these features may not be vital to a image format as both guest/host's filesystem can also provide similar functionality.
(4) I don't have too much understanding on how snapshot works but I think theoretically it would be using the techniques no more than that used in COW and backing file.
After all these thoughts, I still found no reason to not using a 'raw' file image (engineering efforts in Qemu should not count as we don't ask for more features from outside world).
I would be very sorry if my ignorance wasted your time.
references:
"
QEMU supports several image types. The "native" and most flexible type is qcow2, which supports copy on write, encryption, compression, and VM snapshots.