2 new VC_FAULT_FATAL scenarios after an upgrade to 7.8

[MrCheesecake]

Good morning!

We recently upgraded from 7.6 to 7.8 (Running vCenter 6.7U2a w/ vSAN) and are seeing two different and intermittent provisioning errors:

VC_FAULT_FATAL - Unexpected error occurred while monitoring VC task updates

and

VC_FAULT_FATAL - The name 'a workstation name' already exists

For the task updates one, I have verified that all the services are happily running on the vCenter.  I can't seem to find anything really interesting in the connection broker or vCenter logs.

For the "already exists" scenario, I see where the VM does exist within vCenter (powered off) but the logs seem to indicate a new/different ID for it.  We do currently have the "Allow resuse of pre-existing computer account" enabled but am not sure if that's a contributing factor.  In this case, the best fix seems to be to delete the VM from vCenter and then let ViewDBChk clean everything up on the connection broker.

Has anyone seen similar issues/behaviors?

[MrCheesecake]

I think the issues may actually be related.  It appears to start with the error while monitoring VC task updates.  Cloning fails and provisioning is disabled based on the setting to disable on error.  After a while, Horizon attempts a recovery operation where it attempts to remove the suspect machine but fails- But tries to re-clone the machine only to see that the VM is still in vCenter.

[MrCheesecake · Accepted solution]

One of my colleagues found that we had some duplicate folder names within our VSAN datastore that appear to be the root cause of the cloning issues.  After restarting provisioning, a new folder for the problem VM is created with a "_1" appended to it and allows things to proceed.  We deleted the original folders and everything has been running clean/smooth.

I suspect that these folders were lost/locked during a vCenter reboot at some point but will keep an eye out for them moving forward.

[BenFB]

There was a bug that was fixed in 7.5.2/7.7 that addressed folders not getting cleaned up when a linked clones was deleted. We had to manually clean these up almost daily to avoid the extra folders with a "_1", "_2", etc...

Deletion of Linked Clone Pool does not remove all file from vCenter and after deletion of pool *.hlo...