From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ma5BK-00053z-E6 for qemu-devel@nongnu.org; Sun, 09 Aug 2009 05:59:14 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ma5BF-0004zn-IR for qemu-devel@nongnu.org; Sun, 09 Aug 2009 05:59:13 -0400 Received: from [199.232.76.173] (port=47065 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ma5BF-0004ze-6p for qemu-devel@nongnu.org; Sun, 09 Aug 2009 05:59:09 -0400 Received: from mail2.shareable.org ([80.68.89.115]:51545) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Ma5BE-0005jF-KQ for qemu-devel@nongnu.org; Sun, 09 Aug 2009 05:59:08 -0400 Date: Sun, 9 Aug 2009 10:59:06 +0100 From: Jamie Lokier Message-ID: <20090809095906.GA518@shareable.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Qemu-devel] Virtual PC images still corrupt - but better than before List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: qemu-devel@nongnu.org I recently looked at the release notes for kvm-84, and saw it merged from qemu-svn in February, and one of the changes was: improve Virtual PC disk format support So, having reported bugs in that before (to the extent a Windows 2003 image couldn't boot; it spent forever listing chkdsk errors), I decided to try the new code. Specifically I tried kvm-88. It didn't work, but was much improved. I'm presuming it was the contribution below: Subject: [Qemu-devel] [PATCH 0/7] block-vpc: Improve support for VHD images Kevin Wolf wrote: > Jamie Lokier schrieb: > > Kevin Wolf wrote: > >> This patch series improves the support for Virtual PC images. Until > >> now, support for this image format is read-only and broken for large > >> images. With these patches applied, you can create and write to VHD > >> Dynamic Disks and some bugs in the read support are fixed. They have > >> been tested with qemu-img convert from and to raw images and a > >> successful openSUSE installation on a fresh VHD image. > > > > Ooh, I look forward to trying these patches. :-) > > > > I have some VHD image of Windows which always resulted in lots of > > scandisk errors when Windows booted from it (using -snapshot), and the > > same when converted to a QCOW2 file by qemu-img. > > I think there is only one integrity patch in the series which fixes > images > 4 GB. Is this the case with your image? Yes, the image is about 80GB. 83,886,080,000 bytes to be exact. > [My implementation] is the simplest one I could think of and it's > mostly to have at least something to convert images. I don't think I > would run a VM on it except for testing. > > > So I look forward to trying these patches on that image, which I don't > > use know but kept for this very purpose, and seeing if it's fixed the > > errors. > > Thanks for testing and please report back. I hope it works fine now. Let's see. Previously I'd started by trying to run a VM directly from the VPC image, but that was a bad idea. Then I tried using "qemu-img convert" to convert it to raw, but that was corrupt too. Then I used Microsoft's tool for conversion to raw, and the raw image was usable with QEMU and KVM. There were changes to VPC support merged from qemu-svn into kvm-84. I used "qemu-img convert" from kvm-88 for testing, except that I confirmed the size issue occurs with kvm-84 too: 1. Strikingly, it produces the wrong raw image size. Firstly, the new code interprets the disk image with the wrong size: $ /usr/local/kvm-83/bin/kvm-img info original.vpc image: original.vpc file format: vpc virtual size: 78G (83886080000 bytes) disk size: 6.0G $ /usr/local/kvm-84/bin/kvm-img info original.vpc image: original.vpc file format: vpc virtual size: 78G (83884277760 bytes) disk size: 6.0G $ ls -l expanded_by_VirtualPC.vhd -rw-r--r-- 1 jamie jamie 83886080512 2008-05-26 07:47 expanded_by_VirtualPC.vhd The correct image size is probably 83886080000 bytes, which means the older code calculated it correctly and the new code does not. Microsoft's conversion tool adds an extra 512 bytes on the end, which are all zeros and probably aren't required for qemu/kvm. Unsurprisingly given the above output, "qemu-img convert" produces raw image of the wrong size too - the size reported as "virtual size". I checked the partition size on this image, and found the partition used for real data to be smaller than the smaller size produced by the new VPC format code. So I looked at the extra 1802240 bytes, and found they were all zeros. 2. The amount of corrupt sectors is very much improved. Whereas kvm-72 produced a huge number of corrupt sectors - more than I counted, kvm-88 produced just 3 corrupt sectors of 512 bytes in the entire 80GB file. In two of them, the correct file has data where the kvm-88 output has zeros; in the other corrupt sector, kvm-88 has non-zeros where the correct file has zeros. (I'm assuming the output from Microsoft's tool is correct). That's close to perfect, but obviously not perfect enough. I have the offsets of the corrupt sectors, so I'm hoping it won't be hard to reproduce by attempting to read just those sectors through the block-vpc.c code and deducing where it goes wrong. -- Jamie