[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Virtual PC images still corrupt - but better than before
From: |
Jamie Lokier |
Subject: |
[Qemu-devel] Virtual PC images still corrupt - but better than before |
Date: |
Sun, 9 Aug 2009 10:59:06 +0100 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
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
- [Qemu-devel] Virtual PC images still corrupt - but better than before,
Jamie Lokier <=