vWorld Short: Cannot Create a VMFS Datastore on Nested ESXi Running on vSAN

September 25, 2026 - By admin

When working with nested ESXi environments, sometimes a problem that looks like a simple storage issue is actually caused by the storage layer underneath the nested hypervisor.

In my lab, I wanted to create a local VMFS datastore on an additional virtual disk attached to a nested ESXi host.

The disk was visible to ESXi, and I was able to create a GPT partition, but creating the VMFS datastore failed.

In this short note, I will show how I troubleshot the issue and what was required to make VMFS work when the nested ESXi virtual disk was stored on vSAN.

The problem

The nested ESXi host was running as a virtual machine in my lab.

I added an additional virtual disk that I wanted to use as a local VMFS datastore.

When I tried to create the datastore from vCenter, the operation failed with:

An error occurred during host configuration.

Operation failed, diagnostics report:
Unable to create Filesystem,
please see VMkernel log for more details:

Failed to create VMFS on device
mpx.vmhba0:C0:T1:L0:1

At this point, the problem looked like a normal disk or partition issue.

Step 1 — Check the disk

First, I checked if ESXi could correctly see the device:

esxcli storage core device list -d mpx.vmhba0:C0:T1:L0

Then I checked the current partition table:

partedUtil getptbl /vmfs/devices/disks/mpx.vmhba0:C0:T1:L0

It is also worth checking if the disk is detected as a possible vSAN device:

vdq -q

and if it is already used by vSAN:

esxcli vsan storage list

These checks confirm the disk is visible and not already used by another ESXi storage service.

Step 2 — Recreate the partition

In my case, I wanted to completely recreate the disk layout.

Warning: The following commands remove the existing partition layout. Do not run them on a disk containing data that you want to keep.

First, I defined the disk:

DISK=/vmfs/devices/disks/mpx.vmhba0:C0:T1:L0

Then I created a new GPT partition table:

partedUtil mklabel $DISK gpt

Next, I checked the usable sectors:

partedUtil getUsableSectors $DISK

In my lab, the result was:

34 524287966

I then created a VMFS partition:

partedUtil setptbl $DISK gpt \
"1 2048 524287966 AA31E02A400F11DB9590000C2911D1B8 0"

The partition was created successfully.

Now I tried to create a VMFS6 filesystem:

vmkfstools -C vmfs6 -S LocalDS ${DISK}:1

But this time I received:

ATS on device /dev/disks/mpx.vmhba0:C0:T1:L0:1: not supported

Failed to create VMFS on device mpx.vmhba0:C0:T1:L0:1

Error: vmkfstools failed:
vmkernel is not loaded or call not implemented.

The partition itself was created correctly, so this was no longer looking like a partition table problem.

Step 3 — Check vmkernel.log

When vmkfstools returns a generic error, vmkernel.log is usually the next place I check.

For example:

tail -n 50 /var/log/vmkernel.log

or:

grep -i -E "vmfs|mpx.vmhba0:C0:T1" \
/var/log/vmkernel.log | tail -50

In my case, the important messages were:

ScsiDeviceIO: Cmd ... 0x16 ... to dev "mpx.vmhba0:C0:T1:L0" failed

H:0x0 D:0x2 P:0x0
Valid sense data: 0x5 0x24 0x0

FSS: Failed to create FS on dev [mpx.vmhba0:C0:T1:L0:1]
fs [LocalDS] type [vmfs6] ... => Not supported

The interesting part here was:

Cmd ... 0x16

SCSI command 0x16 represents RESERVE(6).

The device was rejecting this request with:

0x5 0x24 0x0

which indicates an illegal request / invalid field in the SCSI command.

The disk also did not support ATS, so VMFS needed to use SCSI reservation functionality during filesystem creation. The reservation request was rejected, and VMFS creation failed.

Step 4 — Check where the nested ESXi disk is actually stored

This was the important part.

From the perspective of the nested ESXi host, the disk looked like a normal local SCSI device:

mpx.vmhba0:C0:T1:L0

But of course, in a nested environment, this is not really a physical disk.

I checked the virtual machine configuration of my nested ESXi host and found that the additional virtual disk was stored on my vSAN datastore:

vworld-cl01-ds-vsan01

with my normal vSAN storage policy.

So the real storage path looked like this:

Nested ESXi
    |
    +-- Virtual SCSI device
            |
            +-- VMDK
                    |
                    +-- vSAN Datastore
                            |
                            +-- Physical ESXi / vSAN

This was the key to understanding the problem.

The nested ESXi sees a SCSI disk, but SCSI operations issued by the nested hypervisor still need the virtualized storage stack underneath it to handle them. In this lab, the vSAN-backed VMDK prevented the required SCSI reservation operation from completing.

Step 5 — Enable FakeSCSIReservations on the physical ESXi hosts

The solution in my nested lab was to enable the vSAN advanced setting:

/VSAN/FakeSCSIReservations

Configure this on the physical ESXi hosts running the vSAN cluster, not inside the nested ESXi host.

On each physical ESXi host, run:

esxcli system settings advanced set \
-o /VSAN/FakeSCSIReservations \
-i 1

To verify the configuration:

esxcli system settings advanced list \
-o /VSAN/FakeSCSIReservations

The important value should now be:

Int Value: 1

I repeated this configuration on each physical ESXi host participating in the vSAN cluster.

Then I returned to the nested ESXi host and tried to create the datastore again:

vmkfstools -C vmfs6 \
-S LocalDS \
/vmfs/devices/disks/mpx.vmhba0:C0:T1:L0:1

If the operation still fails immediately after changing the setting, power off and power on the nested ESXi VM and try again.

Why this happens

This issue is easy to misdiagnose because two different storage views are involved.

The nested ESXi sees:

Local SCSI Disk

But the physical infrastructure sees:

VMDK
  |
  +-- vSAN object

So when troubleshooting nested ESXi storage, it is important not to stop at:

esxcli storage core device list

You also need to check how the virtual disk of the nested ESXi VM is backed on the physical infrastructure.

In my case:

Nested ESXi
     |
     +-- VMFS6 creation
             |
             +-- ATS unavailable
                     |
                     +-- SCSI RESERVE(6)
                             |
                             +-- Reservation rejected
                                     |
                                     +-- VMFS creation fails

The actual problem was therefore below the nested ESXi layer.

Alternative solution

If you do not want to enable FakeSCSIReservations on the physical vSAN hosts, another option is to move the virtual disk used by the nested ESXi to a datastore that does not have this limitation in your environment.

For example:

Physical ESXi
     |
     +-- VMFS or NFS Datastore
             |
             +-- Nested ESXi VMDK
                     |
                     +-- Local VMFS inside nested ESXi

You can move only the additional VMDK used for the nested datastore while keeping the nested ESXi VM itself on vSAN.

In my lab, this means moving Hard disk 2 from the vSAN datastore to another datastore using Storage vMotion, and then creating the VMFS datastore again from inside the nested ESXi host.

Share with: