→ Applies to: SynetoOS 6.x and above
Overview
Servers running SynetoOS must meet the following requirements:
| Category | Requirements |
| Memory | 32 GB is reserved for SynetoOS and it's in-memory cache |
| Boot environment | 2× SSD, >240 GB, mirrored* |
| Disk Controller(s) | HBA or RAID Controller configured in JBOD / Non-Raid / HBA / IT mode |
| Storage | 20% usable capacity free, at all times |
*preffered configuration. Checkout Boot environment section for other options
Memory
Of total host memory, 32 GB is reserved for SynetoOS and its in-memory cache — a fixed allocation. Remaining capacity is available for guest VMs.

Boot environment
The boot environment is where SynetoOS is installed. It is provisioned either on a dedicated boot controller where the platform has one, or directly on two boot disks owned by the hypervisor; in both cases the pair is mirrored so a single drive failure doesn't take the host down.
| Condition | Configuration |
| No dedicated boot controller on the platform | 2× boot disks, 240 GB minimum each (SSDs preferred), reserved for the hypervisor and mirrored at the OS level. A single disk controller on the server is used. |
| Dedicated boot controller present | Boot controller + 2× boot disks, 240 GB minimum each (preferred), hardware-mirrored. |
Configure one path only. A dedicated boot controller and OS-level mirrored SSDs are alternatives, not additive.
Boot Disk Types
| Type | Acceptance |
| SSD | Preferred |
| 10K/15K RPM SAS HDD, NVMe | Accepted |
| SATA HDD | Accepted only when no other option is available |
When boot disks are SSD/NVMe, they also serve as the Write Acceleration (SLOG) tier for a hybrid pool configured at initial deployment — no separate disk need to be allocated for that role*.
Installation Type
| Installer | Acceptance |
| Automated | Installs SynetoOS on mirrored SSD drives or a dedicated boot environment, on validated server platforms |
| Manual | Can install on (any) a single disk |
Boot disks are never used as data disks. The disks holding SynetoOS are dedicated to the boot environment and never part of the storage pool.
Storage Pool Layout
A disk group is a set of physical disks assigned a single role and redundancy level within the pool. The pool is built by combining one or more disk groups; each group fails and rebuilds independently of the others. A data disk group is commonly referred to as a vdev — the two terms are used interchangeably in this document.
| Disk Group | Function |
| Data | Holds pool data. Redundancy level is set per group: mirror or parity (single/double/triple). |
| Spare | Idle disk that auto-replaces a failed member of a data group (Optional). |
| Read cache | SSD/NVMe extension of the in-memory cache, for working sets larger than RAM. Optional. |
| Write Acceleration (SLOG) | SSD/NVMe tier absorbing synchronous writes (databases, application-consistent checkpoints) to reduce write latency. Optional; on hybrid pools, served by the boot environment SSDs — see Boot environment. |
Data Group Layout Comparison
| Layout | Comparable to | Tolerance | Capacity efficiency | Random IOPS | FIT |
| Mirror | RAID1 | 1 disk / pair | 50% | Highest | VMs, databases, latency-sensitive |
| Stripe + Mirror | RAID10 | 1 disk / mirrored pair | 50% | Highest (scales with vdev count) | VMs, databases at larger capacity, latency-sensitive |
| Single parity (RAIDZ1) | RAID5 | 1 disk / group | High | Lowest | Capacity-first, low-IOPS bulk |
| Double parity (RAIDZ2) | RAID6 | 2 disks / group | Medium | Low | Backup targets, general-purpose |
| Triple parity (RAIDZ3) | — | 3 disks / group | Lower | Low | Large-capacity archival |
- IOPS scale with vdev count, not disks per group. Favor more, narrower groups over one wide group.
- Disks must match in size.
- Write Acceleration (SLOG) is required for hybrid (HDD-backed) storage pools.
- Write Acceleration (SLOG) on all-flash storage pools is not required, it's optional.
Example layouts
Hybrid — 4× HDD, 2× SSD

Layout: 2× HDD vdevs (data), 1× mirrored Write Acceleration (SLOG) partition on boot SSDs:
Condition Configuration Data vdevs 2× mirror vdevs, HDD (4 disks total) Write Acceleration (SLOG) Mirrored, carved as partitions on the 2 boot SSDs — no dedicated write acceleration disks Fit General-purpose hybrid pool needing sync-write acceleration without extra drive bays
RAIDZ1 — 4× HDD, 2× SSD

Layout: 1× RAIDZ1 vdev (data), 4 disks (3 data + 1 parity equivalent):
Condition Configuration Data vdevs 1× RAIDZ1, 4 disks (3 data + 1 parity equivalent) Write Acceleration (SLOG) Mirrored, carved as partitions on the 2 boot SSDs — no dedicated write acceleration disks Fit Capacity-first bulk storage, tolerates 1 disk failure, lowest IOPS of the three examples
All-flash — 4× SSD/NVMe

Layout: 2× SSD/NVMe mirror vdevs (data):
Condition Configuration Data vdevs 2× mirror vdevs, SSD/NVMe Write Acceleration (SLOG) / Read cache None — media latency is low enough that neither earns its slot Fit Highest-IOPS tier: databases, latency-sensitive VMs
Free Space Recommendations
| Threshold | Reason |
| 20% usable capacity | Must remain free on the configured storage pool for optimal performance. Performance degrades once the pool starts filling up. |
- Subtract the 20% before sizing usable capacity, VM growth, and snapshot/Recovery Point retention — not after.
- Monitor trend, not just current usage: fragmentation-driven degradation appears as the pool approaches the threshold, not only after crossing it.
Disk Controller(s)
No hardware RAID on the data path, in any configuration. Redundancy, checksumming, and self-healing are handled by the storage engine. A hardware RAID layer intercepts disk access and its own write cache, which conflicts with that model and can mask corruption instead of catching it.
| Requirements | Details |
| Controller mode | HBA or RAID Controller configured in JBOD / Non-Raid / HBA / IT mode. |
| Management | The disk controller is managed directly by SynetoOS — not any platform specific RAID tooling. |
| Boot RAID | A mirrored hardware RAID configuration can be used (see Boot environment). |
One physical controller can present both the boot environment and the storage pool.