Rebuilding VMFS without an extent

Answer

The following procedure can be used to rebuild a VMFS using only the original storage volume. For the purpose of this example, we will assume that a VMFS datastore was created as "storage1" on /dev/sda3 partition (50G) on the boot disk of ESX system. After this, a 100G partition was added to the VMFS as an extent from a SAN LUN (vmhba1:0:0:1).

We will also assume that the VMs on the VMFS do not have any snapshots in place.

This procedure will be outlined both with and without the use of VirtualCenter.

1. Create a new storage volume (which will be temporary) from your SAN or internal disks. This should be large enough to hold all current VMs residing on VMFS "storage1".
2. Create a new VMFS datastore (which will be temporary) called "VMFStemp"
3. Power off all VMs that reside on the VMFS "storage1"
4. Move all VMs to the new storage location
1. Using VirtualCenter
1. right-click on each VM in the inventory, and choose "migrate"
2. follow the wizard, and choose to keep the VM on the same ESX server
3. When prompted if you wish to keep the VM on the same storage, choose to move the VM to different storage, and specify the "VMFStemp" datastore as the target
2. Without using VirtualCenter
1. Open a root user Service Console session to the ESX host (using ssh protocol with something like Putty)
2. Change Directory to /vmfs/volumes/storage1
3. Execute : "for d in *;do;mkdir /vmfs/volumes/VMFStemp/$d;done"
4. Execute : "for d in *;do;cp $d/* /vmfs/volumes/VMFStemp/$d;done" {this will take a LONG time, do not interrupt it}
5. Execute : "for vmx in */*.vmx;do;vmware-cmd -s unregister /vmfs/volumes/${vmx};done"
6. Change Directory to /vmfs/volumes/VMFStemp
7. Check all .vmx and .vmdk (not -flat.vmdk) files in the VM directories for absolute pathnames
• This can be done by changing into each directory, and performing "less <file>" where <file> is the filename you which to search. If we find any pathname in the file that include the prefix of "/vmfs/volumes", then these need to be adjusted to the new pathname for the same file. If this file is in the same directory as the vmx or vmdk file, it can be reduced to a simple filename without the full pathname.
• If the absolute pathname found is related to the sched.swap.derivedName parameter, it may be ignored.
8. Execute : "for vmx in */*.vmx;do;vmware-cmd -s register /vmfs/volumes/${vmx};done"
5. You should now see all your VMs running from their new storage location. At this point you may power them on and back off to ensure they are still operational. This is a recommended precaution as the next step will destroy the original VMFS and the original copies of the virtual disks and config files.
6. Using VI Client (connected to either VirtualCenter or ESX host) highlight the ESX host on the left, and choose the Configuration Tab on the right.
7. Open the "Storage" view (not Storage Adapters)
8. Highlight the "storage1" VMFS datastore, and click on the Remove link at the top of that box
1. If this fails, you may remove this manually
1. Remove the mapping of the "extent" LUN from the ESX host and Rescan from the Storage Adapter view.
2. Execute "dd if=/dev/zero of=/dev/sda3 count=32 bs=1M" from the Service console session to eliminate the VMFS signature on the partition
3. Execute "vmkfstools -V" to reread VMFS information
4. At this point, a Refresh on the Storage view in VI Client should no longer show "storage1"
9. Now recreate "storage1" on the sda3 partition by clicking on "add storage" link and following the wizard.
10. Once "storage1" is recreated, follow step #4 to move all the VMs from VMFStemp storage to storage1 instead of from storage1 to VMFStemp
11. After this is complete, you can Remove the VMFStemp datastore and return both the 100G extent LUN and the storage volume used for VMFStemp to other uses.