I have been struggling along with various VM performance issues over the last couple of months using VMware Fusion 5.x, as well as the latest 6.0.3. I just didn’t get the time to dedicate to find a fix for the performance degradation I was seeing until just recently.
I have the following specifications on my Macbook Pro Retina which I use for development purposes:
I have a Windows 7 Professional VM running in VMware Fusion, with a spec that I had tried all kinds of different configurations on – mainly 2 vCPUs, and 4GB RAM though. This VM is running on the built-in 256GB SSD.
Nothing seemed to fix the performance issues I was seeing, which was that by at least half way though a typical work day of using Visual Studio and a few tabs of Chrome/IE/Firefox, the VM would slow down to an absolute crawl. I knew it was the VM though, as everything in OSX Mavericks, the host OS was perfectly normal. Most of the time just restarting the Windows VM itself would not help though – I would have to reboot the whole macbook.
The other week I decided enough was enough, and spent a bit of time googling and looking around the VMware Communities forums for a fix. Here is the combination of settings that seems to have resolved my issues now.
Settled on a VM spec of 3 x vCPUs (helpful for Visual Studio), and 4GB RAM.
Disabled app nap for VMware Fusion (Applications -> Right-click, Get Info on VMware Fusion, and tick the box that says “Prevent App Nap”.
Added 3 x new entries into my VM’s configuration file (.vmx file). To edit the .vmx file you’ll need to right-click your VM and select “Show Content”. This will allow you to browse the file content of the VM, and you’ll need to locate your VM’s .vmx file. Right-click this file and open it in your text editor of choice. I added the following lines to the bottom of the file:
This is a very quick post today, but relates to an issue I had after upgrading my VMware Fusion install from 5.x to 6.0.2.
I am running a Windows 8 SP1 guest VM for development purposes on my mac, and right after upgrading and booting my Windows VM noticed this. The issue is that all the Windows UI elements – icons, text, etc look humongous on my 1920×1200 LCD monitor. The macbook’s LCD itself looked OK though. You can’t really see it that well in the screenshot below, but trust me, the section below with a few icons was about a quarter of my screen.
I knew this was a new setting that had somehow been toggled in Fusion since the upgrade, so I had a quick look around and found it. To disable this feature, go to your Virtual Machine Settings -> Display, and untick “Automatically adjust user interface size in Windows”.
Fusion will prompt you to logout of your current user session in the Windows VM. After logging back in again, things should be back to normal.
Hope that saves someone 15 minutes of looking for the cause in the future!
The other day I came across this issue, it was quite late at night so it took me a little longer than I would have liked to realise what the issue actually was.
I had a vCenter 5.0 server which had not been joined to the local Active Directory domain. My goal was to get this added to the rest of the AD domain. After adding the vCenter server to the domain, rebooting, and checking that all the VMware services had started up correctly afterwards, I connected the vSphere client and saw that all the ESXi hosts were in a disconnected state.
At this point I tried right-clicking a host and manually connecting it – this worked, but only 60 seconds or so, and then it disconnected again. Whilst it was connected it was manageable, and of course all the VMs on each host were still fine. I tried restarting management agents on a host and retrying the procedure, but this didn’t help either. My next step was to reboot an ESXi host that didn’t have anything critical running. Still nothing at this point.
So I decided to consult the VMware vpxd log files on the vCenter server. Consult this VMware KB article to see where to find these logs.
Before opening the latest vpxd.log file, I tried the reconnect on a host again using the vSphere client, and watched for the disconnect. At the exact time I noticed the host appear disconnected again, I noted down the time on the system clock, then opened the vpxd logs to navigate to this time and take a look. Here is what I found:
2013-01-04T00:00:22.121Z [02504 warning 'Default'] [VpxdInvtHostSyncHostLRO] Connection not alive for host host-28
2013-01-04T00:00:22.121Z [02504 warning 'Default'] [VpxdInvtHost::FixNotRespondingHost] Returning false since host is already fixed!
2013-01-04T00:00:22.121Z [02504 warning 'Default'] [VpxdInvtHostSyncHostLRO] Failed to fix not responding host host-28
2013-01-04T00:00:22.121Z [02504 warning 'Default'] [VpxdInvtHostSyncHostLRO] Connection not alive for host host-28
2013-01-04T00:00:22.121Z [02504 error 'Default'] [VpxdInvtHostSyncHostLRO] FixNotRespondingHost failed for host host-28, marking host as notResponding
2013-01-04T00:00:22.126Z [02504 warning 'Default'] [VpxdMoHost] host connection state changed to [NO_RESPONSE] for host-28
This clearly shows the issue and points to it being a connectivity issue of some sort. Looking up these specific errors led me over to this VMware KB article, and it was at this point that it suddenly dawned on me – with the late night I had carelessly overlooked the Windows Firewall. Of course, Windows Firewall has settings for Windows Domains too, and of course this server had just joined the domain, so existing Firewall policies in place for vCenter that were previously on “public” settings, were now not enabled for “Domain”.
Timing the issue also revealed that it was 60 seconds before hosts disconnected again. So the issue here was that port 902 used for the host heartbeat between vCenter and the ESXi hosts was being blocked on the vCenter firewall. Unblocking this by simply enabling the rule for “Domain” fixed the issue and as soon as that was applied, all hosts reconnected by themselves. Of course I also took the time to ensure other vCenter firewall exceptions were correctly configured.
To fix, I just enabled the Domain profile that the firewall rule applies to.
Lastly, when examining VMware log files and settings, you may come across references to VMs, Hosts, or other VMware “objects” named as “host-28” or “vm-07” for example. These are VMware’s way of keeping reference of objects by what is called a MoRef, or “Managed object reference”. You may know host-28 as esxi03.yourdomain.local for example, so I thought I would include a handy tip for working out the Managed Object Reference name of an ESXi host to help with those vpxd.log diagnostics. Let’s say you find an interesting error mentioning moref “host-28”. You don’t know which host this is, so you can use PowerCLI to work out the morefs of hosts in a cluster and then match up the reference to the actual host name. Use this bit of script to achieve this:
Get-VMHost | Sort Name | Select Name,@{Name="MoRef";Expression={$_.ExtensionData.MoRef}}
