How to Use ESXCLI to Restart Management Agents on ESXi (7/8/9)

What is the command to restart services in ESXi?

There is no single universal command since it depends on which service you need to restart. Here is a quick reference:

If you are unsure which service to target, or if the host is broadly unresponsive, you can restart all management agents at once:

services.sh restart 

Not sure which method fits your situation? The next section helps you match your symptom to the right fix.

Why Restart ESXi Management Agents Right Now

Management agents fail silently. Your VMs keep running, but the host becomes a black box as you can’t manage it, monitor it, or trust what vCenter is telling you. These are the signs that a restart is the right call.

• The vSphere Host Client won’t load or times out. The host is reachable by ping, but the login page hangs. This points to hostd, not a network issue.
• vCenter shows the host as “Disconnected” or “Not Responding.” You can still log in directly, but vpxa has likely stopped sending heartbeats to vCenter.
• VM operations get stuck mid-task. Actions like Power On, Take Snapshot, or Edit Settings hang at a fixed percentage and never complete.
• The Host Client UI is extremely slow. Clicking through menus takes seconds per action, usually a sign that hostd is consuming excessive memory or is caught in a loop.
• Events and logs have stopped updating. The Events tab in vCenter freezes and log files show no new entries. When agents hang, diagnostic data stops flowing too.
• Network changes aren’t taking effect. Configuration updates to a Standard Switch or Distributed Switch haven’t propagated. Restarting the agents forces a refresh.
• “Agent Unable to Retrieve VM Creation Options” error. This appears when provisioning a new VM and means the management agent can’t query the host’s available hardware resources.

How to Restart ESXi Management Agents with 3 Methods

Before running any command, take two minutes to check your environment. The restart itself is safe, but the timing and method matter, too.

Will Restarting Management Agents Affect Running VMs?

No. Restarting hostd and vpxa only affects the management layer. Your VMs run independently of the management layer. They will stay powered on, and their network traffic will not be interrupted.

That said, any in-progress management task, such as a snapshot, a power operation, or a config change, may fail or hang until the agents are back online. Wait for active tasks to complete before proceeding.

Things to Check Before Running Any Command

• Notify other admins. In shared environments, a host briefly showing as “Not Responding” during a restart can trigger false alarms or unnecessary escalations.
• Wait for active vMotion or storage migrations to finish. Restarting agents mid-migration can leave the task in an unrecoverable state.
• Check whether NSX is installed. If NSX is present, do not use services.sh restart, and it will restart all services and temporarily interrupt network connections. Restart hostd, vpxa, and fdm individually instead. To check whether NSX is installed, run:

esxcli software vib list --rebooting-image | grep esx-* 

If vsip-esx or esx-vxlan appear in the output, NSX is installed on the host.

• Check for LACP on a Distributed Switch. If LACP is configured, avoid services.sh restart for the same reason. Use individual service restarts only.
• Confirm no backup jobs are running. An active backup holds an open snapshot. If you restart the agents mid-job, the backup software loses its handle on the process and the snapshot can become stranded, leaving the VM running on a delta disk with no cleanup path.

Method 1: Restart Management Agents via SSH

This is the most common approach. It gives you precise control over which services to restart and provides immediate feedback.

Step 1: Enable SSH on the ESXi host

If SSH is not already running, enable it via the vSphere Host Client under Host > Manage > Services > TSM-SSH > Start. Alternatively, enable it through the DCUI under Troubleshooting Options.

Step 2: Connect via SSH

Use PuTTY (Windows) or your system Terminal (macOS/Linux) and log in as root.

Step 3: Restart hostd

/etc/init.d/hostd restart 

Step 4: Restart vpxa

/etc/init.d/vpxa restart 

Step 5: Verify both services are running

/etc/init.d/hostd status
/etc/init.d/vpxa status 

Both should return hostd is running and vpxa is running. If either shows stopped, wait 30 seconds and run the status check again and services can take a moment to fully initialize.

Step 6: Restart the management network interface (if the host is still unreachable)

If both services are confirmed running but the host is still not responding in vCenter, restart the management VMkernel interface. This may briefly drop the management connection but does not affect VM traffic.

esxcli network ip interface set -e false -i vmk0 ; esxcli network ip interface set -e true -i vmk0 

Method 2: Restart Management Agents via the DCUI

The Direct Console User Interface (DCUI) is the yellow-and-grey text menu displayed on the physical monitor connected to your server. Use this method when SSH is disabled or the network is too unstable to establish a remote session.

When to choose DCUI over SSH

The DCUI runs directly on the host console and does not depend on network connectivity. If you cannot open an SSH session or the Host Client won’t load, this is your most reliable fallback.

Step-by-step: Restarting agents via DCUI

1. Access the host console and press F2 to enter the customization menu.
2. Log in with your root credentials.
3. Navigate to Troubleshooting Options using the arrow keys and press Enter.
4. Select Restart Management Agents and press Enter.
5. Press F11 to confirm. The host will run services.sh to restart all management services in sequence.
6. When the status shows Done, press Enter, then press Esc to exit.

Method 3: Restart hostd and vpxa via the Host Client

If you can still access the vSphere Host Client directly but the host appears as “Disconnected” in vCenter, you can restart the agents through the browser without touching the command line.

When this method makes sense

This method only works if the Host Client can still load. If it can’t, hostd itself is the problem, you can go back to Method 1 or Method 2.

Step-by-step: Restarting via Host > Manage > Services

1. Open a browser and log into the ESXi host directly using its IP address or FQDN.
2. In the left-hand navigation panel, click Manage.
3. Select the Services tab.
4. Find hostd in the list, right-click it, and select Restart.
5. Once hostd is back up, find vpxa, right-click it, and select Restart.

What If Management Agents Still Won’t Respond?

If restarting the agents hasn’t restored connectivity, the problem likely goes deeper than a hung service. At this stage, shift from trying fixes to finding the root cause.

Where to Find the Right Log Files

ESXi stores management logs in /var/log/. If the agents are failing to start or crashing immediately after a restart, check these two files first:

• /var/log/hostd.log — covers local host management operations, hardware interactions, and VM task execution.
• /var/log/vpxa.log — covers communication between the host and vCenter Server.

Reading the Logs for Root Cause

Use tail via SSH to view recent entries without opening the full log file:

View the last 50 lines of hostd.log:

tail -n 50 /var/log/hostd.log 

Search for errors in vpxa.log:

grep -i "error" /var/log/vpxa.log 

Look for strings like Connection refused, Failed to discover, or Resource temporarily unavailable. If you see persistent I/O errors, the agents may be stuck waiting on a storage array that is no longer responding — check whether any datastores are in an All Paths Down (APD) or Permanent Device Loss (PDL) state.

Reconnecting the Host in vCenter After a Successful Restart

vCenter does not always automatically detect that the agents are back online. If the host still shows as “Disconnected” or “Not Responding” after a confirmed restart, trigger a manual reconnection:

1. Right-click the host in the vCenter inventory.
2. Select Connection > Connect.
3. Confirm the SSL certificate thumbprint if prompted.

When to Escalate to a Full Host Reboot

If the restart commands hang indefinitely or return a Device or resource busy error, a process may be stuck in an uninterruptible state — typically caused by a storage or kernel-level failure that the management layer cannot recover from on its own.

If services.sh restart does not complete within 10 minutes, or if logs show kernel-level errors that indicate the host is no longer stable, plan for a full reboot. Since the management agents are down, you will likely need to issue the reboot through your server’s hardware management interface (iDRAC, iLO, or IPMI).

Back Up Your ESXi VMs Before the Next Management Failure

Restarting management agents resolves the immediate problem. But it doesn’t protect you from what happens during the window when your host is unmanageable, a stranded snapshot, a failed backup job, or a VM that can’t be recovered because no clean restore point exists.

Manual intervention works once. A reliable backup strategy works every time.

i2Backup is an enterprise backup solution. It protects VMware VMs without installing any agents on the host or the guest, using native VMware APIs to back up at scale with zero impact on production workloads.

Key Features of i2Backup

• Agentless VM backup. i2Backup uses native virtualization platform APIs to back up VMware VMs without touching the guest OS or disrupting running workloads. No agents to install, no production impact.
• Instant VM Recovery. In the event of a host failure, i2Backup can remotely mount a VM backup directly to the target platform, bringing the VM back online without waiting for a full restore.
• Point-in-time recovery. Continuous backup logs and multiple restore points let you recover to any specific moment — useful when data corruption or accidental deletion is the issue, not just a full host failure.
• Flexible scheduling and automatic cleanup. Set backup schedules by the hour, day, or week. Outdated backups are removed automatically based on your retention rules, keeping storage usage under control without manual intervention.
• Centralized monitoring and alerts. A web-based management interface gives real-time visibility into backup status, with email and SMS alerts so your team knows immediately if a job fails.
• Broad platform compatibility. Beyond VMware, i2Backup supports Hyper-V, OpenStack, Huawei HCS/FusionCompute, ZStack, and more, useful if your environment spans multiple virtualization platforms.

Management agent failures are rarely predictable. Having a clean, recent VM backup means that when something does go wrong, recovery is a matter of minutes, not hours of troubleshooting.

FAQ

Q1: Does restarting hostd affect running VMs?

No. Management agents like hostd and vpxa operate independently of the layer that runs your virtual machines. The VMs will continue to run, process data, and maintain network connectivity throughout the restart. The only thing that becomes briefly unavailable is the management interface itself.

Q2: How do I verify the agents restarted successfully?

Run the status check command via SSH:

/etc/init.d/hostd status
/etc/init.d/vpxa status 

Both should return a “running” status. Also check that the host returns to a Connected state in the vCenter inventory — that confirms vpxa has successfully re-established communication with vCenter.

Q3: What is the difference between hostd and vpxa?

hostd manages the host’s local resources and VM operations directly. vpxa is the vCenter communication agent — it receives instructions from vCenter Server and passes them to hostd for execution. If hostd is the engine, vpxa is the relay.

Q4: Can I restart management agents without SSH access?

Yes. Use the DCUI via a physical console or a remote hardware management tool like iDRAC or iLO. If the vSphere Host Client is still accessible, you can also restart services directly under Host > Manage > Services.

Q5: Do I need to restart management agents after a network config change?

Usually not. But if you have applied changes to a vSphere Distributed Switch and the host remains “Out of Sync” in vCenter, restarting the agents can force a configuration refresh and resync the host’s state with the vCenter database.

Conclusion

A management agent failure feels more serious than it is. In most cases, your VMs are still running, and the problem is isolated to the management layer, and a targeted service restart is all it takes to restore visibility and control.

The three methods covered in this guide give you a fix for every scenario: SSH for precise control, DCUI when the network is unreliable, and the Host Client when the issue is limited to vCenter connectivity. If none of those work, the log files will point you to the real cause — whether that’s a storage issue, a credential mismatch, or something that requires a full host reboot.

One thing a service restart can’t do is recover data. If an agent failure causes a backup job to fail or leaves a snapshot stranded, you need a clean restore point to fall back on. Setting up agentless VM backups with Info2soft’s i2Backup before the next failure, not after, is the simplest way to make sure recovery is always an option.