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

[Kevin Wolf]

Shahar Frank schrieb:
> ----- "Kevin Wolf" <address@hidden> 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.

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).

>>> 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?

Kevin