Re: [Qemu-devel] Problem installing NT4 under QEMU 0.9.1 - IDE driver error under high load?

[Jamie Lokier]

Mark Cave-Ayland wrote:
> Upon reboot, I get a BSOD and errors about files being corrupted on the 
> partition. However the error goes away, and the install completes fine 
> after the reboot if I use the cdrom directly, i.e. I run qemu like this:
> 
> qemu-system-x86_64 -hda /home/images/ntfs.img -cdrom
>       /dev/hda -vnc localhost:11 -no-acpi -win2k-hack -boot d
> 
> If I execute 'md5sum winnt4.img' and 'md5sum /dev/hda' then I get back 
> the same MD5 hash for both the physical CDROM copy and the local CD 
> image, so I am fairly sure the local CD image is not corrupt. I have 
> also tried with/without -win2k-hack and it doesn't seem to make a 
> difference.
> 
> My theory is that there is some form of race condition in the IDE driver 
>  related to the transfer speed. When using the local winnt4.img CD 
> image, the installation is very quick, but the resulting file system 
> appears to be corrupted. When I use the real CD inserted into /dev/hda, 
> the installation is much slower but the file system appears fine.
> 
> Has anyone else experienced similar symptoms during normal QEMU usage?

Fwiw, I am experiencing similar problems with Windows Server 2003
which is already installed.

Someone else prepared a working WS2003 image inside VirtualPC (a
Microsoft VM which runs only on Windows hosts).

I took the disk image, which QEMU understands (thank you), and tried
to run it under QEMU (with/without KQEMU), and KVM.

(It bluescreened on boot but that's an NT problem from changing
hardware.  I applied the registry fix which lets it boot, using a
Windows XP guest (running in QEMU) to apply the registry fix.  Then it
booted.  This is due to QEMU providing PIIX3 while VirtualPC provides
PIIX4 IDE emulation.)

On the first successful boot, my WS2003 image insisted on running
chkdsk.  It took a _very_ long time in KVM (due to video refresh
slowness), so I ran it in QEMU which is ironically much faster at
this, even without KQEMU.

chkdsk showed thousands of errors, which it repaired.  But even after
repair, some files are corrupted or missing in the running image.

I still have yet to verify whether the image is fine, or was corrupted
when it was sent to me, or was sent to me in a "suspended" rather than
"powered off" state.  But such a large number of chkdsk repairs isn't
expected for a "suspended" state, and corruption isn't likely.

I had also wondered if may QEMU's VHD disk format module wasn't
handling the format correctly.

But another possibility is a fault in the IDE emulation.  -win2k-hack
didn't change the behaviour.

-- Jamie