diff options
Diffstat (limited to 'emulators/vmware3/files/Hints.FreeBSD')
| -rw-r--r-- | emulators/vmware3/files/Hints.FreeBSD | 167 |
1 files changed, 0 insertions, 167 deletions
diff --git a/emulators/vmware3/files/Hints.FreeBSD b/emulators/vmware3/files/Hints.FreeBSD deleted file mode 100644 index 15aa5a2f69dc..000000000000 --- a/emulators/vmware3/files/Hints.FreeBSD +++ /dev/null @@ -1,167 +0,0 @@ -$FreeBSD$ - -Here is a list of some useful hints on using VMware on FreeBSD. - -- Note that this port includes some kernel modules, which means you -should rebuild and reinstall this port everytime you update the kernel -so as to keep them in sync; otherwise VMware might coredump or crash -together with the whole system if kernel interfaces were somewhat -different than before. - -- Full screen text mode does not work. Don't ever do it! - -- Full screen graphics mode will work, but you have to be careful e.g. -when running a DOS prompt on MS Windows. Hitting Alt+Enter will crash -VMware before you can say "Chuck!" - -- Running VMware as root is NOT the right way to do it. Edit -/etc/fbtab to obtain the proper permission for the device files that -you are going to access, then run VMware as a normal user. - -- Raw disk may not work. Use virtual or plain disk instead. - -- The vmware-mount.pl utility does not work. If you want to mount -the "disk" while VMware is not running, you must use plain disks -instead of virtual ones. Set up a 63 sector file as an "mbr" -section, then a file for each partition on the "plain" disk. -To mount the "disk", use vnconfig -c /dev/vn__ file and -then mount the vn device. - -If you are setting up a plain disk as a workaround for the broken -raw disks, you will need to set up the disk description file -by hand, as the configuration editor will complain. Here is a -sample one: - -DRIVETYPE ide -CYLINDERS 16383 -HEADS 16 -SECTORS 63 -ACCESS "/path/disk.mbr" 0 63 -ACCESS "/dev/rad0s1" 63 4192902 -RDONLY "/dev/null" 4192965 12305790 - -The geometry must be the physical geometry reported by the disk. -grep ad0 /var/run/dmesg.boot and look for the 3 numbers in the -brackets. They are the C/H/S. - -In the example above, "disk.mbr" is file used to keep a replacement -MBR for the disk. You can use dd if=/dev/rad0 bs=1b count=63 of=mbr -to create it if you like. The reason is so that the guest's decision -about which OS you booted last is different than the host's (this is -for the FreeBSD boot manager). You can also feel free to replace -the MBR with the standard boot manager if you like. fdisk(8) and a vn -device can help with this, though you will have to be sure and -supply the correct geometry to fdisk(8) since the vn device won't -support those calls. This time it's the BIOS "fake" geometry. -Watch out! - -As you can see, the 1st partition simply is a FreeBSD slice device. -The first number after the filename is the offset in blocks where the -given file starts in the plain disk. The last number on the line is -the length of the block. If you are using a file, its length must -be equal to this number * 512. - -The last entry is an example of how to block out partitions you don't -want VMware to mess with. Why do this instead of simply making the -C/H/S numbers for the disk smaller? Because then the guest's BIOS -might not make the same choices about the "fake" geometry to use, -which would prevent the OS from booting in most cases. - -You might be able to follow the same procedure to make SCSI drives -work. It is slightly less likely to work as SCSI vendors often -differ as to how they set up BIOS geometries. Your raw device -must end up having the same BIOS geometry as a Bustek SCSI -controller, which is the device VMware virtually supplies as the -host adapter. - -- It is a good idea to disconnect removable media devices (CDROMs -and Floppies and the like) from the "guest" either when they are -empty or when you're about to eject the media. - -- Under FreeBSD, floppy device should be configured as follows: - - Type: file - Path: /dev/fd0 - -(Obtain the write permission on /dev/fd0 if you write floppy disks) - -- VMware creates a file that is about 25% larger than the guest OS's -RAM size, unlinks it and mmap's on it on the first startup of the VM. - -The default directory for the mmap is the value of TMPDIR environment -variable, or if it's undefined, /tmp. - -Therefore, it would be a good idea to have your TMPDIR variable -defined as a directory 1) that performs fast, 2) that has sufficient -free space, and 3) that isn't on MFS; if your /tmp doesn't meet those -three conditions. - -1 is because that will significantly improve the performance, 2 is -because the VM cannot even boot when the mmap fails, and 3 is because -such a large, active file on MFS could lead the system to deadlocks. - - -Alternatively, you can make /compat/linux/tmp to fake /tmp, however, -you should note that it would cause you silly troubles: Imagine a -Linux application (say, Linux Netscape) which creates a temporary file -in /tmp and passes it to some external program; you'll see it actually -creates a file in /compat/linux/tmp when the external program searches -/tmp literally. - -- There is a bug you may wish to work around if you aren't running -5-current or a very recent 4-stable system. - -Some background first: With FreeBSD, when you mmap a file, the syncer -will attempt by default to periodically synchronize the on-disk version -of the file with the changes being made in the mmap'd region. You can -change this behavior using the MAP_NOSYNC flag to mmap(). With this -flag, the syncer will leave the dirty pages alone and only the -pagedaemon will flush them when it's absolutely necessary. However, -Linux always behaves as if the MAP_NOSYNC flag was given, but the -Linuxulator was not adding MAP_NOSYNC to the flags as part of the -compatibility layer. But that is ok, since unlinking the last reference -to an mmap()ed file causes FreeBSD to add MAP_NOSYNC in anyway (under -the theory that if the machine reboots in that situation the file's -inode would be freed since it would be an orphan). - -The problem is that VMware doesn't actually unlink the save-to-disk file -when resuming -- it merely uses it in place. The result is that the -MAP_NOSYNC flag doesn't get set, which causes the performance of a -resumed session to be terrible compared to a new session. Every time the -syncer runs (sysctl -a kern.filedelay), vmware hangs while the RAM file -dirty pages are flushed. - -This problem has been fixed in 4.2-STABLE as of 2 Mar 2001 -(sys/i386/linux/linux_machdep.c versions 1.13 and 1.6.2.3). - -- If you configure vmware to use bridging, you must still specify the -"Host only" mode to the VMware configurator. It will still work just -like a bridged interface. If your bridged VMware guest is a DHCP client, -you may wish to fix its Ethernet address so as not to generate a new -lease every time you start VMware. To do so, add this line to your -guest's .cfg file: - -ethernet0.address = "00:50:56:1e:ad:bf" - -You can only change the last 5 hex digits, which MUST be unique (at least -within your LAN). - -Note that bridging only works on (real) Interfaces where both the 'set -promisc 1' and 'set autosrc 0' steps function. This means that the -interface must be capable of transmitting frames with other than its own -Ethernet address and receiving promiscuously. Most interfaces can, but -notably wi interfaces are among those that cannot. Note that promiscuous -mode is entered when the vmware.sh startup script is run, which may -cause increased interrupt loads on your machine if it's plugged into a -busy network. If you only run vmware infrequently, it may be better to -only manually run the vmware startup script (as root) just before you -start vmware and again (with the stop argument this time) when you're -finished. - -- Don't miss the VMware FAQ available on the official site. - - http://www.vmware.com/products/productfaq.html - --- -Akinori -Aki- MUSHA <knu@idaemons.org> -Nick Sayer <nsayer@FreeBSD.org> |