Fusion 7 is running VERY SLOW on the GM of Yosemite

[Stevamundo]

Basically Fusion 7 is unusable on the GM of Yosemite because fusion 7 is so slow.

When I was still on Mavericks 10.9.5  Fusion 7 was working just great. What happened?

Is anyway that i can fix this? Or do I have to wait for an update?

[perjoh]

Hello

I have the same problem with a MacBook Pro (Retina, 15-inch, Early 2013) 10.10.2 and Fusion pro 7.1.0.

The problems started after i upgraded to 10.10.2 and the windows 7 that run on fusion i slow and some times stop responding.

Someone that have any ide what to do ?

[HPReg]

This is not the same problem at all. Please open a new thread.

[flyboydea]

Yep my iMac 2011 with Yosemite 10.10.1 with Fusion 7.1.0, my VMs were running dog slow.  Running the terminal command did bring my VMs back into functionality but a little slower than before.  I hope Apple and VMware get things worked out for the future.

[mhawley5]

I just installed the OS X 10.10.2 update.  What is the command to remove the the [sudo nvram boot-args="debug=0x10"] command.  I want to see how the machine functions with it removed.  Still a novice at the command functions!

Thanks,

M Hawley

[kmfurdm]

How to Reset NVRAM on your Mac - Apple Support

[dariusd]

Hi M Hawley,

Running sudo nvram -d boot-args will clear the boot-args setting, undoing the effect of the earlier sudo nvram boot-args="debug=0x###" command.

A note of caution about kmfurdm's advice... The instructions in the linked Apple Support article certainly will clear boot-args, but it could possibly clear a lot of other stuff which you don't necessarily want to clear.

Cheers,

--

Darius

[mjhd]

Hi,

I'm experiencing the same bad system performance and high CPU utilisation on vmware.vmx process on a MacBook Pro (Retina, 13-inch, Early 2013), since Yosemite 10.10.2.

I managed to fix it with a workaround by disabling folder sharing. the other solutions didn't work for me.

my debugging steps:

System: MacBook Pro (Retina, 13-inch, Early 2013)

initial setup Yosemite 10.10.2 & Fusion 7.1 + Folder sharing ON:

1- Nvram changed and rebooted = no improvement, system response time and CPU high utilisation

2- VMware tools uninstall and  new install = no improvement

3- Yosemite new install over current Yosemite =no improvement

4- disable Folder share under Fusion 7.1 = fixed the issue

5- Downgrade to fusion 6 Pro.Version 6.0.5, and enable folder share = same behaviour, system response time and CPU high utilisation

6- Disable folder sharing on Fusion 6 = fixed the issue

Current setup Yosemite 10.10.2 & Fusion 6 (Pro.Version 6.0.5) + Folder sharing OFF:

summary:

I was able to link the issue on my MacBookPro with Fusion 6 & 7 to Folder Sharing. Disabling it fixed the issue!

SHELL:

MacbookPro:~ my$ !490

nvram -p | grep boot-args

boot-args debug=0x10

sudo powermetrics -s interrupts
Machine model: MacBookPro10,2 SMC version: 2.6f59 EFI version: MBP102.0106.B07 OS version: 14C109 Boot arguments: debug=0x10 Boot time: Thu Feb  5 07:35:13 2015 *** Sampled system activity (Thu Feb  5 11:33:18 2015 +0100) (5000.69ms elapsed) *** ****  Interrupt distribution **** CPU 0:   Vector 0x46(SMC): 1.20 interrupts/sec   Vector 0x56(HDEF/EHC1): 51.39 interrupts/sec   Vector 0x57(EHC2): 3.00 interrupts/sec   Vector 0x72(IGPU): 213.57 interrupts/sec   Vector 0x74(HDEF): 1.00 interrupts/sec   Vector 0x76(SATA): 24.60 interrupts/sec   Vector 0xdd(TMR): 1341.42 interrupts/sec   Vector 0xde(IPI): 162.18 interrupts/sec CPU 1:   Vector 0xdd(TMR): 40.99 interrupts/sec   Vector 0xde(IPI): 120.78 interrupts/sec CPU 2:   Vector 0xdd(TMR): 1063.65 interrupts/sec   Vector 0xde(IPI): 209.37 interrupts/sec CPU 3:   Vector 0xdd(TMR): 33.00 interrupts/sec   Vector 0xde(IPI): 158.18 interrupts/sec
in my opinion VMWare has its fair share in the issue, not only Apple.

regards,

[xsived]

Hi,

Turning off just the 'Desktop' check box by the Mirrored Folders under Settings/Sharing "solved" the problem for me.

I'm on fusion 7.1.0 and Yosemite 10.10.2

Best regards

[mjhd]

Hi,

thanks for the feedback, I confirm, that is working for me too, under Fusion 6.0.4 and Yosemite 10.10.2.

It time for VMWare to fix the bug!!!

Cheers

[HPReg]

What you are experiencing may have the same symptoms (slow VM), but the cause is different.

This thread was mainly about the Apple bug on iMac. What you describe, however, seems to be a VMware bug indeed. We are investigating...

[HPReg]

mjhd and xsived, which exact version of

o Windows

o VMware Tools

are you running inside the VM?

[xsived]

Hi,

I have Windows 7 Ultimate 32 bit as Fusion guest OS

My VMWare tools have Version 9.9.0, build-2304977

Actually there is at another (newer) thread on this issue (10.10.2 and Fusion pro 7.1.0 superslow)

Best regards

[mjhd]

Hi,

please find the answer to your queries.

+ Windows / Pro, 64 bit

o VMware Tools, 1st I had the version included with Fusion 7.1.0, and after downgrade to Fusion 6.0.4 then respectively version 9.6.2 build 1688356

ok?

Please let me know, if you need more details!

regards,

[HPReg]

mjhd and xsived,

Thanks for the info. This the issue tracked by this thread has been answered (when Apple released Yosemite 10.10.2), let's use the new thread Re: 10.10.2 and Fusion pro 7.1.0 superslow to track the new issue from now on. Thanks!

[michaelosity]

I'm having the same issues on a MacBook Pro (Retina, 15", Early 2013), OS X Yosemite 10.10.2, and VMWare Fusion 7.1.1 (the latest I'm aware of). I've tried clearing NVRAM, turning-off Sharing, etc. and none of it seems to work for me. The symptom is that I launch the VM (Windows 8.1) and let it run for a bit. I'm not doing anything on the guest OS, it's just sitting at the desktop. After a while (10-15 minutes) the vmware-vmx starts to go to 100% CPU usage.

Attached is a sample of the process if that helps.

[dariusd]

Hi michaelosity, and welcome to the VMware Communities!

The sample log you attached suggests that your virtual machine was doing a lot of disk I/O.  Are you sure that it's not just some background task within the guest OS that's indexing the disk, or defragmenting, or doing a backup or a cloud sync?   Keep in mind that, on an SSD, anything that is "disk intensive" will quickly generate close to 100% CPU utilization because the I/O latency is so very low.

It might help to go into VM Settings > Advanced, and set Troubleshooting to Performance, then reproduce the problem and upload the resulting vmware.log from inside the virtual machine's bundle.  That can sometimes give us good clues as to why a virtual machine is not performing as expected.

Cheers,

--

Darius

[michaelosity]

Okay, I'll look to ensure that nothing is going on in the background on the guest OS, but I thought I turned all that off. Attached is a log file from when the behavior was happening. I followed the same pattern as before: boot up Windows 8.1, Go to the Desktop, wait...

[michaelosity]

As far as I can tell, I've disabled everything on the guest OS that could be doing anything in the background with I/O: Windows Defender, Automatic Updates, Disk Indexing, etc. It's a pretty fresh install of Windows 8.1, but I'm using it for Windows Development (unfortunately) so there are the standard Visual Studio installs on there, but none of those need to be running to reproduce the problem. It just seems like after around 10 minutes or so, the VM starts using 100% of the CPU. Even if the guest OS was doing some type of disk I/O, it would seem like that would eventually finish and the CPU would go back down. As far as I can tell, once the CPU goes to 100% the only thing that drops it back down is to make Windows active again (switch desktops to the VM and click on the desktop). More information as I find it, but that seems to be the gist of it. Thanks for your help.

[michaelosity]

So it appears that I hadn't truly turned off Windows Defender. I thought I had disabled it, but it reared its ugly head anyway. For anyone else experiencing this problem, follow the advice of http://windows.microsoft.com/en-us/windows/turn-windows-defender-on-off#turn-windows-defender-on-off... to turn it off.

Thanks again for your help and I'll let you know if the problem reoccurs.