Disclaimer: This is a personal document and is not official or endorsed by VMware. Feedback, suggestions, and edits are welcome.
This document is intended for someone new to Fusion, and possibly someone who is new to virtualization in general. It describes some choices a new user faces when setting up a virtual machine. This guide is written for VMware Fusion 2.0.x; earlier versions have slightly different wording in some places. New users may also be interested in
If you want to be notified of changes and additions to this document, you can use the "Receive email notifications" action in the sidebar on the left. Please use the comments below only for things
specific to this document; general questions are better off in the
Fusion can use existing Boot Camp partitions or use a virtual disk stored in a large binary file. There are advantages to each, but my general advice is that unless you need a specific trait
of a Boot Camp virtual machine, it is better to use a file-based (normal) virtual machine
If you already have a license or requirement for a particular OS, your choice may be easy - just use what you have. On the other hand, if you're thinking of buying a license, or want to try out other OSes, this might be worth some thought. Which OS is "better" is a personal thing and the subject of many a geek flame war, but here are some of my thoughts:
Although it's possible to change the size a normal virtual disk, this can be difficult for beginners, so it's better to get the size right from the start. Consider how you plan to use the guest - what programs and what data. For example, a fresh install of XP (with all patches) will run about 2 GB, but a fresh install of Vista will be more like 8 GB. Office, Photoshop, and other large programs have their own footprint to account for. Regular files are small, but things like digital video can be large (about 10 GB/hour). Finally, you want some breathing room in case your needs change a little bit and for other things like swap space.
Another concern is how much space you have available. Shrinking a disk may require as much free space as the partition to be shrunk (this is usually the size of the virtual disk). Thus it's a bad idea to make the virtual disk as large as the free space.
Remember that snapshots can cause the virtual machine to be larger than the maximum size of the disk - in the worst case, a snapshot can be as large as the maximum size. Thus a virtual machine with a 10 GB disk might need as much as 20 GB space if it has one snapshot, up to 30 GB if it has two, and so on. Also keep in mind that Autoprotect is based on snapshots, so if you're keeping 10 autoprotect snapshots, you might need 110 GB for the disk (10 GB for the base disk + 10 snapshots at 10 GB each).
Under the advanced disk options of the Virtual Hard Disk step, you have the option of using a preallocated or sparse disk, and also monolithic or split. These options are briefly described in A Beginner's Guide to VMware Fusion
. My personal recommendation is sparse-split
(e.g. leave "Allocate all disk space now" unchecked, but check "Split disk into 2GB files"), but if you have a large virtual disk (e.g. on the order of 100 GB) and use snapshots or Autoprotect, you may be better off with sparse-monolithic
in order to avoid running out of file descriptors.
Remember that although sparse disks
grow as necessary, they
don't shrink automatically. If you have a sparse disk with 5 GB, write 5 more GB and then delete 2 GB, you'll still have 10 GB used, not the 8 GB you might expect. The reason for this is that on most OSes, when you delete a file, you're just changing a small amount of metadata for a file to say "nope, nothing here" (this is how disk recovery programs work - they reconstruct what the metadata probably was). However, Fusion operates at too low a level to know the difference between a deleted file that's just wasting space and actual valuable data. When you delete a file, from Fusion's point of view very little has changed. To shrink a disk, Fusion needs help from something that
does know about this difference. During the shrink process, VMware Tools tells the guest OS to identify stuff that's unnecessary so that Fusion can compress the disk. However, this can be a somewhat slow process, and Fusion doesn't start the process until you tell it to.
If you use the Easy Install, one of the options is about making your home folder available to the guest. Your choice controls whether the guest can read or write to your home folder (and in the case of Windows Easy Install, whether special folders are mirrored). This option is not necessary to install or run the guest, and you may wish to disable it for better guest isolation. Leaving it enabled may make it more convenient to access your files.
Software, especially modern OSes, like to gobble RAM. While it might seem like a good idea to give the guest as much RAM as possible, remember that OS X needs some too. The more you give to the guest, the less is available to OS X. It's no good for the guest to have gobs of RAM if host apps (including Fusion!) are being paged out. A good split depends on what you're doing in the host/guest
and how much RAM you have total - if you're doing more work in the host, give more to the host; if you're doing more in the guest, give more to the guest. As a very general
rule of thumb for common configurations (e.g. this may not apply to people with very powerful or very underpowered systems, or who have unusual guest/host work splits), don't assign more than half your RAM to all running virtual machines
You can change the amount of RAM while the guest is powered off (suspended doesn't count) by choosing Virtual Machine > Settings > Memory. If you want to change this before installing the guest, uncheck "Start virtual machine and install operating system now" on the final setup page of the New Virtual Machine Assistant.
After you've installed the guest OS and your programs,
gbullman has a good post on how to experimentally determine how much RAM the guest wants:
At first glance, it might seem that enabling multiple virtual processors is always a good thing, but in many cases it's not. To use an analogy, let's say that physical processing units are seats at a restaurant (granted, a very small restaurant - for the sake of this example, let's say it has 4 seats, e.g. a 2x2 core Mac Pro). Processes are people who want to eat, and sometimes you get a group of people who all want to be seated together. It's easier for the restaurant (i.e. host OS scheduler) to handle seating (i.e. running) 4 single people than a single group of 4 people, especially when you remember that a normal system will easily have tens or hundreds of processes at a time.
To turn this analogy back to a technical explanation, a common problem is
synchronization, where a program decides it needs to make sure it's at the same point across different threads or processors -- in other words, a group of people who want to be seated together. On a physical computer, it's not a big deal because the other CPU isn't doing anything else but catching up (e.g. if one person is a little late for the reservation, it's not a big deal). However, on a virtual machine, the guest is potentially competing with other programs for CPU time - this is more of a problem on Macs with only two cores to begin with (i.e. there aren't as many seats to go around in the first place), which is every currently shipping model except Mac Pros. While the guest is trying to synchronize, even if Fusion has time on one core, it may not be able to make progress and "spins" doing nothing, since it needs
at the same time. To make matters worse, OS X is the one to decide when and where programs get to run, and last I heard, there were no way to ask OS X for the necessary scheduling (i.e. there's no way to make group reservations; the best we can do is to sit down and hope that everyone manages to show up before the restaurant kicks us out and moves on to the next set of people). Exact numbers of course vary by the exact setup, but a rough numbers I've heard of additional idle CPU overhead is in the ballpark of 30%.
This is not to say that using multiple virtual processors is always bad. If you have a workload that actually can make use of multiple cores, you can definitely get a boost. Another useful case (though probably rarer) is if a developer needs to test a program on multiple processors. In general, though, my advice for this area is similar to my thoughts about Boot Camp -
use multiple vCPUs only if you know you need it, but otherwise leave it alone.
You can change the number of virtual processors while the guest is powered off (suspended doesn't count) by choosing Virtual Machine > Settings > Processors. If you want to change this before installing the guest, uncheck "Start virtual machine and install operating system now" on the final setup page of the New Virtual Machine Assistant.
Note: Many operating systems have different kernels or hardware abstraction layers (HALs) depending on how many cores they detect at runtime. Changing the number of virtual processors after installation may not trigger a change of the kernel/HAL. One notable example of this is Windows XP, and Microsoft does not support changing the HAL without a complete reinstall (it's unofficially possible). Therefore, it's better to choose the appropriate number of virtual processors
before installing the guest.
The default network type, NAT, allows multiple computers (e.g. the guest, in addition to the host) to share one connection. This is good for situations where you can only get one IP address (such as when you're directly connected to a cable modem), as well as preventing external computers (perhaps with viruses) from initiating connections to the guest. On the other hand, some useful things, such as Bonjour networking, require Bridged networking. A more detailed explanation of these modes is in Understanding Networking in VMware Fusion
If one type of networking isn't working for you, try the other. If you change the networking type, remember to get a new IP address for the guest if necessary (if you don't know whether it's necessary, it probably is) - exact instructions vary depending on the guest, but for Windows disabling/enabling the network adapter or restarting the guest should do it.
If your guest requires internet access, my suggestion is
NAT if possible and bridged if necessary. Host-only (or even no network at all) is more secure, but is suitable for only some use cases.
You should treat a guest the same way as you would treat a physical computer with regards to security. This means that if you connect it to the internet (which is the default), you should have a firewall, antivirus, and regular updates
. If you have shared folders enabled, this may provide a path for malware to read your personal data or (if the guest is able to write to the folder) infect files. While infected files probably won't affect OS X (I've not heard of cross-platform viruses yet), they could infect other guests that access the files.