All Shared Datastores Failed On The Host | HA Error Fix

What The “All Shared Datastores Failed On The Host” Error Really Means

When vSphere shows the message “All Shared Datastores Failed On The Host”, it is warning that a host in the HA cluster cannot use any of the shared datastores for heartbeat or storage access. In plain terms, the host believes every shared volume it relies on has stopped responding, which places vSphere High Availability at risk for that node.

Behind this message sits an internal event often labeled com.vmware.vc.HA.DasHostCompleteDatastoreFailureEvent. This event fires when HA detects that all shared heartbeat datastores on a host have failed or become unavailable. In a real outage, that would mean the host lost access to shared storage and HA cannot use datastore heartbeats to tell if the host is alive. In many clusters though, the alert appears while workloads stay online and datastore views look healthy, which points to a stale HA or storage status entry rather than a live failure.

VMware documents show that the alarm can linger even when datastores are mounted and virtual machines keep running without issues. In those cases, the problem often traces back to a past storage path issue or a PDL (permanent device loss) on backing devices that left an outdated entry in vCenter services. Restarting the vpxd and vmware-sps services on vCenter clears that stale state once you have confirmed storage health.

So when you see all shared datastores failed on the host in the UI, treat it as a serious signal, then check whether it reflects current reality or only a brief incident that has already cleared. The rest of this guide walks through quick checks, deeper HA fixes, and storage checks so you can decide which path fits your cluster.

Common Scenarios Behind The Alarm

Scenario	What You See	First Check
Real storage outage	Datastores show unavailable on one host and virtual machines go offline or pause I/O.	Check datastore status on that host and compare with other hosts in the cluster.
Stale HA alarm	Alarm shows, but datastores look healthy and workloads keep running normally.	Confirm no storage alerts, then refresh HA or restart vCenter services that track storage.
Heartbeat datastore issue	HA errors about heartbeat datastores along with the shared datastore failure event.	Verify at least two shared datastores are accessible to every host in the cluster.

Quick Health Checks Before You Change HA Settings

Before you touch HA settings or restart services, make sure the host really can see shared storage. A small connectivity issue or zoning mistake can turn a simple warning into a full outage if you rush through changes.

Start from the vSphere Client and the storage system console, then move toward logs only if the basic checks raise questions.

• Compare host views — In the vSphere Client, open the affected host, then Storage and confirm which datastores show attached. Cross-check the same datastores on a healthy host in the same cluster.
• Confirm datastore accessibility — For each shared datastore, check that its status is Accessible on the problem host. If a datastore appears as inaccessible only on that host, you are dealing with a real path or mapping issue.
• Review storage adapters — Under Storage Adapters on the host, verify that HBAs or NICs used for SAN, NAS, or vSAN show online and present the expected devices and paths.
• Ping storage targets — From the ESXi console or SSH session, ping iSCSI or NFS targets to confirm basic network reachability. For Fibre Channel, use esxcli commands to list HBAs and check login status.
• Check array or filer alerts — Log in to the storage array or NAS dashboard and check for disk failures, controller issues, or logged path problems at the time the alarm appeared.

If any of these checks show a datastore missing only from the affected host, focus on storage and fabric troubleshooting first. If the host sees the same devices and volumes as its peers and virtual machines run smoothly, you can treat the issue as either an HA heartbeat problem or a stale status entry.

Fixing All Shared Datastores Failure On A Host In vSphere HA

vSphere HA uses datastore heartbeats in addition to network heartbeats. When the primary host cannot talk to a peer over the management network, it checks shared datastore heartbeats to decide if the peer is alive or isolated. If those heartbeat datastores stop responding from a single host, HA raises events like the one that leads to this alarm.

For HA to work well, each cluster needs at least two shared datastores that every host can access. Those datastores give HA enough redundancy to distinguish a failed host from a temporary network split. When the cluster falls below that minimum, or when one host loses access to all heartbeat candidates, HA starts to raise errors about shared datastores on that host.

Once you are sure that storage on the host is healthy, walk through a short HA configuration pass to sync cluster state and fix heartbeat settings.

• Reconfigure HA on the host — In the vSphere Client, right-click the affected host and choose the option to reconfigure vSphere HA. This forces the HA agent on that host to refresh its datastore and heartbeat view.
• Disable and enable HA on the cluster — If a single host reconfigure does not clear the warning, disable HA at the cluster level, wait for the change to complete, then enable it again so all agents rebuild their state.
• Check heartbeat datastore selection — In cluster settings, open the HA datastore heartbeat section and confirm that at least two shared datastores are selected and accessible from every host.
• Avoid vSAN-only heartbeat — In mixed setups, ensure HA also uses non-vSAN VMFS or NFS datastores for heartbeat. A vSAN-only choice can limit options if a host falls behind on vSAN membership.
• Review HA logs for this host — On the ESXi host, read /var/log/fdm.log around the time of the error for deeper hints on heartbeat selection or datastore failures seen by the HA agent.

If the cluster already meets the heartbeat datastore requirements and HA reconfiguration completes without new errors, yet the same host keeps raising a shared datastore failure event, the problem may sit with vCenter’s view of storage rather than real connectivity.

Clearing Stale Shared Datastore Failure Alarms

Many admins meet this message during maintenance or after a brief storage blip, only to find that every datastore is fine when they run checks. In those cases, the datastore failure alarm often comes from stale entries held by vCenter services that track storage paths and HA events.

VMware notes that the message can stay visible even when datastores are mounted and reachable and virtual machines run without impact. The alarm returns shortly after you acknowledge it or set it back to green. This pattern points to stale data in the storage policy and vCenter server services rather than an ongoing failure.

When you are confident that storage paths and host access look clean, you can treat the error as cosmetic and clear it by restarting the right services during a short maintenance window.

• Confirm no active storage incident — Double-check datastore views, storage array alerts, and ESXi logs for any current I/O errors or devices in PDL or APD state.
• Plan a small vCenter outage — Restarting core services such as vpxd and vmware-sps will briefly interrupt management access, so schedule the action when that interruption is acceptable.
• Restart storage-related services — On the vCenter server, restart the vCenter service and the storage policy service. Once they come back, they rebuild their datastore status view from the hosts.
• Recheck the alarm state — After services stabilize, open the host summary page again. In many cases, the “all shared datastores failed on the host” message disappears and stays clear.

If the warning keeps returning even after a vCenter service restart and HA reconfigure, capture logs from vCenter and the affected host and open a case with VMware so they can review the HA and storage layers in more depth.

Storage And Fabric Checks When The Failure Is Real

When the alarm is backed by real storage loss, the host truly cannot reach any shared datastore that HA expects. In Fibre Channel, iSCSI, NFS, or vSAN setups, that usually traces back to transport issues, path failures, zoning mistakes, or storage device trouble.

Once you confirm that a datastore is missing only from the affected host, put HA changes on hold and fix storage connectivity first. Solving fabric issues usually clears the datastore failure event as a side effect.

• Check path states on the host — In the host’s Storage Adapters view, review each device and its paths. Look for paths marked dead or standby that should be active, and rescan adapters to refresh path states.
• Validate fabric logins — For Fibre Channel setups, use esxcli storage san fc list on the host to confirm that HBAs register correct port IDs and logins to the fabric.
• Confirm LUN presentation — From the storage array side, confirm that the host’s initiators are in the correct groups and that the same LUNs are presented to all hosts in the cluster.
• Review recent changes — Check whether any storage firmware, driver, zoning, or multipathing changes landed shortly before the error started. Rollbacks or fixes there often restore datastore access.
• Look for datastore corruption alerts — If VMware logs show VMFS corruption events or LUN damage, pause changes, protect data, and follow vendor guidance before bringing datastores back.

After you restore datastore access and confirm that the host now sees the same shared volumes as its peers, reconfigure HA on that host and clear any remaining datastore failure events. If you patched or upgraded ESXi shortly before the incident, confirm that storage drivers and firmware match the current compatibility guide for your setup.

When To Escalate And How To Reduce Repeat Alarms

Some clusters see the “All Shared Datastores Failed On The Host” message only once, tied to a clear storage outage. Others see it return across maintenance cycles or random host restarts. A repeating pattern usually signals either a design gap in HA and heartbeat settings or deeper storage path fragility.

Use each occurrence as a chance to tighten both HA design and storage hygiene so that future alerts either disappear or map cleanly to genuine incidents.

• Loop in storage and VMware vendors — If you find repeated path drops, login failures, or VMFS warnings, gather logs and contact both your storage vendor and VMware to review the stack together.
• Confirm cluster datastore design — Make sure every host in the HA cluster sees at least two shared datastores and that those volumes are suitable heartbeat candidates across all nodes.
• Baseline storage performance — Track latency and path flaps over time. Spikes around backup windows, firmware tasks, or heavy maintenance can reveal weak spots that trigger heartbeat issues.
• Document maintenance steps — For planned storage work, record clear steps to place hosts in maintenance, evacuate workloads, and bring paths back in a controlled order so HA does not misinterpret transient loss.
• Review host build templates — Confirm that new or rebuilt hosts receive the same storage drivers, firmware levels, multipathing rules, and VMkernel settings as stable members of the cluster.

With those habits in place, the next time you see “All Shared Datastores Failed On The Host”, you will know whether you are looking at a short-lived heartbeat hiccup, a stale HA record, or a real storage event that needs deeper work. That clarity keeps your cluster safer and cuts down on noisy alarms that distract from real incidents.