Problem Description
During the deployment or configuration of a Druva VMware backup proxy, the activation process fails during the vCenter credential configuration stage.
Symptoms
The
ProxyConfutility fails with the explicit error:Failed to set vc cred Internal error.The local proxy interface displays a "successful" activation message, but the backup proxy fails to appear in the Druva Management Console.
Associated symptoms include VM UUID mismatches and general communication failures with the vCenter server.
Cause
This issue occurs when a breakdown in communication between the Proxy VM, vCenter, and the Druva Cloud prevents the local utility from authenticating or registering credentials. The primary triggers include:
Network Configuration Failures: Incorrect or unassigned static IPs on the proxy interface (e.g.,
ens160), preventing the proxy from establishing its network identity.Network Port Blockage (Port 902): The proxy is blocked from communicating with the vCenter FQDN over port 902 (NFC), which is required for secure VMware data tunneling.
vCenter Inventory Desync (UUID Mismatch): vCenter cannot locate the Proxy VM's specific BIOS UUID (often due to a corrupted deployment or cloning issue). Because vCenter cannot identify the VM, it rejects the credential pairing.
Service Handshake Timeouts: The internal service on the Druva Cloud side experiences a handshake timeout (
MainService-1000) while attempting to process the registration.
Traceback / Logs
1. ProxySetup Logs
Plaintext
[2026-03-19 12:41:53,761] [ERROR] ip address not found for interface ens160 [2] [2026-03-19 12:42:23,762] [ERROR] Proxy Setup failed at state 2 <function configure_network_wrapper>
2. VMWARE.log
Plaintext
level=error ts=2026-03-20T07:20:16.54089473Z code=vmware-1000 message="Internal error: VM not found with UUID [42392b43-1832-124f-2b50-4e9580d417ba]"
3. Controlservice Logs
Plaintext
code=MainService-1000 message="Internal error" traceback="druva.com/godevkit/errortype.DecodeAPIErrorToServiceError..."
Resolution
Follow these steps in sequence to isolate and resolve the credential assignment failure:
Step 1: Validate Local Network and DNS Identity
The ProxyConf utility must establish a valid network identity before it can bind credentials.
Verify that the proxy has a valid static IP assigned to its interface (
ens160) and can successfully resolve the vCenter FQDN.Ensure outbound HTTPS traffic (Port 443) is wide open to Druva Cloud endpoints (
*.druva.com).
Step 2: Verify Port 902 (NFC) Connectivity to vCenter
Credential handshakes require open pathways to the ESXi/vCenter management layer.
Ensure firewall rules permit the proxy to communicate over Port 902 to both the vCenter and individual ESXi hosts.
Workaround: If port 902 is blocked on the vCenter FQDN but open directly on the ESXi hosts, test by temporarily entering the ESXi FQDN in
ProxyConfto check if the credential error clears.
Step 3: Restart Hung Druva Services
If the local services are hung during a failed handshake, they will continuously reject new credential requests.
Check the status of the local Druva service:
Bash
service Druva-EnterpriseWorkloads status
If the service is unresponsive or in a failed state, restart it:
Bash
service Druva-EnterpriseWorkloads restart
Step 4: Fix Inventory Desync (Address UUID Mismatches)
If your vmware.log contains the VM not found with UUID error, vCenter cannot map the credentials to this specific VM identity.
Action: To resolve a corrupted inventory state, delete the failing Proxy VM entirely from the vCenter inventory. Deploy a fresh OVF template to ensure a clean, synchronized BIOS UUID registration from scratch.
Step 5: Verify Account Status and Privileges
Ensure the credentials entered into the Druva Management Console match the vCenter account and hold the required VMware administrative permissions.
Check your domain controller or vCenter configuration to ensure the backup service account has not been locked out before re-running
ProxyConf.