167 lines
7.3 KiB
Text
167 lines
7.3 KiB
Text
$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>
|