Stretching vSAN ESA cluster in SDDC Manager API explorer fails with "Unable to perform operations on stretched cluster using NSX 2.x with VCF 3.x BOM for clusterId ..."
search cancel

Stretching vSAN ESA cluster in SDDC Manager API explorer fails with "Unable to perform operations on stretched cluster using NSX 2.x with VCF 3.x BOM for clusterId ..."

book

Article ID: 384483

calendar_today

Updated On:

Products

VMware SDDC Manager

Issue/Introduction

Symptoms:

  • Validating the Cluster Stretch Spec in API explorer is successful:

  • Starting the cluster stretch task in API explorer returns "in progress" after executing, but nothing happens, no task is created in SDDC Manager GUI.
  • In the domainmanager.log we can see that the task failed with this error:

    2024-11-20T07:16:50.517+0000 ERROR [vcf_dm,673d8ce1004175fbee428555649cac30,a3bb] [c.v.e.s.s.c.StretchClusterManagerWorkflowInitiatorClient,dm-exec-17]  Failed to create Stretch vSAN Cluster - cl01-abcdefgh in VMware Cloud Foundation execution context with task id 1ef28135-c1cd-4d9e-b4a2-ba90cda7ebfc
    com.vmware.evo.sddc.stretchclustermanager.common.exception.StretchClusterException: Unable to perform operations on stretched cluster using NSX 2.x with VCF 3.x BOM for clusterId b98fefe7-d358-40d6-9558-696a285dab61
            at com.vmware.evo.sddc.stretchclustermanager.common.StretchClusterManagerWorkflowInitiatorClient.createStretchClusterExecutionContext(StretchClusterManagerWorkflowInitiatorClient.java:64)
            at com.vmware.evo.sddc.stretchclustermanager.service.StretchClusterWorkflowInitiator.updateStretchClusterSpecAndInitiateWorkflow(StretchClusterWorkflowInitiator.java:172)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
            at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at java.base/java.lang.reflect.Method.invoke(Method.java:569)
            at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:343)
            at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:196)
            at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:163)
            at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:751)
            at org.springframework.aop.interceptor.AsyncExecutionInterceptor.lambda$invoke$0(AsyncExecutionInterceptor.java:115)
            at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
            at com.vmware.vcf.common.tracing.TraceRunnable.run(TraceRunnable.java:59)
            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)

Environment

VMware Cloud Foundation 5.x

 

Cause

Performing vSAN Stretch was not automated for VCF version 3.x. It was introduced in later versions. So, at the beginning of the stretch, there was check if the BoM version is 3.x and while evaluating the VCF BoM version, there was dependency of VDS flag is_used_by_nsxt in order to decide if BoM version > 3.x.

Resolution

This is a known issue that has been resolved from VCF 9.0 release onwards.

Please contact VMware support for assistance with the workaround for earlier VCF versions.