Yesterday one of my VMs crashed when I tried to suspend it and it lead to quite unpleasant situation: all options for VMs (Start/Stop, Snapshot) become unavailable. So that context menu for VM looks something like this:
I erroneously focused my troubleshooting and googling efforts around one VM issue, and not immediately realized that options were unavailable for all VMs… Consequently wasted quite a bit of time before I was able to resolve this. Jotting down the solution to avoid this in the future.
Problem: After VMware Workstation crash all options for all VMs are greyed our.
Solution: delete contents of %appdata%\VMware folder (2 files – preferences.ini & inventory.vlms)
It will be necessary to re-add your VMs to the list but this should not be a big problem.
* Common sense rule of backing up whatever you delete during your troubleshooting efforts is applicable here as usual
As I moved most of my VMs to NAS, I should admit that whereas it is best solution in terms of providing adequate space for bulky VMs and snapshots and access convenience, you pay for it with decreased performance (at least if you compare it with running VMs off internal SATA 3 SSDs). Latter can be mitigated if you use NAS with good performance and configure it with array of disks, even if it won’t be on pair with SSD but it can be good enough (you also can leverage SSD drives for caching in certain NAS models, but this seems to be an extra possible point of failure in your setup). But what can not be mitigated with NAS it is high price tag for it, as not only you have to pay for NAS device and number of NAS optimized drives, you have to think about extra switch ports and UPS, both for NAS and your network equipment (provided that you use laptop as your VMs host you don’t need UPS for it at least :))
Maybe you can get away with clicking Retry button in response to I/O error you receive from your VM due to intermittent loss of network connectivity, but not always. For example today I was in process ob building K2 4.6.9 VM, going through update procedure of 4.6.7 and my switch went down for 30 seconds, but I was able to continue running my VM by clicking on Retry in response to I/O error message from my VM running from NAS. But the thing is that when I finished the process and decided to take a snapshot to save my work I got this:
Next, as at times Suspend/Resume procedure is able to “solve” minor issues (sort of), I tried this also, but VM just vent into hard restart. After that I won’t be able to power it on again with the following error:
Solution to this in cases when you are sure that your VM is not running is to delete any *.lck files in VM directory and try again.
So power loss on your switch and consequent connectivity loss even for 30 seconds or so may lead to quite harsh / unpleasant situation (think of situation when you continue to do your work to discover that your VM fails only when you decide to take a snapshot). So when you plan for running VMs from NAS budget for UPS to protect your setup for connectivity and/or data loss.
Imagine that you are trying to copy file or folder from your host machine into VMware Workstation VM and receive following error:
Any idea what VMware Workstation trying to tell you? 🙂
Well being acquainted with this software and its occasional quirks my “knee jerk” reaction was to restart VMware Tools service and run repair for VMware Tools as I was more than sure that I have all the necessary permissions. After this didn’t help I looked for other possible reasons and it turned out to be plain old issue with file path being to long for handling… So WMware Workstation is unable to express itself properly and tell you that it is path length issue (probably it could be generic message from OS, I’m not sure). Anyway if you see this error message just modify folder names or move your file or folder couple of levels up the folder three – it will fix your issue.
I tested this with both VMware Workstation 10 & 11 running on Windows 8.1 as a host and with Windows Server 2012 as a guest – so even the latest version has this imprecise/misleading wording in error message.
Today after recurrence of losing all my favorites Microsoft IE (I suppose it has something to do with OneDrive/Synchronization options, though could be updates related) I went on updates spree instead of properly and systematically researching the problem (kind of most tempting way when dealing with technical issues).
After installing bunch of Windows Updates along with refresh of laptop hardware drivers and BIOS firmware I ended up with VMware throwing following error at me:
And this is for VM which is previously worked fine and having about 30 GB of free RAM. At www.petri.com you can find quite good discussion of possible reasons and ways of addressing this problem, and in my case it was because of KB2995388, so I fixed it by removing this optional update.
Due to nature of my work I’m using loads of virtual machines, using mainly VMWare Worksation these days (though I hope to get back to Hyper-V once I start working on my Microsoft certification refresh). In most cases IT Pros use resource demanding VM just because it is often necessary to have whole enterprise technology stack in your lab apart from that particular software on which you happen to be focused at the moment.
So your virtual environment usually involves enterprise technology stack (directory services, sometimes utility services like DNS, DHCP; messaging, databases, web services), and more often than not you end up running rather huge VM as it is preferably to have all this in one VM for the sake of portability and convenience. Such “self-contained” VM is going to require large chunk of your drive space (think snapshots), and as you want performance you likely will try to fit this on SSD, which is great technology by itself but still constrained by its high cost per megabyte of space.
So having said that I barely able to fit about 4 such VMs on my 500 GB SSD, it allows me to have no more than 3 snapshots and recently after deleting number of prior snapshots on the fly in some unsystematic way to free up space for new snapshot I ended up in situation when my paused VM (without recent snapshot) started throwing me this error message upon attempt to start it:
“File not found: <machine>-SnapshotXXX.vmsn” This file is required to power on this virtual machine. If this file was moved, please provide its new location. Cancel/Browse
So rather silly (not googling / researching this properly) I decided to revert to some old snapshot which was way back in terms of where I stopped with things I worked on in this VM, expecting that this will bring my VM backs to life at least. This was big mistake as after reverting to some other snapshot error didn’t gone, it rather continued to ask me about this missing file.
In fact proper solution was to make new snapshot (theoretically it should not be large if your previous existing snapshot was recent) – then copy newly created snapshot file and rename it so that it named as the one about which error message is complaining. The main thing here is not to rush and revert to previous snapshot and use this technique so that you don’t lost your work in progress as I did.