akarpo
Contributor
Contributor

Fusion 5 - Could not open /dev/vmmon: No such file or directory.

Jump to solution

Receiving the following errors when I try to start up my virtual machine(s) in Vmware Fusion 5 -

  • Could not open /dev/vmmon: No such file or directory.
  • Failed to initialize monitor device
  • Cannot find a valid peer process to connect to.

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.

1 Solution

Accepted Solutions
dariusd
Leadership
Leadership

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:

  • Studio Network Solutions iSCSI initiator
  • Viscosity VPN
  • VirtualBox

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

View solution in original post

0 Kudos
37 Replies
avanish321
Expert
Expert

Repair hard disc permissions on mac hard disc using disc utility app and then try to install fusion.

Cheers! Avanish
0 Kudos
akarpo
Contributor
Contributor

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.

0 Kudos
WoodyZ
Immortal
Immortal
0 Kudos
akarpo
Contributor
Contributor

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.

0 Kudos
dariusd
Leadership
Leadership

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.

akarpo
Contributor
Contributor

Thanks, dariusd. Any advice on how we might go about replacing the missing /dev/vmmon/ ?

0 Kudos
dariusd
Leadership
Leadership

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

akarpo
Contributor
Contributor

Diagnostic information generated by Fusion, attached below.

Merry Christmas to all!

0 Kudos
dariusd
Leadership
Leadership

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...Smiley Sad

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

0 Kudos
akarpo
Contributor
Contributor

Thanks for looking into this, Darius. Hope you had an enjoyable Christmas Smiley Happy

Output below.

Last login: Wed Dec 26 04:36:31 from localhost
Alexs-MacBook-Air:~ Alex$ ls -ld /dev /dev/vmmon
ls: /dev/vmmon: No such file or directory
dr-xr-xr-x  3 root  wheel  4639 Dec 25 18:46 /dev
Alexs-MacBook-Air:~ Alexmce_markernbsp;

Which confirms that /vmmon is missing. What might the next step be?

-alex

0 Kudos
dariusd
Leadership
Leadership

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:

  • Studio Network Solutions iSCSI initiator
  • Viscosity VPN
  • VirtualBox

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

View solution in original post

0 Kudos
RJIn
Contributor
Contributor

Hello,

Thanks for the response Darius. Smiley Happy

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

0 Kudos
WoodyZ
Immortal
Immortal

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.

0 Kudos
WoodyZ
Immortal
Immortal

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
0 Kudos
akarpo
Contributor
Contributor

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!

0 Kudos
avanish321
Expert
Expert

wow . good to know this.

Cheers! Avanish
0 Kudos
RJIn
Contributor
Contributor

Glad that you took time to explain why the steps helped me won't help in this case. Now, I understand Smiley Happy

0 Kudos
dariusd
Leadership
Leadership

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

0 Kudos
vmwtece
Contributor
Contributor

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.

0 Kudos