A virtual NAS is not free. It eats real host RAM, real CPU and real disk, twenty-four hours a day. This checklist sizes the host honestly before you install anything, so the lab is a pleasure instead of a slow disappointment.
Most failed NAS labs do not fail at the install — they fail at the planning. The host looked big enough on paper, so QTS got whatever was left, and the result crawls. This page works through the four resources the VM truly needs, with honest starting figures and the reasoning behind each one. Read it before the core setup guide, and the install itself becomes the easy part.
👆 A host resource check with example figures — your numbers will differ, but all four rows must pass before the install starts
QTS will technically start on very little memory, but a NAS is not just a file server any more: the desktop interface, indexing, thumbnails and every app you open all live in RAM. Treat 2 GB as the absolute floor — the system runs, slowly, and complains — and 4 GB as the honest starting point for a lab you will actually enjoy. If you plan to try heavier apps such as photo management or containers, 8 GB is where life gets comfortable. The other side of the ledger matters just as much: RAM given to the NAS is RAM your other VMs lose. Check what the host has free after everything else is running, not what the box has in total.
File serving is light work, so 2 vCPU runs a QTS lab well. Add more only for a reason: software transcoding, many simultaneous users, or heavy apps. Throwing eight cores at a lab NAS mostly wastes them, and on a busy host it can actually hurt — the hypervisor has to schedule those cores together. Start small, watch the VM's own CPU graph for a week of real use, and raise it only if the graph — not a feeling — says so.
Budget datastore space for four things, not one: the system disk, the data disks you create today, the growth you will allow next month, and the VM snapshots you will take before updates. Snapshots are the silent eater — each one keeps the changes made since it was taken, and a forgotten snapshot on a busy NAS grows quietly until the datastore is full and the VM pauses. Decide your snapshot habit now (take one before an update, delete it after the test passes) and the space problem mostly disappears.
The VM needs an IP address on the same network your PCs use, ideally a fixed one — set it in QTS during setup or reserve it in your router — because every shortcut, mapped drive and backup job will point at that address for years. Also be honest about the host's network card: if the host's single gigabit port already feeds three busy VMs, the NAS shares that same pipe. For a learning lab that is fine. For a stand-in office server it is the first bottleneck you will meet.
Gather everything the video uses for the install in one folder before you create the VM: the QTS system image, any matching firmware file, and Qfinder Pro for finding the NAS afterwards. Keep a second copy of that folder off the host entirely. Community images and specific firmware builds have a habit of becoming hard to find later, and the day the VM breaks is the worst day to discover that. These files are your rebuild kit — treat them that way from the first hour.
If your host passes all four checks with room to spare, you have a good home for a QTS lab: learning, testing apps, rehearsing a migration, training a junior admin. If it passes only by squeezing, expect a slow NAS and do not blame QTS for it. And whatever the host looks like, the frame from the core guide still stands: this is a lab. It is not where the office's only copy of anything lives — that job needs real hardware or QNAP's licensed virtual product, and both have pages of their own in this series.
Watch the video to see the host preparation and the full install done live, start to finish.
▶️ Watch Full VideoTreat 2 GB as the technical floor and 4 GB as the honest starting point for a lab. The QTS desktop, indexing and apps all live in memory, so a starved VM feels broken even though nothing is wrong. Give it 8 GB if you plan to run heavier apps, and always check the host still has enough left for its other VMs.
Yes, for learning. Workstation runs the same kind of VM; just remember your PC also needs its own RAM and CPU for your daily work, and the NAS stops every time the PC sleeps or shuts down. A lab that powers off at night is fine for practice — it is not a server.
Enough for the changes your NAS makes between the snapshot and the moment you delete it. Snapshots are for short, deliberate moments — before an update, for example — not permanent storage. Take one, test, delete it. A forgotten snapshot on a busy NAS can quietly grow until it fills the datastore and pauses the VM.