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

[Kevin Wolf]

Shahar Frank schrieb:
>> 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 ;-).

Right. Extending a file format in a compatible way when the format is
not designed to be extended, is always hackish.

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

In general yes, but I think in this case it's reasonable to make the
extension. The code that deals with this data is in two places: Creating
the image and opening it. When the image is opened, the path is copied
to a normal zero terminated string, so no problems there.

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

As Dan said, probing is error prone and likely to lead to security
problems. You should provide a way to specify the right format instead
of increasing security risks.

You really _can't_ tell raw images from other formats. So don't force
any user to do it to achieve what he wants.

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

That would be another possibility to specify the file format, yes.

With respect to blurring boundaries: Probably it should be defined first
what a protocol really is. There are people who believe that there is no
difference at all between formats and protocols. There are other people
who think it are two completely different things. And the code doesn't
say who's right.

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

Sounds good. I'm looking forward to your upcoming patches.

Kevin