qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Josh Durgin
Subject: Re: [Qemu-devel] qcow2: Can create qcow2 image format on rbd server
Date: Tue, 09 Dec 2014 17:57:36 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0

On 12/09/2014 01:49 AM, Stefan Hajnoczi wrote:
On Tue, Dec 9, 2014 at 3:52 AM, Josh Durgin <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]