Receiving the following errors when I try to start up my virtual machine(s) in Vmware Fusion 5 -
Reinstalled Vmware Fusion 5 using these instructions - http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=101783...
Uninstalled. Restarted. Reinstalled. Restarted. Started virtual machine, same errors.
Thinking it might be a problem with the virtual machine, I copy over another virtual machine that's running just fine on another Mac downstairs. Same errors. I'm running 10.8.2 on a 2012 Macbook Air.
Starting to think this is an enviroment problem, but I'm not sure where to start looking beyond the manual uninstall instructions. Any assitance would be greatly appreciated.
One strange thing I noticed - even after a manual uninstall and subsequent reinstall, it still lists the old virtual machine name in the Virtual Machine library list. Also, /dev/vmmon is still missing after a reinstall.
Thanks, Alex.
Looking further back in the support information bundle's history gave me a big clue. It seems that some driver on your system is triggering the problem by consuming all of the available "character device major numbers" (a small number used to identify a driver/device). I can't immediately identify the culprit driver, but the possibilities include:
We have quite a few users with VirtualBox alongside Fusion, so I doubt that VirtualBox is the cause, or I'd expect to have seen more widespread reports of this problem, unless it's being exacerbated by some other environmental factor.
It's also possible (although less likely) that it is a problem with one of the drivers built in to Mac OS, or it might even be one of the other drivers in VMware Fusion, but – again – in either of those cases I'd expect to have encountered more reports of the problem unless it's triggered by some other factor on your system.
Could you try temporarily uninstalling either the SNS iSCSI initiator or Viscosity VPN and see if that helps?
Cheers,
--
Darius
Repair hard disc permissions on mac hard disc using disc utility app and then try to install fusion.
Thanks for the reply avanish. I tried that, disk utility isn't reporting anything abnormal - http://cl.ly/image/3U1W3Y1S2w2j
Attempting to start the virtual machine after the repair yields the same errors.
Have a look at: Troubleshooting Fusion startup issues (1003484)
Thank you for the reply, WoodyZ. Unfortunately, the items listed in the KB do not resolve my issue (manually reinstalling & removing library files + repairing disk persmissions). Trying to create a brand new VM yields the same errors on first startup. Again, I think it's an enviroment issue.
Somewhere in my enviroment, there exists VMware data/settings that persist after a manual uninstall. This data goes beyond what's listed here http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=101783...
I've manually deleted all these files, restarted and upon a reinstall (and an additional restart), Fusion still somehow remembers the name of the last virtual machine I had in my virtual machine library. How is this possible? Again, there is data/service that is in corrupted/malformed which is not corrected during the reinstall process.
Please do not follow those instructions. (NOTE: the parent post containing the instructions, including steps purporting to create a directory at /dev/vmmon, has now been deleted.) /dev/vmmon is not supposed to be a directory... it is a device node. It should never be created manually. Creating a directory at that location is quite likely to make VMware Fusion fail. (FWIW, Mac OS won't even allow me to make a directory under /dev, even as root/sudo...)
--
Darius
Message was edited by: dariusd to mention the deletion of the parent post to which I referred.
Thanks, dariusd. Any advice on how we might go about replacing the missing /dev/vmmon/ ?
Hi akarpo,
The device node /dev/vmmon should be created automatically when our vmmon kernel extension (com.vmware.kext.vmx86) loads. That kernel extension should automatically be loaded when you start VMware Fusion, and should automatically be unloaded when you quit VMware Fusion.
There are all sorts of places where environmental problems could cause the above procedure to fail. The best way for us to figure out what's happening is through a support information bundle: Launch VMware Fusion, go to the Help menu and choose Collect Support Information. That will create a file on your Desktop. Attach that file to a reply in this thread, and I'll take a look. There will probably be sufficient information in that file for me to figure out what's going wrong.
Cheers,
--
Darius
Hi again akarpo, and a Merry Christmas to you too! If only I had a nice solution to your problem that I could gift-wrap up and give you, but not yet...
Thanks for the support information bundle. It's told me a little bit about what's going on, but there are still more questions than answers. I'd appreciate if you could do the following steps in order:
1. Launch VMware Fusion. Don't attempt to power on any VMs... just leave it running.
2. On your host, also launch Applications > Utilities > Terminal.
3. At the prompt in the Terminal window, run the following exact command:
ls -ld /dev /dev/vmmon
The output should look something like this (but it might also contain error messages in your case)...
host:~ username$ ls -ld /dev /dev/vmmon
dr-xr-xr-x 3 root wheel 4259 Dec 24 18:48 /dev
crw------- 1 root wheel 36, 0 Dec 26 01:12 /dev/vmmon
host:~ username$
4. Copy the resulting output from your Terminal window and paste it into a reply in this thread.
5. Quit Terminal and quit VMware Fusion.
Let me know if you have any questions, particularly if you don't already happen to be familiar with Terminal and aren't comfortable with it!
Thanks!
--
Darius
Thanks for looking into this, Darius. Hope you had an enjoyable Christmas
Output below.
Last login: Wed Dec 26 04:36:31 from localhostAlexs-MacBook-Air:~ Alex$ ls -ld /dev /dev/vmmonls: /dev/vmmon: No such file or directorydr-xr-xr-x 3 root wheel 4639 Dec 25 18:46 /devAlexs-MacBook-Air:~ Alexmce_markernbsp;Which confirms that /vmmon is missing. What might the next step be?
-alex
Thanks, Alex.
Looking further back in the support information bundle's history gave me a big clue. It seems that some driver on your system is triggering the problem by consuming all of the available "character device major numbers" (a small number used to identify a driver/device). I can't immediately identify the culprit driver, but the possibilities include:
We have quite a few users with VirtualBox alongside Fusion, so I doubt that VirtualBox is the cause, or I'd expect to have seen more widespread reports of this problem, unless it's being exacerbated by some other environmental factor.
It's also possible (although less likely) that it is a problem with one of the drivers built in to Mac OS, or it might even be one of the other drivers in VMware Fusion, but – again – in either of those cases I'd expect to have encountered more reports of the problem unless it's triggered by some other factor on your system.
Could you try temporarily uninstalling either the SNS iSCSI initiator or Viscosity VPN and see if that helps?
Cheers,
--
Darius
Hello,
Thanks for the response Darius.
Recently we had a smilar issue and when we went to ~/library/logs folder, VMware folder was missing.
So, we created folder named "VMware" inside ~/library/logs folder with the correct permissions and retsarted the and that fixed the issue for me. So, if you would like try the steps and see.
Also if the folder exists delete the folder and re-create it and do restart the Mac.
Thanks
RJIn wrote: Recently we had a smilar issue and when we went to ~/library/logs folder, VMware folder was missing.
So, we created folder named "VMware" inside ~/library/logs folder with the correct permissions and retsarted the and that fixed the issue for me. So, if you would like try the steps and see.
Also if the folder exists delete the folder and re-create it and do restart the Mac.
First of all "similar" and "same", especially in cases like this, are two distinctly different issues and secondly (as shown by the contents of the support bundle) the appropriate log folders exist on akarpo's system with the appropriate logs in them, therefore deleting and recreating them will really do nothing more then the state they're already exist in.
Alex, In a Terminal could you copy and paste the following command and then press Enter. Then attach the devlist.txt file it created on the Desktop to a reply.
ls -l /dev > ~/Desktop/devlist.txt
Good news everyone! Uninstalling SNS Network Solutions iSCSI initiator did the trick! Everything is working normally again. I didn't even have to reinstall Fusion, just a restart after the SNS uninstall was sufficient.
One other thing worth mentioning, since I had SNS installed alongside Fusion for quite some time (and it was working just fine) - I'm starting to think there may have been a third object in play that could have modified my enviroment. I installed the Intel Hardware Accelerator Execution Manager (HAXM) through the Android SDK recently. I know Intel released an update on November 21st for HAXM to resolve some issues experienced by users with Ivy Bridge chips (and I have a 2012 Macbook Air). I'm not sure if the 1.04 update available on Intel's site is also pushed through the Android SDK manager (which updates all the subcomponents). Perhaps that could have messed up the Fusion hypervisor? Hard to tell.
Also, Woody - I've attached the requested output as well, in case you wanted to look at it. Let me know if there's any other diagnostic information you'd like to take a look at.
Thank you everyone!
wow . good to know this.
Glad that you took time to explain why the steps helped me won't help in this case. Now, I understand
Cool. Glad we got things going again!
I still felt there was too much mystery (and too little explanation) in the solution, though, so I dug a little bit deeper, and found something interesting...
On my Mountain Lion host (MacPro5,1, 10.8.2, with no 3rd-party drivers loaded), I have only eight free character device major numbers free immediately after the OS boots. This is very surprising – it's much lower than I'd expected. The dump of /dev you kindly provided shows that VirtualBox claims at least two of them (37=vboxdrv, 38=vboxnetctl), Viscosity VPN claims at least another two (39=tap*, 40=tun*), Intel HAXM claims at least one (18=HAX);. It's entirely possible for drivers to claim those numbers without appearing in the listing of /dev, so there may be others consumed besides the ones we can see.
VMware Fusion wants at least two (one for vmmon – a.k.a. vmx86 – and one for vsock).
So... I think that it may not have been any one single driver that caused the problem... it was simply that there were too many "character drivers" on your host, and removing one of them freed up enough devices for Fusion to successfully launch. It would seem that we need to ask Apple to allow more of these character devices to be created...
Thanks for your patience with this issue. Not only did we successfully solve your immediate problem, but I learned a lot about how our driver integrates into Mac OS, and we've found another possible action we can take to help make Fusion more robust in the future. Awesome!
Cheers,
--
Darius
I have this exact same issue 'Could not open /dev/vmmon " etc.
I do not have, or at least am not aware that I have the SNS Network Solutions iSCSI initiator on my system. Even if I did I wouldn't know how to uninstall it. :smileysilly:
My situation is that I have this OS X 10.8.4 system, onto which I migrated an old 10.7.4 system using Migration Assistant. I didn't power down my Windows 7 VM before doing the migration, should have read the manual I suppose. Whatever the MA did to my old system it now won't boot. I just powered it down following the migration not thinking anything of it and now it won't boot. My guess is that the Apple Migration Assistant did something to prevent the old apps and system from booting. Googling the problem comes up with nothing. The long and the short of it is that I can't get back to my old system to shut down the VM.
I followed the advice of uninstalling VM 5.x and reinstalling and repairing permissions, no dice. I followed the suggestions to fake the VM into a shutdown state, no dice.
I have attached my 'ls -l /dev' in the file called devlist.txt. I have attached my Support Information from VM Fusion.
Help please is all I can ask.