General Troubleshooting Procedures

This section presents some general procedures you can follow to diagnose and fix a problem with VMware.

12.1.1 Try to Identify the Part of the System That’s Causing Trouble

If one of your devices won’t work, the problem has a large scope and may lie in the guest operating system’s user interface, the guest’s drivers, the VMware guest or host configuration, your host system’s drivers, or the real hardware. Do the following to try to determine where the problem lies:

•

As a sanity check, make sure the host’s hardware and drivers work. Try to do something that’s similar to what you’d do on a guest system. (For example, if your guest can’t talk to the serial port, make sure that you can run a terminal program from the host.)

•

Make a quick inspection of your guest system’s virtual hardware in the VMware Configuration Editor. Make sure that the devices point to the right places, and perhaps more important, if Linux is your host, make sure that you clicked the Install button to bring the device into the configuration (this is an easy procedure to overlook).

Try a known working guest operating system. Linux and Windows 98 are good for this purpose, because they install and boot quickly and have perfect device support. If the devices work under one of these systems, then the problem is almost certainly in the guest system.

•

If you’ve isolated the guest as the trouble spot, try the simplest device access commands that you know of. For example, if you have trouble with parallel ports under a Linux guest, try redirecting some output directly to /dev/lp0.

If you have trouble booting a virtual machine, you’ll need to figure out where your boot block is. Find the boot partition (see section 2.4 for more information on how a PC boots) and then find your guest system’s main partition (C: on a Windows guest, and / (root) on a Unix−like guest).

12.1.2 Diagnostic Messages and Errors

VMware Workstation may display a diagnostic message or abort with an error. The diagnostic messages usually aren’t fatal (like what you get when the guest system sends an unsupported CD−ROM command). These messages won’t stop VMware or its guest system, but they may become annoying after a while.

On the other hand, aborts (also labeled PANIC) stop your virtual machine in its tracks. If you get an abort, pay close attention to the message. Some aborts result from known bugs and include a message containing the text bugNr=n, where n is some number. This message means that the bug is already in VMware’s database, and if a newer Workstation release is available, it may fix this bug.

You may also get an “Unimplemented” abort message, which usually means that one of the guest system’s device drivers tried to do something with the virtual hardware that VMware can’t handle. You can usually deduce what the hardware is by the message (and, in some cases, by what the guest was doing right before the crash). If you get one of these aborts, you may be able to avoid it by disconnecting the device in question. In the worst kind of crash, VMware trips over itself so badly that it can’t catch its own error, and the host operating system has to take over. Fortunately, crashes of this type are rare, and they’re usually related to a condition on the host system. (Broken VMware kernel modules on a Linux host may cause this kind of crash.) If you encounter a problem like this, first check your host system configuration to see if it’s known to work well with VMware Workstation, or whether there are issues listed in the documentation.

Where to Find Diagnostic Messages

One of the best places to look for VMware diagnostic messages is in your virtual machine’s log file. On a Windows host, this file is in your virtual machine’s configuration directory as VMware.log. On a Linux host, you’ll find it in the same directory as your configuration file; the file name ends with .log (for example, freebsd.log).

Normally, VMware removes a virtual machine’s log file when it switches configurations or exits, so if you want to look at the file, you must keep the VMware application running with the same active configuration (it doesn’t matter if you turn off the virtual machine, though). However, the log file remains if VMware aborts abnormally.

12.1.3 Other Resources

problems related to the host and guest operating systems, general configuration, VMware Tools, and networking. Also be sure to check this book’s index or table of contents for the appropriate subject.

In addition, VMware’s support page at http://www.vmware.com/support/ offers other, up−to−date solutions. In particular, the online troubleshooting documentation includes information about many obscure hardware bugs that affect a very small percentage of systems.

Your guest operating system’s support area also may have something of note regarding your processor and the hardware that corresponds to VMware’s virtual hardware. And keep your motherboard in mind; some issues regarding a motherboard’s chipset or BIOS may cause trouble. (You can find information on these issues on VMware’s support pages as well.)

Finally, if you’re a registered VMware customer, you can always contact VMware’s technical support people directly.