(Update 7/18/2012: My theme cuts off the title. The full title is, “VirtualBox 4.1.18: How to solve “Failed to load unit ‘HGCM’ (VERR_SSM_UNEXPECTED_DATA)”.)
So, this is a bit of a departure from my usual type of post, but it’s still DevOps-related (an area I’m increasingly getting into), and people are probably searching for this.
My experience with this error
I had to send in my Windows laptop for warranty repair, and I was running a couple work-critical VirtualBox virtual machines (“VMs”) on it. I use Vagrant to run them without a GUI, and moving them was easy. I used vagrant package, copied over the project files, and ran vagrant up on the destination machine. This was not the issue.
I got this error when I suspended the virtual machines, then tried to resume them
So for some reason the VMs started up without issue. However, upon suspend and resume, I started getting the titular error. I searched for it on the Internet and found a VirtualBox forum which linked to a bug report which suggested editing the .vbox file. This is in <home directory>/VirtualBox VMs/<name of VM> and is named after the VM as well. It ends in .vbox.
Now, before you edit it, make sure you:
- Suspend or shut down all running VMs
- Close VirtualBox
If you don’t, this won’t work because VirtualBox will use the previous configuration anyway.
OK, so open up the .vbox file. Search for SharedFolders. You will see something like:
<SharedFolder blah blah blah />
Anywhere in the file you see that, change it simply to:
and save the file.
Now open VirtualBox and try resuming the afflicted VM again. It should work. If it doesn’t, go check the .vbox file and make sure VirtualBox didn’t change it back. If it did…then make sure you followed the two preparatory steps above. I’m speaking from experience here. You can’t skip those.
And you’ll be good!
Update (7/17/2012): If you have several VMs that you run together, sometimes one of them will resume while the others fail with this error. If you resume that one, you may be able to subsequently resume the others. Not sure why this happens since the VM in question didn’t have any VirtualBox shared folders (not even in the XML), though some were using NFS. Perhaps it was internal-network related. Just noting this here since it happened.