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.