Monday, August 06, 2007

generalAvailability(VMware Fusion) && num(VCPUs) != numRunning(VMs)

Because every geek needs to post a blog entry with a title written in predicate logic every once and a while :)

Fusion 1.0 is now generally available! Woo Hoo

This post links to a ZDnet article (though there are many others) because I wanted to make a slight correction. I don't have anything against ZDnet, thanks for the coverage. I can see how VCPUs and VMs might be confounded and this little error seems to have spread beyond the land down under; the tubes must have been particularly empty during the last week.

VCPUs, or virtual CPUs, are what Fusion (and other VMware products) expose to the virtual machine (VM) to allow the VM to execute instructions. In other words when you run programs in a virtual machine they think they are running on a real computer and running instructions on a real CPU. To greatly simplify things, a VM uses the abstraction of a VCPU to confine the execution of a single virtual machine and ensure that it can't wreak havoc on the rest of the system that it's running on (including other VMs).

Just like a real computer can have 1 or more processors (CPU) a VM can have 1 or more VCPUs.

How many VCPUs can a VM have?
In Fusion each VM can have 1 or 2 VCPUs. This is the same as Workstation 6. We actually create new VMs with a default of 1 but allow people to set it to 2. Why you may ask? The more the merrier right? Well it turns out that's not quite the case. There are certain things that will run "faster" given the extra parallelism but some things actually run slower. This is because of our dependence on a host operating system; OS X in the case of Fusion and Linux and Windows in the case of Workstation. Because the programs running the the VM have no idea they are running inside a VM they assume they have full control of the hardware. In particular they can ask that certain instructions be run simultaneously on certain CPUs. One of the main tenets of virtualization is that execution in a virtual machine should behave the same and yield the same results as running on a real computer. This means that Fusion can't turn around and run the requested instructions at different times; they must be run at the same time on the different CPUs. This turns out to be rather hard to do efficiently on most systems.

So if it's sometimes slower why run with 2 VCPUs?
The main reason would be to actually test out multithreaded code. It's hard to guarantee that you've written thread safe code. Most problems will arise when running stress tests and going from 1 to 2 CPUs.

OK, so how many VMs can I really run then?
In theory, we set an (artificial) upper limit of 24 VMs. In practice we will never let you start a VM if the computer you are running on doesn't have enough resources. For example if you have a limited amount of memory and you are trying to start a VM that will consume much more than the memory available (to the point that your entire system, not just the VM, would become unusable) then we won't let you start that VM. This means that even if you have an XServe maxed-out at 16 GB of RAM you might not ever reach the 24 VM limit.

Long story short, we don't limit you to 2 VMs (we limit it to 24 but that won't really matter in practice given the current state of hardware), we do limit you to 2 VCPUs since more just wouldn't effectively run faster. Load up that system with RAM and run the VMs you need to get your work done :)

1 comment:

Ben Gertzfield said...

Boy, am I glad you didn't use short-circuit Boolean logic in that post title.