I had been without my MacBook Pro while it was in repair for a power-related issue. Prior to my handing over my system to Apple, I secure wiped the entire disk but some Vaulted users for demonstrating the system malfunctions.
Upon my first system restore, I was unable to run any of my machines as the reported “File locked” in the Virtual Machine list as their state.
The machine packages themselves were not locked at a file system level; however, upon exposing the package contents of each Virtual Machine, there existed a series of .lck files. So, knowing I had a good backup still of course, I proceeded to delete the least innocuous and most likely candidate file first: .vmx.lck.
Presto! Once that file was removed, I reloaded Fusion and confirmed the status had changed to “Powered off” which was its true status. I had a hunch that the machine still would not work though as there were several lock files remaining. Where had they come from? Hadn’t I powered the machines off prior to the last cloning? Then it hit me… I test all my clones by booting directly to them though I don’t use the disks once I confirm they are operational – except once when I launched my XP virtual machine to get access to files I left within it. While this could be the reason for one series of lock files, how could that explain that my Vista, 2008, Ubuntu, RedHat, CentOS, Celerra, and so on were all in “File Locked” state when I know those systems hadn ‘t been accessed subsequent to the clone operation and, therefore, were in a clean state?
For now, I decided to delete all the lock files and confirm each machine’s health. Though I chose to relaunch Fusion for good measure, simply double-clicking the package, using “File | Open…” or “File | Open Recent” would all have worked.
What I need to schedule for a lab now is to test if recovering from a clone is related to the creation of the lock files. Until then, case closed… happy VMing again.
Bordeaux or CrossOver?
I am an avid user of virtualization and emulation since as long as I can remember. However, what a heavy-weight solution it is to support an application only by means of a virtualization host.
For example, I use a great program to learn German called the Rosetta Stone. Unfortunately it ships only with a Windows installer and no means of running on my other two primary OSs, Linux and OSX (Leopard and Panther), other than by means of some emulation/encapsulation/virtualization layer. Here is where CrossOver and products such as VMware can readily and reliably step in (especially the latter).
As it has been for a while, I first try to run the application in CrossOver then should that fail, I’ll install it into as a guest into my VMM, usually VMware nowadays. Of course there are programs I will install straight into a VM for other reasons, such as interaction, dependencies or data exchange between existing or planned programs.
The downside to both of the above solutions is cost. Now aside from running free virtualization products (which I do), I don’t see cutting ties to VMware any time soon (not just because I’m certified and therefore must proselytize).
A CrossOver license is required for each machine that I install it on, regardless of whether or not there isn’t concurrent usage.
The pros for Bordeaux are:
- Inexpensive! (I can afford to dish out for a copy for each of my key systems)
- Supports Linux (I use BSD for servers only right now really so its BSD support is neither a pro or con)
- Office 2007 support (CrossOver still lists their support of 2007 as primitive)
The cons for Bordeaux are:
- Less official application support
- Doesn’t support OSX installation officially
Right now, I’m betting on CrossOver over Bordeaux only in that it is the established player. Once I see Bordeaux support Office 2007, I’ll reconsider. I run a few Windows VMs on my MacBook Pro so I’m well covered regardless and can wait patiently.