Что такое Virtual Machine Manager

Virtual Machine Manager (VMM) — официальный пакет Synology для запуска полноценных виртуальных машин на NAS под управлением DSM. В отличие от Container Manager (контейнеры), здесь гостевая ОС получает свои CPU/RAM/диски и работает как отдельный компьютер внутри гипервизора на том же железе, что и файловый сервер.

На практике VMM удобен, когда нужен Windows или Linux «рядом с данными» на уже купленном Synology: тестовый стенд, лёгкий сервис, лаборатория, временная VM — без отдельного сервера. Это не замена Proxmox VE или ESXi: кластера, живой миграции и «тяжёлой» серверной виртуализации здесь нет, зато есть привычный UI DSM и близость к хранилищу.

Родительский обзор платформы: Synology и DSM. Сравнение с гипервизором «по делу»: Proxmox, Proxmox VE.

Требования к NAS

Перед установкой из Package Center проверьте совместимость модели в документации Synology и железо:

  • CPU с виртуализацией — нужны аппаратные расширения (Intel VT-x / AMD-V). На слабых ARM/entry-level моделях пакет часто недоступен или бесполезен.
  • RAM — DSM + файловые службы + снимки уже едят память. На каждую VM закладывайте выделенный объём сверху: Windows 10/11 комфортнее от 4–8 ГБ гостевой RAM; лёгкий Linux — от 1–2 ГБ. Практичный минимум для домашнего VMM — NAS с 8+ ГБ и апгрейдом слотов; для нескольких VM смотрите 16–32 ГБ.
  • Storage — образы ISO, виртуальные диски и снапшоты VM занимают место на томе. Держите VM на отдельном томе/shared folder с запасом: снапшот раздувает потребление быстро. SSD-кэш помогает I/O, но не заменяет свободное место.
  • Сеть — хотя бы один свободный физический/логический интерфейс для виртуальных коммутаторов; на одном NIC всё тоже работает, но изоляция гостей слабее.

Правило: если NAS уже «висит» на SMB, Snapshot и Hyper Backup — не вешайте на него тяжёлую Windows с SQL «потому что можно». VMM делит CPU, RAM и диски с DSM.

Установка и создание VM

  1. Package Center → Virtual Machine Manager → установить (нужны права администратора).
  2. Откройте VMM → мастер настройки хранилища: укажите том/папку для виртуальных дисков и ISO.
  3. Создайте виртуальный коммутатор (см. ниже) до или вместе с первой VM.
  4. Создать виртуальную машину: имя, CPU (vCPU), RAM, виртуальный диск, сеть, ISO для установки.
  5. Запустите VM, откройте консоль в браузере, установите гостевую ОС как на обычном ПК.
  • Число vCPU и объём RAM задавайте с запасом для DSM: оставьте хосту несколько ГБ и ядра под файловые задачи.
  • Для дисков чаще используют тонкое выделение (thin) — удобно, но следите за реальным занятым местом на томе.
  • Гостевые утилиты / VirtIO (где применимо) улучшают диски и сеть; ставьте после установки ОС.

Образы ISO

Установочные образы загружаются в хранилище VMM (раздел ISO / Image):

  • Официальные ISO Windows, Ubuntu, Debian, других дистрибутивов — с проверенных зеркал.
  • Драйверы/утилиты (VirtIO и т.п.) — отдельным ISO, подключаемым как второй CD/DVD к VM.
  • Не храните десятки ISO «на всякий случай» на том же томе, где критичные данные пользователей — заведите отдельную папку и квоту.

После установки ОС ISO можно отключить от VM, чтобы гость не пытался грузиться с «диска» снова.

Сети и виртуальные коммутаторы

VMM строит сеть через виртуальные коммутаторы, привязанные к физическим интерфейсам NAS или работающие во внутренней сети хоста:

  • Внешний / bridged — VM получает адрес в вашей LAN (DHCP роутера или статику). Удобно для сервисов, доступных из локалки.
  • Внутренний — связь только между VM и/или хостом; наружу — через NAT/прокси на другой машине.
  • Несколько коммутаторов помогают разделить «лабораторию» и прод, если на NAS больше одного NIC или VLAN.

Учитывайте Firewall DSM и то, что открытые порты на IP виртуалки — это уже поверхность атаки. Для удалённого доступа к гостю предпочтительнее VPN, а не проброс RDP/SSH на WAN.

Снапшоты

Снапшоты VM в VMM — контрольные точки состояния диска (и при необходимости памяти) перед рискованным шагом: обновление ОС, смена роли, эксперимент.

  • Делайте снимок до крупного изменения; проверяйте откат на некритичной VM хотя бы раз.
  • Снапшоты занимают место и замедляют I/O при длинной цепочке — не копите их месяцами «на всякий случай».
  • Снапшот ≠ бэкап: при смерти тома/массива точки внутри VMM не спасут. Для важных гостей — экспорт/копия диска, Active Backup / бэкап из гостя, или репликация данных на другой носитель (см. схему бэкапов в статье про Synology).

Типичные сценарии

  • Windows / Linux гостевые — тестовый клиент, «чистая» среда для софта, лёгкий файловый/веб-сервис, который неудобно заворачивать в контейнер.
  • Тестовые стенды — лаборатория AD/DNS, проверка обновлений, песочница перед выкаткой на прод. Здесь VMM на домашнем/офисном NAS часто достаточен.
  • Лёгкие сервисы — небольшой Linux с одним приложением, когда образ Docker неудобен или нужен полный systemd/ядро. Для типичных reverse proxy / VPN / wiki чаще выгоднее Container Manager.
  • Учёба и домашняя лаборатория — несколько небольших VM без покупки отдельного гипервизора.

Ограничения vs Proxmox VE и ESXi

  • Synology VMM — UI в DSM, VM рядом с NAS, минимум отдельного железа. Минусы: зависимость от модели/лицензий пакета, общая судьба с файловым сервером, слабее экосистема кластера/автоматизации.
  • Proxmox VE — KVM + LXC, кластер, миграции, тонкие пулы, ZFS/Ceph по вкусу, API и зрелая серверная практика. Имеет смысл, когда виртуализация — основная нагрузка. Обзор линейки: Proxmox.
  • VMware ESXi / аналог — enterprise-гипервизор, другие лицензии и сопровождение; для дома/малого офиса чаще избыточен, если нет уже сложившейся экосистемы VMware.

Частая схема: Proxmox (или другой гипервизор) для серверов и VM, Synology — хранилище и бэкап-таргет. VMM на NAS — когда «одна-две VM без отдельного хоста» важнее максимальной производительности.

Безопасность и ресурсы (не убивать DSM)

  • Лимиты CPU/RAM — не отдавайте гостю всё: при OOM или 100% CPU страдает DSM, SMB и снимки. Оставьте запас под пики бэкапов.
  • Диск — следите за свободным местом тома: тонкие диски + снапшоты могут внезапно заполнить массив.
  • Изоляция — не монтируйте в гостя «весь /volume1» без нужды; отдельные виртуальные диски и папки с ACL.
  • Доступ — RDP/SSH только из LAN/VPN; обновления гостевой ОС планово; отдельные учётки, не общие с админом DSM.
  • DSM — 2FA, Firewall, без выставления панели «как есть» в интернет (см. Synology).
  • Контейнеры vs VM — если хватает Docker-образа, берите Container Manager: меньше накладных расходов на RAM/CPU.

Когда VMM уместен

  • Synology уже стоит, нужна 1–2 небольшие VM без покупки отдельного сервера.
  • Тестовые/лабораторные задачи, лёгкие гостевые сервисы, учёба.
  • Железо подтверждено: VT-x/AMD-V, достаточно RAM и места на томе.

Когда лучше отдельный гипервизор (Proxmox/ESXi): много VM, нужна предсказуемая производительность, HA/кластер, живые миграции, или NAS уже нагружен файлами и бэкапами. Тогда VMM на том же устройстве — лишний риск для DSM.

Услуги

Нужна помощь с Virtual Machine Manager на Synology: проверка совместимости модели, установка пакета, сеть/коммутаторы, создание Windows/Linux VM, снапшоты и схема «не убить DSM»?
Помогаю аккуратно вписать VMM в существующий NAS или подсказать, когда выгоднее вынести виртуализацию на Proxmox.
Свяжитесь для консультации и обсуждения деталей.