Since the day VMware came out, virtualizing OS X quickly became a peculiar resource for most IT professionals, including:
- Software developers interested in writing applications for iPhone, iPad and Mac using XCode wth Objective-C or Swift without being forced to buy a Mac.
- System administrators wanting to test experimental configurations and/or simulating changes in a secure environment before bringing them into production.
Not to mention all the IT enthusiasts working in a Windows environment yet interested to take a look at the latest versions of Apple's operating system, maybe without being forced to commit thousands of money for an hardware they're not interested in.
If you don't know what VMware is, or you have never heard of virtualization, I recommend you to go fill your gaps by reading the relevant Wikipedia entry and then the taking a look on the VMware official website. I'll just say that we're talking about a virtualization software that allows you to run one or more virtual machines - each one running its own operating system - on a single hardware platform of your choice, usually running Windows or Linux (or any other VMware-supported OS). In the following article I'll address a specific issue affecting a OS X Yosemite Virtual Machine running on a Windows or Linux platform powered by VMware Fusion or VMware Workstation.
The problem
If you stumbled upon this post you've likely already experienced the most common problem of this specific configuration: the huge performance issue affecting OS X after upgrading it from Maverick to Yosemite, or even installing Yosemite directly. This is a critical issue, considering that we're talking about a refresh rate dropping from 40-50 to 2-3 FPS (frames-per-second, taking an average PC as benchmark): a massive performance drop that makes the system almost unusable either for basic desktop navigation than for most complex applications such as XCode.
At first glance the problem seems to be related to a less-than-optimal usage of the resources allocated to the virtual machine: unfortunately, assigning more RAM or processors to the VM in question doesn't seem to fix it: the system seems unable to efficiently draw the GUI, constantly mingling between foreground and background windows.
As a matter of fact, the issue isn't related to a lack of allocated resources at all: the problem lies in some changes made by Apple to Beam Sync (short name for Beam Synchronization), a feature first introduced in OS X 10.4.x to better handle screen redraw, GUI and Windows management: which, ironically enough, is exactly what is broken right now. That's because it seems like Yosemite's Beam Sync is working fine on a real Apple PC, but appears to be a significant issue when running within a virtual machine. Needless to say, Beam Sync is an OS X native feature, thus it's also activated automatically whenever the system starts.
The solution
Now that we've identified the issue, the fix is pretty simple: we just need to disable Beam Sync and our system performances will drastically increase, reverting back to what we had with Maverick. Unfortunately, there is no native functionality to disable Beam Sync: in order to do this we need to use some low-level maintenance software such as Apple's Quartz Debug developer tool or a third-party script.
If you want to be sure that disabling Beam Sync is the key to solve your problem, just download the Quartz Debug developer tool from here, install it, then run it and disable the offending feature as shown in the following screenshot:
The bad news is that, since Beam Sync is started automatically by the operating system, you'll need to repeat this step after each and every Login.
Fortunately for us, a brilliant insanelymac.com user (JasF being his name) developed a handy tool called BeamOff that lets you disable Beam Sync with just one click: you can download the source code on GitHub or a compiled version here: the latter has been published by the author itself near the end of this thread on insanelymac.com support forums. The reason BeamOff is so great is not only because it's a lot more practical than the Quartz Debug developer tool but also, most importantly, because it can be used to automate the process.
In order to do exactly so, rtrouton of derflounder.wordpress.com built a special LaunchAgent which, togheter with BeamOff, serves the purpose of automatically disabling Beam Sync right after each boot, which happens to be the perfect solution for our scenario. All we have to do in order to implement it is download the installer (in .zip format), unpack it and run it on our VM: he'll take care of adding the most recent version of BeamOff in the /Applications folder and installing the LaunchAgent in the /Library/LaunchAgents folder.
For those interested to build a customized version of the installer, the entire project's source code is available on GitHub, also including - in the /Resources/ folder - the compiled version of BeamOff and the project files used to build the installer.
Thanks to rtrouton and to derflounder.wordpress.com for solving the issue!
