[Qemu-devel] Comparison of virtual disks?

[Qemu-devel] Comparison of virtual disks?

[Erik Rull]

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

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

[Max Reitz]

[-- 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 --]

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

[Paolo Bonzini]

On 04/05/2015 13:14, Max Reitz wrote:
> 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.

In addition to this, there are a bunch of image formats that have good
read performance: I can think of vhdx, vmdk, vdi.  These can be used as
backing images for qcow2, for example the virt-v2v tool uses this trick
to convert Hyper-V and VMware images without copying them first.

Paolo