Always take snapshots when the guest is powered-down.

Although in VMWare Workstation you can take a snapshot at any time, you cannot clone a snapshot taken of a powered-on guest.

So for example, I patched a new Windows Server 2003 guest OS with dozens of Windows Updates, installed SQL Server, installed and configured SQL Server Reporting Services, etc. It took hours. I made snapshots at each phase, and indeed was able to revert back to one after screwing up royally. However, when I later went to clone the "all patches" snapshot to re-use the guest somewhere else, I was unable to do so because the guest had been on when I took the snapshot. I pulled out all my teeth in frustration and smashed them with a hammer, then began uninstalling everything after the patches.

Check the guest firewall settings if you have host-to-guest network problems

If you have double-checked that the virtual network settings are not to blame for an inability of the host to communicate with the guest, then ensure the guest firewall settings are not blocking incoming requests.

In my case the guest was using bridged networking and could ping the host and connect to the internet via the LAN gateway. The host could not ping the guest, the reason being that the guest firewall disallowed incoming echo requests by default. Further, since I wanted to use the guest as an http server, I needed to allow http requests at the firewall level. The agony preceding this discovery was akin to a hot knife stabbing repeatedly into my liver.

32 bit guests created on a 64 bit host can only be deployed on a 32 bit host if the deployed host hardware supports 64 bit processing

This one is counterintuitive. Just because it's a 32 bit guest doesn't mean it's going to run on a 32 bit host.

Newer machines tend to support 64 bit processing. Older ones don't. It's entirely possible that a host will be running a 32 bit OS but be 64 bit capable. How do you know? Download CPU-Z and it will examine the hardware and tell you. The VMWare CPU Identification Utility might also help, but I'm unclear as to whether it just checks for a 64 bit OS, or hardware 64 bit capability.

If you want to interact with a virtual machine as part of your network, you need to adjust its networking settings to specifically use one of the host machine's network adapters.

Don't set the adapter to "Shared networking (NAT)". This isolates the virtual machine behind the virtual networking adapter. You'll find you can't even ping the VM from the host.

Good for interacting

Bad for interacting

The credit for this post goes to Peter, who close to a year ago sent out instructions on how to use differencing disks in a different way to save significant hard drive space when using virtual machines (Virtual PC 2007), while keeping your pristine baseline image...well...pristine (read-only no less). As I'm tired of looking up the old email every time I forget the steps (going senile in my old age), I'm putting the steps here:

1. In the VPC console, highlight your VPC > Click Settings > Select Undo Disks > Click Enable > undo disks > Click OK
2. Turn on, and then immediately turn off the VPC. Choose to save changes but not commit them. The whole point is to get an Undo disk (file with extension of .vud).
3. Find the undo disk (.vud) and rename the VUD extension to VHD. Tricky!
4. Return to VPC console, highlight your VPC and choose newly renamed VHD as Hard Disk 1.
5. Answer "Continue" when warned about the undo disk.
6. In Settings dialog > Select Undo Disks > Clear the check-box to disable undo disks > Click OK (and blissfully ignore the catastrophic warning).
7. At file system, set parent disk to 'read-only'.
8. Boot VPC and work as normal, but with the knowledge that your pristine baseline image is safe.
9. I like to take it one step further for data and hook it up with a separate virtual data drive (easier for incremental backups).

This tip is originally from Invirtus VM Optimizer (now vOptimizer it seems). If you're interested in a further explanation, in their words:

Microsoft Differencing Disks

As you may have read in our differencing disk article on our website, differencing disks are wonderful tools for extending virtual machines, but are terribly inefficient in disk space concerns. If you intend to use a differencing disk  more than a few times and you intend your differencing disks to have a moderate shelf life, consider using undo disks instead. Not in the classic sense, however. To ensure the parent image is held pristine we recommend a new way of using undo disks.

Instead of having your writes chained to the back-end of a VHD by way of undo, or VUD, we recommend creating then renaming the VUD to VHD and using it on the front-end to reduce ambiguity. Doing this will save you tons of disk space, guaranteed and you will not lose any functionality. To get there, however, you have to follow a few "new" steps.

And of course, do all of the above at your own risk. I'm not responsible for any chaos that ensues: Peter is.