From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ENURU-0003H7-AE for qemu-devel@nongnu.org; Thu, 06 Oct 2005 08:01:45 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ENURP-0003Fy-UX for qemu-devel@nongnu.org; Thu, 06 Oct 2005 08:01:41 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ENURN-0003FV-JQ for qemu-devel@nongnu.org; Thu, 06 Oct 2005 08:01:38 -0400 Received: from [72.14.204.205] (helo=qproxy.gmail.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1ENURM-0003Yb-Mx for qemu-devel@nongnu.org; Thu, 06 Oct 2005 08:01:37 -0400 Received: by qproxy.gmail.com with SMTP id p32so416671qba for ; Thu, 06 Oct 2005 05:01:31 -0700 (PDT) Message-ID: Date: Thu, 6 Oct 2005 08:01:31 -0400 From: Karl Magdsick Subject: Re: [Qemu-devel] harddrives and QEMU In-Reply-To: <43445E7D.2090803@shires.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <434419E9.7070800@shires.org> <20051005213402.GA24303@jbrown.mylinuxbox.org> <43445E7D.2090803@shires.org> Reply-To: Karl Magdsick , qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.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 numbe= r 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