From owner-freebsd-emulation Thu Jul 27 5:46: 9 2000 Delivered-To: freebsd-emulation@freebsd.org Received: from shrimp.baynetworks.com (ns4.BayNetworks.COM [192.32.253.7]) by hub.freebsd.org (Postfix) with ESMTP id 30ADC37B527 for ; Thu, 27 Jul 2000 05:46:04 -0700 (PDT) (envelope-from bwithrow@BayNetworks.COM) Received: from mailhost.BayNetworks.COM (ns4.baynetworks.com [132.245.135.84]) by shrimp.baynetworks.com (8.9.1/8.9.1) with ESMTP id IAA07438; Thu, 27 Jul 2000 08:39:37 -0400 (EDT) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id IAA16764; Thu, 27 Jul 2000 08:42:30 -0400 (EDT) Received: from baynetworks.com (kyzyl [192.32.150.103]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with ESMTP id IAA16126; Thu, 27 Jul 2000 08:42:30 -0400 for Message-Id: <200007271242.IAA16126@pobox.engeast.BayNetworks.COM> X-Mailer: exmh version 2.1.1 10/15/1999 X-Exmh-Isig-CompType: repl X-Exmh-Isig-Folder: FreeBSD To: John Reynolds Cc: emulation@freebsd.org, bwithrow@nortelnetworks.com Subject: Re: FreeBSD/VMWare setup for dummies? In-Reply-To: Message from John Reynolds of "Thu, 27 Jul 2000 01:47:36 PDT." <14719.63272.547232.364667@whale.home-net> Mime-Version: 1.0 Content-Type: text/plain Date: Thu, 27 Jul 2000 08:42:30 -0400 From: Robert Withrow Sender: owner-freebsd-emulation@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Thanks for the info. Actually, late last night I actually flopped in the correct direction (probably accidentally). I'll note where your stuff differs from mine: :- First off, is the NT/BSD boot disk an IDE disk? I hope so. Even VMware :- themselves say booting a VM from scsi is at best experimental. I would :- seriously doubt it would work under FreeBSD, but maybe It's scsi, and it seems to work. :- You can edit the .hda file like so Turns out it can be a file of any name (even though .hda is a good choice). You simply refer to this file in the "fileName" line of your config file's disk configuration. For example: scsi0:0.fileName = "nt4.hba" :- you need the actual geometry which you can get from dmesg :- I got these numbers by going into /stand/sysinstall into the partition :- editor for 'ad0'. As others have suggested, it is probably easier to just use "fdisk". If you enter that command with no arguments you get a listing that gives you everything you need. For example: parameters to be used for BIOS calculations are: cylinders=1111 heads=255 sectors/track=63 (16065 blks/cyl) and The data for partition 1 is: sysid 7,(OS/2 HPFS, NTFS, QNX or Advanced UNIX) start 63, size 7164927 (3498 Meg), flag 0 :- I plugged "starting" and "ending" numbers for both slices into the :- example template from the Hints file. This is where I and the Hints :- file differ. Uhh.. As I understand it, the numbers are starting sector and *number of sectors* (not ending sector). This interpretation works for me and I've seen mail in this list that echoes it. :- VMware itself guessed at the raw partition sizes in my original .hda :- file Yeah. I saw that. But the numbers it put in the file disagreed with the numbers from "fdisk" so I went with the numbers from "fdisk". Anyone know why this is? Is the above interpretation incorrect? Two other things. 1) The Hints.FreeBSD file suggests that you should map out areas you don't want VMWare to touch with that "/dev/null" thing. I've found that you need only *avoid mapping* those sectors, and VMWare is happy to not touch them. In my case partition 1 is NT and 2 is FBSD. My config file has only the MBR and the NT partition mentioned. I discovered that this worked when I was looking at my setup in the Configuration Editor: It deleted the /dev/null line. My contention is that VMWare is happy with sparsely mapped drives. 2) VMWare does a "cd" to the config directory. Thus, if you place all the files in that directory, you can dispense with long paths. Anyway, I'll put my config files at the end. Now, for the fun stuff: I got NT to boot with all this, then immediately got the "blue screen of death". Turns out that I'm running a multiprocessor NT HAL (Hardware Abstraction Layer) and VMWare exports a uniprocessor HAL. NT gets is undies in a twist and refuses to play in this situation. This is covered on the VMWare support site, where the recommend that you only try to fix this if you are "very experienced" in NT whacking. I looked at the Microsoft support site and changing from a MP HAL to a uni HAL is definitely voodoo and chicken guts. No wonder it is "industry leading software". Phooey! Bottom line: I'd s**t-canning the NT stuff and installing Win2K in a virtual disk, like VMWare suggests. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-emulation" in the body of the message