Everyday Virtualization

VMFS Volume Extents Decision Factors

Planning your storage architecture in a VMware environment is one of the most critical design elements. Even more critical: sizing of VMFS datastores.

• By Rick Vanover
• 04/26/2010

The VMFS answer is to use a volume extent. This process, which is permitted up to 32 times per VMFS datastore, can extend the 2 TB limit (minus 512 bytes) to 64 TB. I'll explain both sides of the coin followed by a recommendation on how you can go about determining if a volume extent is the right step for your environment.

Using Extents To Minimize Free Space Inventories
In situations where you have uniform tiers of storage in terms of disk performance, size and storage protocol; it may make sense to use VMFS volume extents to present all of the storage to your VI3 or vSphere environment as one aggregated volume. This makes administration simple, as you do not have to monitor the free space inventories of multiple volumes. Further, you can group a drive shelf of like storage together. Many disk shelves or trays will now exceed 2TB, even with high-performance RAID algorithms. In this situation, it may be more administrative-friendly to have one VMFS datastore at 3.81 TB instead of one at 2 TB and another 1.81 TB.

Extents naturally work for the virtual machine with gigantic storage requirements. All of the VMDK files for that volume can be contained in the VMFS volume with the extents. It is important in this situation, however, to perform extents only across like-performing shared storage targets. Simply aggregating dissimilar storage to present a larger, single volume is a recipe for disaster.

Forgo Using Extents in Favor of Right-Sized VMDK Files
The other side of the coin is to not use VMFS volume extents. Instead, use VMDK files across the different datastores in a right-sized fashion. This eliminates the burden of multiple free-space inventories across multiple volumes if they are fixed-sized and not expected to grow. The downside of this is that the overall number of shared storage targets may increase, making the storage provisioning process marginally more difficult.

Use Extents Wisely
Should you decide to perform a VMFS volume extent, do so carefully. It is an easy step, yet easy enough to do it incorrectly also. For example, you can perform a VMFS extent on local storage to shared storage. This is clearly a situation that rarely makes good sense, but the vSphere Client will not warn or prohibit you from making this configuration.

To perform an extent, select a VMFS volume in the host's configuration tab, storage section area. To start the extent process, right-click on a volume and select the increase button (See Fig. 1).

Figure 1. The increase button is available to extend a current datastore to a new storage target accessible to the host.(Click image to view larger version.)

Tip: If you are consolidating shared storage volumes from older ESX or ESXi installations, it may be a good time to get the VMFS volume up-to-date. Current vSphere installations format volumes at 3.33. If your volume is at a lower version of VMFS, it maybe worth re-formatting it now before it becomes too big to evacuate and reformat later. Though VMFS is backwards and forward compatible, it is a good idea to stay current. Read this earlier blog post for version information.

Once you assign the extent to the VMFS volume, you are locked into it. The target that was added cannot be removed without destructive action to the volume.

Impact of Using VMFS Extents
While it may seem that extents make administering the storage allocated to a vSphere or VI3 environment simpler, there may be an impact to disk performance. It is worth doing some benchmarking and circling back to any best practices for your storage platform to see if there is a sweet spot that makes datastore extents work for your environment.

How do you go about extents? Share your comment here.