vSphere Maintenance Mode: Key Facts and Best Practices

Every now and then, vSphere admins need to take an ESXi host offline, maybe for a firmware update, hardware replacement, or routine patching. But doing that in a production environment isn’t as simple as flipping a switch. That’s where Maintenance Mode comes in as a safeguard. It’s essentially like hanging a “Do Not Disturb” sign on your ESXi host, ensuring workloads are safely moved and nothing new tries to run on it while you perform your work.

Whether you’re dealing with a standalone ESXi host or a node in a vSAN cluster, Maintenance Mode helps you prep the system, protect running workloads, and manage risk during planned downtime. If you’re working in a modern vSphere 8.x setup, here’s what you need to know about how it works, what your options are, and when to use each one.

What Happens When an ESXi Host Enters Maintenance Mode?

When you place a host into Maintenance Mode, you’re telling vSphere “this host is temporarily unavailable, move workloads elsewhere.” In practice, that means:

• No new VMs or tasks on the host: Once in maintenance mode, you cannot create or power on any virtual machines on that host. vCenter/DRS will also avoid placing or migrating new VMs to that host while it’s in maintenance.
• Running VMs get evacuated: Any active VMs must be moved off or shut down. In a cluster with vSphere DRS enabled, vCenter will automatically live-migrate (vMotion) the running VMs to other hosts. If DRS is disabled or it’s a standalone host, you need to manually migrate or power off the VMs first; the host won’t enter maintenance mode until all VMs are migrated or stopped.
• Host services are halted: All compute and storage operations local to that host are stopped (aside from what’s needed for management). Essentially, the host is idle with respect to workloads until maintenance is done. No new storage I/O or network tasks will originate from it.

The host remains in maintenance mode until you manually exit it. (If you’re using vSphere Lifecycle Manager for patching, there’s an option to automatically exit maintenance mode after remediation, for example, after the host reboots successfully with new patches.) This behavior is consistent whether you invoke maintenance mode through the vSphere Client UI, the ESXi Host Client, or via automation tools like PowerCLI or esxcli. The host will not resume normal operations (and won’t accept new VMs) until maintenance mode is disabled.

Maintenance Mode on Standalone Hosts

For standalone ESXi hosts (not part of any cluster or vSAN), putting the host into maintenance mode is straightforward. There’s no distributed resource scheduler to juggle migrations, so you simply ensure no critical VMs are running, then activate maintenance mode. You can do it via the vSphere web UI or using command-line tools.

vSphere Web Client (UI)

1. Prepare the host: Shut down or migrate any running VMs on the host. (In a standalone scenario, you typically have to power off VMs, since there’s no cluster for vMotion.)
2. Enter Maintenance Mode: In the vSphere Client, right-click the host in the inventory and navigate to Maintenance Mode -> Enter Maintenance Mode. Confirm the action when prompted. The host’s status will change to indicate it’s in maintenance mode.
3. Perform your maintenance: Now you can safely update hardware, apply patches, etc., on that host.
4. Exit Maintenance Mode: When done, right-click the host and choose Exit Maintenance Mode to bring it back online for running VMs.

Command-Line Tools (ESXCLI & PowerCLI)

You can also script or automate host maintenance using command-line tools:

• Using ESXCLI (run directly on the ESXi host via SSH or local CLI):
  • Enter maintenance mode:
  • esxcli system maintenanceMode set –enable true
  • Exit maintenance mode:
  • esxcli system maintenanceMode set –enable false
• Using PowerCLI (from a management machine with vCenter/PowerCLI):
  • Connect to vCenter:

Connect-VIServer <vCenterServerName>

• • Put host in maintenance mode:

Set-VMHost -VMHost <HostName> -State Maintenance

• • Bring host out of maintenance mode (reconnect it):

Set-VMHost -VMHost <HostName> -State Connected

• • (vSAN only) – If the host is part of a vSAN cluster, newer versions of PowerCLI let you specify the data evacuation mode in the same command. For example, to enter maintenance with full data evacuation on a vSAN host:

Set-VMHost -VMHost <HostName> -State Maintenance -VsanDataMigrationMode Full

Maintenance Mode in a vSAN Cluster: Evacuation Options

Putting a host into maintenance mode gets trickier when that host is part of a vSAN cluster. In vSAN, each host isn’t just running VMs; it’s also storing chunks of data for those VMs (since vSAN distributes storage across the hosts). This means when one host goes down for maintenance, you need to decide what to do with the data that lives on that host. vSAN maintenance mode presents three evacuation options to handle this, depending on how long the host will be offline and how much risk you can tolerate.

When you initiate maintenance mode on a vSAN cluster host, vSphere pops up a dialog asking which data migration mode to use. The choices are Full Data Migration, Ensure Accessibility, or No Data Migration. Your selection determines how vSAN will treat the host’s stored data while the host is offline. Below is a breakdown of each option and when to use it:

Full Data Migration

When to use: The host will be down for an extended time, or you’re decommissioning it entirely.

With Full Data Migration, vSAN will evacuate all data from the host before it enters maintenance mode. All vSAN components (disk segments) on that host are copied to other hosts in the cluster. This option offers the highest level of data safety because it ensures the cluster has all data replicated elsewhere, even if this host stays offline indefinitely. However, it’s also the slowest and most resource-intensive option. Expect a lot of data traffic on the network and heavy I/O on the cluster while everything relocates. The host won’t actually enter maintenance mode (i.e., be safe to power down or reboot) until all data is migrated and is verified in its new locations.

Trade-off: Full evacuation is safest, but if your host has terabytes of data, this can take a long time (potentially hours or more, depending on cluster size and network speed). Use it when data availability is paramount or if the host might be out of service for a while. (For example, use Full Data Migration if you plan to keep the host offline overnight or longer, or if you’re removing it from the cluster.) Ensure the cluster has enough free capacity to accept the extra data and that your maintenance window is long enough for the data transfer to complete.

Ensure Accessibility (Default)

When to use: The host will be down only briefly—e.g. for a quick reboot, patching, or small maintenance task. This is the default recommendation for transient maintenance.

Ensure Accessibility tells vSAN to **migrate only the minimum data needed to keep VMs accessible (running) while the host is offline. In practice, vSAN checks each VM’s storage components: if a VM’s data on the host already has another replica on a different host (per the storage policy), vSAN does nothing for that VM—the data on the down host will just be temporarily “missing” but the VM continues running on the remaining replica. If a component exists only on the host (say, the host held the last replica of some data), then vSAN will copy that component to another host to avoid an outage for that VM. This strategy avoids unnecessary data movement and is much faster than full migration, since it only moves what it must. All VMs stay online (they might become non-redundant during the maintenance, but they remain accessible).

A key point: because this mode can leave some data with only one copy (until the host returns), vSAN will wait a bit before trying to rebuild redundancy. By default, vSAN waits 60 minutes after a host goes into maintenance mode (Ensure Accessibility) before starting to rebuild missing replicas on other hosts. This is known as the vSAN repair delay or “object repair timer.” If the host comes back within that time, no permanent rebuild is needed (it just rejoins and everything is redundant again). If the host stays down longer than the timer, vSAN assumes the host might not return soon and begins repairing/rebuilding data on remaining hosts to get back to the proper redundancy level. (This 60-minute timer is adjustable; as of vSAN 6.7 U1 it can be changed in the UI if you plan a longer maintenance but still want to use Ensure Accessibility.)

Trade-off: Ensure Accessibility is usually best for short maintenance tasks (like a quick reboot for a patch) because it’s quick and avoids shuffling tons of data. Just be aware that while the host is out, your cluster’s fault tolerance is reduced for any data that only had replicas on that host. Plan to restore the host promptly. If something goes wrong and the host can’t come back, you’ll want to either manually trigger a rebuild or know that vSAN will start rebuilding after the delay. This mode strikes a balance between safety and speed for most routine updates.

No Data Migration

When to use: Only in emergencies or very special cases – essentially if you need the host down immediately and have assessed the risks. (Often used when doing a quick full-cluster shutdown or if you absolutely cannot wait for data migration.)

No Data Migration tells vSAN not to evacuate any data from the host. The host simply marks its components as absent and enters maintenance mode immediately. This is the fastest way to enter maintenance mode because it does no prep work at all. However, it’s also the riskiest: any data that lives only on that host will become unavailable until the host is back online. In other words, if a VM doesn’t have a second replica on another host (for example, a VM using a policy with no redundancy, or if the cluster was in a degraded state), that VM will lose access to its data and likely crash. Even VMs that do have another replica will be running without their usual redundancy (similar to the ensure accessibility case) until the host returns or until vSAN repairs the data elsewhere (which still only happens after the 60-minute delay by default).

Because of these implications, use “No Data Migration” sparingly. Typical use case: you are shutting down the entire cluster or vSAN cluster (e.g. a planned power outage in a data center). In a full cluster shutdown, you might not care about evacuating data because all hosts are going down anyway. In such scenarios it’s common to use no evacuation on each host as you power everything off, since you’ll bring all hosts (and data) back up together. VMware notes that this option is primarily intended for scenarios like complete cluster power-downs. If you choose it during normal operations, ensure that any running VMs are either okay to lose for the downtime or have replicas on other hosts.

Trade-off: No Data Migration lets you enter maintenance mode immediately, but at the potential cost of VM downtime or even data loss if the host fails to come back. Only choose this if speed is absolutely critical and you’re certain the environment can tolerate the host’s data being offline. In general, avoid this option unless (a) you know all VMs on the host have another copy of their data on other hosts and (b) you are prepared to possibly lose redundancy or shut down those VMs. When in doubt, pick one of the safer options above.

What’s New in vSphere 8.x Maintenance Mode?

The core concept of maintenance mode hasn’t changed over the years, but vSphere 8 (particularly 8.0 Update 3 and beyond) introduced a few enhancements that vSphere administrators should know about. These new features make maintenance mode more powerful or convenient:

• Live Patching with Partial Maintenance Mode: Starting in vSphere 8.0 Update 3, VMware introduced ESXi Live Patch ability. This allows applying certain critical ESXi patches without a full reboot and without vMotioning off all VMs. During a live patch, the host automatically enters a partial maintenance mode state. In partial maintenance mode, new VMs can’t be started or migrated to the host (similar to regular maintenance), but the existing VMs keep running on that host. They are momentarily fast-suspended and resumed (a very brief stun, using VMware’s FSR technology) to apply the patch in memory, but they are not fully powered off or moved. This operation is non-disruptive to most VMs – from the VM’s perspective it’s like a quick pause/unpause. Live patching is useful for fixing certain hypervisor bugs with near-zero downtime. (If a VM can’t be FSR’d – e.g., those with Fault Tolerance or certain pass-through devices – the patch process will flag it and you might need to manually migrate or shut down that particular VM.)
• Parallel Remediation of Hosts: vSphere Lifecycle Manager (vLCM) in newer releases supports patching or upgrading multiple hosts in a cluster in parallel, as long as those hosts are in maintenance mode. Traditionally, vSphere would update hosts one by one (to avoid too many hosts down at once). Now, if your cluster can tolerate it, you can remediate say 2, 4, or more hosts at the same time to speed up cluster-wide updates. You enable this via the Remediation Settings (there’s an option to allow parallel remediation for hosts already in maintenance mode). The system will choose a safe number of concurrent hosts (and you can override the limit if needed). In vSphere 8.x, this feature is highly scalable – in fact, up to 96 hosts can be updated concurrently if configured via API in a massive environment – though in practice you’re limited by how many hosts you can afford to have offline at once. Parallel remediation is a speed boost feature: it doesn’t change how maintenance mode works, but it can shrink your maintenance windows for large clusters by updating many hosts at once.
• PowerCLI Improvements for Maintenance Mode: Automating maintenance tasks is easier in recent PowerCLI versions (PowerCLI 12.x / vSphere 8 and above). Specifically, the Set-VMHost cmdlet now supports a -VsanDataMigrationMode parameter, so you can specify the vSAN evacuation option in the same command that enters maintenance mode. For example, as shown earlier, you can do Set-VMHost -State Maintenance -VsanDataMigrationMode Full to ensure Full Data Migration on a host via script. In the past, if you wanted to automate that, you had to invoke a separate method or API to handle the vSAN data mode. This improvement streamlines automated workflows, ensuring your scripts can handle vSAN cluster maintenance more elegantly.

Aside from these enhancements, the fundamentals of Maintenance Mode remain the same. You still need to make sure VMs are evacuated or suspended, you still choose an evacuation mode for vSAN, and a host in maintenance mode still behaves like it’s “out of service” until you bring it back. The new features just reduce downtime or administrative effort. In short, entering and exiting maintenance mode in vSphere 8.x works just as it did in earlier versions – the process and precautions haven’t fundamentally changed, but now you have a few extra tools to make it smoother.

Best Practices for Using Maintenance Mode

To get the most out of maintenance mode and avoid any hiccups, keep these best practices in mind:

• Plan your evacuation mode based on downtime length: Use Full Data Migration if you expect the host to be offline for an extended period or if you are permanently removing it from the cluster. Use Ensure Accessibility for quick reboots or short maintenance tasks (it’s the fastest while keeping VMs running). Avoid No Data Migration unless you’re absolutely sure it’s safe (e.g. during a total cluster shutdown or other controlled scenario) – it’s rarely worth the risk otherwise.
• Check cluster health and capacity beforehand: Always verify that your cluster has enough free capacity and is in a healthy state before putting a host in maintenance. For vSAN clusters, ensure no disk failures or rebuilds are already in progress (you don’t want to compound issues). Also double-check storage policies compliance – if you’re about to remove a host, are any VMs already down to a single replica? If so, fix that or be extra cautious. Ensuring sufficient resources on remaining hosts prevents overload when VMs move over.
• Verify no VM will get “stuck”: Identify any VMs that cannot be migrated automatically. Examples include VMs with connected physical devices (USB passthrough, DirectPath I/O for GPUs/NPUs), VMs using certain local devices, or vSphere Fault Tolerance secondaries. Such VMs can block a host from entering maintenance. Either shut those VMs down, or manually migrate them to another host that can support the device (if possible) before you enter maintenance mode. This way, you won’t have the maintenance task hanging waiting on one VM.
• Schedule and notify: Perform host maintenance during an appropriate maintenance window and notify relevant teams in advance. Putting a host in maintenance might trigger alerts in monitoring systems (since the host will not be handling workloads). It’s wise to silence or suppress alerts for that host during the maintenance window to avoid false alarms. Communicate with your team or users about the expected impact (e.g., “Host X will be in maintenance mode from 10 PM to 11 PM, VMs will be running on other hosts”).
• One host at a time (usually): In clusters that are running near capacity or for very critical environments, it’s best to enter maintenance mode on one host at a time. This maintains cluster redundancy (HA failover capacity) and prevents excessive strain. If you plan to use parallel remediation for faster patching, ensure your cluster can tolerate multiple hosts in maintenance (e.g., you have N+2 or N+3 redundancy and low load). It’s all about balancing speed with risk.
• Ensure the right tools/versions: If you’re automating via scripts, make sure you’re using up-to-date tools that support the latest features. For example, if using PowerCLI, confirm that you have a version that includes the -VsanDataMigrationMode parameter (PowerCLI 12+). Similarly, if you plan to try the new live patching, ensure the hosts and vCenter are updated to 8.0 U3 and that you understand the compatibility (some VMs like those with FT or certain passthrough devices won’t live-patch and need manual handling).
• Monitor the process: After initiating maintenance mode, keep an eye on the tasks. Especially in vSAN clusters, you can monitor the data evacuation progress. If it’s taking too long (e.g., Full Data Migration stuck at some percentage for a very long time), there might be an issue (like network slowness or a component that can’t move). Be prepared with a back-out plan or extra time if needed. Likewise, once maintenance is done and you exit maintenance mode, verify that the host re-syncs any data (vSAN will resynchronize data if needed).

By following these practices, you can reduce the risk of surprises when taking a host offline.

Final Thoughts

Maintenance Mode isn’t just a check-box in vCenter – it’s a crucial mechanism for protecting your infrastructure and workloads during planned downtime. It lets you service hosts (upgrade hardware, apply patches, fix issues) without introducing unnecessary risk to running VMs. By understanding how maintenance mode works and how vSAN handles data evacuation, you can choose the right approach for each situation and avoid unintended outages or data loss.

In summary: plan your maintenance, pick the appropriate evacuation option, and let vSphere do the heavy lifting of safeguarding your VMs. Whether you’re replacing a failing NIC, updating ESXi to the latest patch, or rebalancing resources in a cluster, Maintenance Mode is your friend for a smooth process. So next time you need to take a host offline, plan carefully and use the tools vSphere provides – you’ll minimize downtime and keep your IT environment running like a well-oiled machine.