* Re: [Qemu-devel] Comparison of virtual disks?
2015-05-03 8:16 [Qemu-devel] Comparison of virtual disks? Erik Rull
@ 2015-05-04 11:14 ` Max Reitz
2015-05-04 12:27 ` Paolo Bonzini
0 siblings, 1 reply; 3+ messages in thread
From: Max Reitz @ 2015-05-04 11:14 UTC (permalink / raw)
To: Erik Rull, qemu-devel@nongnu.org
[-- Attachment #1: Type: text/plain, Size: 2783 bytes --]
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,
>
> Erik
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.
Max
Konsole output
[-- Attachment #2: Type: text/html, Size: 3614 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread