From: Karl Magdsick <kmagnum@gmail.com>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] harddrives and QEMU
Date: Thu, 6 Oct 2005 08:01:31 -0400 [thread overview]
Message-ID: <cd8ecdef0510060501h54822ecfh4f41751049a791a6@mail.gmail.com> (raw)
In-Reply-To: <43445E7D.2090803@shires.org>
> >
> Alright, but here's the rub. If a drive can be booted by a machine. Why
> can't it boot from Qemu if it's accessing the raw disk via the windows
> interface? This needs no messing with bios or disksize to boot of a
> regular machine.
>
I hope someone else will chime in, but my guess is that the problem
lies in that an MS Windows "drive" is really a partition, not the entire
drive. Under Windows you're specifying the equivalent of
the Linux /dev/hda1 , /dev/hda2, /dev/hdb1, /dev/hdb5 and not
actually /dev/hda or /dev/hdb.
In other words, to QEMU it looks like the drive got chopped off at some
point. All of the data before a certain point and after another point on
the HD is simply missing (and the indexing is incorrect if a non-zero number
of bytes have been chopped from the beginning of the disk).
I'm not sure if MS Windows includes the MBR in the first drive on the disk.
In order to pass the "D drive" to qemu, and actually give QEMU access
to the entire raw HD, the "D drive" partition would have to fill the entire
HD, and MS Windows would have to make the MBR available as part
of the first (only, in this case) partition on the HD.
Presumably, you'd like QEMU to make up a fake partition table/MBR
to present to the guest OS so that the guest OS sees a self-consistent
disk.
-Karl
next prev parent reply other threads:[~2005-10-06 12:01 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-05 18:22 [Qemu-devel] harddrives and QEMU Brett (Mare) Henley
2005-10-05 21:34 ` Jim C. Brown
2005-10-05 23:15 ` Brett Henley
2005-10-06 12:01 ` Karl Magdsick [this message]
2005-10-06 12:50 ` Karl Magdsick
2005-10-06 15:14 ` Thomas Steffen
2005-10-06 16:58 ` Brett (Mare) Henley
2005-10-07 17:43 ` Jim C. Brown
2005-10-06 12:03 ` Jim C. Brown
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=cd8ecdef0510060501h54822ecfh4f41751049a791a6@mail.gmail.com \
--to=kmagnum@gmail.com \
--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).