A TrueNAS VM completed installation on ESXi, but the pool-creation screen reported that no disks were available. Adding another virtual disk did not immediately resolve it.
That symptom is usually narrower than it first appears. TrueNAS deliberately excludes its boot device from data-pool candidates. If no other unassigned device is visible to the operating system, the storage wizard has nothing to offer. The investigation should therefore follow the disk from ESXi virtual hardware, through the virtual controller, into the TrueNAS kernel, and only then into the web interface.
Before fixing visibility, decide whether this is a test VM or a production storage system. That choice determines whether a VMDK is an acceptable data device at all.
The boot disk cannot become a data pool
TrueNAS needs a separate boot device and data device. The installer writes the operating system to the selected boot disk, and that disk is not available for pool creation afterward.
The current TrueNAS installation guide specifies at least two virtual disks for a VM: one for the operating system and one for storage. Its current minimum boot-device guidance is 20 GB. A screen showing no pool disks immediately after installation often means the VM has only that boot VMDK.
For a meaningful redundant test, use one boot disk plus at least two equal-sized data disks. One data VMDK can demonstrate the interface and sharing workflow, but it provides no ZFS redundancy.
Confirm the disk exists in ESXi first
Shut down the TrueNAS VM before changing its virtual storage unless the exact controller and guest configuration are known to support hot-add. In the ESXi host client or vSphere Client, open the VM’s hardware settings and verify:
- the new hard disk is listed as a separate device;
- its capacity is what you intended;
- it is connected and configured to connect at power-on;
- it is attached to a virtual storage controller present in the VM;
- it is not the same backing file as the boot device;
- the configuration was saved successfully.
If the disk entry is absent after reopening the settings, TrueNAS cannot discover it. Fix the VM configuration before changing anything inside the guest.
The official TrueNAS ESXi deployment guide provides a current example of creating the VM, assigning resources, installing to a boot disk, and adding storage devices. Use it as the baseline for controller and device selection rather than relying on a screenshot from a different ESXi release.
Determine whether TrueNAS sees the device
After the VM starts, open the TrueNAS shell and list block devices with size, type, model, and serial information:
lsblk -o NAME,SIZE,TYPE,MODEL,SERIAL
Then review recent kernel storage messages:
dmesg | grep -Ei 'scsi|sd[a-z]|nvme|disk|error'
These are read-only checks. Compare the output with the known boot-disk size and the VMDK size configured in ESXi.
There are two fundamentally different outcomes:
The disk is absent from lsblk
The problem is below the TrueNAS storage interface. Recheck the VM’s saved hardware, connection state, controller, and power cycle. If necessary, remove only the newly added empty VMDK from the VM configuration and add a new data disk through a supported virtual SCSI controller. Do not remove the boot disk or select an option that deletes a backing file unless its identity is certain and deletion is intended.
The disk appears in lsblk but not in the pool wizard
TrueNAS can see the hardware, so investigate eligibility. The device may be:
- the active boot disk;
- already assigned to a pool;
- carrying partitions or ZFS labels from an earlier use;
- part of an imported or exported pool;
- reserved by another storage function.
Match the device by size and serial rather than assuming /dev/sdb is always the new disk. Device letters can change across boots or controller changes.
If the device contains a pool that should be retained, use the import workflow. If it is a genuinely disposable test VMDK, TrueNAS can wipe it through the storage interface after its identity is verified. Do not paste a low-level wipe command into the shell as a first diagnostic step: a correct command aimed at the wrong device is still destructive.
Resource sizing for a small TrueNAS VM
The current TrueNAS hardware guide lists 8 GB RAM as a minimum and recommends a 20 GB SSD boot device. A practical small file-server test can start with two virtual CPUs and 8–16 GB RAM, then be measured under the intended workload.
More virtual CPUs do not compensate for slow storage, an oversubscribed datastore, or host memory pressure. ZFS relies heavily on memory for caching and metadata. Avoid designing the VM around aggressive memory overcommit or routine swapping, and monitor the ESXi host as well as the guest.
Capacity planning also needs to account for snapshots, metadata, and free space. A VMDK’s nominal capacity is not a promise that the backing datastore can safely absorb all future writes.
VMDKs are suitable for a lab, not a production ZFS design
The most important correction is architectural. The TrueNAS hardware guide warns that virtualized TrueNAS with virtual disks is not a safe or supported design for critical production data and can lead to corruption. Virtual disks are appropriate for development and proof-of-concept use, where the goal is to learn the interface or test a workflow.
Putting a ZFS mirror across two VMDKs on the same ESXi datastore does not protect against failure of that datastore, its RAID controller, or its shared storage path. ZFS sees two virtual devices, while both may depend on the same underlying failure domain.
For production, the preferred design is bare metal or direct access to a dedicated storage controller through PCI passthrough. TrueNAS then sees the physical drives and can manage ZFS redundancy, health information, and error handling directly.
HBA passthrough must be exclusive
Passing an HBA through to the TrueNAS VM gives the guest direct ownership of that controller. ESXi and other VMs cannot simultaneously use disks attached through the same passed-through device.
Do not pass through the controller that hosts the ESXi boot device, the datastore containing other VMs, or any storage the hypervisor must continue to manage. Production designs commonly use a separate HBA dedicated to TrueNAS data drives, while ESXi boots and stores its own VM files on a different controller or device.
Before enabling passthrough:
- Map every physical disk to its controller and slot.
- Identify where ESXi boots and where each datastore resides.
- Confirm that the candidate HBA serves only the drives intended for TrueNAS.
- Verify server, firmware, ESXi, and TrueNAS compatibility.
- Maintain an independent backup; neither ZFS redundancy nor RAID is a backup.
A safe diagnostic path for “No disks available”
Use this order to avoid destructive guesswork:
- Classify the deployment as lab/PoC or production.
- Confirm that the VM has a boot disk and at least one separate data disk.
- Power off and inspect the saved ESXi virtual hardware.
- Start TrueNAS and identify devices with
lsblk. - If the data disk is absent, troubleshoot the VM controller and disk attachment.
- If present but unavailable, determine whether it is boot, assigned, imported, or carries old metadata.
- Wipe only a disposable device whose identity has been proven.
- For production, redesign around dedicated HBA passthrough or bare metal instead of treating VMDKs as durable storage hardware.
The pool wizard is the last stage in the path, not the first. Establishing exactly where the disk disappears turns a vague TrueNAS error into a controlled ESXi or device-eligibility diagnosis.
