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

[Shahar Frank <sfrank@redhat.com>]

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

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

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

> Kevin

Shahar