Домашняя лаборатория на Proxmox: с чего начать

MAATRIX

Вы посмотрели пару видео про Proxmox, прочитали про домашние лаборатории на Reddit — и теперь хочется своё. Но в голове застряло: «наверное, нужен серьёзный сервер, стойка, куча дисков». Спешим успокоить: нет, не нужен. Домашняя лаборатория — это в первую очередь про практику и ошибки без последствий, а не про железо мечты. Разберём, с чего реально стоит начать, чтобы не утонуть в подготовке и наконец начать нажимать кнопки.

Какое железо реально нужно для старта

Главная ловушка новичков — думать, что домашняя лаба должна повторять продакшн какого-нибудь хостера. Не должна. Для первых шагов подойдёт почти всё, что стоит без дела:

• старый офисный десктоп на Core i5-i7 4-6 поколения;
• мини-ПК (Intel NUC, Lenovo ThinkCentre Tiny, HP EliteDesk) — тихий, компактный, съедает мало электричества;
• старый ноутбук с закрытой крышкой (если не жалко превратить его в headless-сервер);
• б/у брендовый сервер (Dell, HP, Supermicro) — если готовы мириться с шумом вентиляторов.

Что действительно важно — это поддержка аппаратной виртуализации: Intel VT-x или AMD-V. Без неё Proxmox тоже установится, но полноценные VM с KVM работать не будут (останутся только контейнеры LXC, а это уже не тот опыт). Проверить поддержку легко ещё до установки — в BIOS/UEFI обычно есть пункт вроде «Intel Virtualization Technology» или «SVM Mode», его нужно включить. Если сомневаетесь, что за процессор — большинство настольных CPU за последние 10-12 лет виртуализацию поддерживают, это скорее вопрос «включено ли в BIOS», чем «есть ли вообще».

По остальным параметрам ориентируйтесь так:

8 ГБ памяти звучит скромно, но для 3-4 лёгких VM и пары LXC-контейнеров этого достаточно — просто не рассчитывайте поднять одновременно десяток тяжёлых сервисов. SSD важен даже больше, чем много ядер: диск на HDD ощутимо тормозит и загрузку системы, и снапшоты, и вообще всю отзывчивость интерфейса.

Отдельный совет: не покупайте железо специально под лабораторию, если у вас уже есть что-то простаивающее. Старый игровой ПК, который родственники «отдали, потому что медленный» — отличный кандидат. Понять, действительно ли вам нужно что-то мощнее, вы сможете только после нескольких месяцев практики, когда упрётесь в реальные ограничения, а не воображаемые.

Установка Proxmox: с чего начать

Сама установка Proxmox VE не сложнее установки любого Linux-дистрибутива: скачиваете ISO, пишете на флешку, грузитесь с неё, отвечаете на несколько вопросов мастера — диск, сеть, пароль root. Через 10-15 минут у вас уже работает веб-интерфейс на порту 8006, а первую виртуальную машину можно поднять в течение получаса. Подробный пошаговый разбор установки и создания первой VM мы уже разбирали в статье Proxmox VE с нуля: первая виртуалка за 20 минут — не будем дублировать её здесь, лучше сосредоточимся на том, что делать после установки.

Единственный момент, специфичный именно для домашней лабы: если у вас один сетевой порт и роутер раздаёт IP по DHCP, проще всего один раз зарезервировать за MAC-адресом вашего сервера постоянный IP в настройках роутера — так веб-интерфейс Proxmox всегда будет доступен по одному и тому же адресу, и вы не будете каждый раз гадать, куда переехал сервер после перезагрузки.

Первые VM: пробуем разные дистрибутивы

Первое, ради чего стоит завести домашнюю лабу — это возможность держать под рукой сразу несколько операционных систем и переключаться между ними без переустановки. Начните с простого:

• разверните Ubuntu Server (самый распространённый вариант, много документации);
• рядом — Debian (более консервативный, ближе к тому, что часто стоит на реальных серверах);
• если интересно — Rocky Linux или AlmaLinux (RHEL-совместимые, другая экосистема пакетов, другой firewall по умолчанию);
• для сравнения — Alpine Linux (минимализм, musl вместо glibc, полезно понять разницу на практике).

Смысл не в том, чтобы держать их все одновременно постоянно, а в том, чтобы почувствовать разницу: разный менеджер пакетов (apt vs dnf vs apk), разное поведение systemd, разные дефолтные firewall (ufw vs firewalld vs iptables вручную). Когда вы разворачиваете сервис на «незнакомом» дистрибутиве в первый раз, вы гораздо быстрее учитесь гуглить правильные вещи и понимать логику системы, а не просто копировать команды.

Практический совет: перед тем как ставить систему «набело», один раз потратьте время на шаблон VM (Proxmox поддерживает клонирование и шаблоны). Настроили один раз базовую Ubuntu с нужными пакетами и SSH-ключами — сохранили как шаблон — дальше разворачиваете новые VM за минуту клонированием, а не проходите установку заново каждый раз.

LXC-контейнеры: практика без лишнего оверхеда

После пары VM обязательно попробуйте LXC-контейнеры — это второй столп Proxmox, и в домашней лабе он особенно уместен. LXC-контейнер не тащит за собой отдельное ядро и виртуальное железо, стартует за секунды и почти не расходует ресурсы в простое — идеально, когда на скромном железе хочется держать одновременно много мелких сервисов: DNS-фильтр, домашний Git-сервер, мониторинг, тестовый веб-сервер.

Разница между LXC и полноценной VM — не абстрактная теория, а то, что реально стоит прочувствовать руками именно в лаборатории, пока цена ошибки нулевая. Мы разбирали механику подробнее в статье LXC против виртуальной машины: разница на практике — если не уверены, когда что выбирать, полезно прочитать до того, как начнёте плодить десяток контейнеров.

Практическое правило для домашней лабы: для всего лёгкого и линуксового (веб-сервер, прокси, DNS, мелкий скрипт по расписанию) — берите LXC, экономите ресурсы. Для всего, что требует изоляции на уровне ядра, отдельного ядра как такового (не-Linux система), или где вы специально тестируете поведение целой ОС — берите VM.

Домашний сервис на практике: медиасервер и хранилище

Голая практика без цели быстро надоедает — гораздо интереснее, когда лаборатория решает реальную бытовую задачу. Два классических первых проекта:

Медиасервер. Поднимите Jellyfin или Plex в отдельной VM или LXC, подключите к нему папку с фильмами/сериалами (через bind-mount, если это LXC, или через отдельный виртуальный диск в VM), настройте доступ из локальной сети с телевизора или телефона. Это простая, но полноценная задача: установка пакета, настройка сети, транскодирование, права доступа к файлам — всё как в «настоящем» проекте, только без давления продакшна.

Файловое хранилище. Разверните Samba или NFS-шару в отдельном контейнере, чтобы иметь общую сетевую папку для всех устройств дома — резервные копии с ноутбука, общий архив фото, рабочие файлы. Здесь же удобно попробовать подключить второй диск именно под данные, отдельно от системного — ровно та практика с разделением «система/данные», которая потом пригодится и на реальном сервере.

Оба проекта дают конкретный, ощутимый результат — не абстрактную «виртуалку с Ubuntu», а сервис, которым вы реально пользуетесь каждый день. Это сильно повышает мотивацию разбираться дальше, когда что-то не заработало с первого раза.

Снапшоты: экспериментируйте без страха всё сломать

Вот где домашняя лаборатория раскрывается по-настоящему — это безопасная площадка для того, чтобы наконец разобраться, как на самом деле работают снапшоты, а не бояться их трогать на проде. Перед любым рискованным экспериментом (обновление системы, смена конфигурации сети, тест непонятного скрипта из интернета) сделайте снапшот прямо из веб-интерфейса Proxmox — одна кнопка, несколько секунд.

Дальше — экспериментируйте осознанно:

• сломайте что-нибудь специально (удалите системный пакет, поломайте fstab) и откатитесь снапшотом — почувствуйте, что откат действительно работает и насколько быстро;
• попробуйте сделать несколько снапшотов подряд и посмотреть, как растёт объём, занимаемый дельтами;
• если ваше хранилище на LVM-thin или ZFS — сравните поведение снапшотов на них: некоторые типы хранилищ вообще не поддерживают снапшоты VM (например, обычный LVM без thin-provisioning или простой каталог), и лучше узнать об этом заранее в лаборатории, чем в момент, когда снапшот реально понадобился.

Мы отдельно разбирали механику снапшотов — что это на самом деле копия изменений, а не полная копия диска, и в каких случаях они могут неожиданно тормозить или занимать больше места, чем ожидалось — в статье Снапшоты в Proxmox: как они устроены и когда опасны. Домашняя лаба — идеальное место прочитать её и сразу проверить всё руками, а не поверить на слово.

Бюджет и приоритеты: не гонитесь за enterprise сразу

Рано или поздно захочется «настоящего» опыта — кластера из нескольких узлов, распределённого хранилища Ceph, отказоустойчивости с автоматической миграцией VM между серверами. Это нормальное желание, но для одного домашнего сервера оно преждевременно и часто просто вредно:

• кластер из двух узлов Proxmox не даёт полноценной отказоустойчивости — там своя механика кворума, и без третьего узла (или голосующего устройства) вы рискуете словить ситуацию хуже, чем при одном сервере; мы разбирали это подробно в статье Кластер Proxmox из двух узлов: почему это плохая идея;
• Ceph требует минимум 3 узла с приличным сетевым каналом между ними и ощутимо нагружает диски — на одном домашнем сервере он не просто избыточен, а физически не имеет смысла (Ceph — про распределённость, а распределять на одной машине нечего).

Честный план для домашней лаборатории выглядит скучнее, но работает лучше:

1. Один узел Proxmox. Разберитесь с VM, LXC, сетью (мосты, VLAN при желании), снапшотами и бэкапами до автоматизма.
2. Простое хранилище — локальный SSD/NVMe плюс, возможно, отдельный диск под данные. Без RAID-контроллеров и экзотики.
3. Регулярные бэкапы средствами Proxmox (встроенный vzdump или отдельный Proxmox Backup Server) — да, даже в домашней лабе, потому что привычка бэкапиться должна формироваться на несерьёзных данных, а не когда цена ошибки реальна.
4. Только когда всё это стало рутиной и скучным — переходите к следующему уровню: второй узел, тестовый кластер, эксперименты с сетевой изоляцией VLAN, попытки понять Ceph хотя бы теоретически.

Никто не проверяет ваше домашнее железо на сертификат enterprise-уровня. Задача лаборатории — не повторить продакшн один в один, а дать вам набить руку на настоящих, а не выдуманных ошибках: перепутали диск при клонировании VM, забыли снапшот перед обновлением, неправильно настроили мост и потеряли сеть до сервера. Именно эти шишки, набитые дома без последствий, экономят часы (а иногда и деньги) потом — на реальной рабочей инфраструктуре, будь то свой сервер или арендованный VPS.

Частые вопросы