Stretch new MWLD (9.0.2) problem - mapOfSubClusterNameToPath cannnot be empty

[G Kastelic]

Hi

I am building POC (in LAB) and have problems with stretching Management Cluster. Lates build, 9.0.2

Got stuck at 83% where NSX should create SubCluster AZ zones etc...

Did try to manually create Sub Zones, put hosts inside and from NSX side it's all good, all green, policy applied,... Just SDDC task will fail on every retry.

Any ideas?

2026-03-23T11:04:34.619+0000 DEBUG [vcf_dm,69c11e42830bb7a4c5f778f2a10b30a6,2ca8] [c.v.e.s.o.c.ProcessingTaskSubscriber,dm-exec-10]  Invoking task ApplySubConfigOnTransportNodeCollectionAction.PREVALIDATE Description: Apply subconfig on Transport Node collection, Plugin: NsxtPlugin, ParamBuilder null, Input map: {mapOfCvdsNameToId=ConfigureNsxt____65__NsxtPolicyAddHosts____1__ConfigureNsxWithTnpAttached____3__AddhostWithSubClusterConfigAndUpdateTnc____2__mapOfCvdsNameToId, transportNodeCollectionId=ConfigureNsxt____65__NsxtPolicyAddHosts____1__ConfigureNsxWithTnpAttached____3__transportNodeCollectionId, nsxtManagerVip=ConfigureNsxt____65__NsxtPolicyAddHosts____1__nsxtManagerVip, mapOfSubClusterNameToPath=ConfigureNsxt____65__NsxtPolicyAddHosts____1__ConfigureNsxWithTnpAttached____3__AddhostWithSubClusterConfigAndUpdateTnc____2__mapOfSubClusterNameToPath, mapOfNetworkProfileNameToCvdsConfigs=ConfigureNsxt____65__mapOfNetworkProfileNameToCvdsConfigs}, Id: 0a1706c9-9d19-17e2-819d-19f1242900a6 ...

2026-03-23T11:04:34.657+0000 DEBUG [vcf_dm,69c11e42830bb7a4c5f778f2a10b30a6,2ca8] [c.v.e.s.o.c.c.ContractParamBuilder,dm-exec-10]  Contract task Apply subconfig on Transport Node collection input: {"nsxtManagerVip":{"address":"vcf9-nsxmgr.demo.lab.si","port":0,"username":"svc-vcf9-sddc-vcf9-nsxmgr-1014","password":"*****"},"transportNodeCollectionId":"2c8bb2dd-6c0c-4e65-b2fc-8e4fb423eef7","mapOfNetworkProfileNameToCvdsConfigs":{"vcf9-vc01-VCF-mgmt-cl01":[{"name":"VCF-mgmt-cl01-vds03","uuid":"50 2c b2 8f 4e df b0 06-8b d6 b5 80 00 63 23 64","moid":"dvs-25","uplinkConfig":{"uplinkProfileName":"vcf9-vc01-VCF-mgmt-cl01-VCF-mgmt-cl01-vds03","geneveVlanId":2308,"activeUplinks":["uplink2","uplink1"],"teamingPolicy":"LOADBALANCE_SRCID","standbyUplinks":[],"deviceToUplinkMap":{"uplink2":"uplink2","uplink1":"uplink1"}},"ipAddressPoolSpec":{"name":"TEPs-STRETCH","ignoreUnavailableNsxtCluster":false}}]},"mapOfCvdsNameToId":{"VCF-mgmt-cl01-vds03":"50 2c b2 8f 4e df b0 06-8b d6 b5 80 00 63 23 64"}}

2026-03-23T11:04:34.666+0000 ERROR [vcf_dm,69c11e42830bb7a4c5f778f2a10b30a6,2ca8] [c.v.e.s.o.model.error.ErrorFactory,dm-exec-10]  [45406] VCF_ERRORS_GENERIC_INPUT_PARAM_ERROR Invalid parameter: {0}

com.vmware.evo.sddc.orchestrator.exceptions.OrchTaskException: Invalid parameter: {0}

at com.vmware.vcf.common.fsm.plugins.nsxt.policy.action.ApplySubConfigOnTransportNodeCollectionAction.preValidate(ApplySubConfigOnTransportNodeCollectionAction.java:78)

at com.vmware.vcf.common.fsm.plugins.nsxt.policy.action.ApplySubConfigOnTransportNodeCollectionAction.preValidate(ApplySubConfigOnTransportNodeCollectionAction.java:39)

at com.vmware.evo.sddc.orchestrator.platform.action.FsmActionState.lambda$static$0(FsmActionState.java:22)

at com.vmware.evo.sddc.orchestrator.platform.action.FsmActionState.invoke(FsmActionState.java:66)

at com.vmware.evo.sddc.orchestrator.platform.action.FsmActionPlugin.invoke(FsmActionPlugin.java:161)

at com.vmware.evo.sddc.orchestrator.platform.action.FsmActionPlugin.invoke(FsmActionPlugin.java:147)

at com.vmware.evo.sddc.orchestrator.core.ProcessingTaskSubscriber.invokeMethod(ProcessingTaskSubscriber.java:403)

at com.vmware.evo.sddc.orchestrator.core.ProcessingTaskSubscriber.processTask(ProcessingTaskSubscriber.java:540)

at com.vmware.evo.sddc.orchestrator.core.ProcessingTaskSubscriber.accept(ProcessingTaskSubscriber.java:128)

at jdk.internal.reflect.GeneratedMethodAccessor559.invoke(Unknown Source)

at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.base/java.lang.reflect.Method.invoke(Method.java:569)

at com.google.common.eventbus.Subscriber.invokeSubscriberMethod(Subscriber.java:85)

at com.google.common.eventbus.Subscriber.lambda$dispatchEvent$0(Subscriber.java:71)

at com.vmware.vcf.common.tracing.TraceRunnable.run(TraceRunnable.java:63)

at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)

at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)

at java.base/java.lang.Thread.run(Thread.java:840)

Caused by: java.lang.NullPointerException: mapOfSubClusterNameToPath cannnot be empty

-------------------------------------------

Attachment(s)

SubCluster-can-not-be-empty.txt   5 KB 1 version

[snapfriend]

Hello G Kastelic

Your error code resembles with VMware KB article. Please check if it will help you out for your upgrade.

https://knowledge.broadcom.com/external/article/432593/nsx-edge-deployment-from-sddc-fails-whil.html

-------------------------------------------

[G Kastelic]

I found problem - resources to low on base host. Stretch workflow is changing vSAN default policy during stretch (all VMs object re-sync) which is causing NSX manager VM slow performance (some services to restart) and it does not provide info for SDDC to build specs -> empty payload -> error and Task failed. Restart does not try to recreate info from needed for payload, it just retry with wrong/empty payload.

Fix: before running stretch API change vsan policy for NSX VM from default to something else (i created some dummy, no redundancy policy upfront). In this case stretch workflow will skip policy change for this VM during workflow. After stretch just manually change policy for this NSX VM as it should be.

https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-0/building-your-private-cloud-infrastructure/stretching-clusters/stretch-a-cluster.html

When you stretch a cluster, SDDC Manager modifies the site disaster tolerance setting for storage policy associated with datastore of that cluster from None - standard cluster to Site mirroring - stretched cluster. This affects all VMs using default datastore policy in that cluster. If you do not want to change the site disaster tolerance setting for specific VMs, apply a different storage policy to those VMs before stretching the cluster.

-------------------------------------------