Stargate service fails to start when the Cloud Extensibility Proxy VA is rebooted
search cancel

Stargate service fails to start when the Cloud Extensibility Proxy VA is rebooted

book

Article ID: 328565

calendar_today

Updated On:

Products

VMware

Issue/Introduction

This article provides steps to recovery the environment.

Symptoms:
  • In the /data1/proxylogs/va-remote-proxy.0.log file, you see similar to:
Unable to find the ovf environment.
[2][S][2020-11-12T09:48:37.412Z][1][PropertyManager][proxyUrl][unable to get OTK. Proceeding with defaults: java.lang.RuntimeException: unable to find one_time_key. Wont be able to start the system
        at com.vmware.ccs.remote.proxy.common.PropertyManager.getOneTimeKey(PropertyManager.java:70)
  • Running the ovfenv command returns there is no ovf property.
  • The /opt/vmware/etc/vami/ovfEnv.xml is 0 bytes.


Cause

The Stargate service running on the Cloud Extensibility Proxy VA (CExP VA) is constantly using its OVF environment properties and their values, while on the other hand vCenter Server where Cloud Extensibility Proxy VA is running does not claim to retain guest properties.

Rebooting vCenter Server leads to missing OVF environments of the Virtual Machines running in this vCenter Server. So once the vCenter Server is rebooted and the VA Virtual Machine is restarted this issue occurs.

Resolution

Currently there is no resolution.

Workaround:
To work around this issue:

Note: There currently is no workaround if another node is not available.
  1. Copy /opt/vmware/etc/vami/ovfEnv.xml from a working CExP VA to the corrupted node
  2. In the ovfEnv.xml replace the ONE_TIME_KEY and rdc_name properties to the values set in the /usr/local/bin/proxy.properties on the corrupted CExP VA.
  3. Restart the corrupted CExP VA with this command: systemctl restart rdc-proxy