Portal Home > Knowledgebase > VMware Knowledge Base > After an ESX/ESXi installation, upgrade, or reinstall, SAN LUNs are damaged

After an ESX/ESXi installation, upgrade, or reinstall, SAN LUNs are damaged


  • After completing an ESX/ESXi installation, reinstall, or upgrade you are unable to see or attach to LUNs.
  • LUN is showing that it contains Linux style partitions.
  • This issue occur after you successfully completed an install with HP Rapid Deployment Pack (RDP)
  • This issue occur after you successfully completed an installation, upgrade, or reinstall with your SAN attached.


This issue can occur during the installation of ESX/ESXi when a Storage Area Network (SAN) is attached.  A LUN can be chosen unintentionally instead of the local disk.  The LUN can be damaged when the ESX/ESXi installation writes to your SAN.
During the ESX/ESXi installation process the installer may identify a SAN LUN as /dev/sda if the PCI device numbering has an HBA as a lower number than the local SCSI. 
This can also occur when using the Rapid Deployment Pack from HP to install an ESX/ESXi host. The Rapid Deployment Pack software from HP automates the deploying and provisioning of server software and system BIOS utilities.  Rapid Deployment Pack does its initial configuration using a LinuxPE image instead of DOSPE image.
When updating the system BIOS and array configuration, the Rapid Deployment Pack installation sends a GRUB.IMG to the first disk (/dev/sda) so that it can boot from the local disk to do the operating system installation. This LinuxPE image includes QLogic and Emulex fiber channel drivers which can mean that /dev/sda is discovered on the SAN storage instead of on local storage. In this case the GRUB.IMG is placed on the SAN disk rather than the local disk, thus overwriting the VMFS filesystem resident on /dev/sda of the SAN.
Note: No data recovery is possible if the LUN has been overwritten by an installation of ESX/ESXi.
The LVM header for the LUN is overwritten and you need to restore from backup. For running virtual machines you may be able to use Converter to hot migrate the virtual machine to a different datastore, but this does not always work, it's dependant on where the vmdk file is on the LUN.
To confirm that your LUN has been overwritten by the installer, you can take a 31 MB dump of /dev/sda on the SAN disk and skip the first 32256 bytes. If you then mount this dump using the loop device you can see the contents of a Linux /boot directory.
If you run fdisk on your LUN you also see the partitions created by the installer.
A typical installation creates the following partitions:
Disk /dev/sda: 73.2 GB, 73274490880 bytes
255 heads, 63 sectors/track, 8908 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
   Device Boot    Start       End    Blocks   Id  System
/dev/sda1   *         1        13    104391   83  Linux
/dev/sda2            14      1926  15366172+  83  Linux
/dev/sda3          1927      5113  25599577+  83  Linux
/dev/sda4          5114      8908  30483337+   f  Win95 Ext'd (LBA)
/dev/sda5          5114      6133   8193118+  83  Linux
/dev/sda6          6134      6388   2048256   82  Linux swap
/dev/sda7          6389      8895  20137446   fb  Unknown
/dev/sda8          8896      8908    104391   fc  Unknown 
Normally your LUN only consists of a VMFS partition which is indicated by the ID type 'fb'.
Note: Always detach your SAN prior to any installation, upgrade, or reinstall of an ESX/ESXi host.
Alternatively, you can unpresent the LUNs from the ESX/ESXi host until after the installation, upgrade, or reinstall is completed. This is a more complicated solution that only makes sense if physical access to the server is not possible.

Based on VMware KB 1003881

Also Read