Disclaimer: This is a personal document and is not official or endorsed by VMware. Feedback and suggestions are welcome.
Note: This is very unsupported (since an important technique it depends on, manual linked cloning, is also very unsupported).

Motivation and Use Case

One use case for Fusion is where untrusted users need temporary access to virtual machines, such as a grade school computer lab. This HOWTO will show how to set up an environment that's relatively safe and appropriate - guest users will not be able to make persistent changes to the virtual machine, but login time will not be adversely affected.

Another use case is if you want to quickly provide a sandbox - for example, I might want to loan my laptop to a friend and allow them to install any software in the guest(s), but leave the host alone.

Difficulty Level and Requirements

Very Advanced: You should be familiar with editing .vmx files and be experienced with creating and using virtual machines, and preferably other VMware products. You will need administrator account because we will be editing system files. You should be familiar with general OS X usage and security, as well as know how to use the command line.

This builds off the technique in HOWTO: Manual Linked Cloning in Fusion. You should read that first, understand the principles of what's going on, and be able to do it.

You must be using Leopard, which introduced Guest accounts. You might be able to script the equivalent in Tiger, but I'm not sure where to begin looking for that.

I assume good host security, i.e. unprivileged users cannot access stuff they're not supposed to.

Background

In an untrusted environment, one user must not be allowed to affect others (e.g. student A should not be able to leave malware around to impact student B). A less paranoid use case would be that you might want to guarantee a fresh working environment. A Guest account in Leopard will get us partway there - changes are discarded when the user logs out. An administrator can modify the default user template, which allows us to put arbitrary files in the Guest account.

The problem with the naive approach of simply dumping a virtual machine in the default user template is that virtual machines are large. Each time a user account is created (which happens each time the Guest logs in), the user account is copied. This isn't a problem for the default set of files, but add in a multi-gigabyte virtual machine (or two, or three...) and login times will be unacceptably long.

We could keep the virtual machine in a shared location as described in A Beginner's Guide to VMware Fusion, but this would violate the security motivation - if anyone can write to the virtual machine, and the virtual machine is persistent, than they can affect later users. Fusion requires virtual machines to be writable, so you can't clear the write bits and still have the virtual machine run.

We can solve both problems by using a linked clone as described in HOWTO: Manual Linked Cloning in Fusion. A nice property of a linked clone is that it starts off very small - on the order of a few megabytes at most, as opposed to many gigabytes. Due to the small size, the template will still copy quickly. At the same time, a linked clone doesn't care if the parent is writable (and in fact it's better if it's not), so we can keep the base disk read-only and therefore safe.

Limitations and Notes

This is not a method to lock down Fusion or a virtual machine. Users will still be able to create new virtual machines, bring in their own, or copy out the one they're working with (though this last task requires some Fusion knowledge).

While this can be used to make a virtual machine that resets to a known-good configuration, using a nonpersistent disk is a simpler solution for non-malicious users. Note that a malicious user can circumvent a nonpersistent disk if given full access to all the virtual machine files, so a nonpersistent disk by itself is not sufficient for all cases.

These changes will affect not only the guest user, but any newly created user. This might or might not be a problem for you.

Instructions

Create the Virtual Machine

Follow the instructions in the Prepare the Guest section of HOWTO: Manual Linked Cloning in Fusion. If only the guest user will be using this virtual machine, you don't need to sysprep it (if you choose not to, you may have to make sure the MAC address remains constant). I will assume the shared virtual disk is placed in /Users/Shared/. Unlike HOWTO: Manual Linked Cloning in Fusion, let's use absolute paths for this one (not strictly a requirement, but I tend to like relative paths when dealing with my own files and absolute paths when dealing with other users).

Make sure that none of the .vmdk files or the folders containing them (all the way up to /Users/Shared/) are writable. The .vmdk files not being writable is obvious - you don't want a user modifying these files, that would defeat the security point. A slightly less obvious constraint is that the folders must not be writable - if they were, even though users couldn't modify the .vmdk files themselves, they could replace them with other files (thus effectively modifying them).

Create a linked clone as in HOWTO: Manual Linked Cloning in Fusion and make sure it works as expected. Remember to take a snapshot before powering on, and if you did power on, remove any uuid entries from the .vmx file so the guest user isn't prompted about them.

Copy to Default User Template

Once you're happy with the virtual machine, we need to put it in the default user template so that the guest user will see it. On Leopard, the default user templates are located in /System/Library/User Template/. Unfortunately, they're root owned, so even with sudo it's a little bit of a pain to deal with (for example, you can't cd into them). You can enable root access (I wouldn't recommend this) or just live with it for the little while it takes to do this step (which is what I did and will assume for the rest of this document). You might also want to create a backup copy of the default user template.

Open a terminal window and cd to /System/Library/ (I will assume you're there for the rest of this document). We can't go further, since User Template is root owned. At this point, every time we reach into the User Template folder we'll need sudo. Lets first take a look around. Assuming your default language is English (adjust appropriately if not), the command would be

sudo ls -lAF User\ Template/English.lproj/

which on my system returns

-rw-------   1 root  wheel    3 Jul 24  2007 .CFUserTextEncoding
drwx------+  3 root  wheel  102 Mar 31  2008 Desktop/
drwx------+  4 root  wheel  136 Dec 15 21:21 Documents/
drwx------+  4 root  wheel  136 Dec 15 21:21 Downloads/
drwx------+ 20 root  wheel  680 Mar 31  2008 Library/
drwx------+  3 root  wheel  102 Mar 31  2008 Movies/
drwx------+  3 root  wheel  102 Mar 31  2008 Music/
drwx------+  4 root  wheel  136 Dec 15 20:26 Pictures/
drwxr-xr-x+  4 root  wheel  136 Mar 31  2008 Public/
drwxr-xr-x+  5 root  wheel  170 Dec 15 20:26 Sites/

It's what you would expect a blank user template to look like. Anything you copy in here will automatically be copied to a new user's account (this is true not only of guest users, but any newly created user).

Let's assume you want to put the virtual machine in the guest's Documents directory (other good choices might be on the Desktop or just in their home folder). If the prepared clone is located at /Users/etung/Virtual Machines/Default.vmwarevm, the command would be:

sudo cp -r /Users/etung/Default.vmwarevm User\ Template/English.lproj/Documents/

If you log in as a guest now, you should see the virtual machine and the login process should be fast (since the added virtual machine should not have been very large).

Copy Other Support Files

We could stop here, but if you were to run the virtual machine in the guest account, you'd see Fusion's first-run windows (since the guest has not run Fusion before, and remember that when the guest logs out all the guest's files are erased, so having run Fusion doesn't persist). We can get around this by making Fusion think it's already been run once. We need two preference files: com.vmware.fusion.plist and VMware Fusion/preferences.

com.vmware.fusion.plist

com.vmware.fusion.plist is located in /Users/${USER}/Library/Preferences/com.vmware.fusion.plist. If you've run Fusion, it probably has a bunch of entries, but we're only interested in the boolean VMWelcomeScreenViewed_2.0. If you have the developer tools installed, you can make a copy and work on it using Property List Editor (which will allow you to selectively keep other entries you want, though I suggest getting rid of anything in the favorites list); if not, you can use the following command to create a dummy file:

defaults write com.vmware.fusion-copy VMWelcomeScreenViewed_2.0 -bool yes

Now copy this to the User Template folder (modify path as appropriate for your user):

sudo cp /Users/etung/Library/Preferences/com.vmware.fusion-copy.plist User\ Template/English.lproj/Library/Preferences/com.vmware.fusion.plist

preferences

The preferences file is located in /Users/${USER}/Library/Preferences/VMware Fusion/preferences. If you've run Fusion, it probably has a bunch of entries, but we're only interested in the value of pref.registrationViewed. You can create a copy and edit it to your liking, or paste the following into a text file (watch out for line endings, some browser/text editor combinations mangle them. You can work around this by deleting the newline and typing it yourself) - make sure to save it as a plain text file with no extension.

.encoding = "UTF-8"
pref.registrationViewed = "TRUE"

Now copy this to the User Template folder (modify path as appropriate for your user):

sudo cp /Users/etung/Library/Preferences/VMware\ Fusion/preferences-copy User\ Template/English.lproj/Library/Preferences/VMware\ Fusion/preferences

At this point, if you log into the guest and start Fusion, you should not see the first-run windows.

Further Extensions

You might want to further customize the default user template - for example, you might be able to get the cloned virtual machine to automatically start (look in com.apple.loginitems.plist, though I'm not sure about syntax). You could add other virtual machines to the guest account. You could copy over other parts of the support files (perhaps populate the Virtual Machine Library).