HI Subhajit,
Yeah you are correct the link that I posted does "seem" to have no relationship to what I did. It was only part of the solution this is what I had to do to solve the problem. This is exactly what I had to do:
0. Increase the volume size on the MSA using the SMU
Now logon to the ESXi host and issue the following commands (only have to do on one esxi host in the vmware cluster) :
1.partedUtil fixGpt "/vmfs/devices/disks/naa.600c0ff00029475d0e5a605b01000000"
2.partedUtil getUsableSectors /vmfs/devices/disks/naa.600c0ff00029475d0e5a605b01000000
Make a note of the large number
3./etc/init.d/storageRM stop
Stops the storage monitor (has no affect on the running esxi system)
4. run this command
offset="128 2048"; for dev in `esxcfg-scsidevs -l | grep "Console Device:" | awk {'print $3'}`; do disk=$dev; echo $disk; partedUtil getptbl $disk; { for i in `echo $offset`; do echo "Checking offset found at $i:"; hexdump
-n4 -s $((0x100000+(512*$i))) $disk; hexdump -n4 -s $((0x1300000+(512*$i))) $disk; hexdump -C -n 128 -s $((0x130001d + (512*$i))) $disk; done; } | grep -B 1 -A 5 d00d; echo "---------------------"; done
5. partedUtil setptbl /vmfs/devices/disks/naa.600c0ff00029475d0e5a605b01000000 gpt "1 2048 2539061214 AA31E02A400F11DB9590000C2911D1B8 0"
(based on information ontained from ruinning command 4.)
6. vmkfstools --growfs "/vmfs/devices/disks/naa.600c0ff00029475d0e5a605b01000000:1" "/vmfs/devices/disks/naa.600c0ff00029475d0e5a605b01000000:1"
7. /etc/init.d/storageRM start
(restart the storage monitor)
You are also correct - no down time was required - I was able to do all this with the VM's running on the Datastore.
However the point I'm trying to make is that in a NetApp environment you do not have to extend the VMFS file system - it happens automatically. You extend the volume on the MSA and immediatley VMFS is the correct size. (no need to manually extend)
thanks for taking the time to reply.