A virtual machine missing from vCenter may still be running on an ESXi host. Its files may still be intact on a datastore. Or the inventory symptom may be the visible edge of a storage, configuration or snapshot failure.

Do not begin with “register the VM again.” First determine which layer lost the truth.

Classify the failure

vCenter inventory problem

The VM appears in the ESXi Host Client or the host’s inventory but not in vCenter. The host and datastore may be healthy while management state is out of sync.

Host inventory problem

The files exist on an accessible datastore, but neither vCenter nor the intended host has the VM registered.

Configuration problem

The VM folder exists, but the .vmx is missing, corrupt or points to unavailable devices or disks.

Disk or snapshot-chain problem

Configuration exists, but a disk descriptor, base extent or snapshot delta is missing, inaccessible or inconsistent. This is a data-recovery problem, not an inventory refresh.

Datastore or host failure

The storage is unavailable or the host cannot access it. Repairing inventory cannot recover data the host cannot safely read.

Guest or application failure

The VM powers on, but the guest OS or application is unhealthy. “Powered on” is only a hypervisor state.

Preserve the evidence before mutation

Record:

  • vCenter, ESXi and cluster/host relationship;
  • VM name, managed-object identity and UUID where known;
  • registered host and power state from each management surface;
  • datastore and full VM folder path;
  • .vmx, NVRAM, log and virtual disk descriptor files;
  • base and snapshot/delta relationships;
  • virtual hardware version, firmware and devices;
  • network/distributed-switch and port-group dependencies;
  • encryption/key-provider dependencies;
  • last successful backup and recovery point; and
  • last known workload state.

Take a protected listing or vendor-supported copy of metadata where appropriate. Do not rename or edit files to make the folder look tidy. Sparse, flat, delta and descriptor files play different roles despite similar names.

Establish the inventory authority

If vCenter manages the ESXi host, use vCenter as the normal registration authority. Broadcom warns that registering directly on a managed host can create an inventory mismatch. A VM should be registered on only one ESXi host at a time.

Before registering anything, search vCenter and the relevant hosts by path, UUID and VM identity—not only display name. A stale or inaccessible object may already own the same configuration.

Do not unregister a live or ambiguous VM merely because another console does not show it. Confirm its power and ownership state on the host.

Validate the surviving files

A normal VM folder commonly contains configuration, logs, virtual-disk descriptors and their data extents, plus snapshot-related files when snapshots exist. Exact contents vary by version and features.

Verify:

  • the .vmx is readable and identifies the expected VM;
  • every configured disk descriptor exists;
  • each descriptor’s backing extent or parent relationship is present;
  • the datastore has enough free capacity for expected operations;
  • no backup, migration or consolidation task still owns the files; and
  • logs do not show an unresolved storage or syntax failure.

If a VM points to a snapshot/delta disk, do not redirect it to the base disk just because the base exists. The delta can contain the newest writes. Do not delete snapshot files or interrupt consolidation.

Choose the recovery path

Reconcile vCenter and host state

When the VM is healthy on the host but missing only from vCenter, follow Broadcom’s current inventory-synchronisation procedure for the exact vCenter/ESXi version. Protect running workloads and distributed-switch dependencies before reconnecting or removing a host.

Register the surviving configuration

When a valid .vmx and complete disk chain exist but the VM is absent from inventory, register it through vCenter on the intended host. Registration references the existing files; it is not a restore and does not create an independent copy.

Restore from backup

Use the backup product’s supported workflow when configuration or disk data is missing, inconsistent or the required recovery point is earlier. Record whether the restore preserves or creates VM identity and how networks are handled.

Reconstruct only from known-good disks

If only virtual disks survive, create a new VM shell only when generation/firmware, controllers, boot disk, network and application dependencies are known. This is a new configuration around recovered data, not the original VM magically reappearing.

Escalate the disk chain

If descriptors, deltas or snapshot state disagree, stop. Gather the .vmx, descriptors, file listing and logs for Broadcom or the storage/backup vendor. Generic internet commands can write the wrong point in the chain.

Decide whether it was moved or copied

VMware may ask whether the VM was moved or copied when its location changes.

  • Moved: the original instance changed location and should normally retain its UUID.
  • Copied: another instance now exists or may exist, so the copy should receive a new VMware UUID.

That choice addresses VMware-level identity only. A copied guest can still duplicate its hostname, IP address, domain identity, database instance, licence, monitoring identity or scheduled tasks. Keep it isolated until those are resolved.

If you cannot prove which happened, treat the VM as a copy and protect production from duplicate identity while the owner decides.

First boot belongs off the production network

Disconnect the virtual NIC or attach the recovered VM to an isolated port group before first boot when a duplicate or stale workload could exist. This is particularly important for directory services, DHCP/DNS, mail, databases, backup servers and applications that send notifications or process queued work.

During isolated boot, confirm:

  • the intended OS and disks appear;
  • filesystem and application recovery completes without unexplained errors;
  • time and identity match the recovery decision;
  • services and scheduled tasks do not create external side effects;
  • virtual hardware and VMware Tools state are understood; and
  • the workload owner’s data checks match the selected recovery point.

A console login is not acceptance.

Reconcile virtual hardware and networks

Compare the recovered VM against its design:

  • CPU and memory;
  • firmware, Secure Boot and virtual TPM/encryption;
  • storage controllers and every virtual disk;
  • NIC type, MAC policy, port group and VLAN;
  • distributed-switch availability;
  • removable ISO/device attachments;
  • VMware Tools and guest compatibility; and
  • autostart, affinity, HA/DRS or backup tags/policies.

Do not upgrade virtual hardware or Tools during the first recovery boot unless the recovery specifically requires it. Each extra change makes rollback and root-cause analysis harder.

Verify production readiness

Platform

The VM is registered once, on the intended host/cluster, and vCenter and the host agree on its state. Storage and snapshot/consolidation status are clean.

Guest

The expected OS boots, time and disks are correct, device/driver state is understood, and critical events are reviewed.

Network and identity

The VM joins only the intended port group, duplicate identity is eliminated, DNS/routes are correct and management access follows policy.

Application and data

The application owner validates the recovery point, service function, authentication, data integrity and integrations. Outbound jobs remain controlled until approved.

Protection

Monitoring and backup recognise the recovered identity, a new backup completes, snapshot cleanup behaves normally and the restore procedure is updated.

Cut over and retire ambiguity

Power off or permanently isolate any conflicting original. Connect the recovered guest during an approved window, watch platform and application evidence, and retain the source backup/files for the agreed rollback period.

Document the exact recovery source, registration or restore path, move/copy choice, identity changes, isolated checks, application approval and retirement decision. Guest recovery is complete only when inventory, files, identity, application and protection all describe the same reality.