[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Comparison of virtual disks?

From: Max Reitz
Subject: Re: [Qemu-devel] Comparison of virtual disks?
Date: Mon, 04 May 2015 13:14:33 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0

On 03.05.2015 10:16, Erik Rull wrote:
Hi all,

is there a comparison chart of the different disk formats supported by QEMU? Especially throughput, latencies and robustness against unexpected power loss on the host would be interesting.

Thanks a lot.

Best regards,


Hi Erik,

I'm sorry, but I don't know whether such a chart exists (the closest thing I know is http://en.wikipedia.org/wiki/Category:Disk_images - which is not very close...). However, the general assumption we as developers are working with is that if the user's top priority is performance, they should use raw; and if they want to use all of the features qemu's block layer provides, they should use qcow2. All other formats are implemented merely for compatibility and ideally they should not be used for running VMs, but only for converting them to qcow2 using qemu-img convert.

Especially considering performance (throughput and latency), qcow2 will probably be the only format that we are really willing to work on. For the other drivers, the general idea is that "reasonably fast" is enough, but we probably won't go out of our way to make the implementations as fast as possible.

On the other hand, other formats may support special raw-like operating modes (e.g. vpc does), making them potentially automatically as fast as raw is, if configured appropriately.

Finally, there is robustness: raw will be as robust as it gets, because it should behave just like a real disk. For qcow2, we took special care to make sure the image will not be corrupted if qemu or the host crash. There are options like cache=unsafe and lazy-refcounts=on, which may corrupt the image in case of a crash, but at least the latter results in a special flag being set which makes qemu check and, if need be, repair the image the next time it is used. Speaking of checking and repairing, that's something that is only really implemented for qcow2, too. From what I can see, qed supports it, too; vdi and vmdk only support checking (I don't know how thorough it is); and vhdx has a journal which I guess means it is pretty safe against unexpected crashes, too.

We are trying to make all formats resistent against unexpected crashes (by flushing metadata whenever necessary), but I think it is safe to say here too we are paying special attention to qcow2.

So, all in all, raw is the format of choice if all you need is performance; if you do need features not offered by raw, qcow2 (the "QEMU image format") is the recommended choice. Or, to quote qemu-img's manpage: "For running VMs, it is recommended to convert the disk images to either raw or qcow2 in order to achieve good performance."

Again, sorry I don't have a full chart to present to you.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]