As I wrote about on the virt-tools site, you presently need to make a number of choices about how to store disk images — file or LV? allocated or sparse? raw or qcow2?
If you’ve decided to go with using a host file, raw is the obvious choice, but qcow2 offers more features, like compression, snapshots, and backing files. Unfortunately the flexibility of qcow2 makes it somewhat slower, and so Stefan Hajnoczi at IBM has proposed a simplified qcow-like format called QED.
Stefan’s description summarises the problems and the proposed solution well:
QEMU Enhanced Disk format is a disk image format that forgoes features found in qcow2 in favor of better levels of performance and data integrity. Due to its simpler on-disk layout, it is possible to safely perform metadata updates more efficiently.
Installations, suspend-to-disk, and other allocation-heavy I/O workloads will see increased performance due to fewer I/Os and syncs. Workloads that do not cause new clusters to be allocated will perform similar to raw images due to in-memory metadata caching.
The format supports sparse disk images. It does not rely on the host filesystem holes feature, making it a good choice for sparse disk images that need to be transferred over channels where holes are not supported.
QED won’t contain compression or encryption which Stefan argues (rightly IMHO) are already done better at other levels in the stack. A new format is a chance to think about what has changed in filesystems and block devices since last time, notably support for TRIM, the popularity of extent-based filesystems, and encryption now being found in most guest OSes (so not needed in the block device). We can also learn from what went wrong with qcow2, such as its propensity towards disk corruption when used in some configurations.
Of course libguestfs will get QED support for free, since it will come with qemu.