VCF Import requires self managed VCSA

[rexit1982]

VCF Brownfield import requires that the VCSA vm be running on the cluster it manages. The over all structure of the pods today does not deploy self managed and I can think of several reasons why that is useful. Seems like there would be two primary approaches if there was a desire to add automated VCF Import at all. Automate a cross vcenter vmotion after deployment or add an option in the beginning for a vcsa deployment to be nested as a topology. I have not done any vetting of either being valid or practical but those are the first two things that came to mind. Wanted to solicit input on how to approach.

[rutgerblom]

Hi @rexit1982, I understand the challenge here. You're right about that for a normal SDDC.Lab Pod deployment we want to keep the VCSA VM on a physical ESXi because that has some benefits. However, given that "VCF" would become kind of an alternative deployment and VCF Import has this requirement, it would be interesting if you could investigate further on how deploying a nested vCenter could be accomplished.
I think deploying it nested from the start would be the cleanest method. Furthermore, it would be preferrable if we can control the VCSA deployment target using a variable in config.yml or some logic that sees to that the VCSA VM is deployed nested when the user chooses to deploy "VCF". There are other things to consider as well like having to wait until the nested ESXi hosts are available and the order in which the playbooks are executed. Much could probably be controlled using conditionals on the items in Deploy.yml. Thoughts?

[rexit1982]

Looking things over there are not vsan ansible modules to configure vsan without vcenter. It will be a decent rework of the deployment workflow, more default capacity in the nested vsan datastore. I probably should have read more before I started plopping more components into the deployment, but I think a VCF deployment will probably work better as an alternative deployment mode with the option on the other components to be deployed inside or outside of it. I don't think it will be practical to just point the vcsa inside or outside, it would make the conditional checks needed to not break everything that already works super fragile.
Maybe it would make sense to have a Deploy.Mode option and take SDDC, ESXiOnly, or VCF as values. Move the handling for your DeployESXiOnly up to that (should jsut be a variable rename) and if it is that or SDDC run the existing deployment if it is VCF run through the alternate build process, forking off Deploy.yml after either router deployment or ISO creation. I'd pull the SDDC Manager and VCFImport stuff into that build process since it brings no value to the existing build unless you manually move vcenter.