Boot from SAN LUN was erroneously attached to ESXi host in a cluster.
search cancel

Boot from SAN LUN was erroneously attached to ESXi host in a cluster.

book

Article ID: 402818

calendar_today

Updated On:

Products

VMware vSphere ESXi

Issue/Introduction

After a boot from SAN LUN is erroneously mounted on an existing ESXi host, the OSDATA file system is mounted and any attempts to detach the LUN will fail with the following error: "The resource '<vml id>' is in use". 

 

If you list the vmfs volumes on the affected host, you see two OSDATA directories, where only one should exist on a correct configuration. See ESXi System Storage Overview for more details

 

Environment

ESXi 8.x

Cause

The OSDATA directory is a partition on an ESXi boot drive which consists of persistent and non-persistent storage volumes. Once the erroneous volume is mounted, possibly through a host reboot after LUN attached, the mounted file system holds a lock on the mistakenly attached LUN. Since the file system is actively mounted, the LUN cannot be detached because it is in use. 

 

 

 

Resolution

Identify the erroneous OSDATA partition

  1. First identify the LUN naa. number for the erroneously attached boot LUN. See Identifying disks when working with VMware ESXi for additional details.
  2. Once you've confirmed the incorrect LUN naa., now identify the full path of the incorrect OSDATA volume.

 

    1. Open an SSH session to ESXi using the root account
    2. List file system paths

[root@esxi:~] esxcli storage filesystem list


Mount Point                                                                         Volume Name                                                           UUID                                
--------------------------------------------------------------------------   ------------------------------------------                                ----------------------------------- 
/vmfs/volumes/68430746-a8b7293c-0cb9-xxxxxxxxxxxx   OSDATA-68430746-a8b7293c-0cb9-xxxxxxxxxxxx  68430746-a8b7293c-0cb9-xxxxxxxxxxxx 
/vmfs/volumes/6844e8c6-89ca1ae8-d7b3-xxxxxxxxxxxx   OSDATA-6844e8c6-89ca1ae8-d7b3-xxxxxxxxxxxx  6844e8c6-89ca1ae8-d7b3-xxxxxxxxxxxx 

 

     3.Run vmkfstools on the full path of the OSDATA volumes. Run on both OSDATA paths to match the highlighted naa with the incorrect LUN. Note the path of the incorrect OSDATA volume once identified.

         [root@esxi:~] vmkfstools -Ph -v 10 /vmfs/volumes/OSDATA-6844e8c6-89ca1ae8-d7b3-xxxxxxxxxxxx

VMFS-5.61 (Raw Kajor Version: 14) file system spanning 3 partitions.
File system label (if any) : OSDATA-6844e8c6-89ca1ae8-d7b3-xxxxxxxxxxxx
Mode: public ATS-only
apacity 24 TB, 9 MB available, file block size 1 MB, max supported file size 62.9 TB
Volume Creation Time: Thu Jan 16 09:48:54 2020
Files [max/free) : 130000/129809
Per Blocks (max/free) : 64512/39881
Bub Blocks (max/free) : 32000/31974
econdary Ptr Blocks [max/free) : 256/256
File Blocks (overcommit/used/overcommit 4) : 0/25165047/0
(overcomit/used/overcommit $) : 0/24631/0
(overcomit/used/overcommit 4) : 0/26/0
Volume Metadata size: 932544512
Diak Block Size: 512/512/0
JUID: 6844e8c6-89ca1ae8-d7b3-xxxxxxxxxxxx 
Partitions spanned (on "lvm") :
naa. ################################:1
Unable to connect to vaai-nasd socket [No such file or directory]
s Native Snapshot Capable: NO
OBJLIB-LIB: Objlib cleanup done.
WORKER: asyncOps=0 maxActiveOps=O maxPending=O maxCompleted=O

     3. Unmount the incorrect OSDATA volume using the full path of the OSDATA volume identified in the previous step

[root@esxi:~] esxcli storage filesystem unmount -p  /vmfs/volumes/OSDATA-6844e8c6-89ca1ae8-d7b3-xxxxxxxxxxxx

     4. Detach the erroneous LUN using the vCenter web client. See Detach a LUN device from ESXi hosts for additional information and troubleshooting steps.

Powered by Wolken Software