Home > Blogs > VMware Fusion Blog > Author Archives: Eric Tung

Author Archives: Eric Tung

VMware Fusion 301: Control of Hardware, part 1

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

Tip: VMware Toolbox

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?

Open Toolbox
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).

VMware Fusion 101: Introduction to Tools

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.

Tip: Find Virtual Machines

Show in Finder
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.

Tip: Guest OS Type

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.

Tip: Switch Virtual Disk Type

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.

VMware Fusion 201: Split vs. Monolithic Virtual Disks

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.

VMware Fusion 201: Snapshots

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. Snapshot_1
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.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.

Tip: Control-click

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.

VMware Fusion 201: Preallocated Virtual Disks

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.