Ninety percent of virtual NAS problems are born in one settings screen. Disk in the wrong slot, the wrong adapter, no autostart — each one is a two-second choice that costs an evening later. These are the settings that matter, and why.
A QTS virtual machine has dozens of settings, but only a handful decide whether it boots, appears on the network and comes back after a power cut. This page takes those few in order, with the safe choice for each and the symptom you get when you choose otherwise. Set them once, at creation, and most of the classic lab failures simply never happen.
👆 The settings summary for the QTS lab VM — each row is explained below (settings recreated for illustration)
Pick Linux / Other Linux 64-bit when you create the VM. QTS is a Linux-based system, and the template decides the virtual hardware VMware presents: controller types, adapter defaults and boot behaviour all follow from it. Choosing a Windows template does not stop the install, but it seeds odd defaults you will fight later. Two minutes of care here saves a rebuild.
QTS boots from its system disk, and the VM must find that disk first, every time. Attach it before any data disk, keep it in the first slot, and never renumber or remove it — not even temporarily, not even to tidy up. The failure this prevents is total and confusing: data disks perfectly healthy, NAS completely absent, because the system that would read them never started. If you remember one setting from this page, make it this one.
For the install, attach the disks to the virtual SATA controller. SATA is the controller class QTS is built to expect — real QNAP boxes present their drives this way — so detection during setup is boring and reliable. Faster paravirtual controllers exist, but they depend on driver support inside the QTS build you run. Start boring. Once the lab is stable and backed up, controller experiments are a rainy-day project, never a first-day one.
Data disks come in two flavours. VMDK files on a datastore are flexible: easy to create, move, snapshot and back up with the VM — the right default for a lab. Passthrough (giving the VM a whole physical disk) performs like real hardware and lets QTS see the disk's true identity and health data, but the disk is then married to that VM and the datastore conveniences disappear. For learning, choose VMDK. Choose passthrough only when you already know exactly why you need it.
Start with the E1000E adapter. It is not the fastest virtual network card VMware offers, but QTS carries a driver for it in the box, so the NAS appears on your LAN on the first boot. The paravirtual adapter is quicker on paper and invisible in practice if the driver is missing — and a NAS with no network is just a warm box. Prove the lab works on E1000E first; experiment later, with a snapshot taken and console access ready in case the NAS vanishes.
Two final settings decide whether the NAS survives real life. Set the VM to autostart with the host, with a short delay so storage and networking are ready first — otherwise every power cut or host reboot leaves the office without a NAS until somebody remembers to start it by hand. And confirm the boot order points at the system disk. Test both the honest way: reboot the host once, on purpose, and watch the NAS come back alone. That five-minute test is worth more than a month of hoping.
The video shows every one of these settings being chosen live during the install — watch it before you create your VM.
▶️ Watch Full VideoThe network adapter type. If the VM uses a paravirtual adapter that your QTS build has no driver for, the NAS boots perfectly and stays invisible. Switch the adapter to E1000E while the VM is off, boot again, and look for it with Qfinder Pro.
Moving the file is fine; changing its position or slot is the danger. Keep the system disk first in the VM's disk order after any move, and test a full reboot before you trust it. The rule is simple: the disk may travel, its place in the order may not.
Better at some things, worse at others. Passthrough gives real-disk performance and honest SMART data, but the disk belongs to that one VM and datastore snapshots and easy backups go away. For a learning lab, VMDK is the right default almost every time.