Brian Roy published a fun video blog today with some tips for how to do really easy web application development using VMware Fusion on your Mac.

Brian is a web developer, and he does a lot of development using PHP, which ultimately runs in a LAMP stack.  In his case, a lot of his work runs in the Amazon EC2 cloud.

Brian uses VMware Fusion as a way to have a virtual machine instance of Fedora (which is what Amazon runs in its EC2 cloud) on his Mac, in which VM he has created a shared folder that points out onto his Mac, where his PHP and HTML code resides.

Brian likes to code using the text editor Smultron, on his Mac, and so when he saves off what he’s doing in Smultron somewhere in his Mac Documents folder, he can immediately pop over to his Fedora VM on Fusion, and test run that code over the shared folder.

That is to say, Apache, running in that Fedora VM, can execute that PHP code, via the shared folder, which looks out onto Brian’s Mac.

You can watch Brian’s video below, and below that, there’s one of our handy tutorials that talks about shared folders.  Enjoy!

Video: VMware Fusion Developer Tips and Apple after Steve Jobs from Brian Roy on Vimeo.

And here’s that video tutorial on using Shared Folders:

Last week when I wrote about what Tools generally does and mentioned that it enabled 3D acceleration, someone asked a natural question: What makes 3D acceleration in a virtual machine so hard? Why can’t the guest directly control the graphics card?

Continue reading →

Last time I gave a brief overview of what VMware Tools is and why they’re is important. But how do you interact with them?

The main way is via VMware Toolbox. You’ll need Tools installed, of course, and the way you get to it depends on the guest OS you’re running. In Windows, right-click the VMware-three-boxes logo in the system tray and select Open VMware Tools. In Linux or Solaris, run vmware-toolbox. We don’t currently have a Toolbox for OS X guests, and I’m not sure about FreeBSD or Netware. You’ll need to have opened Toolbox as an administrator for some features.

Once in Toolbox, you can get information about what version of Tools you have installed (About tab), shrink a disk (Shrink tab, requires a sparse disk with no snapshots), links to shared folders (Shared Folders tab, if you have them enabled), scripts which are run when the virtual machine powers on/off or suspends (Scripts tab), connect/disconnect devices (Devices tab), and general options (Options tab).

Tools does way more than what’s listed in Toolbox, but the other stuff is either automatic (such as copy/paste support) or configured elsewhere (such as HGFS shared folders, which are under the virtual machine’s Settings).

I've previously alluded to how difficult it is to figure out what's going on in the guest by examining the instruction stream. Yet Fusion can do all sorts of nifty things such as drag-and-drop, Unity, HGFS shared folders, and so on – there's no way Fusion can do all that on its own. So how do we do it?

Enter VMware Tools. Tools is code that lives in the guest and allows us to peek inside. Instead of Fusion staring at a stream of reads and writes and adds and so on to try to figure out what's going on, Tools can just ask the guest OS. Doing things at the right layer makes things so much simpler!

Tools it a bit more than that, though. One of the benefits of virtualization is portability – you can move a virtual machine between computers (in some cases, even as the virtual machine is still running). But what if the first and second computers have different hardware – how can the virtual machine possibly cope if it starts off on a Mac mini, gets suspended, and resumes on a Mac Pro (or maybe even a computer running Windows or Linux and using VMware Workstation, VMware Player, VMware Server, or so on).

Virtual machines don't see the physical hardware directly (which would cause portability problems). More importantly, nearly all hardware expects to be controlled by exactly one OS – even if the guest could see the physical hardware, it would cause lots of problems. Instead, the guest sees a set of emulated hardware that doesn't depend on the actual hardware; Fusion takes care of translating appropriately.

All hardware, even virtual hardware that doesn't really exist, needs drivers for OSes to know how to talk to them. For some of the virtual hardware (for example sound) we emulate existing physical devices, the guest can use standard drivers provided by the OS or third parties. For other virtual hardware (for example video) we use our own "hardware" that doesn't exist in the physical world. While it obeys a basic set of commands, it needs drivers to get all the features (such as 3D acceleration). These drivers are a part of Tools.

Generally speaking, you want to install Tools in the guest, instructions can be found in Fusion's Help. We have Tools for a wide variety of guest OSes – Windows of course, and Linux, and OS X, and Solaris, and FreeBSD, and even Novell Netware. Not all versions of Tools have the same capabilities (we obviously give priority to more commonly used guests), but all are useful.

Ever wonder where your virtual machines are kept? The default location for non-Boot Camp virtual machines is /Users/${USER}/Documents/Virtual Machines. Boot Camp virtual machines are kept in /Users/${USER}/Library/Application Support/VMware Fusion/Virtual Machines. You can also locate a virtual machine by ctrl-clicking on it in the Virtual Machine Library and selecting “Show in Finder”.

Yet another way to find virtual machines is to use the fact that they tend to be quite large. Simply look for where your disk space is being used, perhaps with a tool like Grand Perspective or with a regular Finder search.

Fusion’s view of the world is very low-level – when you run a virtual machine, Fusion sees machine-level instructions like "add registers A and B" or "write the contents of C to memory address X". Based on just this information, we might be able to tell you’re generating network traffic and there’s some video updating going on, but we would not be able to tell what program you’re running to do this, or even what guest operating system you’re running. Knowing what guest OS is being used in a virtual machine is important because some of them have quirks – one might not like video RAM above a certain size, while another might panic if it sees too many PCI slots, and a third might be unforgiving about how long I/O can take. There might be certain shortcuts that can safely be taken for certain guests. When you create a virtual machine, Fusion needs to know the intended guest OS to correct for the quirks and enable optimizations.

If you ever change the guest OS in a virtual machine (say you upgrade from Windows 95 to XP), you can (and should) use the Virtual Machine Library to change the guest OS that Fusion thinks resides within. Knowing which guest OS is being used is also important for things like Tools install – Fusion automatically picks the correct Tools image to use based on which guest OS you’ve told Fusion is being used in the virtual machine.

Now that you’re familiar with sparse, preallocated, split, and monolithic virtual disks, you might be wondering how to switch from one format to another. In Fusion 2.0, this can be done through the virtual machine’s Hard Disk settings pane – select the options you want, then press Apply. Fusion will convert the disk’s format to the one you specified.

As usual, you can do this only if you don’t have any snapshots, and you will potentially need as much free space as the maximum size of the virtual disk.

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.