From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LhPAW-0005OU-Ja for qemu-devel@nongnu.org; Wed, 11 Mar 2009 10:12:24 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LhPAU-0005M5-Re for qemu-devel@nongnu.org; Wed, 11 Mar 2009 10:12:24 -0400 Received: from [199.232.76.173] (port=57922 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LhPAU-0005M0-PC for qemu-devel@nongnu.org; Wed, 11 Mar 2009 10:12:22 -0400 Received: from rv-out-0708.google.com ([209.85.198.246]:54258) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LhPAU-0001A9-9w for qemu-devel@nongnu.org; Wed, 11 Mar 2009 10:12:22 -0400 Received: by rv-out-0708.google.com with SMTP id f25so19017rvb.22 for ; Wed, 11 Mar 2009 07:12:20 -0700 (PDT) Message-ID: <49B7C6BF.6030803@codemonkey.ws> Date: Wed, 11 Mar 2009 09:12:15 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <49B79D50.4090300@redhat.com> In-Reply-To: <49B79D50.4090300@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: [Qemu-devel] Re: Problems KVM-84 Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Jay Mann , Uri Lublin , qemu-devel , kvm@vger.kernel.org Avi Kivity wrote: > Jay Mann wrote: >> Hi, >> >> I just downloaded built and installed kvm-84 on ubuntu Hardy x64 >> 2.6.24-23- >> server and I’m getting the following 2 problems that did not exists >> in kvm-83. >> >> 1. The qemu emulater (bios screen) takes a long time to start (~10 >> seconds), and subsequently Libvirt times out when I try to start a >> guest VM from virsh. > > This is caused by qemu r6404: > > commit 5d4cbd78aa33f6d034a62207c99ad0b64af44621 > Author: aliguori > Date: Thu Jan 22 18:57:22 2009 +0000 > > block-qcow2: keep highest allocated byte (Uri Lublin) > We want to know the highest written offset for qcow2 images. > This gives a pretty good (and easy to calculate) estimation to how > much more allocation can be done for the block device. > It can be usefull for allocating more diskspace for that image > (if possible, e.g. lvm) before we run out-of-disk-space > Signed-off-by: Uri Lublin > Signed-off-by: Anthony Liguori > > Scanning the file at startup is slow. We need to find a better way. Any quick ideas? Seems like this is broken by design. Unless we can find a quick fix, I'm going to revert this in the stable tree. Regards, Anthony Liguori