New scale groups in VMware Cloud Director stay at 1% for scale up operation after OperationDeniedException errors

Products

• VMware Cloud Director

Issue/Introduction

When creating new scale group replicas in VMware Cloud Director the operation stays at 1%. This is after several "Operation denied" and "Access forbidden" errors in the UI.

In /opt/vmware/vcloud-director/logs/vcloud-container-debug.log there are entries similar to:
2026-07-30 18:45:11,135 | ERROR    | Backend-activity-pool-81130 | FutureUtil                     | Could not execute behavior ###:vcloud:behavior-interface:grow:vmware:elasticgroup:1.0.0 on entity ###:vcloud:entity:vmware:scalegroup:########################## | requestId=########################,request=POST https://<Cloud Director Public URL>/cloudapi/1.0.0/entities/###:vcloud:entity:vmware:scalegroup:########################...,requestTime=#######,remoteAddress=###.###.###.###:59290,userAgent=vcd-openapi-client,accept=*/*;version 39.1 vcd=####################,task=#################### activity=(com.vmware.vcloud.backendbase.management.system.TaskActivity,###:####:###################) activity=(com.vmware.vcloud.behaviors.execution.impl.BehaviorExecutionActivity,###:####:##################)
com.vmware.vcloud.api.presentation.entity.security.OperationDeniedException: This operation is denied.
        at com.vmware.ssdc.backend.dao.impl.DefinedEntityDaoImpl.doLoadEntity(DefinedEntityDaoImpl.java:2364)
        at com.vmware.ssdc.backend.dao.impl.DefinedEntityDaoImpl.doLoadEntity(DefinedEntityDaoImpl.java:2357)
        at com.vmware.ssdc.backend.dao.impl.DefinedEntityDaoImpl.doLoadEntity(DefinedEntityDaoImpl.java:2353)
        at com.vmware.ssdc.backend.dao.impl.DefinedEntityDaoImpl.getDefinedEntity(DefinedEntityDaoImpl.java:459)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:566)
        at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:344)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:198)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:163)
        at org.springframework.transaction.interceptor.TransactionInterceptor$1.proceedWithInvocation(TransactionInterceptor.java:123)
        at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:388)
        at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:119)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)
        at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:241)
        at com.sun.proxy.$Proxy336.getDefinedEntity(Unknown Source)
        at com.vmware.vcloud.activities.scaling.AbstractTaskActivity$TaskEnabledPhase.updateScaleGroup(AbstractTaskActivity.java:190)
        at com.vmware.vcloud.activities.scaling.AbstractTaskActivity$TaskEnabledPhase.invoke(AbstractTaskActivity.java:219)
        at com.vmware.vcloud.activity.executors.ActivityRunner.runPhase(ActivityRunner.java:175)
        at com.vmware.vcloud.activity.executors.ActivityRunner.run(ActivityRunner.java:112)
        at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
        at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
        at java.base/java.lang.Thread.run(Thread.java:829)

No VMs are ever created for the scale group replicas, the status stays at "Enabled" and cannot be reset.

Environment

VMware Cloud Director 10.6.x

Cause

The autoscale user was configured without the required domain context. Local VMware Cloud Director users require the @system suffix for API calls initiated by the autoscale service to succeed.

Resolution

To resolve this issue, reconfigure the autoscale user with the correct domain suffix:

1. Log in to the VMware Cloud Director cell as root.
2. Run the following command to set the username with the @system domain: $VCLOUD_HOME/bin/cell-management-tool configure-autoscale --set username=autoscale@system
3. Verify the scale group creation task progresses beyond 1%.

For additional configuration details, see Configure and Publish the Auto Scale Plug-in.