Основы работы с гипервизором Proxmox VE: от установки до запуска сервисов

Введение в Proxmox VE: архитектура и подготовка к установке

Представьте, что у вас есть старый системный блок или мощный сервер, на котором вы хотите запустить одновременно медиасервер, блокировщик рекламы на всю сеть, файловое хранилище и тестовую лабораторию для изучения Linux. Обычно для этого потребовалось бы несколько физических компьютеров или сложная настройка операционной системы, где сервисы могут конфликтовать друг с другом. Proxmox Virtual Environment (PVE) решает эту задачу, превращая «железо» в гибкую ферму ресурсов, где каждая задача изолирована и работает в своей среде.

В основе Proxmox VE лежит идея объединения двух миров: тяжеловесной, но универсальной виртуализации и легкой, производительной контейнеризации. Это не просто программа, которую вы устанавливаете поверх Windows или Ubuntu. Это полноценный дистрибутив операционной системы на базе Debian GNU/Linux, который берет на себя управление процессором, оперативной памятью и дисками, чтобы распределять их между вашими цифровыми проектами.

Философия гипервизора первого типа

В мире ИТ существует разделение гипервизоров на два типа. Гипервизоры второго типа (Type 2) работают как обычные приложения внутри вашей основной ОС. Примерами могут служить Oracle VirtualBox или VMware Workstation. Они удобны для тестов «на скорую руку», но обладают низкой производительностью, так как каждый запрос виртуальной машины проходит через длинную цепочку: гостевая ОС → гипервизор → основная ОС (хост) → аппаратное обеспечение.

Proxmox VE относится к гипервизорам первого типа (Type 1) или «bare-metal» гипервизорам. Он устанавливается непосредственно на физическое оборудование. Хотя технически внутри Proxmox работает ядро Linux, система оптимизирована так, чтобы минимизировать задержки и накладные расходы. В этой схеме путь сокращается: гостевая система взаимодействует с гипервизором, который имеет прямой доступ к ресурсам процессора и памяти.

Такой подход обеспечивает стабильность корпоративного уровня. Если в вашей «домашней лаборатории» зависнет графическая оболочка на Windows, это может потянуть за собой VirtualBox. В Proxmox графической оболочки на самом сервере по умолчанию нет — управление происходит через веб-интерфейс с другого устройства, что высвобождает ресурсы для реальных задач.

Архитектурные столпы: KVM против LXC

Главная особенность Proxmox VE — его «двустворчатая» архитектура. Разработчики интегрировали в одну панель управления две принципиально разные технологии. Понимание разницы между ними критично еще на этапе планирования установки.

KVM (Kernel-based Virtual Machine)

Это технология полной виртуализации. Когда вы создаете VM (виртуальную машину) на базе KVM, гипервизор эмулирует полноценный компьютер с виртуальным BIOS/UEFI, сетевой картой и диском. * Преимущества: Вы можете запустить любую операционную систему — Windows, FreeBSD, Android или экзотические сборки Linux. Гостевая ОС «думает», что она работает на реальном железе. * Недостатки: Высокие накладные расходы. Каждая VM требует выделения фиксированного объема оперативной памяти, который она забирает у хоста сразу, и запускает собственное ядро, что замедляет старт.

LXC (Linux Containers)

В отличие от VM, контейнеры не эмулируют оборудование. Они используют ядро основной системы (хоста) Proxmox, но изолируют файловую систему и процессы. * Преимущества: Потрясающая скорость и эффективность. Контейнер запускается за 1–2 секунды и потребляет ровно столько оперативной памяти, сколько нужно его процессам в данный момент. Если вы выделили контейнеру 4 ГБ RAM, а он использует 200 МБ, остальные 3.8 ГБ остаются доступны другим задачам. * Недостатки: В контейнере можно запустить только Linux. Вы не сможете запустить Windows внутри LXC. Кроме того, поскольку ядро общее, теоретически контейнеры менее изолированы с точки зрения безопасности, чем полные виртуальные машины.

Системные требования и выбор аппаратной платформы

Proxmox VE базируется на Debian и использует ядро с долгосрочной поддержкой (LTS), что делает его совместимым с огромным спектром оборудования. Однако для комфортной работы «с нуля» стоит ориентироваться на определенные параметры.

Процессор (CPU)

Главное требование — поддержка технологий виртуализации. У Intel это Intel VT-x, у AMD — AMD-V. Без этих инструкций в BIOS/UEFI вы не сможете запускать 64-битные виртуальные машины через KVM. * Минимум: 64-битный процессор (даже старый Core i3 или Athlon). * Рекомендация: Чем больше ядер, тем лучше. Proxmox позволяет делать «переподписку» (overprovisioning) по ядрам — например, выделить 8 виртуальных ядер на 4 физических, если нагрузки не пиковые.

Оперативная память (RAM)

Это самый дефицитный ресурс в виртуализации. * Минимум: 2 ГБ для самой системы (Proxmox «прожорлив» к памяти, если использовать файловую систему ZFS). * Рекомендация: Для домашнего сервера оптимально начинать с 16 ГБ или 32 ГБ. Помните, что ZFS (продвинутая система хранения) по умолчанию может забирать до 50% оперативной памяти под кэш чтения (ARC), хотя это значение можно ограничить.

Дисковая подсистема

Proxmox крайне чувствителен к скорости записи логов и баз данных конфигурации. * Избегайте: Установки на USB-флешки или дешевые SD-карты. Они быстро выходят из строя из-за интенсивной записи. * Рекомендация: Используйте SSD для системного раздела и хранения образов виртуальных машин. Для архивных данных и бэкапов отлично подойдут классические HDD. Если вы планируете использовать ZFS для отказоустойчивости, выбирайте диски корпоративного класса или хотя бы те, что не используют технологию SMR (Shingled Magnetic Recording), иначе производительность упадет до нуля при перестроении массива.

Сеть

Минимум один гигабитный порт Ethernet. Proxmox управляется через веб-интерфейс, поэтому серверу необходим стабильный доступ в локальную сеть. Использование Wi-Fi для хоста виртуализации крайне не рекомендуется из-за нестабильности задержек и сложностей в настройке сетевых мостов (bridges).

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

Перед тем как записывать образ на флешку, необходимо выполнить ряд подготовительных действий, которые избавят вас от проблем в будущем.

Обновление BIOS/UEFI: Убедитесь, что на материнской плате стоит последняя версия прошивки. Это часто решает проблемы с совместимостью контроллеров дисков и стабильностью работы процессора.

Настройка параметров BIOS:

* Включите Virtualization Technology (Vanderpool, VT-x или AMD-V). * Включите IOMMU (необходимо, если вы захотите «пробросить» видеокарту или USB-контроллер напрямую в виртуальную машину). * Установите режим работы SATA-контроллера в AHCI (не RAID, если планируете использовать программный RAID от Proxmox/ZFS). * Отключите Secure Boot, если установщик Proxmox не запускается (хотя современные версии поддерживают его, иногда возникают конфликты с драйверами).

Выбор сетевых параметров: Proxmox требует статический IP-адрес. Заранее определите, какой адрес вы выделите серверу (например, 192.168.1.100), узнайте адрес шлюза (вашего роутера) и DNS-сервера (обычно совпадает с роутером или 8.8.8.8).

Создание загрузочного носителя

Для установки используется официальный ISO-образ Proxmox VE. На текущий момент актуальна ветка 8.x, основанная на Debian 12 "Bookworm".

Для записи образа рекомендуется использовать утилиту BalenaEtcher или Rufus (в режиме DD). Если вы опытный пользователь Linux, команда dd в терминале будет самым надежным способом:

dd bs=4M if=proxmox-ve_*.iso of=/dev/sdX status=progress oflag=sync

Здесь /dev/sdX — путь к вашей флешке. Будьте предельно внимательны: ошибка в одной букве может привести к удалению данных с вашего основного диска.

Понимание структуры хранения данных

Важный нюанс, который часто путает новичков: Proxmox разделяет место на диске на «хранилища» (Storages). При установке по умолчанию система создает два типа областей:

local: Здесь хранятся ISO-образы (установочные файлы ОС), шаблоны контейнеров и бэкапы. Это обычная файловая система.

local-lvm (или local-zfs): Это блочное хранилище, предназначенное исключительно для дисков виртуальных машин. Вы не увидите файлы внутри него через обычный проводник, так как данные пишутся напрямую в тома для максимальной скорости.

Если вы устанавливаете систему на один диск, Proxmox автоматически предложит схему разделов. Если дисков несколько, на этапе установки можно выбрать создание зеркала (RAID 1) для системного диска, что защитит сервер от остановки при выходе одного накопителя из строя.

Сетевая модель: Linux Bridge

Сразу после установки Proxmox создаст виртуальный коммутатор — vmbr0. Представьте его как невидимый физический свитч, который «вставлен» в вашу реальную сетевую карту. Все создаваемые в будущем виртуальные машины будут «подключаться» кабелями к этому виртуальному свитчу.

Это позволяет виртуальным машинам получать IP-адреса напрямую от вашего домашнего роутера, как если бы они были отдельными физическими устройствами в комнате. Такая прозрачность упрощает доступ к сервисам, но требует аккуратности: если вы случайно запустите в виртуальной машине второй DHCP-сервер, он может нарушить работу всей домашней сети.

Почему не просто Debian?

Частый вопрос: «Если Proxmox базируется на Debian, почему бы просто не установить Debian и накатить туда KVM?». Ответ кроется в экосистеме. Proxmox предоставляет: * Удобный веб-интерфейс, заменяющий сотни строк в конфигурационных файлах. * Встроенную систему бэкапов и репликации. * Инструменты для объединения нескольких серверов в кластер. * Готовые шаблоны LXC-контейнеров (TurnKey Linux), позволяющие развернуть WordPress или базу данных в один клик.

Proxmox превращает разрозненные инструменты Linux в цельный программный продукт, готовый к эксплуатации «из коробки», сохраняя при этом полный доступ к консоли для тонкой настройки.

Завершая подготовку, убедитесь, что у вас есть монитор и клавиатура, подключенные к будущему серверу. Они понадобятся только один раз — в процессе установки. Как только на экране появится приветствие с IP-адресом и портом 8006, вы сможете отключить периферию и управлять сервером из любой точки вашего дома через браузер.

Развертывание системы на «железо» и навигация по веб-интерфейсу управления

Экран гаснет, появляются бегущие строки загрузки ядра Linux, и сервер перестает быть просто набором микросхем. Установка гипервизора первого типа — это момент, когда физическое оборудование полностью передается под контроль специализированной операционной системы. Proxmox VE базируется на дистрибутиве Debian, поэтому его инсталлятор надежен, предсказуем, но требует предельной внимательности на этапе разметки дисков и настройки сети, поскольку изменить эти базовые параметры «на лету» без остановки будущих сервисов будет крайне сложно.

Процесс установки: от флешки до перезагрузки

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

Лицензионное соглашение и выбор целевого диска

Первый смысловой шаг после принятия EULA — выбор накопителя, на который будет установлена система. Инсталлятор сканирует все подключенные диски и предлагает выбрать один из них в выпадающем списке «Target Harddisk».

Рядом с выпадающим списком находится кнопка «Options», скрывающая критически важные настройки. По умолчанию Proxmox форматирует выбранный диск в файловую систему ext4 и использует технологию LVM (Logical Volume Manager) для создания разделов под саму ОС и под хранилище виртуальных машин. Если сервер оснащен несколькими одинаковыми дисками и планируется использование программного RAID, именно в меню «Options» необходимо сменить файловую систему с ext4 на ZFS (например, RAID1 для зеркалирования двух дисков).

Если установка производится на единственный SSD-накопитель, стандартные настройки ext4 вполне оправданы для домашней лаборатории. Инсталлятор автоматически разметит диск, выделив место под корневой раздел /, раздел подкачки (swap) и локальное хранилище local-lvm для образов виртуальных машин.

Локализация и аутентификация

Следующие экраны запрашивают страну, часовой пояс и раскладку клавиатуры. Часовой пояс критически важен: если время на хосте будет рассинхронизировано с реальным, это приведет к сбоям в криптографических протоколах, ошибкам при обновлении системы и неверным временным меткам в логах резервного копирования.

Экран пароля администратора (root) требует ввода надежной комбинации и адреса электронной почты. Email здесь — не формальность. Встроенные механизмы мониторинга Proxmox будут отправлять на этот адрес уведомления о завершении резервного копирования, сбоях дисков (S.M.A.R.T. ошибки) и доступных системных обновлениях.

Сетевая конфигурация

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

Инсталлятор потребует заполнить следующие поля:

Management Interface: Физическая сетевая карта, к которой подключен кабель.

Hostname (FQDN): Полное доменное имя сервера. Оно должно состоять минимум из двух частей, разделенных точкой. Использовать просто proxmox нельзя, система выдаст ошибку. Для домашней сети отлично подойдет формат pve.local или server.home.lan.

IP Address: Статический адрес, например, 192.168.1.100. Убедитесь, что этот адрес находится вне пула, который ваш роутер раздает по DHCP, чтобы избежать конфликта IP-адресов.

Gateway: IP-адрес вашего роутера (обычно 192.168.1.1).

DNS Server: Сервер разрешения имен. Можно указать адрес роутера или публичные DNS, например, 8.8.8.8.

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

Первый вход и преодоление барьеров безопасности

Когда сервер загрузится, на подключенном мониторе появится черная консоль с приглашением ко входу и текстовым сообщением, указывающим адрес для управления. Выглядит он так: https://192.168.1.100:8006/.

Управление Proxmox осуществляется исключительно через веб-браузер с другого компьютера в той же сети. При попытке открыть указанный адрес браузер неизбежно выдаст предупреждение о нарушении конфиденциальности: «Подключение не защищено» или «ERR_CERT_AUTHORITY_INVALID».

Это нормальное поведение. Proxmox VE использует протокол HTTPS для шифрования трафика между вашим компьютером и сервером. Для работы HTTPS нужен SSL-сертификат. Поскольку сервер только что установлен, он сгенерировал так называемый «самоподписанный» сертификат. Браузеры не доверяют таким сертификатам, так как они не заверены глобальными удостоверяющими центрами. Для продолжения работы нужно нажать «Дополнительные настройки» и выбрать «Перейти на сайт (небезопасно)».

На странице авторизации необходимо ввести:

User name: root

Password: пароль, заданный при установке.

Realm: Linux PAM standard authentication (оставить по умолчанию, это означает аутентификацию через локальную базу пользователей Linux).

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

Сразу после входа появится всплывающее окно: «No valid subscription» (Нет действующей подписки). Proxmox VE — полностью бесплатный продукт с открытым исходным кодом, но компания-разработчик продает коммерческую поддержку и доступ к проверенным корпоративным репозиториям обновлений (Enterprise Repository). Это окно — просто напоминание о том, что вы используете бесплатную версию без технической поддержки. Окно можно смело закрывать, оно не ограничивает функциональность гипервизора.

Анатомия веб-интерфейса

Интерфейс Proxmox VE визуально перегружен кнопками, графиками и таблицами, что часто отпугивает новичков. Однако он имеет строгую логическую структуру, основанную на концепции кластера.

Даже если у вас всего один физический сервер (нода), Proxmox всё равно мыслит категориями датацентра. Это сделано для того, чтобы при добавлении второго, третьего и десятого серверов интерфейс оставался неизменным.

!Иерархия объектов в интерфейсе Proxmox VE

Левая панель (Server View) — это дерево объектов, отражающее иерархию системы:

Datacenter (Датацентр): Глобальный уровень. Настройки, примененные здесь, затрагивают весь кластер. Здесь настраиваются резервное копирование, пользователи, группы, двухфакторная аутентификация и глобальный брандмауэр.

Node (Узел - например, pve): Уровень конкретного физического сервера. Перейдя сюда, вы управляете железом именно этой машины: дисками, сетевыми картами, оперативной памятью, обновлениями ОС и системным временем.

VMs / Containers (Виртуальные машины и контейнеры): Вычислительные сущности, работающие на узле.

Storage (Хранилища): Подключенные дисковые массивы, локальные папки или сетевые диски, где лежат образы CD-ROM, бэкапы и виртуальные жесткие диски.

Центральная панель меняет свое содержимое в зависимости от того, какой объект выбран в левом дереве. Если выбрать узел (Node) и нажать вкладку Summary, отобразятся графики загрузки процессора, потребления оперативной памяти и график сетевого трафика. Вкладка Shell предоставляет полноценный доступ к командной строке сервера прямо в окне браузера. Это избавляет от необходимости подключаться к серверу по SSH через сторонние программы вроде PuTTY.

Настройка репозиториев: подготовка к обновлениям

Сразу после установки система настроена на получение обновлений из репозитория Enterprise. Поскольку коммерческой подписки у нас нет, любая попытка обновить систему завершится ошибкой — сервер получит отказ в доступе (401 Unauthorized) при обращении к серверам Proxmox.

Чтобы сервер мог получать обновления безопасности и новые функции, необходимо переключить его на бесплатный репозиторий No-Subscription. Это официальный источник пакетов, который содержит те же обновления, что и Enterprise, но они не прошли столь длительного тестирования в корпоративных средах. Для домашней лаборатории это идеальный вариант.

Процесс переключения выполняется через графический интерфейс:

В левом меню выберите ваш узел (Node).

В центральном меню разверните раздел Updates и выберите подраздел Repositories.

В списке вы увидите репозиторий с компонентом pve-enterprise. Выделите его и нажмите кнопку Disable в верхней части окна.

Нажмите кнопку Add, в появившемся окне выберите из списка No-Subscription и нажмите Add.

Также на этом экране может присутствовать предупреждение об отсутствии подписки на репозиторий ceph-enterprise (технология распределенного хранения данных). Если Ceph не используется, этот репозиторий также следует отключить.

После настройки источников пакетов необходимо загрузить сами обновления. Это можно сделать через кнопку Refresh в разделе Updates, а затем нажать Upgrade, что откроет окно консоли с запущенным процессом обновления.

Альтернативный и более прозрачный способ — использовать встроенную веб-консоль. Перейдя во вкладку Shell узла, достаточно ввести классическую команду Debian: apt update && apt dist-upgrade -y

Команда apt update скачивает актуальные списки пакетов из новых репозиториев, а apt dist-upgrade устанавливает их, корректно обрабатывая изменения в зависимостях (например, при установке нового ядра Linux). После завершения процесса обновления, особенно если было установлено новое ядро (пакет pve-kernel), сервер рекомендуется перезагрузить кнопкой Reboot в правом верхнем углу интерфейса.

Теперь гипервизор установлен на физическое оборудование, подключен к сети, обновлен до актуальной версии и готов к работе. Навигация по интерфейсу перестает казаться хаотичной, когда становится понятна логика разделения глобальных настроек (Datacenter) и локальных ресурсов конкретной машины (Node). Следующим шагом станет подготовка фундамента для виртуальных машин — создание виртуальных сетей и организация дискового пространства для безопасного хранения данных.

Конфигурация дисковых подсистем, хранилищ и виртуальных сетевых интерфейсов

Свежеустановленный сервер Proxmox VE с NVMe-накопителем на 500 ГБ и жестким диском на 2 ТБ таит в себе неочевидную проблему: если просто начать создавать виртуальные машины, место на быстром диске закончится гораздо раньше, чем вы ожидаете, а попытка загрузить ISO-образ операционной системы на свободное пространство выдаст ошибку. Гипервизор не воспринимает физические диски как единую «папку» для всего подряд. Эффективность работы виртуальной лаборатории зависит от того, насколько точно дисковые массивы и сетевые интерфейсы распределены по своим ролям.

Иерархия хранилищ: Datacenter и Node

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

Такое разделение необходимо для кластеризации. Если у вас несколько серверов, общее сетевое хранилище (например, NFS-шара) добавляется один раз в Datacenter, и сразу становится доступным всем узлам кластера. Для одиночного домашнего сервера это означает двухэтапный процесс: сначала мы подготавливаем диск в меню узла, а затем указываем его роль в меню Datacenter.

По умолчанию после установки система автоматически создает два хранилища на системном диске: local и local-lvm. Они имеют принципиально разную архитектуру и предназначение, что подводит нас к главному разделению дисковых подсистем.

Файловые и блочные хранилища

Все хранилища в Proxmox делятся на две категории, определяющие, как именно данные записываются на физический носитель.

Файловые хранилища (File-level storage) работают поверх существующей файловой системы (ext4, xfs, zfs). Гипервизор создает в них обычные файлы. Хранилище local (тип Directory) — это просто папка /var/lib/vz на системном диске. В файловых хранилищах размещают:

ISO-образы для установки ОС.

Шаблоны LXC-контейнеров.

Файлы резервных копий (vzdump).

Виртуальные диски в формате qcow2.

Формат qcow2 удобен тем, что поддерживает снапшоты (снимки состояния) на уровне самого файла, но работа поверх файловой системы хоста создает дополнительные накладные расходы (overhead) на операции ввода-вывода.

Блочные хранилища (Block-level storage) работают напрямую с блочными устройствами, минуя прослойку в виде файловой системы хоста. Виртуальная машина получает сырой кусок диска (том) и сама форматирует его в NTFS, ext4 или любую другую нужную ей систему. Блочные хранилища используются исключительно для:

Виртуальных жестких дисков (в формате raw).

Корневых файловых систем LXC-контейнеров.

Отсутствие промежуточной файловой системы делает блочные хранилища значительно быстрее, что критично для баз данных и высоконагруженных сервисов внутри виртуальных машин. Хранилище local-lvm относится именно к этому типу.

Глубокий разбор: LVM против LVM-Thin

Технология LVM (Logical Volume Manager) позволяет объединять физические диски в единое пространство и нарезать его на логические тома. В Proxmox используется две реализации этой технологии, и разница между ними определяет стратегию распределения ресурсов.

Классический LVM использует «толстое» выделение (Thick provisioning). Если вы создаете виртуальную машину и выделяете ей диск на 100 ГБ, классический LVM немедленно резервирует эти 100 ГБ на физическом носителе. Даже если внутри гостевой ОС занято всего 5 ГБ, для гипервизора эти 100 ГБ уже недоступны. Это гарантирует, что машине всегда хватит заявленного места, но крайне неэффективно расходует дисковое пространство. Кроме того, классический LVM в Proxmox не поддерживает создание снапшотов виртуальных машин.

LVM-Thin решает обе эти проблемы за счет «тонкого» выделения (Thin provisioning).

!Сравнение LVM и LVM-Thin

При использовании LVM-Thin выделение 100 ГБ виртуальной машине означает лишь установку лимита. Физическое пространство будет заниматься только по мере реальной записи данных гостевой операционной системой. Это открывает возможность для переподписки (Overprovisioning). На физическом SSD объемом 250 ГБ можно создать пять виртуальных машин по 100 ГБ каждая. Пока суммарный объем реально записанных ими данных не превысит 250 ГБ, система будет работать штатно.

Обратная сторона LVM-Thin — риск исчерпания физического пространства. Если физический диск заполнится на 100%, все виртуальные машины, попытавшиеся записать новые данные, будут экстренно приостановлены гипервизором с ошибкой ввода-вывода (I/O error) во избежание повреждения данных. Администратор домашней лаборатории должен самостоятельно следить за метрикой использования пула LVM-Thin.

Добавление новых накопителей

Возвращаясь к нашему серверу с дополнительным жестким диском на 2 ТБ: чтобы задействовать его, необходимо пройти процедуру инициализации через веб-интерфейс.

В разделе узла (Node) -> Disks отображаются все физические накопители. Если диск содержит старые разделы, его необходимо очистить кнопкой «Wipe Disk». После этого принимается решение о типе хранилища.

Для создания файлового хранилища (под бэкапы и ISO) диск инициализируется через меню Disks -> Directory. Proxmox отформатирует его в ext4, смонтирует в директорию /mnt/pve/имя_хранилища и автоматически добавит в Datacenter.

Для создания современной дисковой подсистемы с защитой от "bit rot" (скрытого повреждения данных) используется меню Disks -> ZFS. При создании ZFS-пула (vdev) гипервизор позволяет выбрать уровень избыточности. Для одного диска это будет тип Single-Disk. Если установлено два одинаковых диска, интерфейс предложит Mirror (аналог RAID 1). Созданный ZFS-пул автоматически становится доступным для размещения виртуальных машин. Важно помнить, что ZFS в Proxmox по умолчанию работает как блочное хранилище (zvol) для дисков виртуальных машин, обеспечивая тонкое выделение и поддержку моментальных снимков за счет архитектуры самой файловой системы ZFS.

Виртуальные сетевые интерфейсы и мосты

Дисковая подсистема обеспечивает хранение, а сетевая — коммуникацию. В основе сетевой архитектуры Proxmox лежит концепция Linux Bridge (сетевого моста).

Сетевой мост — это программный коммутатор (свитч) второго уровня модели OSI, работающий внутри ядра Linux. При установке Proxmox автоматически создает мост с именем vmbr0 и подключает к нему основной физический сетевой интерфейс сервера (например, enp3s0).

!Схема работы сетевого моста vmbr0

Когда создается виртуальная машина, гипервизор генерирует для нее виртуальную сетевую карту (vNIC) с собственным MAC-адресом. Эта виртуальная карта подключается к программному мосту vmbr0. С точки зрения вашего домашнего роутера, сервер Proxmox и все запущенные на нем виртуальные машины подключены к одному физическому коммутатору. Роутер видит MAC-адреса виртуальных машин и выдает им независимые IP-адреса по DHCP, точно так же, как если бы это были отдельные физические компьютеры в вашей комнате.

Физический интерфейс, подключенный к мосту, переводится в неразборчивый режим (promiscuous mode). Это означает, что он начинает принимать все сетевые пакеты, приходящие на порт, а не только те, которые адресованы MAC-адресу самого сервера, и передает их в мост vmbr0, который уже решает, какой виртуальной машине адресован конкретный пакет.

Изоляция трафика: VLAN в домашней лаборатории

По мере роста домашней лаборатории возникает потребность в изоляции. Например, вы хотите отделить виртуальные машины, управляющие умным домом (IoT), от контейнеров с личными базами данных. Создавать для каждой сети отдельный физический интерфейс и отдельный мост нерационально. Эту задачу решает стандарт 802.1Q, или VLAN (Virtual Local Area Network).

В настройках моста vmbr0 в веб-интерфейсе есть чекбокс «VLAN aware» (поддержка VLAN). Если он включен, программный коммутатор начинает понимать тегированные пакеты.

При настройке сетевого интерфейса виртуальной машины появляется возможность указать VLAN Tag (VID) — число от 1 до 4094. Если указать, например, тег 10, гипервизор будет автоматически маркировать все исходящие пакеты этой ВМ тегом 10, а входящие пакеты с тегом 10 — направлять только ей. Таким образом, через один физический кабель и один мост vmbr0 можно пропустить десятки изолированных друг от друга виртуальных сетей. Главное условие — ваш физический роутер или коммутатор также должен поддерживать стандарт 802.1Q, чтобы правильно маршрутизировать этот тегированный трафик.

Тщательное планирование того, какие данные будут лежать на LVM-Thin для скорости, какие на Directory для удобства резервного копирования, и как их сетевой трафик будет изолирован через VLAN на мосту vmbr0, формирует надежный фундамент. Настроенная инфраструктура хранения и сети позволяет перейти к непосредственному конструированию сервисов, не опасаясь внезапной нехватки ресурсов или конфликтов IP-адресов.

Развертывание виртуальных машин и LXC-контейнеров: различия, создание и запуск

Сервер с 16 ГБ оперативной памяти может «задохнуться» от трех запущенных сервисов, а может легко и без задержек обслуживать два десятка. Эта разница возникает не из-за магии оптимизации кода, а на этапе архитектурного решения: как именно изолировать и запускать приложения. В Proxmox VE администратор постоянно балансирует между двумя инструментами — виртуальными машинами (VM) и контейнерами (LXC). Ошибка в выборе приводит либо к неоправданному перерасходу ресурсов процессора и диска, либо к проблемам с безопасностью и совместимостью.

Практический выбор: когда VM, а когда LXC

Хотя фундаментальная разница между аппаратной виртуализацией и изоляцией на уровне ядра уже ясна, на практике выбор сводится к оценке накладных расходов и требуемого уровня контроля.

Виртуальная машина эмулирует всё аппаратное обеспечение. Когда гостевая операционная система хочет записать данные на диск, запрос проходит через драйвер гостевой ОС, затем перехватывается гипервизором, транслируется в формат физического хранилища и только потом выполняется. Это создает задержки (overhead). Контейнер LXC обращается к ядру хоста напрямую.

!Сравнение стека выполнения VM и LXC

Правила выбора инструмента в домашней лаборатории:

| Критерий | Виртуальная машина (KVM) | Контейнер (LXC) | | :--- | :--- | :--- | | Операционная система | Любая (Windows, FreeBSD, любые дистрибутивы Linux, Mikrotik RouterOS). | Только дистрибутивы Linux (Debian, Ubuntu, Alpine, Arch и т.д.). | | Накладные расходы | Высокие. Гостевая ОС потребляет RAM и CPU просто для поддержания собственной работы. | Минимальные. Контейнер Alpine Linux после старта потребляет около 30 МБ оперативной памяти. | | Изоляция и безопасность | Строгая аппаратная изоляция. Взлом гостевой ОС не дает доступа к хосту. | Изоляция через пространства имен (namespaces). Риск выхода за пределы контейнера выше. | | Специфичные задачи | Запуск Docker-демонов (рекомендуется), маршрутизаторов (pfSense), систем умного дома (Home Assistant OS). | Легкие веб-серверы (Nginx), DNS-блокировщики (Pi-hole), базы данных, файловые серверы. |

Если сервис можно запустить в Linux и он не требует сложных манипуляций с модулями ядра (например, поднятия собственных VPN-туннелей WireGuard на низком уровне), приоритетным выбором всегда должен быть LXC.

Подготовка: ISO-образы и шаблоны

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

Для виртуальных машин используются классические ISO-образы — виртуальные оптические диски с установочными файлами ОС. Их необходимо скачивать с официальных сайтов разработчиков ОС и загружать в Proxmox через раздел local -> ISO Images -> Upload.

Для LXC используются CT Templates (шаблоны контейнеров). Это сжатые архивы (tar.gz или tar.zst), содержащие уже распакованную и настроенную файловую систему конкретного дистрибутива (rootfs). Proxmox умеет скачивать их самостоятельно: в разделе local -> CT Templates кнопка Templates открывает доступ к десяткам официальных сборок от разработчиков Proxmox и сообщества TurnKey Linux.

Создание виртуальной машины: анатомия настроек

Процесс создания ВМ (кнопка Create VM в правом верхнем углу) состоит из серии вкладок. Оставление всех параметров «по умолчанию» работает, но лишает систему производительности. Разберем критически важные настройки.

Вкладки General и OS

Помимо имени машины, здесь выбирается ISO-образ. Важный параметр — Guest OS Type. Если устанавливается Windows, выбор соответствующей версии адаптирует базовые параметры эмуляции под требования Microsoft.

Вкладка System

Здесь определяется виртуальное «железо» материнской платы.

Machine: Исторически стандартом была архитектура i440fx (эмуляция чипсета 1996 года). Для современных систем, особенно если планируется проброс физических PCI-устройств (видеокарт) внутрь ВМ, следует выбирать q35 (эмуляция современного PCIe-интерфейса).

BIOS: Стандартный SeaBIOS подходит для старых ОС. Для современных дистрибутивов и Windows 11 обязателен выбор OVMF (UEFI). При выборе UEFI потребуется добавить специальный диск EFI Storage (хранилище для загрузчика), разместив его на любом доступном диске.

QEMU Guest Agent: Эту галочку нужно ставить всегда, если в гостевую ОС планируется установить одноименную службу. Без агента гипервизор не знает IP-адрес машины и не может корректно заморозить файловую систему перед созданием резервной копии.

Вкладка Disks: qcow2 против raw

Здесь определяется формат виртуального жесткого диска. Выбор зависит от типа хранилища (файловое или блочное), на котором создается ВМ.

Если хранилище блочное (ZFS или LVM-Thin), формат всегда будет raw (сырые данные). Гипервизор просто выделяет кусок блочного устройства и отдает его машине. Это самый быстрый вариант с минимальными задержками.

Если хранилище файловое (Directory, NFS, SMB), появляется выбор между raw и qcow2. Формат qcow2 (QEMU Copy On Write) — это специализированный файл, который поддерживает внутренние снапшоты (снимки состояния) и тонкое выделение (thin provisioning) даже на тех файловых системах, которые сами по себе этого не умеют. Если создать диск qcow2 на 100 ГБ, изначально он займет на хосте несколько мегабайт и будет расти по мере записи данных. Файл raw на файловом хранилище сразу займет все 100 ГБ (если ФС не поддерживает sparse-файлы) и не позволит делать снимки состояния средствами Proxmox.

В поле Bus/Device критически важно выбрать VirtIO Block или SCSI (с контроллером VirtIO SCSI). Это паравиртуализованные интерфейсы. В отличие от эмуляции старых IDE или SATA дисков, VirtIO знает, что работает в виртуальной среде, и передает команды ввода-вывода напрямую гипервизору, минуя сложную трансляцию.

Вкладка CPU и Memory

Количество ядер (Cores) выделяется в зависимости от задач. Важно понимать, что ядра виртуальные (vCPU). Можно выделить четырем виртуальным машинам по 4 ядра, имея физически всего 4 ядра на сервере. Планировщик гипервизора будет распределять процессорное время между ними.

В настройках памяти скрыт мощный механизм — Ballooning Device (динамическое выделение памяти).

!Демонстрация работы механизма Memory Ballooning

Если задать ВМ максимум 4096 МБ и минимум 1024 МБ памяти с включенным Ballooning, произойдет следующее: при старте машина получит 4 ГБ. Если другие ВМ на сервере начнут испытывать нехватку оперативной памяти, гипервизор даст команду драйверу Balloon внутри нашей ВМ «надуть шар». Этот виртуальный драйвер запросит у гостевой ОС свободную память (например, 2 ГБ), заблокирует её и вернет гипервизору. Гостевая ОС будет считать, что память занята системным процессом, а гипервизор отдаст эти 2 ГБ нуждающейся машине. Когда нагрузка спадет, «шар сдуется», и память вернется первой ВМ.

Вкладка Network

Аналогично дискам, в поле Model следует выбирать VirtIO (paravirtualized). Эмуляция сетевых карт Intel E1000 или Realtek потребляет значительно больше ресурсов процессора хоста при высокой сетевой активности.

Создание LXC-контейнера: архитектура безопасности

Создание контейнера (кнопка Create CT) выглядит проще, так как мы не эмулируем железо. Пропускаются вкладки BIOS, Machine и контроллеров дисков. Но на первой же вкладке есть важнейший чекбокс, определяющий архитектуру безопасности: Unprivileged container (Непривилегированный контейнер).

По умолчанию чекбокс включен, и снимать его следует только в исключительных случаях.

В Linux права суперпользователя (root) привязаны к идентификатору пользователя (UID) равному 0. В привилегированном контейнере UID 0 внутри контейнера равен UID 0 на хост-сервере. Если злоумышленник найдет уязвимость в изоляции LXC и вырвется из контейнера, он окажется в системе Proxmox с полными правами администратора.

В непривилегированном контейнере используется механизм сдвига идентификаторов (UID mapping). Ядро Proxmox берет UID 0 внутри контейнера и проецирует его на безопасный, ничем не обладающий UID (например, 100000) на хосте. Внутри контейнера сервис «думает», что работает от имени root, имеет право биндить порты ниже 1024 и управлять своей изолированной файловой системой. Но если произойдет побег из контейнера, на хосте этот процесс окажется бесправным пользователем 100000, который не сможет даже прочитать системные логи сервера.

Расплата за безопасность непривилегированных контейнеров — сложности с монтированием сетевых шар (SMB/NFS) напрямую внутрь LXC и проблемы с пробросом специфичных физических USB-устройств. Права доступа файлов на таких устройствах не будут совпадать со сдвинутыми UID контейнера.

Вкладка Network в LXC позволяет сразу задать статический IP-адрес или выбрать DHCP, а также указать шлюз. В отличие от ВМ, где сеть настраивается внутри установленной ОС, Proxmox сам модифицирует конфигурационные файлы сети внутри rootfs контейнера перед его запуском.

Первичная эксплуатация и доступ

После создания и нажатия кнопки Start, получить доступ к экрану можно через раздел Console. Для ВМ Proxmox использует noVNC — HTML5-клиент, который транслирует изображение с виртуальной видеокарты прямо в браузер. Для LXC консоль открывает прямой доступ к tty (терминалу) контейнера.

Первое действие после установки любой гостевой ОС в виртуальную машину — установка QEMU Guest Agent. В дистрибутивах Linux это делается через пакетный менеджер (например, apt install qemu-guest-agent в Debian/Ubuntu). В Windows агент устанавливается с отдельного диска с драйверами VirtIO. После установки агента и его запуска на вкладке Summary виртуальной машины в веб-интерфейсе Proxmox появятся реальные IP-адреса гостевой ОС, а команды выключения (Shutdown) будут передаваться не через жесткое ACPI-событие нажатия кнопки питания, а через программный вызов, что гарантирует корректное завершение работы баз данных и системных служб.

Понимание разницы между эмуляцией и контейнеризацией, правильный выбор паравиртуализованных драйверов и настройка сдвига прав в LXC превращают Proxmox из простого запускатора образов в эффективную платформу, где каждый мегабайт оперативной памяти и каждый такт процессора расходуются строго на полезную нагрузку. Запущенные сервисы теперь работают стабильно, но любая аппаратная поломка диска или программный сбой внутри гостевой системы могут уничтожить данные, что подводит к необходимости организации надежного резервного копирования.