After MacOS 10.15.7 Update, Fusion 11.5.6 slow to boot to desktop

[mac_pro_user]

Using Fusion 11.5.6.

Just updated iMac Pro to MacOS 10.15.7.  Fusion is now exhibiting slow boot to desktop times for Windows Server 2008 R2...  Below are a sequence of snap shots of the boot process spanning over 2 minutes.  Start appears normal, but screen goes gray to black and stays black for upwards of 2 minutes, before normal boot to desktop.

This behavior is exhibited for Windows Server 2008 R2 virtual machines only.  Windows 7, Windows 10, Windows Server 2012 boot times are normal.

Anyone have any ideas what may be causing this issue?  Prior to 10.15.7 update, boot times were immediate.

[ColoradoMarmot]

Are you on a fusion drive by chance?  It's possible that some of the pieces of the virtual disk have aged out to the spinning drive.

[mac_pro_user]

I'm using iMac Pro SSD 4TB drive.

Nothing was changed in the Fusion 11.5.6 installation/configuration and only MacOS was updated to 10.15.7.

Prior to OS update, all was working fine...

In fact, once I am, eventually, able to get to the desktop all is normal and responsive as ever.

[ColoradoMarmot]

Couple of ideas:

- What's the guest and host CPU and RAM configurations?  If there's too many cores allocated to the guest, it may be starving the host.

- Do you have snapshots and/or autoprotect turned on?

[mac_pro_user]

iMac Pro:

CPU:  3 GHz 10-Core Intel Xeon W

RAM:  64 GB 2666 MHz DDR4

Guest:  2 CPU; 8GB RAM; 2048 Video RAM, 3D Enabled

No snapshots or autoprotect.

Again, just prior to MacOS update, boot times were immediate.

[bluefirestorm]

In the sequence of pictures, what I've noticed is that the occupied space of the virtual disk(s) of this VM is large (645.8GB) and two other VMs are also powering up/powered up.

Does it happen when this is the only VM powering up?

Is the virtual disk(s) of this VM with pre-allocation? What is the size that the Windows 2008 R2 VM suppose to see? Is the 645.8GB substantially larger than what is intended for the VM?

Other than these things, you may have look at the vmware.log whether it is the VM taking long (e.g. taking long time to open the virtual disks if indeed the virtual disks are that big, but shouldn't take long with SSD unless it is retrying things which possibly hints that the virtual disks structure may not be healthy) or may have to look at the Event Log of the Windows 2008 R2 VM once logged in.

Here is a very old Microsoft article about slow startup of Windows 2008 R2 but the hotfix is no longer available.

https://support.microsoft.com/en-us/help/2617858/unexpectedly-slow-startup-or-logon-process-in-windo...

[mac_pro_user]

The VM is configured as a 1TB single disk file VM (not pre-allocated).  The host system has 2TB free.

I just performed a reboot and the log file is attached.

You can see the last few minutes of the boot process takes approximately 2+ minutes (8:11AM -> 8:14AM).

[bluefirestorm]

The opening of the virtual disk looks fine.

2020-10-31T08:11:52.472-08:00| vmx| I005: DISK: DiskConfigureVirtualSSD:  Disk 'scsi0:0' identified as Virtual SSD device.

2020-10-31T08:11:52.472-08:00| vmx| I005: DISK: Opening disks took 3 ms.

It looks like things start to slow from this point onwards in the vmware.log

2020-10-31T08:11:53.913-08:00| svga| I005: SVGA enabling SVGA

2020-10-31T08:11:53.916-08:00| svga| I005: SVGA-ScreenMgr: Screen type changed to RegisterMode

When the SVGA video driver is loaded, over 33 seconds has elapsed from the start of the log. For reference a Windows 10 VM on Fusion 11.5.6/macOS 10.15.7 on a 2014 MBP just under 21 seconds has elapsed at the same point.

2020-10-31T08:11:51.809-08:00| vmx| I005: VTHREAD 4438236608 "vmx" tid 1277757

2020-10-31T08:12:25.105-08:00| vcpu-0| I005: Guest: vm3d: SVGA WDDM Full Display driver, Version: 8.17.02.0001, Build Number: 16772660

2020-10-31T08:12:25.105-08:00| vcpu-0| I005: Guest: vm3d: WDDM OS version: 6.1, build number: 7601, service pack version: 1.0, platform Id: 2, product type: 3, suite mask: 0x112

It might not be a good comparison considering that there could be more services starting up in the Windows Server 2008 R2 VM (if this is a domain controller, DHCP server, or database server, etc) than a Windows 10 VM and add to that there are inherent inefficiencies of an old OS like 2008 R2. You could try to compare this with the other Windows 2008 R2 VM and/or Windows 7 VM and it might be a better comparison than using a Windows 10 2004 VM.

One thing I noticed is that the Hard Disk Buffering is disabled. Try to leave it as "Automatic" in the Advanced settings of the VM.

2020-10-31T08:11:52.242-08:00| vmx| I005: DICT      hard-disk.hostBuffer = "disabled"

And try to change the virtual optical drive from IDE to SATA and remove the ISO file reference if it is not needed during the boot up.

[mac_pro_user]

Any idea what is happening below?  Seems to be taking significant time:

2020-10-31T08:12:25.410-08:00| svga| I005: SVGA-ScreenMgr: Screen type changed to ScreenTarget

2020-10-31T08:12:26.120-08:00| vcpu-0| I005: Guest: DXUM_service: 2020-10-31T08:12:26.0009| Thread ID: 804 |Aero disabled

2020-10-31T08:12:42.144-08:00| mks| I005: SWBWindow: Number of MKSWindows changed: 0 rendering MKSWindow(s) of total 1.

2020-10-31T08:12:46.153-08:00| vcpu-0| I005: Tools: Tools heartbeat timeout.

2020-10-31T08:12:46.153-08:00| vcpu-0| I005: Tools: Running status rpc handler: 1 => 0.

2020-10-31T08:12:46.153-08:00| vcpu-0| I005: Tools: Changing running status: 1 => 0.

2020-10-31T08:12:46.153-08:00| vcpu-0| I005: Tools: [RunningStatus] Last heartbeat value 4 (last received 20s ago)

2020-10-31T08:12:52.131-08:00| mks| I005: SWBWindow: Number of MKSWindows changed: 1 rendering MKSWindow(s) of total 1.

2020-10-31T08:13:01.233-08:00| mks| I005: SWBWindow: Number of MKSWindows changed: 0 rendering MKSWindow(s) of total 1.

2020-10-31T08:13:28.913-08:00| mks| I005: SWBWindow: Number of MKSWindows changed: 1 rendering MKSWindow(s) of total 1.

[bluefirestorm]

I think that is the point when switching from windowed mode to running in background shown in the VM Library. I don't know if that has any effect in the startup time (but I doubt so). I run VMs in single window most of the time in Fusion.

[operando · Accepted solution]

Started after installing VMware Tools 11.2.0 or VMware SVGA driver 8.17.2.1 from Windows Update on Windows Server 2008 R2.

Not sure what it does, but disabling "VMware SVGA Helper Service" in the guest OS fixed black screen on boot.

[mac_pro_user]

That did the trick!

Excellent!

[operando]

Fixed in VMware Tools 11.2.1:

https://docs.vmware.com/en/VMware-Tools/11.2/rn/VMware-Tools-1121-Release-Notes.html#resolvedissues

https://my.vmware.com/group/vmware/downloads/details?downloadGroup=VMTOOLS1121&productId=491