$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/rfd0 (Obtain the write permission on /dev/rfd0 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. - Don't miss the VMware FAQ available on the official site. http://www.vmware.com/products/productfaq.html -- Akinori -Aki- MUSHA Nick Sayer