Skip to main content

Device expanded/shrank messages are reported in the VMkernel log for VMFS-5

 


 Symptoms
  • A VMFS-5 datastore is no longer visible in vSphere 5 datastores view.
  • A VMFS-5 datastore is no longer mounted in the vSphere 5 datastores view.
  • In the /var/log/vmkernel.log file, you see an entry similar to:

    .. cpu1:44722)WARNING: LVM: 2884: [naa.6006048c7bc7febbf4db26ae0c3263cb:1] Device shrank (actual size 18424453 blocks, stored size 18424507 blocks)

  • A VMFS-5 datastore is mounted in the vSphere 5 datastores view, but in the /var/log/vmkernel.log file you see an entry similar to:

    .. cpu0:44828)LVM: 2891: [naa.6006048c7bc7febbf4db26ae0c3263cb:1] Device expanded (actual size 18424506 blocks, stored size 18422953 blocks)
 Purpose
This article provides steps to correct the VMFS-5 partition table entry using partedUtil. For more information see Using the partedUtil command line utility on ESX and ESXi (1036609).
 Cause
The device size discrepancy is caused by an incorrect ending sector for the VMFS-5 partition on the device.
 Resolution
Depending on the device condition reported, follow one of these methods for the corresponding condition:

Note: This resolution is applicable only if the device has one VMFS-5 partition.

TSE NoteYou do not need to set or unset /Disk/PreventVMFSOverwrite as part of any of these operations since this protection only applies to where the VMFS filesystem exists, which is 17M into the disk from the start of the fb partition. The changes this KB article recommends applies to the MBR or GPT, which is at the front of the disk and NOT past the 17M point.

Device shrank condition

.... cpu1:44722)WARNING: LVM: 2884: [naa.6006048c7bc7febbf4db26ae0c3263cb:1] Device shrank (actual size 18424453 blocks, stored size 18424507 blocks)
  1. Calculate the number of sectors by which the device shrank. For example:

    18424507 - 18424453 = 54

  2. Connect to the ESXi host console and run this command to extract the present ending sector partition information:

    partedUtil getptbl /vmfs/devices/disks/naa.6006048c7bc7febbf4db26ae0c3263cb

    You see output similar to:

    gpt
    1147 255 63 18432000
    1 2048 18426500 AA31E02A400F11DB9590000C2911D1B8 vmfs 0


  3. Calculate the correct ending sector by adding the result of step 1. For example:

    18426500 + 54 = 18426554

  4. Note: Prior to running the VMFS resize command, please verify that VMFS write protection is disabled. If it is not disabled, please disable it temporarily. Please follow the steps below:

    To verify the current status of the VMFS overwrite protection

    esxcfg-advcfg --get /Disk/PreventVMFSOverwrite

    To disable VMFS overwrite protection, run the command:

    esxcfg-advcfg -s 0 /Disk/PreventVMFSOverwrite

    Once the VMFS overwrite is enabled, you can perform the delete or resize operation as follows:

    partedUtil delete /vmfs/devices/disks/naa.6006048c7bc7febbf4db26ae0c3263cb 1

    Alternatively, you can use this partedUtil resize command:

    partedUtil resize "/vmfs/devices/disks/t10.945445000000000063000000000000000000000000000000" 1 2048 18426554

    For more information, see Using the partedUtil command line utility on ESX and ESXi (1036609).

    To re-enable overwrite protection after resizing the partition table, run the command:

    # esxcfg-advcfg -s 1 /Disk/PreventVMFSOverwrite

  5. Run this command to create a new partition table with starting sector 2048 and the ending sector from step 3:

    partedUtil setptbl /vmfs/devices/disks/naa.6006048c7bc7febbf4db26ae0c3263cb gpt "1 2048 18426554 AA31E02A400F11DB9590000C2911D1B8 0"

    You see output similar to:

    gpt
    0 0 0 0
    1 2048 18426554 AA31E02A400F11DB9590000C2911D1B8 0


  6. Run this command to remount the VMFS:

    vmkfstools -V

Device expanded condition:

.... cpu0:44828)LVM: 2891: [naa.6006048c7bc7febbf4db26ae0c3263cb:1] Device expanded (actual size 18424506 blocks, stored size 18422953 blocks)
  1. Calculate the number of sectors by which the device expanded. For example:

    18424506 - 18422953 = 1553

  2. Connect to the ESXi host console and run this command to extract the present ending sector partition information:

    partedUtil getptbl /vmfs/devices/disks/naa.6006048c7bc7febbf4db26ae0c3263cb

    You see output similar to:

    gpt
    1147 255 63 18432000
    1 2048 18426553 AA31E02A400F11DB9590000C2911D1B8 vmfs 0


  3. Calculate the correct ending sector by subtracting the result of step 1. For example:

    18426553 - 1553 = 18425000

  4. Run partedUtil delete or resize command to delete / resize the partition table:

    Note: Prior to running the VMFS resize command, please verify that VMFS write protection is disabled. If it is not disabled, please disable it temporarily. Please follow the steps below:

    To verify the current status of the VMFS overwrite protection

    esxcfg-advcfg --get /Disk/PreventVMFSOverwrite

    To disable VMFS overwrite protection, run the command:

    esxcfg-advcfg -s 0 /Disk/PreventVMFSOverwrite

    Once the VMFS overwrite is enabled, you can perform the delete or resize operation as follows:

    partedUtil delete /vmfs/devices/disks/naa.6006048c7bc7febbf4db26ae0c3263cb 1

    Alternatively , you can use this partedUtil resize command:

    partedUtil resize "/vmfs/devices/disks/t10.945445000000000063000000000000000000000000000000" 1 2048 18425000

    For more information, see Using the partedUtil command line utility on ESX and ESXi (1036609).

    To re-enable overwrite protection after resizing the partition table, run the command:

    esxcfg-advcfg -s 1 /Disk/PreventVMFSOverwrite

  5. Run this command to create new partition table with starting sector 2048 and the ending sector from step 3:

    partedUtil setptbl /vmfs/devices/disks/naa.6006048c7bc7febbf4db26ae0c3263cb gpt "1 2048 18425000 AA31E02A400F11DB9590000C2911D1B8 0"

    You see output similar to:

    gpt
    0 0 0 0
    1 2048 18425000 AA31E02A400F11DB9590000C2911D1B8 0


  6. Run this command to remount the VMFS:

    vmkfstools -V

Comment
Issue :
we could not increase the Size of the datastore after increasing the Size of the Lun from SAN.
Device was already showing the storage with increased size
while we tried to increase the Size of datastore , it could not detect the device,
Resolution :
Increased the Size of Lun again from Storage
Logged in to the host directly
Able to see the device now to increase the size

Comments

Popular posts from this blog

Integration with vCloud Director failing after NSXT upgrade to 4.1.2.0 certificate expired

  Issue Clarification: after upgrade from 3.1.3 to 4.1.2.0 observed certificate to be expired related to various internal services.   Issue Verification: after Upgrade from 3.1.3 to 4.1.2.0 observed certificate to be expired related to various internal services.   Root Cause Identification: >>we confirmed the issue to be related to the below KB NSX alarms indicating certificates have expired or are expiring (94898)   Root Cause Justification:   There are two main factors that can contribute to this behaviour: NSX Managers have many certificates for internal services. In version NSX 3.2.1, Cluster Boot Manager (CBM) service certificates were incorrectly given a validity period of 825 days instead of 100 years. This was corrected to 100 years in NSX 3.2.3. However any environment originally installed on NSX 3.2.1 will have the internal CBM Corfu certs expire after 825 regardless of upgrade to the fixed version or not. On NSX-T 3.2.x interna...

Calculate how much data can be transferred in 24 hours based on link speed in data center

  In case you are planning for migration via DIA or IPVPN link and as example you have 200Mb stable speed so you could calculate using the below formula. (( 200Mb /8)x60x60x24) /1024/1024 = 2TB /per day In case you have different speed you could replace the 200Mb by any rate to calculate as example below. (( 5 00Mb /8)x60x60x24) /1024/1024 =  5.15TB  /per day So approximate each 100Mb would allow around 1TB per day.