Not a Delphi or even Pascal related post on this occasion, but an experience that may interest any developer running Windows in a VM on a Mac.
I have been using Parallels desktop virtualisation solution to run Windows on my iMac since the day I got it (or I should say “them”, since I have one at work as well as my own at home).
Up to now it has “just worked”, and worked very well.
A few weeks ago I decided I needed to shuffle things around to free up some space on my system volume. As part of that I decided to move my VM’s onto an external HDD. After some initial experimentation with one VM I concluded that this was not having any material impact on performance (one concern I had read when considering such a move) so went ahead and moved them all. I have quite a few:
- Oxygene (Windows 8 64-bit, Oxygene + Visual Studio Express editions for Mobile and Web etc)
- Delphi (Windows 7 64-bit, all key/interesting versions of Delphi)
- Windows 7 for apps – a “sandbox” where I can try apps out
- Windows 7 for games
- Android x86
- LAMP
Plus various templates that provide “clean” baseline VM’s that I can use to create new VM’s as/when appropriate. All up, almost 500GB of VM’s, so moving these things takes time, especially over USB 2.0
But for a couple of weeks this has all been chugging along nicely.
Then, this past weekend, there was an OS X Mountain Lion update and a Parallels 9 update, which I applied and that’s when my troubles seem to have begun although I didn’t realise until a little later.
The Problem
On Sunday I tried to fire up my Oxygene VM and was told that the VM could not be started due to an error: “Unable to change permissions on virtual machine”
I hadn’t changed any permissions myself so had no idea why this would be a problem now. I tried my Delphi VM. Same problem. Same problem with all my VM’s in fact (except one, which I only discovered yesterday – I’ll come to that in a minute).
But I have had trouble – once – after a power outage damaged a volume leading to spurious errors that had me similarly scratching my head for a while. Verifying and repairing the volume fixed things on that occasion. There was no power outage in this case, but I thought I’d try it anyway. It didn’t help on this occasion.
Worth noting is that the specific “Repair permissions” facility in Disk Utility only applies to files installed by software packages and so cannot help if the issue is with permissions on user created files, as in this case.
A peek at the Parallels support forums provided a few clues from older Parallels versions (but nothing recent), such as explicitly setting read-write permissions on specific files in the VM bundle. Initially this seemed to help. I was able to start my VM’s after changing the permissions, but once having been stopped/suspended they again refused to restart. Curiously, the modified permissions had reverted and this time changing them back to read-write made no difference.
Have You Tried Switching It Off and Back On Again ?
I tried re-booting the entire system.
Hey presto! My VM’s would once again start/resume as normal. But only on and only once. Having started just one VM and then suspended it all the VM’s once again became unusable. It didn’t seem to matter which VM I chose as my one and only VM to start.
There then followed many fruitless hours trying to figure out how OS X permissions worked beyond the simplified level at which they are exposed via Finder.
Love / Hate
I confess to a love/hate relationship with OS X. I love the way it “just works” pretty much all the time and I love the way that the dirty details are kept out of the way but can be got at when needed. But I hate the dirty details themselves. Or rather, the fact that information about them can be hard to find. I actually quite like working with a CLI, and the OS X terminal reminds me a lot of my old Amiga… but I digress.
As I said, it was fruitless. Getting dirty with details didn’t help.
Parallels support remoted to my machine on two separate occasions, and they couldn’t figure it out either.
A Solution – Hopefully Only Temporary
Then yesterday I realised that there was one VM still living on my system volume – Windows Games.
And it started just fine. Start-Stop-Start-Stop… no problem.
So I moved one of the smaller VM’s back from the external drive to the system volume. Start-stop-start-stop… no problem.
Clearly something has gone wrong either as part of the OS X update, the Parallels update, some bizarre interaction between the two or – possibly – corruption on the volume in question that the verify/repair tools are not able to identify.
Now though I can at least get back to “work” by simply moving my VM’s back to the system HDD.
Hey ho.
At some point I shall shuffle things around so that I can reformat before putting everything back and seeing if that fixes things.
In the meantime, this could be a cautionary tale for anyone contemplating putting their VM’s on an external drive.
Or, if someone has had similar experiences in the past and can shed some light on how they solved it, that would be useful too.
Thanks for the update. My VMs are on the local drive, but it’s good to know.
If you like getting closer to the metal in OSX, you might like products from Rixstep http://rixstep.com/. In particular, Xfile and CLIX. These guys are serious gurus.
Looks interesting. I will take a look at them later. Thanks. 🙂
Have you tried reaching out to Parallels for comment? I’m currently on Parallels 8, and am wondering whether upgrading to v9 is a good idea. I’m having some issues with my Windows 8.1 VM under v8.
As I mentioned in the article, I have had two remote sessions where a Parallels support rep took control of my machine and investigated. I suppose they didn’t put any significance on the fact that the VM’s were on an external drive since this isn’t normally a problem.
And it is quite possibly not a Parallels problem per se, but an issue with my external volume – the fact the a reboot fixes things, albeit for only one instance of starting a VM, suggest to me that it is something other than a simple “bug” or other issue in Parallels itself.
Ah right. Sorry, I missed that when glancing through your article. It’s been a hectic morning. 🙂
Did you try to format external volume to OS X’s specific file system?
Yep, it has always been a Mac formatted volume.
I ran into that a while back while trying to move my Time Machine files to another volume. It was an ownership issue.
You need to open Finder, right-click on the external volume, select Get Info, then go down to the very bottom and fiddle with “Sharing & Permissions” for the drive. Make sure that your regular user has “Read & Write”. Then click the gear at the very bottom and select “Make the owner” then “apply to enclosed items”.
Yep did all that – and more (using a bash Terminal – Finder only exposes a subset of permissions). On my version of OS X the ownership setting on the drive inverts the logic – it is now “Ignore ownership”, but either way, ownership was set to be respected.
There is a further update on this issue however. My problem wasn’t as 100% solved as I had though.
Yep did all that – and more (using a bash Terminal – Finder only exposes a subset of permissions). On my version of OS X the ownership setting on the drive inverts the logic – it is now “Ignore ownership”, but either way, ownership was set to be respected.
There is a further update on this issue however. My problem wasn’t as 100% solved as I had thought.
Come to think of it, there was something else, too. Ahhh… yes. In Disk Utility, if you select the drive (the indented one), at the bottom you’ll see an item that says “Owners Enabled”. That needs to be set to “Yes”. The easiest way to do that is to reformat the drive, but supposedly there are ways to do it as well.