Problem Description
Customers may notice frequent, recurring login and logout events in their VMware vCenter Server logs originating from the
druvaphxservice account. These log entries are typically associated with API user agents such as pyvmomi or govmomi.These events can generate concern or trigger automated security alerts, especially when observed during time windows when no active backup jobs are scheduled or running.
Cause
This behavior is expected and normal operational functionality of the Druva-VMware integration. It does not indicate a security breach, misconfiguration, or software malfunction.
The primary drivers for these frequent log entries include:
Automated Inventory Synchronization: The Druva proxy routinely queries vCenter to discover new Virtual Machines (VMs), track infrastructure modifications, and maintain an up-to-date environment map.
Snapshot Management: Background API calls are regularly made to prepare, create, or consolidate VMware snapshots.
Concurrent Operations: Multiple parallel workflows or background validation processes can cause overlapping API connections.
Session Maintenance: Transient network fluctuations can trigger quick session retries, resulting in rapid, back-to-back login and logout logs.
Traceback
The vCenter Server Tasks and Events console or forwarded syslog entries will typically display informational event strings similar to the following:
User druvaphx@vsphere.local@192.168.1.50 logged in as pyvmomi/vSphere Python SDK
User druvaphx@vsphere.local@192.168.1.50 logged out (duration: 00:00:02)
User druvaphx@vsphere.local@192.168.1.50 logged in as govmomi/v0.24.0
š” Note: These are categorized as standard informational events by VMware vCenter and are not accompanied by error codes, faults, or warning symbols.
Resolution
Because these events are architectural necessities for API-driven infrastructure management, no corrective action or software fix is required. These logs can be safely ignored.
However, to optimize log readability and manage vCenter noise, you can implement the following best practices:
Filter Security Alerts: If your SIEM (Security Information and Event Management) system or vCenter alarm rules flag the
druvaphxservice account for frequent authentication, create an exclusion rule to allow expected API traffic from the Druva Backup Proxy IP address.Stagger Scheduled Tasks: Distribute backup schedules across different VM groups cleanly to prevent unnecessary peaks in concurrent API processing.
Validate Network Stability: If the login frequency appears abnormally high (e.g., multiple times per second), ensure that network latency between the Druva Backup Proxy and the vCenter server is stable to prevent excessive session retries.
Verification
To ensure that your environment is functioning normally alongside these log entries:
Verify that all scheduled VMware backup and restore jobs are completing with a Success status in the Druva Management Console.
Confirm that the
druvaphxservice account permissions match the minimum requirements outlined in the Druva documentation.Check that the vCenter events do not contain explicit failure codes (such as
Cannot login due to bad credentials).