Re: [Qemu-devel] qcow2: Can create qcow2 image format on rbd server

[Josh Durgin <josh.durgin@inktank.com>]

On 12/09/2014 01:49 AM, Stefan Hajnoczi wrote:
> On Tue, Dec 9, 2014 at 3:52 AM, Josh Durgin <josh.durgin@inktank.com> wrote:
>> On 12/08/2014 05:58 AM, Jun Li wrote:
>>>
>>> On Fri, 12/05 18:01, Max Reitz wrote:
>>>>
>>>> On 2014-12-05 at 16:32, Jun Li wrote:
>>>>>
>>>>> Currently, qemu-img can not create qcow2 image format on rbd server.
>>>>> Analysis
>>>>> the code as followings:
>>>>> when create qcow2 format image:
>>>>> qcow2_create2
>>>>>     bdrv_create_file(filename, opts, &local_err);  --> Here will create a
>>>>> 0 size
>>>>>     file(e.g: file1) on rbd server.
>>>>>     ...
>>>>>     ret = bdrv_pwrite(bs, 0, header, cluster_size); --> So here can not
>>>>> write
>>>>>     qcow2 header into file1 due to the file1's length is 0. Seems
>>>>>     qemu_rbd_aio_writev can not write beyond EOF.
>>>>>     ...
>>>>>
>>>>> As above analysis, there are two methods to solve the above bz as
>>>>> followings:
>>>>> 1, When create file1, just create a fixed-size file1 on rbd server(not 0
>>>>> size).
>>>>
>>>>
>>>> Should be possible by using -o preallocation=falloc or -o
>>>> preallocation=full.
>>>
>>>
>>> Although "-o preallocation=falloc or -o preallocation=full" can create a
>>> qcow2
>>> format image successfully, but when perform "qemu-img resize file.qcow2
>>> +500M", then use the extend 500M disk image still hit the same issue(as
>>> rbd
>>> block driver does not support growable file).
>>
>>
>> Why not use 'rbd resize' and raw images instead?
>> rbd already supports snapshots, cloning, thin provisioning, and
>> differential backup natively, so putting qcow2 on top tends to just add
>> overhead.
>
> In general, I don't expect many people to use qcow2 on rbd either.
>
> However, qcow2 does work on top of iSCSI, LVM, or host block devices
> and some users actually use this feature (even though there is LVM
> thin provisioning, for example).  So the failure on rbd is unexpected
> and inconsistent.
>
> The way it works on other protocols is that the user must first create
> an adequately sized volume before running qemu-img create.  With rbd
> this doesn't work because we truncate the volume to 0 bytes during
> create.
>
> Either we need to fix this (without losing the ability to qemu-img
> create -f raw rbd:... 10G) or we should have a clear error message.
>
> The simplest way would just be to detect rbd create with size 0 and
> print a clear error message like "image formats that grow on demand
> are not supported on rbd".

Either way sounds fine to me. I don't think it's worth adding the
complexity of dynamic growth to the rbd driver when it can be solved
simply at higher levels.

Josh