VMWare’s VMFS 3 allows adding extents on the fly, and from either a separate LUN on a SAN or from extra space within a LUN that was expanded or migrated to a larger LUN. However, because it is possible doesn’t mean it should be done. There are 2 accepted ways to increase the size of a VMFS though there are at least 4 ways to do it.
How not to expand a VMFS
The absolute worst thing to do would be to create a concatenated metaLUN on the same RAID group and join it to the original LUN used by the VMFS that you need to expand. This creates performance problems on your SAN (as does any concatenated metaLUN on the same disks), and creates a problem with dual partitions on the same LUN.
This problem still exists if you instead migrate the VMFS LUN to a larger LUN, then add an extent in VMWare. We need a way to avoid having two partition tables on the same LUN.
A better (and acceptable) way to expand a VMFS
Instead of migrating to a larger LUN or creating a concatenated metaLUN, there is a better way:
- Create a separate LUN sized just for the additional space needed
- Present this new LUN to the ESX server
- Add this LUN as an extent
This will avoid having a LUN with two partition tables on it, it’s quick, and acceptable to VMWare. But there is an even better way, though it requires more effort unless you have Storage VMotion.
The best way to expand a VMFS LUN.
The preferred method of adding space to a VMFS LUN is not always possible. It requires having enough space to perform.
- Create a new LUN sized as large as you need the final size of the entire VMFS to be.
- Present it to the ESX host.
- Shut down each guest VM then move (clone, then delete) each one from the original LUN over to the new larger LUN.
- - OR -
- Use Storage VMotion to select them all and move them over to the new LUN.
-Mike
(originally published in 2008)





[...] in 2008 I wrote about expanding a VMFS partition on a SAN prior to VSphere. A lot has changed since then, forcing me to write an update. Now VMware [...]