QTS running on your existing VMware host is the cheapest way to learn the QNAP system properly — every setting, every app, no hardware to buy. Here is the complete lab setup in the right order, with the limits nobody mentions in the tutorials.
The build has three moving parts: a VMware virtual machine, a system disk that QTS boots from, and data disks that hold your pools and files. Get the disk order and the update setting right and the whole job takes an afternoon. Get them wrong and you will be troubleshooting a NAS that never boots or dies at its first firmware update. This core guide walks the full setup end to end; the case guides in this series then take each big decision — host resources, VM settings, storage, updates, backups, real-versus-virtual and QNAP's official virtual option — one at a time.
👆 The VM shape used in this guide — the small system disk stays attached and boots first, your files live on the separate data disks (settings recreated for illustration)
You are not installing a QNAP product the normal way. QTS normally ships only on QNAP hardware. The lab method boots QTS inside a VMware virtual machine, so you can learn the system, test apps and rehearse settings without buying a NAS. Be clear about what that means before you start: QTS is QNAP software, licensed for QNAP hardware. A virtualised install is a lab and learning exercise. Some QNAP cloud services and licence-bound apps may refuse to run or break, a firmware update can break the install, QNAP support does not cover it, and it must never hold the only copy of an office's data. QNAP also sells an official, supported way to run its system in a VM — QuTScloud, a licensed virtual appliance — which has its own page in this series. This guide is about the free lab route, with its eyes open.
You need a working VMware host (ESXi or Workstation) with resources you can genuinely spare: a sensible starting point is 2 vCPU and 4 GB RAM for the VM, plus free datastore space for the data disks. Before you create anything, collect what the video shows for this install — the QTS system image used for the VM and a browser on the same LAN for the setup pages that follow. Keep a copy of every file you use outside the host. If the VM ever breaks, those files are your rebuild kit, and re-downloading them later is not always possible.
Create a new virtual machine and choose a guest OS family of Linux / Other Linux 64-bit — QTS is a Linux-based system and this template gives it compatible virtual hardware. Give it 2 vCPU and 4 GB RAM to start; both can be raised later while the VM is powered off. Resist oversizing it on day one. A lab QTS idles happily on modest resources, and the host usually has other virtual machines to feed. Name the VM clearly — months later, QTS-Lab tells you far more than New Virtual Machine 3.
Disk order is the step most failed installs get wrong, so follow it literally:
Never remove, resize carelessly or renumber the system disk afterwards. If QTS cannot find it at boot, the NAS simply does not start — even though every data disk is perfectly healthy.
Connect the VM to the virtual switch or port group your normal LAN uses, so your PC can reach it. Choose the E1000E adapter type first: QTS recognises it with built-in drivers, which makes the first boot boring — and boring is what you want. The faster paravirtual adapter only helps if the QTS build you run ships a driver for it, and a NAS that never appears on the network is the classic symptom when it does not. Power on the VM and watch the console while QTS starts. The first boot is slow; give it several minutes before you touch anything.
From a PC on the same network, open Qfinder Pro (QNAP's free finder tool) or type the VM's IP address into a browser. The new system appears uninitialised. The setup wizard will ask you to create the administrator account, name the NAS and set the time zone. Two habits matter here: use a strong, unique admin password — a NAS is a favourite target precisely because it holds everyone's files — and when the wizard offers automatic firmware updates, choose notify-only or manual. On this kind of install, an update is a deliberate project, never a background event; Step 7 explains why.
Open Storage and Snapshots and create a storage pool from the data disks. With two disks, a RAID 1 mirror gives one-disk fault tolerance inside QTS; with one disk you get capacity and no protection at all. Then create a volume and your first shared folder, copy some test files across, and — the step everyone skips — reboot the VM once and confirm the NAS comes back on its own with your folder intact. A lab you have not reboot-tested is a lab you do not actually have yet. One honest warning about that mirror: whether it protects you from anything real depends on where the virtual disks physically live, and that trap has its own page in this series.
Finish with the rule that keeps this lab alive: firmware updates on a virtualised QTS are manual and deliberate, always. On real QNAP hardware an update is routine maintenance. Here, a new QTS version can change what the virtual hardware must look like, and the NAS may simply not boot afterwards. So: leave notifications on, automatic updates off, and when you do update, snapshot the VM first, export the QTS configuration backup, update, and test before you trust it again. The full discipline — including how to recover when an update breaks the boot — is covered in the update case guide in this series.
The complete installation — VM creation, disks, network and the full QTS setup — is shown live in the video.
▶️ Watch Full VideoNo. QTS is licensed for QNAP hardware, so a community-style virtual install sits outside that licence and outside QNAP support. QNAP's supported route for a virtual NAS is QuTScloud, its own licensed virtual appliance. This guide treats the VM route as what it honestly is: a learning lab, never a production NAS and never the only copy of important data.
Check the three usual causes first: the network adapter type (start with E1000E, which QTS supports with built-in drivers), the VM sitting on a different network segment than your PC, and the system disk not booting first. Also give the first boot several minutes — QTS starts slowly on a fresh install.
Not automatically. Turn automatic firmware updates off and update only deliberately: VM snapshot first, configuration backup exported, then update and test. A QTS update can change what the virtual hardware must present, and virtualised installs are known to fail booting after an update that real hardware takes in its stride.