1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
|
$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>
|
