A VM you built last week freezes at two in the afternoon. Not a crash, not a blue screen. The screen simply stops, the clock inside the guest stalls, and nothing you click responds. You open vCenter and there it is: a small question mark on the VM, asking you to choose Retry or Cancel. The message underneath says there is no more space for the virtual disk. The datastore is full. Until somebody frees space, that VM is going to sit there, alive but paused, and so might every other VM sharing the same shelf.

This is the day storage stops being a box you ticked in a wizard and becomes the thing your whole job rests on. So let us slow down and look at where a VM actually lives. Picture a large shared warehouse with numbered shelves. Each shelf holds boxes that belong to different teams, and several delivery vans (your ESXi hosts) can back up to the same shelf and grab or drop boxes at the same time. In VMware that shelf is a datastore. The boxes are the files that make up your VMs. Learn what is on the shelf, how the shelf is built, and how full you are allowed to fill it, and the frozen-VM afternoon never happens to you.

What a datastore actually is

A datastore is a named container for files that ESXi and vCenter treat as one place to store things. That is the whole idea: it hides the messy details of the storage underneath (which physical disks, which network path, which LUN) and gives you one tidy name like datastore-prod-01 with a capacity and an amount free. A LUN, by the way, is just a slice of storage that a storage array hands out to a host, like cutting one numbered ticket from a big roll. You format that slice once, and from then on you think in datastores, not in LUNs.

The reason this matters so much in VMware is the word shared. The same datastore can be mounted by many hosts at once. That single fact is what makes the clever features later in this series possible. Moving a running VM from one host to another (vMotion, Part 9) works because the VM files never move; both hosts already see the same shelf. Restarting VMs automatically when a host dies (HA, Part 10) works for the same reason. If you remember one thing from this part, make it this: in a real VMware setup, storage is shared on purpose.

A VM is a folder of files

Here is the part that surprises new engineers. A virtual machine is not a mysterious object locked inside ESXi. It is a folder of ordinary files on the datastore, named after the VM. Browse the datastore and you can see them. Knowing the cast of files turns vague problems (the VM is broken) into specific ones (the disk descriptor points at the wrong file).

The files you will actually see

The two you will talk about most are the pair that make up the disk. The small .vmdk is a text descriptor, a few kilobytes, that records how big the disk is and what kind it is. The large -flat.vmdk (or for thin disks a sparse file) holds the actual bytes of the guest operating system and its data. When someone says a VM has a 100 GB disk, they mean that data file. Snapshots, backups and clones (Part 8 and Part 14) are all really operations on these files.

The three kinds of datastore you will meet

The shelf can be built in different ways. As a fresher you mostly need to recognise three and know when each shows up.

VMFS, NFS and vSAN in plain terms

VMFS (Virtual Machine File System) is a file system that ESXi puts on block storage, the kind delivered over Fibre Channel, iSCSI, NVMe or a local disk. It is built so several hosts can read and write the same volume safely at once, which a normal Windows or Linux file system cannot do. The current version is VMFS-6. NFS is simpler to picture: a storage box (a NAS) shares a folder over the network, and ESXi mounts that folder the way you map a shared drive at home. vSphere supports NFS v3 and v4.1. vSAN flips the model: instead of a separate array, each ESXi host contributes its own internal drives, and vSAN pools them into one datastore that every host in the cluster sees. No external storage box at all.

Thin vs thick: the one to really understand

If you go deep on one thing in this part, make it this, because it is the setting behind that frozen VM. When you create a virtual disk, you choose how its space is handed out. Thick provisioned reserves the full size on the datastore right away. Ask for a 100 GB thick disk and 100 GB leaves the free pool immediately, whether the guest writes one byte or ninety gigabytes. Thick comes in two flavours: lazy zeroed (space reserved now, each block wiped clean the first time it is written) and eager zeroed (the whole thing wiped up front, which takes longer to create but is required for a few features).

Thin provisioned is the opposite. The disk shows the guest its full size, say 100 GB, but on the datastore it only takes up what is actually written. Copy 10 GB of data into a 100 GB thin disk and the file on the shelf is about 10 GB. It grows as the guest writes. This is wonderful for using space well, and it is exactly where new engineers get burned, because the numbers stop adding up in your head.

Thick has two flavours: lazy zeroed and eager zeroed

Thick provisioning splits into two options, and the whole difference comes down to zeroing. Before a guest can safely use a block of disk, any leftover data sitting in that physical spot has to be overwritten with zeros, so one VM can never read scraps left behind by another VM that used the space before it. Both thick types reserve the full size the moment you create the disk. What changes is when that zeroing happens.

Thick provision lazy zeroed is the usual default. The full space is set aside straight away, so a 100 GB disk takes 100 GB on the shelf at once, but each block is only wiped clean the first time the guest actually writes to it. Creating the disk is quick, because nothing is zeroed yet. The only cost is a very small, one-time pause on the first write to each fresh block, brief enough that most workloads never feel it.

Thick provision eager zeroed does all the cleaning up front. When you create the disk, the host writes zeros across every block before the VM is allowed to touch it, so creation is noticeably slower and a large disk can take a while to appear. In return there is no first-write delay later, because the work is already finished. It gives the steadiest, most predictable performance for the heaviest, latency-sensitive workloads, and a few older features such as legacy Fault Tolerance used to require it.

You choose between all three from the same dropdown when you create or migrate a disk: Thin Provision, Thick Provision Lazy Zeroed, or Thick Provision Eager Zeroed. One modern wrinkle is worth carrying with you: on all-flash arrays that support VAAI, the storage hardware can offload the zeroing work, which narrows the real-world gap between lazy and eager so far that eager zeroed earns its place only in the specific cases that genuinely need it.

Here is the real-world specific that no tidy explanation gives you. With thin disks you can hand out more space than the datastore physically has, which is called overcommitment, and it works fine right up until the guests fill in their blanks. When the total written data reaches the real capacity, the next write has nowhere to go. ESXi does not corrupt the VM; it does something stranger. It pauses the VM and raises a question with the literal message There is no more space for virtual disk (in the logs, msg.hbacommon.outofspace), offering Retry or Cancel. Free up space on that datastore, click Retry, and the VM carries on from the exact instruction it stopped on. Miss it, and every thin-disk VM on that datastore can stall together. The fix is rarely heroic: delete an old snapshot, storage vMotion a VM elsewhere, or grow the datastore. The lesson is to watch free space before it ever gets there.

How big can these things get

Two numbers worth carrying in your head. A single VMFS datastore can be up to 64 TB, and a single virtual disk (VMDK) can be up to 62 TB. The gap between them is not a typo. The datastore also has to hold the VM config files, swap, snapshots and a little file-system overhead, so you can never quite fill one 64 TB datastore with one 62 TB disk and nothing else. In daily life you will work with datastores far smaller than this, but it is the kind of limit an interviewer likes to poke at, so it is handy to know.

FAQ

What is the difference between a datastore and a LUN?
A LUN is a raw slice of storage an array presents to a host, with no VMware file system on it yet. A datastore is what you get after ESXi formats that LUN with VMFS (or after it mounts an NFS share). You manage and think in datastores; the LUN is the plumbing underneath.

Can two ESXi hosts use the same datastore at the same time?
Yes, and that is the point. VMFS is a clustered file system designed for exactly this, and NFS and vSAN are shared by nature too. Shared access is what lets a VM move between hosts with vMotion or restart elsewhere with HA, because the files never have to move.

Is thin provisioning bad for performance?
On modern storage the difference is small enough that most workloads will never notice, because the only extra cost is a quick zero-on-first-write as new blocks are touched. The real trade-off with thin is management, not speed: you must monitor free space so you do not overcommit your way into a full datastore.

How big can a VMFS datastore and a single VMDK be?
A VMFS datastore can reach 64 TB and a single virtual disk can reach 62 TB. You will rarely build anything near that, but the numbers come up in interviews and in capacity planning, so they are worth remembering.

VMFS or NFS, which should I use?
For a fresher the honest answer is that you usually inherit whatever the team already runs rather than choosing. VMFS suits block storage like Fibre Channel and iSCSI; NFS is simpler to set up over the network and avoids the format step. Neither is universally better; they fit different storage hardware.

References

• Creating vSphere Datastores, Broadcom TechDocs
• Virtual machine stops with There is no more space for virtual disk, Broadcom
• Troubleshooting an ESXi datastore or VMFS volume that is full, Broadcom

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts