Five VM settings decide whether your virtual DSM boots cleanly, sees its disks and shows up on the network. The rest of the configuration page can honestly stay at defaults.
When a virtual DSM misbehaves, the cause is rarely DSM — it is a VM setting quietly fighting it: disks on the wrong controller, a network adapter DSM has no driver for, a boot order that skips the bootloader. This guide takes the five settings that matter, one by one, including the VMDK versus RDM question answered honestly instead of dogmatically.
👆 The five settings that matter — everything else in the VM configuration can stay at defaults for a DSM lab (settings recreated for illustration)
Attach both the bootloader disk and the data disks to the VM's SATA (AHCI) controller. This is the controller style real Synology hardware resembles, and it is what DSM's storage stack expects to enumerate. Disks hung off other controller types may appear inconsistently, appear in the wrong order, or not appear in Storage Manager at all. Order on the controller matters too: bootloader first, data disks after, matching the boot order — DSM finds its system partitions by this layout.
Neither is wrong; they optimise for different things:
Learning lab: VMDK. Rehearsing disk-failure behaviour: RDM. And never mix the two inside one storage pool — the pool inherits the worst confusion of both.
DSM ships drivers for Intel-style adapters, so E1000E works out of the box. VMXNET 3 offers lower overhead but depends on the DSM build including a suitable driver; when a fresh install never appears on find.synology.com, adapter type is suspect number one. There is no prize for fixing this later — start on E1000E, get the NAS running, and only experiment with VMXNET 3 afterwards, with a snapshot taken first. Also confirm the VM is attached to the port group your PC sits on; a NAS on an isolated lab network is invisible to the setup tools by design.
Three minor toggles repay attention. Autostart: enable it (with a short delay) so the NAS returns by itself after host maintenance or a power cut — a NAS that needs a human to boot it fails its one job. Boot order: lock it to the bootloader disk; a one-time boot from the wrong device is the classic cause of a 'dead' lab that is actually fine. Time sync: let the VM sync time properly, because DSM schedules, certificates and two-factor codes all quietly depend on the clock being right.
The video shows each VM setting being chosen for this install — watch it before you create yours.
▶️ Watch Full VideoFirst check the controller: DSM expects its disks on the SATA (AHCI) controller, in order, with the bootloader disk first. Disks presented differently may not enumerate the way Storage Manager expects.
For realism, yes — DSM sees a real disk and real SMART data. For convenience, no — you lose snapshots and portability. A learning lab is usually happier on VMDK; a disk-failure rehearsal wants RDM.
Change the network adapter to E1000E and confirm the VM is on the same network segment as your PC. Those two fix the large majority of invisible-NAS installs.