Holodeck 9.1 Encounter Issues on VCFA Day 0 Deployment.

[Weng Chee Poon]

Hi,

I encountered an issue during the VCFA deployment using the VCF Installer.

Is this a known issue? Should VCF Automation (VCFA) be deployed during the initial VCF installation (Day 0), or is it recommended to deploy it later as a Day 2 operation?

Kindly please advise.

Thanks.

[Allan Solomon Mejia]

Hi Weng Chee,

 

This isn't generally considered expected behavior. In VCF 9.1, VCF Automation (VCFA) is supported as part of the Day 0 deployment workflow, so it shouldn't normally require postponing to a Day 2 operation simply to avoid deployment failures.

 

Before concluding it's a product issue, I'd recommend checking a few items:

• Verify that all prerequisites for VCFA are met (DNS forward/reverse resolution, NTP synchronization, certificates, network connectivity, and supported software versions).
• Review the detailed installer logs to identify the component that failed during the Deploy and Configure VCFA stage rather than relying solely on the workflow summary.
• Confirm that the VCF 9.1 release notes do not list this as a known issue and that you're using the latest available installer build or patch level.

 

If the failure is isolated to VCFA while the core VCF deployment completes successfully, a temporary workaround is to finish the VCF deployment first and deploy/configure VCFA afterward as a Day 2 task. However, that should be viewed as a workaround rather than the recommended deployment approach.

 

To help narrow down the root cause, could you share:

• The exact error message from the installer logs.
• The VCFA and VCF 9.1 build versions.
• Whether this is a Holodeck lab or physical hardware deployment.
• The logs from the failed deployment step (particularly the VCFA deployment logs).

With those details, it should be possible to determine whether this is an environmental issue, a configuration problem, or a known product defect.

[Weng Chee Poon]

Hi,

I tried rebuilding the entire VCF stack again without selecting VCF Automation during the Day 0 deployment.

However, I'm not sure why VCF Automation was still deployed as part of the Day 0 deployment, and this time the deployment completed successfully.

Is this a known issue or a bug?

Thanks.

[Dhruv Tyagi]

Did you use the same config file? If yes, then the first time you ran New-HoloDeckInstance command with -DeployVcfAutomation flag, the flag would be set to true in the config file. So when you used the same config file for your next deployment, that flag remained true and deployed VCFA. Using a new config for a new deployment would fix your issue

[Weng Chee Poon]

Yup, same config.

Then, it is make sense, that's why VCFA deployed after I rebuild again.

[Allan Solomon Mejia]

Hi Weng Chee,

 

That's an interesting observation.

 

The fact that VCFA was still deployed during the Day 0 workflow even though you didn't explicitly select VCF Automation and that the deployment completed successfully on the second attempt suggests that the issue is unlikely to be related to the Day 0 deployment model itself.

 

This points more toward one of the following:

• A transient environmental issue (DNS, NTP, network connectivity, API timeout, or certificate validation).
• A race condition or timing issue during the initial deployment.
• An installer defect that is triggered only under specific conditions.

 

If the deployment completed successfully without any configuration changes, I wouldn't immediately classify this as a known VCF 9.1 product bug. A true product defect would generally be reproducible under the same conditions.

 

It would still be worthwhile to compare the installer logs from both the failed and successful deployments, particularly:

• VCFA deployment logs
• SDDC Manager orchestration logs
• Cloud Builder/Installer logs (if applicable)
• Any lifecycle or deployment task logs around the timestamp of the failure

 

Also, could you confirm:

• Which VCF 9.1 build and patch level you're running?
• The VCFA version that was deployed?
• Whether this is a Holodeck nested environment or physical hardware?

 

If VMware Support hasn't already identified this as a known issue, I'd recommend opening an SR and attaching both the failed and successful log bundles. Comparing the two executions should help determine whether this was an environmental transient or an issue worth escalating to engineering.

 

Please share any error messages or relevant log excerpts if you're comfortable doing so, and we can help narrow down the root cause.