In addition to the sparse and preallocated virtual disks, there's another, orthogonal set of options: split and monolithic. You can have a sparse/split virtual disk (the default in Fusion 2.0), a sparse/monolithic virtual disk (the default in Fusion 1.x), a preallocated/split virtual disk, or a preallocated/monolithic virtual disk.

While sparse vs. preallocated affects how the data inside the guest is stored in the .vmdk file, split vs. monolithic affects how the .vmdk file is stored on the host. In a monolithic virtual disk, everything in a virtual disk is kept in one file - this includes metadata about the virtual disk (e.g. size, geometry, parent disk, and so on). Note: You might still have multiple vmdk files in a virtual machine (either because you have multiple disks or because you have snapshots). The previous posts about sparse and preallocated virtual disks showed monolithic disks.

In contrast, a split virtual disk is, well, split into multiple files. There's a small, plaintext metadata file, and a number of slice files. If you have a preallocated/split virtual disk, each slice (except possibly the last) will be 2 GB. If you have a sparse/split virtual disk, each slice can be up to 2 GB, depending on how much data falls into that slice. Preallocated/split virtual disks have a -f### suffix (where ### is a number), while sparse/split virtual disks use a -s### suffix.

So why choose one over the other? Split disks are critical in some cases - for example, some filesystems (such as FAT) can't deal with files larger than a certain size. By splitting virtual disks to be below this limit (typically 4 GB), you can keep a virtual machine on such a filesystem without losing data. Another advantage of split disks is that you don't need as much space to consolidate snapshots or shrink virtual disks. We try hard not to lose data, so rather than doing these operations in place (where something could go wrong if the power fails), we make a copy and only replace it when we're sure it succeeded. Because of this, if you use a monolithic disk, you might need as much free space as the virtual disk occupies to complete such an operation. On the other hand, with a split virtual disk, you only need 2 GB (or less, if you have a sparse slice that's smaller) since each slice can be done individually.

On the other hand, monolithic disks have some advantages too. In addition to more obvious limited computing resources such as CPU or disk space, one of the not as well known ones is something called file handles. OSes need to keep track of which files are being used, and has a limited number of file handles to do this with. If the OS runs out of file handles, no more files can be opened. Remember that you're using a lot more files than just the documents you're working on - programs need to open files to read resources, for temporary use, and lots of other not immediately obvious things. With a monolithic virtual disk, you use only one file handle per virtual disk. With a sparse virtual disk, you use one file handle per slice, which can quickly add up if you've got a large virtual disk with a lot of snapshots.

Continuing in our theme of the different ways to move to VMware Fusion, today’s video revolves around importing a Parallels-based virtual machine or Virtual PC for Mac-based virtual machine to run on VMware Fusion 2.

Lots of people enjoy the stability, power, and user-friendliness of VMware Fusion, and as such, are switching from Parallels Desktop for Mac to instead use VMware Fusion 2 to run Windows on Mac.

And people who have been using Virtual PC for Mac to run Windows in emulation (NOT virtualization, like VMware Fusion) on their Power PC-based Macs, but who are now moving to Intel Macs, will certainly be looking for a new way to run Windows on Mac.

In fact, recently, people like Walt Mossberg of the Wall Street Journal, and Dave Girard of Ars Technica have been noting that VMware Fusion is the better way to run Windows on the Mac.

Switch to Fusion with Unparalleled Ease

In order to make this really easy for our users to switch and not have to rebuild their VMs, and the work that went into them, we’ve included a feature in VMware Fusion 2 that allows you to directly import Parallels and Virtual PC for Mac (for those people moving from Power PC-based Macs up to Intel-based Macs) to run in VMware Fusion.

Like most things with VMware Fusion, it’s easy, straight-forward, and “just works.”  You can check out the video below to see how easy it is.

And as a quick ad, this video is taken from the more than dozen VMware Fusion 2 video tutorials made freely available to help you get the most out of VMware Fusion 2.

I previously gave a tip about how to make effective use of snapshots, but what about how they actually work? As I mentioned, one of the key things to understand about snapshots is that they only store the differences between the current state and the original state. Technically-minded people will recognize this as copy-on-write.

Let's suppose you have a sparse virtual disk as shown. You then take a snapshot and do a little bit of work - modify the file at the far right and shorten the one before it. Once you take a snapshot, the original base disk is no longer written to, but is still read from. Most of the virtual disk is still pointing at the base file, but what you did change now refers to the snapshot. By itself, snapshot 1 is not enough to represent the virtual disk, nor is the base disk. Snapshot 1 might not even contain complete files, but only parts of files that have changed.

If you take another snapshot and make more changes, a similar process happens - now neither snapshot 1 nor the base file are written two, but are still referenced. New changes go to snapshot 2.

Hopefully you can see why each snapshot can take up as much space as is allocated to the virtual disk - you might overwrite every single block, and Fusion needs to keep both the original (in case you want to revert to the snapshot) and the new data.

With a preallocated virtual disk, it's nearly the same story. Only the base disk changes to a 1-to-1 mapping, but each snapshot is still sparse.

Unlike OS X, most other operating systems require the use of multibutton mice. Most Mac users know you can ctrl-click to simulate a right click, and you can do that in Fusion as well. But what if you actually want to ctrl-click in the guest - say, to select multiple items in Explorer?

In Fusion's Preferences, go to the Keyboard & Mouse tab, Mouse Shortcuts. Uncheck the secondary button shortcut (or map it to something else) - now you can ctrl-click in the guest.

If you still need to right click and don't want to remap to a different shortcut, there may be other options. For laptop users, you can enable two-finger right clicks in System Preferences > Keyboard & Mouse > Trackpad. If you have a Mighty Mouse, you can enable right click in System Preferences > Keyboard & Mouse > Mouse. And of course, since OS X has always supported multibutton mice, you can always plug in your favorite multibutton mouse.

Apple likes to talk about how 50% of all Mac purchasers are switching over to the Mac from the PC. 

Just recently, Apple’s COO, Tim Cook, Apple specifically called out VMware Fusion as one of the driving factors helping people to switch to the Mac, by making it easy to run the Windows apps you’ve come to love, or which don’t have Mac versions, on your Mac, virtually.

Bring your PC with you as you switch

One of the things that helps people do this, is the ability to move an existing PC, a physical Windows box, like a Dell or HP or what have you, to a virtual machine, to run on VMware Fusion.

Yes, it does sound like black magic, but really, it’s quite easy.  In fact, we provide a free tool, VMware Converter, which runs on pretty much any Windows OS, that will make a bit-by-bit virtual machine copy of your existing PC to run on any VMware virtual machine runtime (Fusion, of course, being this team’s favorite).

To help you get a better idea, here are two videos that show exactly how to switch to the Mac with VMware Fusion by bringing along your existing Windows PC.

These are both taken from the more than dozen VMware Fusion 2 video tutorials made freely available to help you get the most out of VMware Fusion 2.

VMware eLearning step-by-step video:

VMware Fusion team’s slightly sexier, though less exhaustive video:

Chris White pinged us on Twitter the other day saying that he was using WindowsBlinds to skin his VMware Fusion Unity windows (Unity demo video here) in Windows look like Mac OS X windows.

We were intrigued, and asked him to take some screenshots to share with everyone.

Chris was nice enough to do so.

Here’s a shot of Internet Explorer with a Mac OS X WindowsBlinds skin on it.  The visual style is “Leo.”  Hmmmm…wonder what that stands for….?

Note how the “close” “minimize” and “maximize” buttons in the upper right of the window look like Mac OS X buttons:

And in a too-meta-moment, here’s a screenshot of the WindowsBlinds UI, which has itself been skinned!

Last time I covered sparse virtual disks. This time, let's look at the other option: preallocated virtual disks.

If you recall, the main advantage of sparse disks is that space is not grabbed upfront, but rather as needed. A preallocated disk, on the other hand, is (as you might expect) preallocated. You tell Fusion that the virtual disk should be 10 GB, and Fusion goes off and grabs 10 GB of disk space. Performance may be slightly better with a preallocated disk.

There are fewer problems with fragmentation on a preallocated virtual disk. As you might recall, there are three layers where a sparse virtual disk can get fragmented: the guest filesystem, the .vmdk file, and the host filesystem. A preallocated disk avoids fragmentation at the .vmdk file level, and fragmentation at the host OS filesystem level will not grow worse over time (since Fusion already grabbed all the disk space, there's no need to get more). For best results, you can defragment the host filesystem before creating a preallocated virtual disk to make sure it's as contiguous as possible.

Having a preallocated disk doesn't mean that your virtual machine will always be the same size, however. The most obvious example is that taking a snapshot or using AutoProtect will increase the needed space, and snapshots tend to grow over time.

Personally, I stick with sparse virtual disks. I like the flexibility of having extra space, which lets me keep more virtual machines at the same time than if I had to commit all that space right away. The only downside is that I have to be a little more careful about not running out of space, but I keep enough free that it's never a problem.

People sometimes get confused about how snapshots work and how to use them. While snapshots are incredibly useful for many things, one major misconception is thinking that they are a form of backup - they're not! If a lightning strike totally fries your computer, a snapshot won't help if it's on the same disk (because your snapshot just got fried too). Sure, you'll probably get lucky - if your computer merely shut down uncleanly, your snapshot may still work. You might not even need to go use the snapshot. But this is not a backup, it's gambling.

If you want to back up a normal virtual machine, shut down (or suspend) the virtual machine and quit Fusion -- you never want to try to read or modify virtual machines when Fusion is working on them. From the Finder, copy the virtual machine to a suitable external drive. Done! If you're feeling really backup-ful, keep the external drive offsite - this way you're protected against disasters that affect your entire location (e.g. fire, flood, etc.) A snapshot is better than nothing, but it's not true backup.

As you use a computer, over time your files will tend to get scattered around the disk. This scattering is called fragmentation, and can slow down performance as the disk head has to seek back and forth between fragments (Note: doesn't apply to solid state media, which doesn't involve disk heads). Defragmentation (or defragging) is the act of reversing the process, putting order back into your system. With virtual machines, proper defragmentation is a little more complex than it is on a physical machine because of the layers involved.

Before we begin, it's important to note that defragmentation isn't a necessary task - your virtual machine will still work just fine even if you never defrag, and the effects of fragmentation are usually not noticeable. Personally, I've never feel the need to defrag. However, if for some reason you do feel the need to defrag, here's how to do it. Note that snapshots get in the way of proper defragmenting.

If you're new to virtualization and computers, you might be confused about why deleting a virtual machine doesn't seem to free up the space you think it should, or why the guest might be complaining it's out of space when there's plenty left on the host (or vice versa). Why this happens becomes clearer when you start thinking in layers.

Before we begin, one common misconception is that Fusion somehow partitions the physical drive - not so! For normal virtual machines, a virtual disk is simply a (probably pretty large) file. We use normal OS X file operations to access it. For Boot Camp virtual machines, there is partitioning of the physical drive involved, but Fusion doesn't do it - you did it when you set up the Boot Camp partition in the first place. While we do use raw disk access for Boot Camp virtual machines, again, it's by standard OS X APIs.

By default, VMware Fusion uses what are called "sparse" disks. That is, we don't grab space upfront, but rather as needed. In the diagram, chunks of space (for technical users, blocks) are represented as squares; colored ones are occupied, white ones are unused. The guest (green) thinks it has an entire 20 GB (or whatever) drive. However, if the guest has only ever written 5 GB to the drive, the .vmdk file (red) will only be 5 GB, not 20. The host (blue) can store the .vmdk however it wants on the actual hard drive, perhaps interspersed with other files (grey).

Since Fusion doesn't grab space upfront, deleting a virtual machine with a 20 GB disk might not (actually, probably will not) free up exactly 20 GB of space. It can be less (as in this example) or more (if you have a snapshot, which I'll cover in a later post). There are other files in a virtual machine, but the virtual disk is usually most of it.

Each layer is (at least somewhat) separated from the others, which can lead to some misunderstandings. For example, if you run out of space in the host, it doesn't matter if you still have 10 GB left in the guest - there's simply nowhere to put the data. Conversely, even if you have 100 GB left on the host, if the guest has used up the entire (virtual) hard disk, it can't write any more data. Keep an eye on free space in both the host and the guest.

The main advantage of using sparse virtual disks is, well, that they take up less space. As always, there's a tradeoff involved, but we think the benefits for most people outweigh the inconveniences. In the next VMware Fusion 201 post I'll talk about your other option, preallocated virtual disks.