DSM running on your ESXi host is the cheapest way to learn Synology properly — every package, every setting, no hardware to buy. Here is the complete install, in the right order, with the limits nobody mentions in the tutorials.
The build has three moving parts: an ESXi virtual machine, a small community bootloader disk that starts DSM, and the genuine DSM installer file from Synology. Get the order right and the whole job takes under an hour. Get the disk order or the update setting wrong and you will be troubleshooting a NAS that never boots. This core guide walks the full setup; the case guides in this series then take each decision — disks, updates, backups, real-vs-virtual — one at a time.
👆 The VM shape used in this guide — the bootloader disk always stays attached and boots first, DSM data lives on the separate data disks (settings recreated for illustration)
You are not installing a Synology product the normal way. DSM normally ships only on Synology hardware. This method boots DSM inside an ESXi virtual machine using a small community bootloader image that presents the VM to DSM as if it were a Synology box, and then installs the genuine DSM system file (the .pat file) downloaded from Synology's official Download Center. DSM is Synology software, licensed for Synology hardware. Running it inside a virtual machine like this is a lab and learning exercise — some Synology services and packages may refuse to run or break, a DSM update can break the install, Synology support does not cover it, and it must never be the only place an office keeps its data. Treat it as a way to learn DSM, test packages and rehearse migrations — not as a production NAS.
You need a working ESXi host with enough free resources: at minimum 2 vCPU and 2 GB RAM you can spare for the VM (4 GB RAM is more comfortable), plus storage for the data disks. Before starting, collect three things:
.pat installer file from Synology's official Download Center — the bootloader and the DSM version must be a pair that is known to work togetherKeep copies of both files outside the host. If the VM ever breaks, these two files are your rebuild kit.
In the ESXi web client choose Create / Register VM → Create a new virtual machine. Pick a guest OS family of Linux / Other Linux 64-bit — DSM is a Linux-based system and this template gives it compatible virtual hardware. Give the VM 2 vCPU and 2–4 GB RAM to start; you can raise both later while the VM is powered off. Do not oversize it on day one — a lab DSM idles happily on modest resources, and the host usually has other VMs to feed.
This is the step most failed installs get wrong. Add the disks in this order:
Never remove or renumber the bootloader disk afterwards. If DSM cannot find it at boot, the NAS simply does not start — even though all your data disks are perfectly healthy.
Attach the VM to the virtual switch or port group that your normal LAN uses, so your PC can reach it. The safe adapter choice is E1000E, which DSM recognises with its built-in drivers. VMXNET 3 is faster on paper but only works if the DSM build you run includes a driver for it — if the NAS never appears on the network, the adapter type is the first thing to check. Power on the VM and watch the console: the bootloader runs, then DSM's kernel takes over. Give it a few minutes on first boot.
From a PC on the same network, open find.synology.com in a browser, or use the Synology Assistant desktop tool. The new system appears as a Not installed device. Connect to it and the Web Assistant asks for the DSM installer: upload the .pat file you downloaded in Step 1. The install formats the system partitions on the data disks and takes roughly ten minutes, followed by a reboot. After that you create the admin account, name the server, and — this matters — skip or delay automatic DSM updates when the setup wizard offers them, for the reason in Step 7.
Open Storage Manager and create a storage pool from the data disks. With two disks, SHR or RAID 1 gives you one-disk fault tolerance; with one disk you get capacity and no protection at all. Then create a volume and your first shared folder. Copy some test files, reboot the VM once, and confirm everything comes back on its own — a lab you have not reboot-tested is a lab you do not actually have yet.
Finish with the rule that keeps this lab alive: in Control Panel → Update & Restore, turn automatic DSM updates off. On real Synology hardware an update is routine; on a virtualised install, a new DSM version can change what the bootloader must emulate, and the NAS may simply not boot afterwards. Update only deliberately: snapshot the VM first, check that your bootloader supports the target DSM version, update, and test. The full discipline is covered in the update case guide in this series.
The complete step-by-step installation — VM creation, bootloader, Web Assistant and first boot — is shown live in the video.
▶️ Watch Full VideoDSM is Synology software licensed for Synology hardware, so a virtualised install sits outside that licence and outside Synology support. That is why every page in this series calls it what it is: a lab and learning setup, never a production NAS and never the only copy of important data.
The usual causes are the network adapter type (switch to E1000E, which DSM supports with built-in drivers), the VM being on a different network segment than your PC, or the bootloader disk not booting first. Check those three before reinstalling anything.
No. Turn automatic updates off. On a virtualised install a DSM update can break the boot process, because the bootloader emulates a specific hardware and DSM pairing. Update only after a VM snapshot, and only to a version your bootloader is known to support.