VMware ESXi and vSphere Cluster Management
Create a VMFS Datastore on a VMware ESXi Host
Learn how to safely create, format, and verify a VMFS datastore on VMware ESXi using the vSphere Client, including LUN planning, compatibility, multipathing, and troubleshooting.
A VMFS datastore is a logical storage container that an ESXi host uses for virtual machine files. This lesson explains how to prepare block storage, create a VMFS datastore in the vSphere Client, verify it, and troubleshoot common storage-discovery problems.
The workflow is destructive: formatting the selected device can overwrite its partition information, filesystem, and existing data. Confirm the storage identity before completing the wizard, especially in production.
What a VMFS Datastore Is
VMFS means VMware Virtual Machine File System. It is a clustered filesystem designed for ESXi hosts. Multiple ESXi hosts can mount the same shared VMFS datastore when the underlying storage is presented consistently and every host supports the VMFS version.
A datastore is not the same thing as the physical storage behind it. A storage array volume or LUN is the block-storage device presented to ESXi. VMFS is the filesystem created on that device, and the datastore is the logical container ESXi exposes for storing files.
- Physical storage or LUN: The underlying block device, such as a local disk or SAN volume.
- VMFS filesystem: The filesystem formatted on the block device.
- Datastore: The named ESXi storage container built on the VMFS filesystem.
Typical datastore contents include virtual machine configuration files, virtual disks, snapshot files, virtual machine logs, and virtual machine swap files. ISO images, templates, and other administrative files may also be stored there.
Supported Storage Foundations
VMFS is created on block-storage devices that ESXi recognizes. Depending on the environment, the device may be:
| Storage type | Typical connection method | Shared or local use | Key preparation tasks |
|---|---|---|---|
| Local disk | Disk controller or direct-attached storage | Usually local to one host | Confirm the disk is unused and correctly identified. |
| Fibre Channel LUN | Fibre Channel fabric and host bus adapters | Commonly shared by a cluster | Configure zoning, LUN masking, paths, and multipathing. |
| FCoE LUN | Fibre Channel over Ethernet | Commonly shared by a cluster | Validate converged-network connectivity, zoning, masking, and paths. |
| iSCSI LUN | IP network and iSCSI initiator | Local or shared | Configure discovery, networking, authentication, target access, and paths. |
| Supported SAS or SCSI device | Direct-attached SAS or SCSI connection | Usually local, depending on hardware | Confirm hardware compatibility and that the device is unused. |
The intended device or LUN must be visible to the target ESXi host before the New Datastore workflow can use it. If it is not visible, resolve presentation or connectivity issues first; do not select an unrelated device as a substitute.
Prerequisites and Planning
| Requirement | How to verify | Why it matters |
|---|---|---|
| Unused target device | Compare the device identifier, capacity, and paths with the storage inventory. | Formatting can destroy an existing datastore, partition, boot volume, or filesystem. |
| Host visibility | Check the host storage-device view or run an ESXi storage query. | The wizard cannot format a device that ESXi has not discovered. |
| Storage presentation | Verify array masking, target access, and host mappings. | The correct LUN must be presented to the intended host or hosts. |
| Transport connectivity | Check Fibre Channel zoning, FCoE configuration, or iSCSI network, discovery, and authentication. | Connectivity problems can hide the LUN or leave it with incomplete paths. |
| Multipathing | Review expected paths and their states. | Multiple healthy paths improve availability and may be required by the design. |
| Sharing plan | Identify whether one host or a cluster will use the datastore. | Every shared-storage host needs consistent presentation and VMFS compatibility. |
| Capacity plan | Record the desired datastore size and any reserved space. | Unallocated capacity may be needed for a later datastore or documented expansion plan. |
| Permissions | Confirm the account has datastore and host storage management privileges. | Insufficient privileges can prevent device selection or workflow completion. |
Choose a naming convention that identifies useful context, such as workload, location, storage tier, or purpose. Examples include PROD-CL01-TIER1-VMFS01 and LAB-ESX01-SSD01. A datastore rename changes its inventory name, but it does not rename the backing LUN or change the storage device identity.
Decide whether to consume the entire device. Using the full device is common when the LUN is dedicated to one datastore. Select a smaller capacity only when the organization has a documented reason to reserve the remaining space for another datastore or a future allocation plan.
VMFS Version and Compatibility
The available VMFS choices depend on the ESXi and vCenter environment. Modern supported environments commonly offer VMFS 6. VMFS 3 and VMFS 5 are older formats that may still exist in established environments, but they should not normally be selected for a new deployment without a documented compatibility requirement.
| VMFS version | Typical status | When it may be selected | Host compatibility consideration |
|---|---|---|---|
| VMFS 3 | Legacy | Only for a specific requirement involving very old ESXi hosts or migration. | All hosts that mount the datastore must support the format and its operational limitations. |
| VMFS 5 | Older, established format | Compatibility or migration scenarios involving existing infrastructure. | Verify support across every host that will access the shared datastore. |
| VMFS 6 | Common modern choice | New deployments when offered and supported by the environment. | Confirm every intended host and the vCenter environment support it. |
Select the default VMFS version supported by the ESXi and vCenter environment unless a documented legacy-host compatibility requirement says otherwise. A shared datastore must use a filesystem version that every intended host can mount.
Create the Datastore in the vSphere Client
- Sign in to the vSphere Client through vCenter Server, or connect directly to the ESXi host when that is appropriate for the environment.
- In the inventory, select the target ESXi host. For shared storage, begin from the host or cluster context that represents the intended consumers.
- Open the host's storage or datastores area and start the action to create a new datastore.
- When prompted for a location, select the target host or appropriate inventory location.
- Choose VMFS as the datastore type.
- Enter the datastore name using the naming convention selected during planning.
- Select the intended available storage device or LUN. Match its identifier, capacity, transport type, and path information against the storage-array record.
- Choose the VMFS version offered by the environment. Use the current supported default unless legacy compatibility has been explicitly documented.
- Configure the datastore capacity. Use the entire device when it is dedicated to this datastore, or select a planned smaller capacity when reserved space has a defined purpose.
- Review the summary carefully. Confirm the host, datastore name, VMFS version, device identifier, capacity, and format warning.
- Finish the wizard and wait for the formatting and mounting operation to complete.
| Wizard step | Required selection | Decision guidance | Common mistake to avoid |
|---|---|---|---|
| Location | Target ESXi host or inventory location | Use the host that can see the intended device. | Creating the datastore from the wrong host context. |
| Type | VMFS | Use VMFS for supported block storage. | Confusing a datastore with an NFS or other file-based datastore. |
| Name | Unique, descriptive name | Include environment, location, tier, or purpose. | Using an ambiguous name that cannot be mapped to storage records. |
| Device selection | Correct unused LUN or disk | Compare stable identifier and capacity with the array record. | Formatting a similarly sized production device. |
| VMFS version | Supported version | Prefer the current default unless compatibility requires otherwise. | Choosing VMFS 3 or VMFS 5 for a new deployment without justification. |
| Capacity | Full or selected device capacity | Follow the documented capacity plan. | Leaving space unused without recording why, or consuming reserved space accidentally. |
| Review | Confirmed summary | Read the format warning and recheck the device identity. | Completing the wizard without validating the backing device. |
After successful completion, the datastore should appear in the inventory and be mounted by the selected host. A shared datastore is not automatically usable by every host merely because one host formatted it; storage presentation and mounting must be validated on every intended host.
Verify the New VMFS Datastore
| Validation item | Expected result | Where to check |
|---|---|---|
| Inventory visibility | The datastore is listed with the expected name. | Datastore inventory and host storage view. |
| Accessibility | The datastore reports accessible or mounted. | Datastore summary and host storage details. |
| Capacity and free space | Values match the planned size and leave operational headroom. | Datastore summary, storage view, or monitoring dashboards. |
| VMFS type | The selected VMFS version is displayed. | Datastore details. |
| Backing device | The device identifier and capacity match the intended LUN. | Datastore backing or device details. |
| Shared-host access | Every intended ESXi host sees and mounts the same datastore. | Each host's storage view and cluster inventory. |
| Multipathing | Expected paths are present and healthy. | Host storage paths or device multipathing view. |
| Functional test | A test folder or test VM can be created if appropriate. | Datastore browser or a non-production test workload. |
For a shared Fibre Channel, FCoE, or iSCSI datastore, verify the same LUN is presented consistently to all hosts. Confirm that each host sees the same stable device identifier, not merely a device with a similar capacity.
ESXi Shell Verification
Use the ESXi Shell only when command-line validation is required and access is permitted by organizational policy. These commands inspect storage; they do not replace careful identification or change control.
esxcli storage core device listLists discovered storage devices, including identifiers, capacity, paths, and device status.
esxcli storage filesystem listLists mounted filesystems and helps confirm the VMFS datastore name, mount point, type, and capacity.
esxcli storage core path listShows storage paths and path states for SAN-backed devices.
esxcli storage core adapter rescan --allRescans all storage adapters after a new device or LUN is presented. Rescan each intended host when shared storage is being prepared.
Operational Considerations
Mounting and Presentation
Storage presentation is the process of making a LUN available to an ESXi host through array masking, zoning, target configuration, or another transport-specific mechanism. Mounting is the ESXi operation that makes a recognized VMFS volume available as a datastore. A LUN must first be presented consistently to every host that will use it; mounting alone cannot compensate for missing presentation.
Expansion
Expanding a datastore and extending the underlying LUN are related but separate operations. The storage array may need to increase the LUN size first. ESXi must then rediscover the larger device, and the datastore expansion procedure must be completed using supported methods. Validate array, ESXi, and filesystem support before changing production storage.
A VMFS datastore can also involve additional capacity known as a datastore extent. Evaluate extents carefully against current operational practices, support guidance, failure-domain requirements, and monitoring standards rather than using them as an automatic substitute for sound capacity planning.
Capacity Monitoring
Monitor both used and free capacity. Leave sufficient headroom for virtual disk growth, snapshots, virtual machine swap files, logs, ISO images, and temporary operational activity. Configure alerts before free space becomes critical, and review workloads that consume unexpected space.
Documentation
Record the datastore name, VMFS version, capacity, free-space policy, backing device identifier, storage-array volume, transport type, expected paths, host list, and intended workload. This mapping makes future expansion, incident response, and storage maintenance safer.
Safety, Permissions, and Duplicate LUNs
Creating or managing datastores requires appropriate storage-management privileges on the ESXi host or in vCenter Server. Permissions are assigned through VMware role-based access control. See Assign Permissions and Access Control System for related access-control concepts.
Be especially careful when copied, replicated, or cloned LUNs are presented to hosts. Duplicate storage can produce signature or resignature warnings and may be mistaken for the original datastore. Do not format a device in response to such a warning until its identity and recovery requirements are confirmed. Follow approved procedures for copied-LUN handling, resignaturing, or recovery.
Production storage changes should follow change-control procedures. Coordinate with storage and network teams when zoning, masking, iSCSI authentication, host bus adapters, switches, or multipathing are involved.
Practical Examples
Local Datastore for a Standalone Lab Host
A standalone host has an unused local SSD. Confirm its device identifier and capacity, create a VMFS datastore using the full device, and name it with a convention such as LAB-ESX01-SSD01. Verify that it is accessible, then use it for test virtual machines.
Shared Fibre Channel Datastore
A storage administrator presents the same unused Fibre Channel LUN to every ESXi host in a cluster. Before formatting, confirm that all hosts see the same device identifier and have healthy expected paths. Create VMFS from one host through vCenter, then verify visibility, mounting, and multipathing on every cluster host before placing workloads on it.
iSCSI-Backed Datastore
Configure the software or hardware iSCSI adapter, networking, target discovery, and authentication such as CHAP when required. Rescan storage, compare the discovered device identifier and capacity with the array record, create the VMFS datastore, and validate it on all intended hosts.
Preserving Capacity
If a newly presented LUN is larger than the current requirement, select a planned smaller datastore size only when the remaining capacity has a documented future allocation. Record the unused space and its intended use so that it is not mistaken for lost or unclaimed storage.
Troubleshooting
The Expected LUN Does Not Appear
- Run a storage adapter rescan.
- Check whether the device appears in the host storage-device list.
- Compare its identifier and capacity with the storage-array record.
- Verify Fibre Channel zoning, FCoE connectivity, iSCSI network access, target discovery, authentication, and LUN masking as applicable.
- Check whether the device is already in use or has an unsupported state.
The Correct Device Is Difficult to Distinguish
Similar capacities and generic storage labels are unsafe identification methods. Stop before formatting. Use an NAA, EUI, or other stable identifier and map it to the array volume. Improve storage naming and documentation if the mapping is unclear.
The Datastore Is Visible Only to One Host
- Confirm that the LUN is presented to every intended host, not only the host that formatted it.
- Rescan storage on the other hosts.
- Check zoning, masking, iSCSI configuration, target access, and path visibility on each host.
- Confirm that every host sees the same device identifier.
Formatting Warns About Existing Data or a Signature
The device may contain an existing VMFS datastore, partition table, filesystem, or copied-LUN signature. Stop, preserve the device, and confirm its identity. Use approved copied-LUN, resignature, or recovery procedures instead of formatting it.
The Datastore Has Reduced Path Availability
Review device and path status. A failed SAN path, switch configuration, host bus adapter, network path, storage controller, or multipathing configuration may be responsible. Coordinate with storage and network teams and correct the pathing issue before placing production workloads on the datastore.
Usable Space Is Insufficient
Review snapshots, virtual machine growth, swap files, ISO storage, logs, and filesystem overhead. If the datastore was intentionally created smaller than its backing device, follow supported procedures to expand it only after validating the array and ESXi steps. Maintain capacity alerts and free-space headroom.
Exam-Relevant Notes
- VMFS is the filesystem; a datastore is the logical storage container exposed to ESXi; a LUN is the underlying block-storage volume.
- The target LUN must be visible before datastore creation.
- Formatting the selected device can destroy existing data.
- Shared VMFS requires consistent LUN presentation and filesystem compatibility across all hosts.
- A storage rescan refreshes ESXi discovery but does not fix incorrect zoning, masking, authentication, or network connectivity.
- Multipathing provides multiple paths to a storage device and must be checked for expected healthy path states.
- Renaming a datastore does not rename its backing LUN or change its storage identity.
For broader storage administration, review Add Raw LUN, Datastore Heartbeating Explained, and the VMware ESXi Online Course.