From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:49279) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TqQfr-0004sm-C9 for qemu-devel@nongnu.org; Wed, 02 Jan 2013 10:56:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TqQfh-0007NZ-01 for qemu-devel@nongnu.org; Wed, 02 Jan 2013 10:56:11 -0500 Received: from indium.canonical.com ([91.189.90.7]:56458) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TqQfg-0007NV-QW for qemu-devel@nongnu.org; Wed, 02 Jan 2013 10:56:00 -0500 Received: from loganberry.canonical.com ([91.189.90.37]) by indium.canonical.com with esmtp (Exim 4.71 #1 (Debian)) id 1TqQff-0004Ol-BE for ; Wed, 02 Jan 2013 15:55:59 +0000 Received: from loganberry.canonical.com (localhost [127.0.0.1]) by loganberry.canonical.com (Postfix) with ESMTP id 463E72E808B for ; Wed, 2 Jan 2013 15:55:59 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Wed, 02 Jan 2013 15:50:11 -0000 From: Stefan Hajnoczi <1025244@bugs.launchpad.net> Sender: bounces@canonical.com References: <20120716123031.26191.29124.malonedeb@chaenomeles.canonical.com> <20121218101820.24095.3926.malone@soybean.canonical.com> Message-Id: <20130102155011.GA12357@stefanha-thinkpad.redhat.com> Errors-To: bounces@canonical.com Subject: Re: [Qemu-devel] [Bug 1025244] Re: qcow2 image increasing disk size above the virtual limit Reply-To: Bug 1025244 <1025244@bugs.launchpad.net> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Tue, Dec 18, 2012 at 10:18:20AM -0000, Andy Menzel wrote: > Any solution right now? I have a similar problem like Todor Andreev; > Our daily backup of some virtual machines (qcow2) looks like that: > = > 1. shutdown the VM > 2. create a snapshot via: "qemu-img snapshot -c nameofsnapshot..." > 3. boot the VM > 4. backup the snapshot to another virtual disk via: "qemu-img convert -f= qcow2 -O qcow2 -s nameofsnapshot..." > 5. DELETE the snapshot from VM via: qemu-img snapshot -d nameofsnapshot... It's not safe to modify the qcow2 file while the guest is running. This means Step 5 is not really safe and could result in an inconsistent image. This may also be causing the problem: the QEMU process has a variable with the next free cluster index. Since Step 5 runs as a separate process it does not update the QEMU process' next free cluster index variable. QEMU doesn't know that there are now free clusters within the image file because you updated the file behind QEMU's back - the result is that it grows the file. Please try deleting the last backup snapshot between Step 1 and Step 2. This way you'll free the space while QEMU isn't accessing the image file. When you boot up the image file again QEMU should reuse the freed clusters. Stefan -- = You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1025244 Title: qcow2 image increasing disk size above the virtual limit Status in QEMU: New Status in =E2=80=9Cqemu-kvm=E2=80=9D package in Ubuntu: Triaged Bug description: Using qemu/kvm, qcow2 images, ext4 file systems on both guest and host Host and Guest: Ubuntu server 12.04 64bit To create an image I did this: qemu-img create -f qcow2 -o preallocation=3Dmetadata ubuntu-pdc-vda.img 1= 0737418240 (not sure about the exact bytes, but around this) ls -l ubuntu-pdc-vda.img fallocate -l theSizeInBytesFromAbove ubuntu-pdc-vda.img The problem is that the image is growing progressively and has obviously no limit, although I gave it one. The root filesystem's image is the same case: qemu-img info ubuntu-pdc-vda.img image: ubuntu-pdc-vda.img file format: qcow2 virtual size: 10G (10737418240 bytes) disk size: 14G cluster_size: 65536 and for confirmation: du -sh ubuntu-pdc-vda.img 15G ubuntu-pdc-vda.img I made a test and saw that when I delete something from the guest, the re= al size of the image is not decreasing (I read it is normal). OK, but when = I write something again, it doesn't use the freed space, but instead grows = the image. So for example: 1. The initial physical size of the image is 1GB. 2. I copy 1GB of data in the guest. It's physical size becomes 2GB. 3. I delete this data (1GB). The physical size of the image remains 2GB. 4. I copy another 1GB of data to the guest. 5. The physical size of the image becomes 3GB. 6. And so on with no limit. It doesn't care if the virtual size is less. Is this normal - the real/physical size of the image to be larger than the virtual limit??? To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1025244/+subscriptions