From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52770) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XyWVw-0004x9-CR for qemu-devel@nongnu.org; Tue, 09 Dec 2014 20:56:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XyWVp-0007X0-BU for qemu-devel@nongnu.org; Tue, 09 Dec 2014 20:56:28 -0500 Received: from mail.hq.newdream.net ([66.33.206.127]:41369) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XyWVp-0007Wq-3c for qemu-devel@nongnu.org; Tue, 09 Dec 2014 20:56:21 -0500 Message-ID: <5487A890.7010105@inktank.com> Date: Tue, 09 Dec 2014 17:57:36 -0800 From: Josh Durgin MIME-Version: 1.0 References: <20141205153210.GA4573@localhost.localdomain> <5481E4E7.9010402@redhat.com> <20141208135827.GB2836@localhost.localdomain> <54867206.6090009@inktank.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] qcow2: Can create qcow2 image format on rbd server List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Jun Li , Jun Li , qemu-devel , Max Reitz On 12/09/2014 01:49 AM, Stefan Hajnoczi wrote: > On Tue, Dec 9, 2014 at 3:52 AM, Josh Durgin 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