Error: Unresolved VMFS volume with signature detected on ESXi
search cancel

Error: Unresolved VMFS volume with signature detected on ESXi

book

Article ID: 371755

calendar_today

Updated On:

Products

VMware vSphere ESXi

Issue/Introduction

When attempting to mount a datastore to an ESXi host, the volume may fail to mount automatically. This typically occurs during disaster recovery tests, after a ransomware recovery, replacing a local storage controller, or when a snapshot/replica LUN is presented. This mismatch between the LUN's current characteristics (such as NAA ID) and the recorded metadata signature prevents the host from mounting the volume to avoid metadata conflicts. This is critical when the affected datastore contains essential virtual machines, such as a vCenter Server, that must be restored.

Symptoms

  • vCenter Server Down: vCenter VM may appear as "Inaccessible" or be lost because its primary storage is unavailable.
  • Mount Error: When trying to mount a datastore, the following error is encountered: 'An unresolved VMFS volume with signature naa.#### has been detected on disk'.
  • Greyed Options: The options to mount the datastore with 'Assign new signature' or 'Keep existing signature' are greyed out in the vSphere Client. The only available option is to 'Format the disk'.
  • Missing Datastore: The datastore does not appear in the /vmfs/volumes directory during an SSH session.
  • Storage Visibility: The physical storage device appears attached but is not consumed as a datastore.

Validation

Log in to the ESXi host via SSH and run: esxcfg-volume -l

  • Duplicate extents found: Indicates two snapshots of the same datastore are presented to the host. 

    VMFS UUID/label: ##-##-##/####
    Can mount: No (duplicate extents found)
    Can resignature: No (duplicate extents found)
    Extent name: naa.####:1     range: 0 - 4194047 (MB)
    Extent name: naa.##:1     range: 0 - 4194047 (MB)

  • Some extents missing: Indicates the original datastore is a multi-extent volume, and the host requires access to all constituent snapshot LUNs.
  • Snapshot detected: Confirms the LUN contains a replica of an existing VMFS volume UUID, but the NAA ID or LUN ID has changed.

Environment

  • VMware vSphere ESXi 7.x
  • VMware vSphere ESXi 8.x
  • VMware vSphere ESXi 9.x (including 9.1 VVF)
  • Local storage controller replacements
  • Storage Replication/Clones (e.g., NetApp, HP Alletra)

Cause

ESXi detects a signature mismatch or duplicate extents, triggering signature protection.

  1. Controller replacement: Replacing a local storage controller causes the disk to report a new device ID (naa.###, t10.###), triggering snapshot detection.
  2. Storage Replication/Snapshots: Presenting a LUN replica to the same or a different cluster (e.g., during DR testing) without re-signaturing.
  3. Snapshot Sets: Storage arrays presenting multiple LUNs with the same VMFS UUID simultaneously.

Resolution

Resignature and Mount the Volume

  1. If the reason is 'duplicate extents found', engage the storage vendor to ensure only one snapshot LUN is presented or detach duplicates.
  2. List the detected volumes to find the UUID: esxcfg-volume -l
  3. Re-signature the LUN using the following command: esxcli storage vmfs snapshot resignature -u "########-########-####-############"
  4. If the reason is 'some extents missing', validate that the host has access to all constituent snapshot LUNs before attempting to resignature.

Restore Critical Virtual Machines (e.g., vCenter Server)

  1. Rescan storage across the cluster to ensure all hosts see the new signature.
  2. Browse the new datastore, which will be prefixed with snap-XXXX-.
  3. Locate the .vmx file for the vCenter Server or lost VM.
  4. Register the .vmx file to the inventory.
  5. Power on the virtual machine.
  6. (Optional) Rename the datastore back to the original name if the original volume is no longer present.

Additional Information

Powered by Wolken Software