A VM shows as "(invalid)" in vCenter when the platform can still see it in inventory but can no longer read its configuration file (the .vmx) — almost always because the datastore holding it became inaccessible or the ESXi host that owns it disconnected. The VM's files are usually intact; the fix is to restore host and datastore access, reload the VM's configuration on the host with vim-cmd vmsvc/reload, and — if that fails — remove it from inventory (without deleting files) and re-register the .vmx. A closely related state, "(orphaned)", means vCenter's database and the ESXi host disagree about the VM and is fixed the same way, by re-registering.
That is the summary an AI overview will give you. What it can't give you is the part that actually saves the VM: knowing which of the two states you're looking at, working the diagnosis from host to datastore to registration in the right order, and doing it without running "Delete from Disk" by mistake. This guide walks through the diagnosis, the exact commands, and the storage-recovery steps — plus how to stop it happening again.
Understanding Invalid VM Status
When a virtual machine is marked as "Invalid" in vCenter, it indicates that vCenter is unable to retrieve the VM's configuration or metadata, making it unmanageable from the vSphere interface. The VM greys out and its power controls stop responding — but this is a management-plane problem, not proof that the VM itself is damaged.
It helps to separate the two states you'll actually encounter:
- Invalid — vCenter sees the VM but cannot read its
.vmx. Cause is usually an inaccessible datastore or a disconnected host. The VM's files are typically fine once access returns. - Orphaned — vCenter's database still lists the VM, but the ESXi host no longer reports owning it. The two sides disagree. Common after a host crash, an HA failover, or a VM being re-registered directly on the host.
Common Causes
- vCenter and ESXi Host Communication Issues: Network disruptions, host failures, or vCenter service issues
- Corrupt or Missing VM Configuration Files: .vmx and .vmdk files may become corrupted or deleted
- Datastore Inaccessibility: Storage failures, disconnected datastores, or insufficient space
- Permissions Issues: vCenter or ESXi lacking sufficient permissions to access VM files
- Host Disconnections: ESXi host goes offline, crashes, or enters maintenance mode
The Recovery Path at a Glance
Work the problem from the outside in — restore access first, reload second, re-register last. Jumping straight to re-registration before the datastore is back can leave you chasing a problem that fixes itself once storage returns.
Symptom → Cause → Fix
Match what vCenter is showing you to the underlying cause before you touch anything. Most "invalid" tickets are solved by the first two rows.
| Symptom in vCenter | Most likely cause | Fix |
|---|---|---|
| VM greyed out, labeled (invalid) | vCenter can't read the .vmx — datastore inaccessible or host disconnected | Reconnect host / remount datastore, then reload the VM |
| VM labeled (orphaned) | vCenter database and ESXi host disagree (often after a host crash or HA failover) | Remove from inventory (keep files), then re-register the .vmx |
| Every VM on one host goes invalid at once | The ESXi host disconnected from vCenter | Right-click host → Connection → Connect; check management network |
| VMs went invalid after a storage outage | Datastore was unmounted or hit all-paths-down (APD) | Remount the datastore, restart storage services, reload the VMs |
| VM stays invalid after the host reconnects | Stale VM state cached in host memory | vim-cmd vmsvc/reload <vmid> on the ESXi host |
"Register VM" fails or .vmx is missing | .vmx corrupt or deleted | Restore from backup, or recreate the VM and attach the existing .vmdk |
Step-by-Step Troubleshooting
Option 1: Reload the VM
If the VM appears in the ESXi inventory but is invalid, try reloading it:
ssh root@<ESXi_host_IP>
vim-cmd vmsvc/getallvms
vim-cmd vmsvc/reload <VM_ID>
vim-cmd vmsvc/getallvms lists every registered VM with its numeric Vmid in the first column; use that number as <VM_ID>. The reload is non-destructive — it simply forces the host to re-read the .vmx from the datastore — so it's always safe to try first once the host and datastore are reachable.
Option 2: Remove and Re-Register VM
- In vSphere Web Client, right-click the invalid VM and select "Remove from Inventory"
- Browse to the datastore and locate the VM folder
- Find the .vmx file and right-click to select "Register VM"
- Once registered, try powering on the VM
Important: When removing from inventory, do NOT delete the files. Only remove the registration. Choosing "Delete from Disk" here permanently erases the .vmx and .vmdk — the exact opposite of what you want. This same remove-then-re-register procedure is the standard fix for orphaned VMs, where vCenter and the host disagree about the VM.
Option 3: Reconnect a Disconnected Host
If an entire host's VMs are invalid at once, the host — not the VMs — is the problem. In the vSphere Client, right-click the ESXi host, choose Connection → Connect, and confirm the management network and vpxa/hostd agents are healthy. Once the host reconnects, its VMs usually return to normal on their own; reload any stragglers with Option 1.
Fixing Storage and Datastore Issues
If the VM's storage is inaccessible, vCenter cannot read the VMX file. Here's how to resolve storage-related issues:
Check Datastore Availability
esxcli storage filesystem list
esxcli storage filesystem mount -u <UUID>
esxcli storage filesystem list shows each datastore and whether it's currently mounted. If the one holding your VM is unmounted, remount it with its UUID, then reload the VM.
Restart Storage Services
/etc/init.d/lwiod restart
/etc/init.d/nfs restart
Restart the NFS service only if your affected datastore is NFS-backed. After storage is healthy again, return to Option 1 and reload the VM before trying anything more invasive.
Prevention Best Practices
- Monitor logs regularly: Use vRealize Log Insight or Splunk for log aggregation and early warning alerts
- Ensure datastore redundancy: Use multipath storage configurations and implement storage redundancy
- Automate VM backups: Regular backups of VM metadata using Veeam, VDP, or enterprise backup solutions
- Keep systems updated: Regular updates for vCenter and ESXi with proper testing environments
- Implement proper VM management: Avoid force power-offs and use Storage vMotion for migrations
Because most invalid and orphaned VMs are downstream of storage or host instability, prevention is really a high-availability and disaster-recovery exercise: redundant paths so a datastore never simply disappears, and tested backups so a corrupt .vmx is a five-minute restore instead of a rebuild.
Pro Tip: If issues persist, contact VMware Support with log files for deeper analysis. Always test solutions in non-production environments first.