The storage provisioned to the VMware vSphere environment is one area that I frequently clean up. It can be easy targets (such as powered off virtual machines that haven't been used in a long time), or it can be less obvious things (such as a copy of a single VMDK file that wasn't attached to an inventoried virtual machine).
One area that takes a little more work to clean up is VMware vStorage Virtual Machine File System (VMFS) version assignments on a datastore. Each version of vSphere Hypervisor (ESXi) will have a default format version for a VMFS datastore. The current releases of vSphere 4.1 format datastores at VMFS 3.46; the base release of vSphere 4 formatted at 3.33; Virtual Infrastructure 3 formatted at version 3.31 for ESXi 3.5; and ESX 3.0 systems formatted at 3.21.
VMFS is very unique in that it is backwards and forwards compatible. This means a Logical Unit Number (LUN) that has a 3.33 format can interact fine with a datastore that is running at 3.46. (VMware outlines that VMFS 3 datastores are compatible bi-directionally in KB 1005325.)
I take a slightly different approach to maintaining version readiness with VMFS 3 volumes. In a number of situations, I have evacuated the datastore and reformatted it upwards to a newer version of VMFS, such as the current 3.46. To be fair, I've poked around to all of my contacts at VMware maintain that it doesn't officially need to be formatted to the newest version.
I dug a little deeper, and I got confirmation that there is a benefit to reformatting VMFS 3 volumes upward to 3.46. The difference is in how a VMFS 3.46 volume lays out data structures. Basically, VMFS 3.46 will be better aligned to most disk array caching mechanisms by a dynamic resource distribution based on the size of the device. This difference is academic at best, but nonetheless, it is a difference that may be worth the time to upgrade a volume.
Further, if a VMFS volume is evacuated, it requires ensuring it is emptied out completely, and there are no un-inventoried virtual machines or other rogue files on the volume. Storage vMotion makes this task pretty straightforward. If you have the spare storage space and can absorb the extra I/O burden to clear out a datastore for a reformat task, it may be worth considering.
While there is no feature yet that requires a certain version for a VMFS volume to function correctly, if the situation arises, this process will be quite familiar.
What is your take on upgrading VMFS volumes? Share your comments in the discussion.
Rick Vanover is a software strategy specialist for Veeam Software, based in Columbus, Ohio. Rick has years of IT experience and focuses on virtualization, Windows-based server administration, and system hardware.