VMware ESXi and vSphere Cluster Management

How to Create a VMFS Datastore in VMware vSphere

Learn how to create and verify a VMFS datastore on local or SAN-presented storage using the VMware vSphere Client.

A VMFS datastore is a vSphere storage container created on a block-storage device or LUN that an ESXi host can discover. This lesson explains how to prepare storage, create the datastore in the vSphere Client, select a compatible VMFS version, and verify the result.

What a VMFS Datastore Provides

VMFS, or VMware Virtual Machine File System, is VMware's clustered filesystem for block devices used by ESXi hosts. A datastore is the vSphere storage container that hosts use for virtual-machine files and other supported content.

Common files stored on a VMFS datastore include:

Virtual disks, such as VMDK files.
Virtual-machine configuration files.
Snapshot and delta-disk files.
Virtual-machine logs.
Templates and other supported virtual-machine files.
ISO images, when the organization stores installation media on the datastore.

A VMFS datastore is created by formatting all or part of a block device. The device may be a local disk, a RAID-backed volume, or a LUN presented from shared storage.

VMFS Storage Backing

VMFS requires block storage. Block storage exposes a device to ESXi as a disk or SCSI device that can be formatted by the host. Common sources include:

Local storage: disks or RAID volumes physically attached to an ESXi host.
Fibre Channel: block LUNs presented through a Fibre Channel storage-area network.
FCoE: Fibre Channel over Ethernet, which transports Fibre Channel storage traffic over Ethernet.
iSCSI: SCSI block-storage commands transported over an IP network.
Supported SAS or SCSI-attached devices: directly attached block devices supported by the ESXi release and hardware configuration.

File-based storage, such as an NFS datastore, is different. NFS presents a remote filesystem rather than a raw block device for ESXi to format as VMFS.

The target device must already be discovered by the ESXi host before it can normally be selected in the datastore wizard. Storage adapters, network connectivity, SAN zoning, LUN masking, array host mappings, and iSCSI or FCoE configuration may all be required before discovery succeeds.

Storage backing options

Backing type	Typical use	Shared across hosts	Key consideration
Local disk or RAID volume	Standalone hosts, labs, or host-local workloads	No, unless separately presented through supported shared storage	Confirm that the device is unused and supported by the host.
Fibre Channel SAN LUN	Production shared datastores	Yes, when consistently presented	Verify zoning, masking, paths, and identical LUN presentation.
FCoE SAN LUN	Converged Ethernet and Fibre Channel environments	Yes, when consistently presented	Verify FCoE adapters, fabric configuration, and array mappings.
iSCSI LUN	IP-based shared block storage	Yes, when consistently presented	Verify VMkernel networking, initiator access, target discovery, and paths.

Plan Before Creating the Datastore

Datastore creation formats the selected space and can destroy existing partitions, filesystems, or data. Treat the device-selection step as destructive.

Confirm that the LUN or local device is dedicated for VMware use.
Verify that it is not already a datastore, partitioned disk, or device used by another operating system or application.
Confirm the expected capacity, vendor, model, canonical identifier, and storage-array identifier.
Check that the host can see the device and that its paths are healthy.
For shared storage, ensure every intended ESXi host has access to the same LUN with consistent LUN presentation.
Choose a descriptive name based on environment, location, workload, storage tier, or purpose. For example, PROD-FC-01-VM is more useful than datastore1.
Reserve enough capacity for virtual disks, snapshots, swap files, templates, migrations, thin-provisioned growth, and maintenance operations.
Follow storage-array and organizational policies for preferred LUN and datastore sizes.

Prerequisites checklist

Requirement	Why it matters	How to validate
ESXi host can discover the device	The datastore wizard can select only available, recognized storage.	Inspect the host storage devices list or run an ESXi storage-device command.
LUN is not already in use	Formatting an existing device can cause data loss.	Check datastore, partition, filesystem, and array ownership records.
Correct storage protocol and connectivity are configured	FC, FCoE, and iSCSI devices require working adapters, fabrics, networks, and targets.	Check adapter state, target connectivity, zoning, masking, and host mappings.
All intended hosts have consistent access	Shared VMFS requires all participating hosts to reach the same device.	Compare identifiers, capacities, and paths on every host.
Adequate capacity is available	Insufficient free space affects snapshots, migrations, growth, and operations.	Compare planned workload growth with usable capacity and policy limits.
VMFS version meets compatibility requirements	The filesystem version affects which hosts can mount the datastore.	Identify the oldest ESXi host that requires access and check release compatibility.

Choose the VMFS Version

The VMFS version affects host compatibility and filesystem capabilities. The installed vSphere and ESXi release, together with the organization's compatibility requirements, should determine the choice.

If hosts older than ESXi 5.0 must mount the datastore, the historical compatibility case may require VMFS 3.
In an all-modern environment, use the VMFS version supported and recommended by the installed ESXi release.
In a mixed-version environment, identify the oldest host that needs access before creating the datastore and validate the compatibility matrix for the deployed release.
Do not select an older format without a specific interoperability requirement. Legacy formats can limit capabilities and complicate future operations.

Environment condition	Selection approach	Compatibility implication
Hosts older than ESXi 5.0 require access	Evaluate VMFS 3 where the deployed versions require it.	Preserves legacy interoperability but retains an older filesystem format.
Only newer hosts require access	Use the current VMFS version offered and recommended by the environment.	Provides compatibility with the newer hosts and their supported capabilities.
Mixed-version environment	Base the decision on the oldest host that must access the datastore.	All participating hosts must support the selected format.
No confirmed version requirement	Pause and document host versions before formatting.	Guessing can create an inaccessible or unnecessarily limited datastore.

Plan Datastore Size

The wizard may allow you to use the entire device or allocate only part of it. Full-device allocation is typical for a dedicated VMFS LUN because it uses the planned storage container without leaving an unmanaged remainder.

Using only part of a device can be appropriate when storage policy requires it or when the remaining capacity will serve another approved purpose. Reserve capacity when you need room for workload expansion, snapshots, Storage vMotion operations, thin-provisioned storage growth, templates, swap files, or maintenance activities.

Do not assume that advertised LUN capacity equals usable datastore capacity. VMFS metadata consumes some space, and the wizard may be configured to allocate only an extent of the device.

Create the VMFS Datastore in the vSphere Client

Select the target ESXi host that can see the intended device, or open the datastore creation action from the storage inventory.
Start the New Datastore workflow.
Choose VMFS as the datastore type.
Choose the host location when the workflow asks where the datastore will be created.
Enter a descriptive datastore name that follows your naming convention.
Select the intended available disk or LUN. Match its canonical or unique identifier, capacity, vendor, model, and array-side identity. Do not select a device based only on similar capacity.
Select the VMFS version offered by the environment and required by the host-compatibility plan.
Choose whether to consume the full device or specify a smaller size when the workflow supports partial allocation.
Review the proposed name, host, VMFS version, backing device, capacity, and formatting action.
Finish the wizard only after confirming that the device is the correct, unused target.

ESXi formats the selected space as VMFS and mounts the new datastore on the selected host. On shared storage, creation from one host does not by itself guarantee that every other host can access the datastore; their LUN presentation and discovery must also be verified.

Example: shared Fibre Channel storage

A storage administrator presents a new 2 TB Fibre Channel LUN to two ESXi hosts. The vSphere administrator rescans storage on both hosts, confirms that both show the same device identifier and capacity, and creates one VMFS datastore from a host that can see the LUN. Before placing workloads on it, the administrator verifies that the resulting datastore is mounted and accessible from both hosts.

Example: local ESXi storage

A standalone lab host has an unused RAID-backed local volume. The administrator selects the local device, uses its full capacity, and creates the VMFS datastore. The datastore is mounted only on that host; local VMFS storage is not automatically shared with other ESXi hosts.

Verify the Datastore After Provisioning

Use the vSphere Client to confirm that the datastore appears in the Datastores inventory and in the selected host's storage view. Check the following:

The datastore name follows the intended naming convention.
Capacity and free space match the allocation plan.
The VMFS type or version is correct.
The backing device is the intended LUN or local disk.
Every intended host can see and mount a shared datastore.
Storage paths are redundant and healthy where multipathing is expected.
No unexpected storage alarms are present.
Optional: browse the datastore or place an approved test file or test virtual machine on it.

Check	Expected result	If unsuccessful
Datastore is listed	The datastore appears in inventory and the host storage view.	Check the task result, host visibility, and storage rescan status.
Capacity is correct	Reported capacity and free space match the selected allocation, less filesystem overhead.	Check whether partial allocation was selected and confirm the backing device.
Backing device is correct	The datastore identifies the intended LUN or local device.	Stop workload placement and compare canonical and array identifiers.
Expected hosts can mount it	All intended shared-storage hosts list the datastore and can access it.	Compare LUN presentation, rescans, identifiers, and paths across hosts.
Paths are healthy	Expected paths are active and no path or connectivity alarms appear.	Inspect adapters, fabric or network connectivity, array mappings, and multipathing.

Optional ESXi CLI verification

When appropriate permissions and access are available, these commands provide additional verification. Output and command availability can vary by ESXi release.

esxcli storage core device list
esxcli storage filesystem list
esxcli storage core path list

esxcli storage core device list displays discovered storage devices and identifying information.
esxcli storage filesystem list displays mounted filesystems and datastore mount information.
esxcli storage core path list displays storage paths and their states.

Operational Considerations

A shared VMFS datastore allows multiple ESXi hosts to access the same storage under VMware coordination. However, shared datastore availability alone does not configure vMotion, HA, DRS, multipathing, or application clustering. Each of those features has additional configuration and compatibility requirements.

Rescan the relevant ESXi storage adapters after presenting a new LUN or changing storage connectivity.
Use the appropriate multipathing policy for the storage array and environment. Multipathing means using multiple physical paths between a host and a storage device for availability and, depending on policy, load distribution.
Monitor datastore free space, virtual-disk growth, and snapshot growth regularly.
Before removing a datastore, evacuate or remove dependent virtual machines, snapshots, templates, ISO files, swap files, and other contents. Datastore removal is a decommissioning operation, not a routine cleanup action.

Troubleshooting

The expected LUN does not appear in the wizard

Rescan the relevant host storage adapters.
Verify that the device appears in the host's storage-devices list.
Check SAN zoning, LUN masking, array host mappings, and network or fabric connectivity.
Confirm that the correct ESXi initiator or host object has access to the LUN.
Check whether the storage adapter is available and correctly configured.

The device is visible but cannot be selected

It may already contain a datastore, partition table, filesystem signature, or other recognized data.
It may be claimed by another feature or already be in use.
Your account may lack the required host or datastore privileges.
Inspect device and datastore usage before changing anything. Do not overwrite an unknown or production device; validate ownership with the storage team.

The datastore is visible to only one host

Determine whether the backing device is intentionally local.
For shared storage, compare device identifiers, capacities, and path status across hosts.
Rescan affected hosts.
Correct zoning, masking, iSCSI access, FCoE configuration, or array mappings so every intended host sees the same LUN.

An incompatible VMFS version was selected

Document the ESXi versions of all hosts that require access.
Identify the oldest required host and validate the VMFS compatibility matrix for the deployed vSphere release.
If the selected format cannot meet the requirements, plan migration to a correctly formatted datastore. Do not make unverified destructive changes to an existing datastore.

Datastore capacity is lower than the advertised LUN capacity

Check whether only part of the device was allocated.
Allow for VMFS filesystem metadata.
Compare the datastore backing device and configured extent with the intended LUN.
Verify identifiers and capacity values before expanding or recreating storage.

Exam-Relevant Notes

VMFS is a clustered filesystem for ESXi hosts and block devices.
A LUN must be discovered by ESXi before it can normally be selected for VMFS creation.
Local VMFS storage is normally host-local; a shared SAN LUN can be mounted by multiple hosts when consistently presented.
Formatting or reclaiming a device can destroy existing data.
VMFS version selection must account for the oldest host that requires access.
A datastore being visible does not prove that all expected paths are healthy or that vMotion, HA, DRS, or clustering is configured.

For related guidance, see VMFS datastore creation.