VMware ESXi and vSphere Cluster Management

Manage ESXi Security Profile Services and Startup Policies

Learn how to inspect, start, stop, restart, and configure ESXi host services and startup policies in the vSphere Client Security Profile settings.

ESXi host services are background daemons that provide capabilities such as host management, monitoring, time synchronization, and remote administration. The vSphere Client exposes these services through the host's Security Profile settings, where an administrator can inspect service state, perform lifecycle actions, and choose a startup policy.

Service management and firewall management are related but separate tasks. A service process may be running while its network traffic is blocked, and opening a firewall port does not necessarily mean that every service using the port should be enabled. Treat service availability and network exposure as two administrative decisions.

What the Security Profile Services Area Does

The Security Profile services area is a host-level interface for reviewing and controlling ESXi services. For each service, you can generally see whether it is running or stopped, review its configured startup policy, and select an action such as Start, Stop, or Restart.

An ESXi host service is a daemon, meaning a persistent background process that performs a system or management function. Examples include services used for remote command-line access, time synchronization, monitoring, and communication with management infrastructure.

The Security Profile area commonly also contains firewall-related settings. Firewall rules determine which network communication is permitted. Service settings determine whether the associated daemon is operating. Some startup policies use firewall-port state as a trigger, which is why the two settings must be planned together.

Open Host Service Settings in the vSphere Client

  1. Select the target ESXi host in the vSphere inventory.
  2. Open the host's management settings.
  3. Locate Security Profile and its services section.
  4. Open the editing interface for host services.
  5. Select a service to inspect its current status and startup policy.
  6. Choose an action or policy, save the change, and verify the resulting state.

Menu names and the exact location of the edit control can vary between vSphere Client releases. The task remains the same: select the host, open its Security Profile service administration, edit the selected service, and confirm the result.

For a broader introduction to the management interface, see the vSphere graphical interface. If the host is managed by vCenter Server, host inventory and access also depend on the connection between vCenter Server and ESXi.

Inspect Service Status

Before changing a service, identify two different facts:

  • Current state: whether the service is running or stopped right now.
  • Startup policy: the rule that determines when the service starts and stops, including what should happen after a host reboot.

SSH is a useful example. Select SSH in the service list and determine whether it is currently running. Then review whether its policy is Start and stop with host, Start and stop manually, or Start and stop with port usage. A service marked as enabled in one context is not automatically proof that it is currently running or reachable from a particular network.

Service Lifecycle Operations

Start a service

Use Start when a service is stopped and must begin operating immediately. Starting a service changes its current process state; it does not necessarily change the startup policy. Review the policy separately if the service must behave the same way after a reboot.

Stop a service

Use Stop when the service should no longer run. Stopping a management-oriented service can interrupt administration, monitoring, automation, or troubleshooting. Stopping SSH, for example, can terminate or prevent remote shell access to the host. Confirm that another approved management path is available before stopping a critical service.

Restart a service

Use Restart when a configuration or connectivity change requires the daemon to reload or reinitialize. A restart briefly interrupts the service. It can help after changing service-specific settings, restoring network access, or correcting a transient condition, but it does not fix an incorrect firewall rule, route, DNS setting, or remote server configuration by itself.

Change a startup policy

Select the policy that matches the service's operational and security requirements, save the change, and then verify both the current state and the expected behavior. Changing a policy is different from merely starting or stopping the service once.

Start — Immediate effect: launches a stopped service. Persistent startup-policy effect: none unless the policy is also changed. Operational caution: confirm that required ports, dependencies, and management access are available.

Stop — Immediate effect: terminates an active service. Persistent startup-policy effect: none unless the policy is also changed. Operational caution: remote access, monitoring, or host-management functions may be interrupted.

Restart — Immediate effect: stops and starts the service again. Persistent startup-policy effect: normally none. Operational caution: expect a short interruption and verify that the service returns to the intended state.

Change startup policy — Immediate effect: changes the rule governing future service operation and may interact with the current state. Persistent startup-policy effect: determines behavior at host boot, shutdown, or firewall-port changes. Operational caution: test after a planned reboot or port change.

ESXi Startup Policies

A startup policy defines when a service starts and stops. The three policy choices below connect service state to either the host lifecycle, administrator action, or firewall-port usage.

Startup policy — Start and stop with host

What starts the service: ESXi host startup.

What stops the service: ESXi host shutdown.

Effect of firewall port state: The service follows the host lifecycle, but required communication still depends on permitted firewall access. If a needed port is opened later, the service can resume attempting its required communication.

Behavior after ESXi reboot: It starts during host boot.

Typical use case: A service that should generally be available whenever the host is online.

Startup policy — Start and stop manually

What starts the service: An administrator explicitly starts it.

What stops the service: An administrator explicitly stops it.

Effect of firewall port state: Firewall-port state does not automatically control this policy.

Behavior after ESXi reboot: The manually selected running or stopped state remains after reboot according to the configured manual behavior; it is not automatically changed by the firewall.

Typical use case: Temporarily enabling a diagnostic or remote-management service for an approved maintenance window.

Startup policy — Start and stop with port usage

What starts the service: One or more associated firewall ports are opened. The service keeps trying until it starts successfully or completes required initialization.

What stops the service: Every associated firewall port is closed.

Effect of firewall port state: Port state directly controls whether the service should run. Opening an associated rule can trigger startup; closing all associated rules can stop it.

Behavior after ESXi reboot: The service follows the state of its associated ports and its initialization behavior.

Typical use case: A service that should remain inactive when no permitted firewall access exists, limiting unnecessary exposure.

Recommended default behavior: The port-usage policy is the recommended default behavior described for service management because it links service execution to permitted firewall access. Apply it when the service's lifecycle is appropriately tied to its associated ports.

Start and Stop with Host

With this policy, ESXi launches the service during host startup and shuts it down as the host powers off. The service is intended to remain available throughout normal host operation.

Starting the daemon does not guarantee that its external task succeeds. For example, a time synchronization service may start and continue trying to reach its configured NTP server after host startup. If the required firewall port is opened later, the service can resume attempting the communication it needs.

This policy suits services that should generally be available whenever the ESXi host is online, such as an operational service required by an approved management or monitoring design. It should not be selected merely because a service is convenient; enable only services that are needed.

Start and Stop Manually

With the manual policy, an administrator explicitly controls whether the service runs. Firewall-port state does not automatically start or stop the service under this policy.

The manually selected running or stopped state remains after an ESXi reboot according to the manual configuration. This makes the policy useful for a diagnostic service or a remote-management service that is enabled only during a planned maintenance window.

For temporary SSH access, first confirm approval and restrict the applicable firewall access. Start SSH manually, perform the maintenance, stop SSH when finished, and verify that remote access is no longer available. A manual policy alone is not a substitute for restricting the firewall and source management networks.

Start and Stop with Port Usage

With this policy, ESXi starts the service when one or more associated firewall ports are opened. The service keeps retrying until it successfully starts or completes its required initialization. When every associated port is closed, ESXi stops the service.

This creates a direct relationship between permitted network exposure and service execution. Opening a firewall rule can cause a port-controlled service to start; closing the entire associated rule set can cause it to stop. A rule change can therefore change service state even when no one selects Start or Stop in the service interface.

Port-based startup is useful when a service should be inactive whenever no authorized network access is permitted. It supports a least-exposure approach, but it still requires careful firewall design: a permitted port should be limited to the necessary protocol, interface, and management sources.

Services and Firewall Ports

A service can depend on one or more allowed ESXi firewall ports for network communication. The service process and the firewall rule set are separate controls:

  • Starting a service enables its process, but blocked traffic can still prevent communication.
  • Opening a port permits matching traffic, but does not necessarily start a manually controlled service.
  • Under port-based startup, opening an associated port can start the service and closing all associated ports can stop it.
  • A service may appear to be running while an external server, route, DNS record, or network policy is unavailable.

Coordinate service changes with the ESXi firewall and approved management networks. For firewall-specific administration, see Configure the ESXi firewall. Enabling a service and allowing its network access are separate decisions that should both be documented.

Practical Examples

Inspect the SSH service

  1. Select the ESXi host in the inventory.
  2. Open the host's Security Profile service configuration.
  3. Locate SSH and determine whether it is running or stopped.
  4. Review whether its policy is host-based, manual, or port-based.
  5. Compare the result with the approved remote-access design before making a change.

The important result is not just the SSH status. You should be able to identify both its current process state and its persistent startup behavior.

Enable SSH only for a maintenance window

  1. Confirm that remote shell access is approved and that the firewall allows only authorized management sources.
  2. Start SSH manually for the required maintenance.
  3. Perform the intended maintenance task.
  4. Stop SSH after completion.
  5. Confirm that remote access is no longer available and that unnecessary firewall access is closed or restricted.

Configure a service to follow host startup

  1. Choose a service expected to be available whenever the ESXi host is operating.
  2. Set its policy to Start and stop with host.
  3. Verify after host startup that the service attempts its normal work, such as contacting required infrastructure.
  4. Validate the behavior after a planned reboot.

Use port-based startup behavior

  1. Choose a service associated with an ESXi firewall rule.
  2. Set its policy to Start and stop with port usage.
  3. Open the relevant firewall port and verify that the service can start.
  4. Close all associated ports and verify that the service stops.

Time synchronization cannot reach its server

  1. Confirm the service's startup policy and current state.
  2. Check that relevant firewall access is permitted when applicable.
  3. Verify network reachability and the configured NTP server separately from service status.
  4. Recheck the service after connectivity is restored.

NTP is the Network Time Protocol. A running NTP-related service proves that the daemon is active; it does not prove that the host can reach or synchronize with the configured time server.

Troubleshooting

The service is stopped after reboot

  • Review the service startup policy.
  • Determine whether it was configured for manual operation.
  • Confirm that the host completed startup successfully.
  • Start the service if required and set the intended persistent policy.
  • Test again after a planned reboot.

A port-controlled service does not run

  • Verify that at least one associated firewall port is open.
  • Check that the service uses Start and stop with port usage.
  • Confirm that network policy permits the required traffic.
  • Review service status after enabling the firewall rule.

SSH cannot be reached even though it appears enabled

  • Confirm that the SSH service is actually running.
  • Verify the applicable ESXi firewall rule and authorized source network.
  • Check connectivity to the host management interface.
  • Ensure that the connection uses the correct host address and SSH port.

The service is running but its external task fails

  • Separate process state from network or application connectivity.
  • Verify firewall allowance, routing, DNS when relevant, and target-server availability.
  • For time synchronization, validate reachability to the configured NTP server.
  • Review logs and service-specific configuration if connectivity is available but the task still fails.

Remote administration was left enabled

  • Stop the unnecessary service.
  • Set a policy appropriate for temporary use.
  • Close or restrict the associated firewall access.
  • Verify that approved management access remains available through the intended method.

Administrative and Security Considerations

  • Use least privilege and enable only services required for operations.
  • Restrict remote-access services such as SSH to authorized maintenance use.
  • Coordinate service changes with firewall rules and approved management networks.
  • Do not disable essential services without understanding the possible host-management and workload consequences.
  • Verify service state after every change and after a reboot when testing startup behavior.
  • Record temporary changes and return services and firewall rules to the approved baseline when maintenance ends.

Host access also depends on permissions and access-control design. Review vSphere permissions and ESXi lockdown mode when determining who may administer services and which management paths remain available.

Exam-Relevant Notes

  • Running describes the current service state; startup policy describes how ESXi determines future state.
  • Start and stop with host follows host boot and shutdown.
  • Start and stop manually requires explicit administrator control and is not automatically driven by firewall-port state.
  • Start and stop with port usage starts when an associated port is opened and stops when all associated ports are closed.
  • A running service is not proof of successful external connectivity.
  • Service enablement and firewall access are separate administrative decisions.