From: Jamie Lokier <jamie@shareable.org>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Problem installing NT4 under QEMU 0.9.1 - IDE driver error under high load?
Date: Fri, 16 May 2008 16:40:03 +0100 [thread overview]
Message-ID: <20080516154003.GC32498@shareable.org> (raw)
In-Reply-To: <482DA817.4010402@siriusit.co.uk>
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
prev parent reply other threads:[~2008-05-16 15:40 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-16 15:28 [Qemu-devel] Problem installing NT4 under QEMU 0.9.1 - IDE driver error under high load? Mark Cave-Ayland
2008-05-16 15:40 ` Jamie Lokier [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080516154003.GC32498@shareable.org \
--to=jamie@shareable.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).