After a power event, a vCenter restore or an interrupted migration, some VMs show in vCenter with (orphaned), (invalid) or (inaccessible) after their name. The knowledge base articles for these states end in actions such as removing the VM from inventory, registering or reloading it, stopping its process, reconnecting hosts or editing the vCenter database. None of the three labels picks one of those actions by itself. An Invalid VM may later need a supported reload or registration once its real cause is fixed, and an Orphaned VM may be running normally on another host, where registering a second copy would be the wrong change.
This article builds a dated, identity-matched record for each affected VM and hands it to the owner who decides. It stops there: it contains no repair.
Scope
vCenter Server 8.x managing ESXi 8.x hosts. Everything below is a read. Out of scope: any repair; a host that is itself Not responding (see the published article ESXi Host Not Responding or Disconnected in vCenter: Narrow the Cause); tracing which host owns a lock on a particular file (see the published VMFS file locks article); NFS lock ownership and recovery; and vSAN object inaccessibility.
What the three labels say
Broadcom KB 312831 (vCenter 7.x and 8.x) defines them:
| Label | KB 312831 definition |
|---|---|
| Orphaned | "The VM exists in the vCenter Server database, but is no longer present in the ESXi host inventory." |
| Invalid | "The ESXi host is offline or inaccessible; the VM configuration file is locked or corrupt, or contains a bad option; other possible causes." |
| Inaccessible | "One or more VM configuration files are inaccessible due to possible network partition issues, physical network issues, storage issues, or file corruption." |
These are observations, not causes. Each definition covers several causes, and KB 312831 says that for invalid VMs "there are many potential causes and additional troubleshooting is required." The record below separates what was observed, which candidate explanations fit it, and what has actually been confirmed.
Step 1: record the vCenter view, with identity
For each affected VM, in the vSphere Client, with the time and time zone of the reading:
| Field | What to record |
|---|---|
| A | VM name exactly as shown, including the suffix, and whether the name has become a datastore path |
| A2 | The vCenter object ID if visible, the datastore and full .vmx path, and the VM's UUID if it is recorded anywhere (a change record, a backup catalogue, the inventory export) |
| B | Summary > Related Objects: the host vCenter believes the VM is on, with its ESXi version and build |
| C | That host's connection state (Connected, Disconnected, Not responding) |
| D | Recent tasks and events for the VM and host: vMotion, maintenance mode, power operations, removals, restores, with times |
| E | Any host alarm, for example "Host IP Address Conflict Detected" |
The display name is not an identity. Two VMs can share a name, and an invalid VM's name can turn into its path: KB 443916 (no version stated) describes a VM that "is listed as Invalid in the inventory and VM name appears as a full datastore path".
If field C is not Connected, record that and hand over the host problem first. KB 312831: "If the host is "Disconnected" or "Not responding," all VMs on that host will be unavailable to vCenter."
Step 2: record the host views, with coverage
With the host owner's agreement, read each host's own inventory and running VM processes. Both commands display only.
| Field | Command | What to record |
|---|---|---|
| F | vim-cmd vmsvc/getallvms on the host from field B |
Whether the host has a VM registered with the same .vmx path |
| G | The same command on every other host that could hold it | The same, per host |
| H | esxcli vm process list on each of those hosts |
For any running VM, its UUID, Display Name and Config File |
KB 314365 (ESXi 8.x) shows esxcli vm process list listing, for each running VM, a "UUID", a "Display Name" and a "Config File" path. Match on the Config File path and UUID from A2, not on the name.
For every host in G and H, also record:
- the time and time zone of the reading;
- whether the command succeeded, failed or could not be run (host unreachable, no access);
- why the host was included: same cluster, a vMotion or restore destination in field D, or another host with access to the datastore.
A failed or unrun read is "unknown", not "not listed". A VM absent from the hosts that were read is absent from those hosts only.
KB 423847 (vCenter 7.x/8.x) describes one pattern this record can show: an orphaned VM where "Checking other hosts in the environment reveals the VM is running on a different ESXi host", with "vCenter restoration or host management service restarts" as typical triggers. KB 451093 (no version stated) describes VMs that "were no longer where vCenter expected them to be" after vCenter lost connectivity during vMotion. A process found in H shows that the VM's process is running on that host. It does not show that the guest or its applications are healthy.
Step 3: record the file view
In the datastore browser, from the host in field B and from any host in H:
| Field | What to record |
|---|---|
| I | Whether the .vmx exists at the A2 path, the folder contents (disks, logs), and the time read |
| J | Whether the datastore is accessible from each of those hosts |
| J2 | The datastore type: VMFS, NFS (with version) or vSAN |
| K | Whether the Register VM option is available or greyed out on that .vmx |
A .vmx that exists has not been checked for a valid configuration, a lock or a live owner, so its presence alone is not readiness to register. A folder that cannot be found from one host is not proof that the VM was deleted.
KB 424735 (ESXi and vCenter 7.x/8.x) lists a greyed-out Register VM option among the symptoms of its file-lock case. It is one symptom of that case, not a test for a lock or for which host holds it.
For file locks, field J2 sets what applies. KB 314365: "VMFS volumes do not have .lck files; their locking mechanism resides within the VMFS metadata." On VMFS, the lock owner is traced as in the published VMFS file locks article, not by looking for .lck files. NFS lock files are out of scope here.
Step 4: record the host log lines
On the host in field B and any host in H, keep the full /var/run/log/hostd.log lines around the time the label appeared, with timestamps and the .vmx path in each line. Compare them with the KB examples:
| Log text seen | Source and its scope | Candidate explanation, not a confirmed cause |
|---|---|---|
"Device or resource busy." on the .vmx, followed by "Marking VirtualMachine invalid" |
KB 424735, ESXi 7.x/8.x | Something holds the .vmx open. Which host or process holds it is unknown until the lock owner is identified |
| "Failed to load VM from vigor during register" and "VM_STATE_INVALID_CONFIG" | KB 443916, no version stated; one incident after a power outage | The configuration did not load. KB 312831 also lists a missing .vmx and a file with invalid options or text errors as causes of an invalid VM, so a syntax fault stays possible after an outage |
A line naming a "Syntax error" in the .vmx |
KB 312831 | Candidate configuration fault, at the line the message names |
| No matching line, or the log has rotated past the time | — | Unknown; record what is missing |
Do not reload or register a VM to produce a fresh log line. Such a step is a change, not a read.
On the host's /var/run/log/vobd.log, KB 432729 (ESXi 7.x/8.x) shows "A duplicate IP address was detected for ##.##.##.### on interface vmk0" when another device holds the host's management address. That case shows up as a disconnected host with orphaned VMs.
Step 5: classify, then hand over
Each VM gets one row. More than one candidate can stay open at the same time.
| What the record shows | Classification | Handed to |
|---|---|---|
| C not Connected, or vobd shows a duplicate management IP | Host or network problem first; VM labels follow from it | Host owner; network owner for the address conflict |
| Orphaned; a host in H runs a process whose Config File and UUID match A2 | Candidate stale vCenter record for a VM running elsewhere (KB 423847 pattern). Registering a second copy is excluded | vSphere owner |
| Orphaned; every host in coverage read successfully, none lists or runs it; D shows a dated removal, migration or restore | Candidate stale inventory entry, with the dated event as its basis | vSphere owner |
| Orphaned; no host lists or runs it, but coverage is incomplete or D shows no event | Unresolved: absence not established | vSphere owner, with the gaps listed |
| Invalid with busy, invalid-config or syntax lines | Candidate lock, missing file or configuration fault; owner of any lock unconfirmed | vSphere owner; VMFS lock owner traced per the published article |
| Inaccessible, and J shows the datastore accessible from that host | One or more of the VM's configuration files cannot be reached or read while the datastore itself is reachable. Candidates from KB 312831 stay open: file corruption, or a storage or network fault affecting those files. Whole-datastore loss is not indicated | vSphere owner, with fields I and the hostd lines |
| Inaccessible, and J not read or not readable | Configuration file access impaired; cause candidates are file corruption, storage, or a network partition (KB 312831). Whether the whole datastore is affected is unknown until J is read | vSphere owner; storage owner if J later shows the datastore unavailable |
| J shows the datastore unavailable from that host (whatever the VM label) | Datastore access lost from that host. This is an observation, not a confirmed all-paths-down, permanent device loss or network cause | Storage owner, with device and network evidence; see proposed A11 |
| Fields conflict, or nothing matches | Insufficient evidence | vSphere owner, record as is |
The handover is the record: fields A to K per VM, the coverage list, the log lines with times, the candidate rows, and what is still unknown.
What this record does not authorise
A matched row or a known owner does not authorise any change. The KBs above go on to steps that change state or cannot be reversed, among them editing the vCenter database (KB 311105), stopping VM processes and moving lock files (KB 443916), removing a VM from inventory and reconnecting hosts (KB 423847, KB 451093), rebooting a lock-owning host (KB 424735) and changing a management address (KB 432729). This article does not reproduce those steps.
Before any of them is considered, the owner needs a qualified review covering, at least:
- the exact vCenter and ESXi versions and topology, including whether vCenter is in a Linked Mode group (KB 311105 requires an offline snapshot of the appliance and, for a Linked Mode replication group, "OFFLINE backups must be created for every member");
- the VM's stable identity (UUID,
.vmxpath, disks) and the exclusion of any live owner; - current tasks and migrations on the VM and hosts;
- workload impact and the VM's backup or replica state;
- a supported recovery and back-out path, and what happens if the step is stopped partway;
- application acceptance after the change;
- validation in an isolated environment where the step allows it.
Then each change is made separately, by the owner, under its own approval.
Worked example (fictional)
The values below are invented to show how a record is read. After vCenter was restored from its 01:00 backup, three VMs show as orphaned at 08:40 AEDT. Cluster prod-a has esx-01 to esx-04; all are Connected.
| Field | app-11 | app-12 | old-test-03 |
|---|---|---|---|
A2 .vmx path |
[ds-01] app-11/app-11.vmx |
[ds-02] app-12/app-12.vmx |
[ds-01] old-test-03/old-test-03.vmx |
| B | esx-02 | esx-02 | esx-01 |
| D | vMotion to esx-04 at 03:10 | none recorded | Delete from Disk task run by the test owner in the host client of esx-01 at 02:20, in esx-01's own event log (after the vCenter backup, so not in vCenter) |
| F, G (all four hosts read at 08:45, all succeeded) | listed on esx-04 | not listed | not listed |
| H (all four hosts, 08:46) | process on esx-04, Config File and UUID match A2 | no process | no process |
| I | .vmx present |
.vmx present, disks present |
folder absent |
| J2 | VMFS | VMFS | VMFS |
| hostd | — | no line for app-12 since 01:00 | — |
Classification:
- app-11: candidate stale vCenter record for a VM whose process is running on esx-04. Guest and application health were not checked. Registering a second copy is excluded.
- app-12: unresolved. Its files are present and no host in
prod-alists or runs it, but no event explains why, and hosts outside the cluster with access tods-02were not read. The owner gets the gap list. - old-test-03: candidate stale inventory entry, based on the dated removal task, not on the missing folder.
None of the three is changed by this record.
Acceptance checks
- Each affected VM has fields A to K, or marked not available with the reason, all with time and time zone.
- Identity is matched on
.vmxpath and UUID where available, never on the name alone. - Every host read is listed with its result; failed reads are recorded as unknown.
- Each VM ends in a candidate row with its evidence, or as unresolved.
- The handover names the owner and lists what is still unknown.
- No change was made. Reading needs no rollback, and no recovery or application acceptance was performed.
Learning notes
- Orphaned, Invalid and Inaccessible describe what vCenter sees, not why.
- Inaccessible is about the VM's configuration files; only field J says whether the datastore itself is reachable.
- A host counts as not listing the VM only for hosts that were actually read.
- A running process is not a healthy application, and a present
.vmxis not a VM ready to register. - On VMFS there are no
.lckfiles to look for. - The record ends in a handover, not a fix.
Related articles
- Published: ESXi Host Not Responding or Disconnected in vCenter: Narrow the Cause
- Published: VMFS file locks: read the lock owner with vmkfstools -D
- Proposed, live only once published: inaccessible datastore, all-paths-down and permanent device loss evidence
- Proposed, live only once published: vSAN witness online but objects inaccessible
Sources
Retrieved 2026-11-03 between 14:33:38 and 14:33:42 UTC (early on 4 November, Australia/Sydney), except KB 314365, retrieved 2026-11-03 at 17:31:43 UTC (4 November, Australia/Sydney). Dates below are each article's own Updated On date.
- Broadcom KB 312831, "Virtual machines appear as invalid or orphaned or inaccessible", 10 September 2026. https://knowledge.broadcom.com/external/article/312831/virtual-machines-appear-as-invalid-or-or.html
- Broadcom KB 424735, "Virtual machine inaccessible or invalid in the vCenter Server UI due to ESXi host file lock", 26 August 2026. https://knowledge.broadcom.com/external/article/424735/virtual-machine-inaccessible-or-invalid.html
- Broadcom KB 423847, "Virtual machine (VM) is listed as orphaned and vCenter shows it running on the wrong host", 28 August 2026. https://knowledge.broadcom.com/external/article/423847/vm-is-listed-as-orphaned-and-vcenter-sho.html
- Broadcom KB 443916, "Virtual machine in invalid state after power outage on ESXi host", 11 June 2026. https://knowledge.broadcom.com/external/article/443916/virtual-machine-in-invalid-state-after-p.html
- Broadcom KB 451093, "VMs in Orphaned or Inaccessible state after vCenter Server loses network connectivity during vMotion", 5 August 2026. https://knowledge.broadcom.com/external/article/451093/vms-in-orphaned-or-inaccessible-state-af.html
- Broadcom KB 311105, "Manually removing a stale virtual machine from vCenter Server", 18 August 2026. https://knowledge.broadcom.com/external/article/311105/manually-removing-stale-or-orphaned-virt.html
- Broadcom KB 432729, "ESXi Host Disconnected and VMs Orphaned due to Duplicate IP Address Conflict", 20 July 2026. https://knowledge.broadcom.com/external/article/432729/esxi-host-disconnected-and-vms-orphaned.html
- Broadcom KB 314365, "Investigating Virtual Machine file locks on ESXi Host(s)", 20 August 2026. https://knowledge.broadcom.com/external/article/314365