Skip to content

Posts tagged ‘san’


Installing ESXi 4.1 with Boot from SAN

We’ve been running ESX since the days of v2.5, but with the news that v4.1 will be the last “fat” version with a RedHat service console, we decided it was time to transition to ESXi. The 30+ step guide below describes our process using an EMC CLARiiON CX3 SAN and Dell hosts with redundant Qlogic HBAs (fiber environment).

  1. Document network/port mappings in vSphere Client on existing ESX server
  2. Put host into maintenance mode
  3. Shutdown host
  4. Remove host from Storage Group in EMC Navisphere
  5. Create dedicated Storage Group per host for the boot LUN in Navisphere
  6. Create the 5GB boot LUN for the host
  7. Add the boot LUN to the host’s Storage Group
  8. Connect to the host console via the Dell Remote Access Card (DRAC)
  9. Attach ESXi media via DRAC virtual media
  10. Power on host (physically or via the DRAC) Read moreRead more

Virtual Center 2.x incorrectly sizes disks during migration

VMs that were formerly RDMs (Raw Device Mappings) and which have had one or more disks grown via LUN migrations in EMC Navisphere (or similar functions in another vendor’s SAN tool) may fail to create the appropriately-sized disks on the target SAN during a storage migration. This is due to the fact that the RDM mapping file on the source SAN never updated to reflect the size of the previously grown LUN (via LUN migration). VMware Virtual Center uses that mapping file to create new VMDK files on the target.  Thus, if the mapping file is not updated to reflect the proper size, Virtual Center will create a smaller file on the target, possible resulting in loss of data or program integrity.

Example: server1 originally had a 30GB C:\ prior to a rebuild. When it was rebuilt, the same LUNs were used. However, due to a larger RAM allocation (i.e. 8GB instead of 4GB), the C:\ drive needed to be expanded. LUN migration in EMC Navisphere was used to accomplish this. However, the mapping file (the pointer .vmdk file) never changed to the new size. When the migration took place, Virtual Center only created a 30GB virtual disk on the target SAN. Windows booted thinking it had a 50GB disk (the expanded size). The result was that applications (i.e. SQL Server) and possibly other components failed to function after migration.

The solution is to delete and re-add the RDMs of any grown VMs before migration to ensure that the right size is used on the target.

Applies to: VMware ESX 3.x, Virtual Center 2.x