Re: [Qemu-devel][PATCH] Qemu image over raw devices

[Shahar Frank <sfrank@redhat.com>]

Kevin Wolf wrote:
> Shahar Frank schrieb:
>> ----- "Kevin Wolf" <kwolf@suse.de> wrote:
>>
>>> Shahar Frank schrieb:
>>>> The following patch enables QEMU to create and use images with any
>>>> format on top of a raw device. Note that -f <format> is not enough
>>> for
>>>> bcking files support.
>>> When would I need to explicitly specify the type of a backing file?
>> The patch doesn't allow you to specify a type (image format). It allows you to force probing. This is done to override the default block-device => raw semantics.
> 
> Ok, I see. But didn't we want to get rid of the probing whenever
> possible because you can't tell raw files from whatever other format
> reliably?
> 
>>>> The patch includes the following:
>>>>
>>>> 1. The check for block devices is weaken so you can override it by
>>>> specifying a protocol
>>>> 2. If a protocol exists but not found in the protocols list, the
>>> logic
>>>> falls back to image type probing. This means use can write
>>>> "probe:filename" or just ":filename"
>>> IIUC, on qemu side this is just another syntax for -drive format=xyz?
>>> Wouldn't it be better to add a parameter to qemu-img then instead of
>>> inventing new ways of specifying the format?
>> The problem is with the backing file, this format does not apply to the backing file and this is the correct behavior - the backing file can be of a different format. Note that the new way is just forcing probing.
> 
> You don't specify the backing file on the command line, so that's not
> what I meant. I really thought only of the parameters to qemu you
> specify on the command line.
> 

You specify the backing file in the "qemu-img create" command line.

> IMHO, the really correct behaviour would be that the image doesn't only
> save the path but also the image format of the backing file - and then
> add a parameter to qemu-img to specify that type.
> 
> This would need a change to qcow2 of course, but I think you can make it
> a compatible change: Writing something like "image.qcow2\0qcow2" as
> backing file to the image should do the trick. And then qcow2 would
> check if the driver is specified and opens the file with exactly that
> driver instead of guessing and possibly being fooled by a bad guest (ok,
> it's not that bad with a backing file because the guest can't write to
> it directly, but you can still commit).
> 

This is not a bad idea, but I think it is too close to be a hack ;-). 
The danger with such a hack is that it may introduce new unexpected 
corner cases such as cluster overflow due that added bytes, code that 
will be confused due the added sting (non zero terminated logic), etc. 
If QCOW2 had a general way to include extensions, I would use that, but 
I think that for now, all I suggesting is a way that use the existing 
protocol notation to force probing.

In fact, what I do is just use the following logic (which was already 
partially used): if you can't find the specified protocol fall back to 
probing. Please note that probing is anyhow the default behavior in most 
cases, so the change is just a way to override the block device default 
behavior.

An additional way I considered is just declaring QCOW2 as a protocol. 
This would allow you to specify "qcow2:/dev/store/lv1". But this blurs 
the boundaries between protocols and image formats (a boundary that is 
not clear enough even today...).

>>>> Note that if regular file/device path names are used, the previous
>>>> behavior is kept.
>>>>
>>>> lvcreate -L 5G -n base store
>>>> dd bs=32k if=win.qcow2 of=/dev/store/base
>>>> ./qemu-img info :/dev/store/base
>>>> lvcreate -L 2G -n l2 store
>>>> ./qemu-img create -b :/dev/store/base -f qcow2 /dev/store/l2
>>>> ./x86_64-softmmu/qemu-system-x86_64 -hda :/dev/store/l2 -L pc-bios/
>>>> lvcreate -L 2G -n l3 store
>>>> ./qemu-img create -b :/dev/store/l2 -f qcow2 /dev/store/l3
>>>> ./x86_64-softmmu/qemu-system-x86_64 -hda :/dev/store/l3 -L pc-bios/
>>> Does it even make sense to store qcow2 images on raw block devices?
>>> qcow2 are usually growing whereas devices tend to not change their
>>> size.
>>>
>> The idea is to allow QCOW2 (or similar formats) capabilities in SAN only environment, where SAN-FS is not applicable (for example because it is too expensive or too complex). 
>>
>> For the size issue, Logical volumes can be extended. In the near future some patches that allow monitoring the internal space usage and then extend the LV size are going to be posted to this list. Another issue that has to be handled is out of space (out of range) scenarios.
> 
> That sounds interesting. :-) How is growing LVs performance-wise? Just
> about the same as growing a file or does it take noticably longer?
>

This depends on your block mapping mechanism and the extension unit 
size. For Linux and LVM2, the underlying mechanism is the device mapper, 
and as much as I could see, it is pretty scalable so you can program a 
table with large amount of mapping without significant performance 
overhead. There is an issue of the number of LVM side mappings, but if 
you work in large enough units (say 64MB, 128MB or larger) it should be 
OK. I didn't play with other logical volumes managers, but I guess that 
the status is pretty much the same. If anybody knows differently, I 
would glad to know about it.

Comparing to files (systems), the allocation/extension unit is typically 
much bigger (4MB comparing to 4KB in FS) and the mapping scheme is much 
simpler (in most cases plain linear, no holes support, no trees, etc.) 
so LVMs perform better but are much less flexible. For our specific case 
it is the correct trade off.

> Kevin
> 
> 
Shahar