Запустится ли HA-VM на другом узле, если её диск локальный?

Зависит от заранее спроектированного хранения данных. Само членство узлов в кластере не делает локальный диск VM доступным на другом хосте. Для восстановления HA-ресурса нужны доступные на целевом узле данные и ресурсы: обычно общее хранилище либо предусмотренный сценарий локальной репликации. Одиночный локальный диск автоматически не переносится.

Можно ли выполнить Live Migration VM с локальными дисками?

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

Заменяет ли снимок виртуальной машины резервную копию?

Нет. Снимок фиксирует точку состояния VM в пределах возможностей выбранного хранилища, но не заменяет резервное копирование или план миграции. Для защиты данных нужны отдельное целевое хранилище, расписание создания копий, правила хранения точек восстановления и обязательная проверка фактического восстановления на тестовом объекте.

Нужно ли проверять восстановление из Proxmox Backup Server?

Да. Успешное создание резервной копии не доказывает готовность к восстановлению. Нужно восстановить тестовый объект и определить фактический срок восстановления. Proxmox Backup Server поддерживает дедупликацию, инкрементальную передачу, проверку целостности и политики хранения, но эти возможности не заменяют проверку того, что копия читается и нагрузка действительно восстанавливается.

Можно ли добавить в кластер Proxmox рабочий узел с существующими VM?

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

Можно ли установить Windows в Proxmox LXC?

Нет. LXC — системный Linux-контейнер, который использует ядро Linux-хоста, поэтому он не подходит для Windows и других ОС, требующих другого ядра. Для Windows следует создавать VM: она запускает собственную гостевую ОС и ядро, а также предоставляет более полную границу изоляции виртуального оборудования.

VM, LXC, кластер, HA и резервное копирование в Proxmox VE

После подготовки отдельного узла Proxmox VE не существует одной универсальной процедуры «настроить всё». Создание VM или LXC, построение кластера, высокая доступность и резервное копирование решают разные задачи и требуют разных предпосылок. Обычно сначала проверяют одиночный узел и готовят ресурсы для гостевых систем, затем настраивают резервное копирование, а кластер и HA вводят только по спроектированной архитектуре; если кластер запланирован изначально, VM и контейнеры разумнее создавать уже в нём.

О версиях и интерфейсе

Ниже описана логика, соответствующая документации ветки Proxmox VE 8 и Proxmox Backup Server 3. Доступные форматы, операции, параметры хранилищ и названия элементов веб-интерфейса зависят от минорного выпуска, типа storage и версии утилит. Перед выполнением операции сверяйте её с руководствами Proxmox VE Administration Guide, Proxmox VE Cluster Manager, Proxmox VE HA Manager и Proxmox Backup Server Administration Guide для установленного выпуска.

Условный порядок настройки Proxmox VE

Этот порядок — не линейная инструкция, а маршрут принятия решений. Один узел может быть достаточен для лаборатории, разработки или некритичного сервиса. Кластер имеет смысл строить не потому, что в него можно добавить хосты, а когда нужны централизованное управление несколькими узлами, плановые миграции либо автоматическое восстановление нагрузок после отказа.

Выберите следующий этап после готовности одиночного узла

Первичная установка, обновление, адрес управления и базовая проверка хоста рассмотрены в статье «Установка и первичная настройка Proxmox VE».

1
Зафиксируйте назначение нагрузки
Для каждой будущей нагрузки определите ОС, требуемую изоляцию, CPU, память, дисковую ёмкость, производительность дисков и сетевые подключения. Результат — карточка нагрузки с решением: VM, LXC или отдельный физический сервер. Если характеристики неизвестны, не назначайте ресурсы по шаблону: сначала измерьте текущую систему или проведите тест.
2
Подготовьте storage и сеть для гостя
Убедитесь, что выбранное хранилище допускает нужный тип содержимого: образы VM, rootfs контейнеров, ISO, шаблоны либо резервные копии. Проверьте свободное место с запасом под рост, операции копирования и снимки. Подготовьте виртуальную сеть: bridge, VLAN и uplink должны соответствовать схеме доступа гостя. Ожидаемый результат — в интерфейсе доступны целевое хранилище и сеть, а их назначение понятно. Детальная настройка сети вынесена в материал о виртуальных сетях VM.
3
Создайте тестовую VM или LXC
Создайте одну нагрузку выбранного типа, запустите её, проверьте загрузку ОС, сеть, запись на диск и штатное выключение. Это подтверждает готовность конкретной комбинации хранилища, bridge и ресурсов, но ещё не подтверждает готовность кластера или HA. При ошибке сначала локализуйте слой: хост, storage, виртуальная сеть или гостевая ОС.
4
Организуйте резервное копирование до критичной нагрузки
Настройте целевое хранилище резервных копий, расписание, retention — правила хранения точек восстановления — и проверку восстановления на тестовом объекте. Ожидаемый результат — существует читаемая резервная копия и понятен её фактический срок восстановления. Если копия создаётся, но восстановление не проверялось, готовность к восстановлению не доказана.
5
Только затем принимайте решение о кластере и HA
До создания кластера проверьте имена узлов, сеть Corosync, кворум, совместимость выпусков, размещение дисков и запас ресурсов после отказа узла. Если эти условия не выполнены, оставьте узел автономным либо доработайте архитектуру. Проектирование количества хостов, N+1-ёмкости и storage-схемы рассматривается в статье «Как спроектировать виртуальную инфраструктуру для продакшена и 1С».

Создать виртуальную машину Proxmox: что подготовить

Виртуальная машина в Proxmox VE запускается через QEMU с аппаратным ускорением KVM, если оно доступно на хосте. VM получает виртуальные vCPU, память, диски и сетевые адаптеры, поэтому может запускать ОС с ядром, отличным от ядра хоста: например, Windows или другой дистрибутив Linux.

Что должно быть определено до создания VM

Область	Что подготовить	Какой результат проверить
Вычислительные ресурсы	Число vCPU, объём памяти, допустимый рост и запас на хосте.	Запуск VM не приводит к дефициту памяти или постоянной конкуренции за CPU у уже работающих нагрузок.
Хранилище VM	Storage, поддерживающее дисковые образы VM; место для диска, роста и служебных операций.	На storage можно создать диск VM; объём не исчерпан в типичной рабочей нагрузке.
Источник установки	ISO-образ, подготовленный диск или образ, сетевая загрузка либо другой документированный для данного выпуска источник.	Источник доступен выбранной VM и проверена его совместимость с гостевой ОС.
Сеть	Виртуальный bridge и, при необходимости, VLAN, адресация, правила доступа и DNS.	Гость после запуска получает требуемую связность, не только доступ к консоли.
Драйверы и интеграция	Выбор контроллеров и сетевых устройств, драйверы гостевой ОС; при необходимости — QEMU Guest Agent.	ОС видит диск и сеть; средства управления получают ожидаемые сведения о госте.

В документации Proxmox VE 8 VM можно создать с установочным ISO, подключённым CD/DVD-источником, подготовленным виртуальным диском или образом, а также с сетевой загрузкой, если её поддерживают прошивка VM и инфраструктура. Сам объект VM можно создать и без установочного носителя: это полезно перед импортом диска, восстановлением из копии или последующим подключением образа. Конкретный набор источников и форматов зависит от версии PVE, выбранного storage и сценария импорта.

Cloud-Init не является установочным носителем

Cloud-Init передаёт параметры начальной конфигурации уже подготовленному совместимому образу VM: например, учётные данные, сеть или ключи. Он не заменяет ISO, импорт диска или развёртывание гостевой ОС.

Proxmox LXC: чем контейнер отличается от VM

LXC — системный Linux-контейнер. Он изолирует процессы, файловую систему и сеть, но использует ядро хоста. В типичном сценарии контейнер развёртывают из шаблона контейнера, доступного в хранилище шаблонов Proxmox VE. Другой штатный путь — восстановление контейнера из совместимой резервной копии; доступность прочих вариантов определяется конкретной версией и задачей.

Выбор между VM и LXC

Критерий	VM	LXC-контейнер
ОС и ядро	Запускает собственную гостевую ОС и её ядро.	Использует ядро Linux-хоста.
Типичное развёртывание	Установка из ISO, загрузка с подготовленного диска или образа, восстановление, импорт поддерживаемого диска.	Создание из шаблона контейнера либо восстановление из резервной копии.
Изоляция	Более полная граница виртуального оборудования и гостевой ОС.	Изоляция процессов при общем ядре; это другая модель доверия.
Ресурсные накладные расходы	Обычно выше из-за отдельной гостевой ОС и ядра.	Обычно ниже для сопоставимой Linux-нагрузки, но это не отменяет требований приложения к памяти и I/O.
Подходящие задачи	Windows, специализированные Linux-ядра, независимые системные окружения, нагрузки с повышенными требованиями к изоляции.	Типовые Linux-службы, которым подходит ядро хоста и модель контейнерной изоляции.

Когда LXC не заменяет полноценную VM

Не выбирайте LXC для Windows и других ОС, которым нужно иное ядро. Контейнер также не подходит, когда приложению требуются собственное ядро, несовместимые модули ядра, нестандартные низкоуровневые возможности или более жёсткая граница изоляции, чем может дать совместное ядро. «Легче VM» не означает «подходит для любой нагрузки».

Шаблон и клон позволяют разворачивать копии уже подготовленной системы, а снимок состояния фиксирует точку её состояния в пределах возможностей выбранного хранилища. Эти механизмы не взаимозаменяемы и не заменяют резервное копирование или план миграции. Их различия и ограничения рассмотрены в статье о клонах, шаблонах и снимках VM.

Что проверить до создания кластера Proxmox VE

Кластер Proxmox VE объединяет конфигурацию узлов через pmxcfs и использует Corosync для кластерного обмена. Он не превращает локальные диски в общее хранилище и не включает высокую доступность автоматически. Инициализация нового кластера на первом узле и присоединение узла к существующему кластеру — разные операции.

Имена и адреса узлов. Каждый узел должен устойчиво разрешать имена остальных узлов через DNS или согласованную запись hosts. Проверьте, что имя не указывает на временный, NAT- или недоступный адрес.
Сеть Corosync. Нужна надёжная связность с малой задержкой между всеми участниками. Определите, по каким интерфейсам пойдут управление, Corosync и Live Migration. Логическое или физическое разделение потоков выбирают по архитектуре и рискам, а не как обязательное свойство каждого небольшого кластера.
Кворум. Кворум — большинство голосов, которое позволяет кластеру безопасно принимать согласованные решения. Для надёжной эксплуатации обычно планируют не менее трёх голосующих участников. Два узла без третьего голоса не дают устойчивого большинства при потере одного узла или разрыве связи.
Два узла. Документация Proxmox VE допускает двухузловые сценарии с QDevice — внешним арбитром голосования. QDevice не является хостом для VM и не добавляет вычислительную ёмкость для перезапуска нагрузок.
Хранилище. Для каждой VM и контейнера определите, будет ли их диск общим для узлов, локальным с репликацией либо локальным без автоматического переноса. Это напрямую влияет на миграцию и сценарий запуска после отказа.
Ресурсный запас. После выхода одного узла оставшиеся должны иметь CPU, память, I/O и сетевую пропускную способность для приоритетных нагрузок. Сам факт наличия свободного второго хоста не подтверждает N+1-ёмкость.
Порядок восстановления. Зафиксируйте, какие инфраструктурные сервисы критичны, в какой последовательности они запускаются и от каких сетей, хранилищ, DNS или каталогов зависят.

Не присоединяйте рабочий узел к кластеру без плана переноса

При добавлении узла к существующему кластеру его локальная кластерная конфигурация в /etc/pve заменяется конфигурацией целевого кластера. Узел с существующими VM или контейнерами нельзя присоединять «для проверки» без резервных копий, документированного плана переноса и учёта последствий для конфигурации. Не применяйте принудительные операции с кворумом ради возврата интерфейса: они требуют отдельного аварийного сценария по официальной документации и могут привести к расхождению состояния.

Кластер создают на выбранном первом чисто подготовленном узле, затем добавляют остальные подготовленные узлы по данным этого кластера. Ожидаемый результат — все узлы видны в едином состоянии, Corosync видит участников, а кворум сохраняется в штатном составе. Если узел не присоединяется или теряет связь, не компенсируйте это изменением голосов: сначала исправьте разрешение имён, адресацию, MTU, маршрутизацию, VLAN либо физическую связность.

Кластер, миграция и HA — разные возможности

Кластер даёт общую конфигурацию и основу для координации узлов. Live Migration нужна прежде всего для планового обслуживания: её доступность зависит от типа гостя, совместимости узлов, сети и размещения дисков. При общем хранилище перенос обычно проще, потому что целевой узел видит те же диски. В сценариях с локальными дисками Proxmox VE может поддерживать миграцию с копированием дисков или репликацию для отдельных конфигураций, но это не универсальное свойство каждого storage и не тождественно HA.

Проверяйте поддержку конкретной операции для выбранного типа хранилища в документации PVE 8: directory, LVM/LVM-thin, ZFS, NFS, Ceph и другие варианты отличаются поддерживаемым содержимым, совместным доступом, миграцией и репликацией. Локальная реплика не является синхронным общим диском: при аварийном переключении могут отсутствовать изменения, не попавшие в последнюю репликацию. Отдельные сценарии переноса разобраны в материале о миграции VM, P2V и V2V.

Почему создание кластера не означает готовую HA

Высокая доступность требует не только нескольких узлов. Управляемая VM или контейнер должны быть назначены HA-ресурсом, кластер должен иметь кворум, а подходящий узел — ресурсы и доступ к данным нагрузки. Для дисков это обычно означает общее хранилище либо заранее спроектированный сценарий локальной репликации; VM на одиночном локальном диске недоступна другому узлу просто потому, что оба состоят в одном кластере.

Proxmox VE HA Manager отслеживает только VM и контейнеры, добавленные как HA-ресурсы. При отказе узла кластер должен исключить одновременный запуск ресурса на старом и новом узлах: в процедуре HA для этого используются кластерные блокировки и ограждение узла с помощью watchdog. Если кворум сохранён, условия ограждения выполнены, а данные и необходимые ресурсы доступны, HA Manager пытается восстановить нагрузку на подходящем узле. Это восстановление с перезапуском, а не продолжение выполнения процесса с той же точки; его время зависит от обнаружения отказа, ограждения, запуска гостя и восстановления самого приложения.

Границы Proxmox VE HA Manager

HA Manager делает	HA Manager не гарантирует
Пытается перезапустить управляемую VM или LXC после сбоя ресурса или отказа узла.	Непрерывную работу приложения без прерывания.
Использует состояние кластера и кворум, чтобы избежать небезопасных конкурирующих действий.	Работу при потере кворума, разрыве сети или ошибочной кластерной конфигурации.
Может восстановить ресурс на другом узле, если там доступны его данные и ресурсы.	Доступность при отказе общего storage, общей сети, питания площадки или зависимой внешней службы.
Помогает сократить время реакции на отказ хоста.	Целостность транзакций приложения, отсутствие потери последних данных или замену репликации СУБД.

HA не заменяет отказоустойчивость приложения

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

Proxmox Backup Server и переносимая копия VM

Proxmox Backup Server предназначен для резервного копирования и восстановления поддерживаемых объектов Proxmox VE. В связке PVE 8 и PBS 3 резервные копии передаются в datastore PBS блоками: это позволяет использовать дедупликацию и инкрементальную передачу при повторных запусках. PBS поддерживает проверку целостности, политики prune/retention для управления сроком хранения и шифрование резервных копий при соответствующей настройке. Совместимость конкретных минорных выпусков PVE и PBS следует сверять по матрице и руководствам установленного релиза.

Не смешивайте резервную копию и артефакты переноса

Механизм	Когда использовать	Чего он сам по себе не обеспечивает
Резервное копирование в Proxmox Backup Server	Регулярная защита VM и контейнеров, хранение нескольких точек, восстановление отдельных объектов или их данных по поддерживаемому сценарию.	Гарантию восстановления без проверки, защиту от всех отказов площадки или полноценную стратегию внеплощадочного хранения.
vzdump-архив	Переносимая резервная копия VM или контейнера, разовое архивирование, восстановление на совместимой PVE-системе.	Дедуплицированное регулярное хранение и управление защитой, равнозначные настроенному PBS.
Экспорт или преобразование виртуального диска	Передача диска в другой гипервизор, подготовка V2V или работа с поддерживаемым целевой системой форматом.	Полную конфигурацию VM, сетевую схему, секреты, согласованность приложения и регулярную защиту данных.
Импорт диска в VM	Подключение существующего поддерживаемого диска к заранее созданной VM на целевой PVE.	Автоматическую корректность драйверов, загрузчика, сетевой конфигурации и запуск в новой платформе.

В Proxmox VE vzdump создаёт архив резервного копирования VM или контейнера на хранилище, поддерживающее размещение резервных копий. Формат и способ восстановления зависят от типа гостя и настроек задания; в документации PVE он рассматривается прежде всего как backup/restore-механизм. Такой архив удобно переносить или хранить как отдельный артефакт, но это не автоматически продуманная схема резервного копирования: нужны расписание, число точек, контроль свободного места, проверка восстановления и решение о хранении копий вне основной площадки.

Под фразой «экспорт виртуальной машины Proxmox» могут иметь в виду разные действия. В ветке PVE 8 нет единой универсальной операции, которая собирает полную конфигурацию VM и все её диски в пакет для импорта в любой гипервизор. Для переноса с последующим восстановлением на совместимой PVE обычно используют vzdump-архив. Отдельный виртуальный диск можно экспортировать или преобразовать поддерживаемым для выбранного storage и формата способом; доступные операции и форматы нужно сверять с руководством и справкой установленного выпуска. Файл диска сам по себе не переносит всю конфигурацию VM, сетевую схему и внешние зависимости и не гарантирует загрузку гостевой ОС на другой платформе.

Выберите механизм защиты или переноса

1
Сформулируйте цель
Если цель — регулярно восстановить VM или контейнер после ошибки, удаления или отказа, выбирайте резервное копирование. Если нужно однократно перенести нагрузку на совместимый PVE, рассмотрите vzdump и восстановление. Если целевая платформа требует отдельный формат диска, планируйте экспорт либо преобразование и V2V-проверку.
2
Для регулярных копий подключите PBS
Добавьте доступный datastore PBS как backup-цель в PVE, создайте задание для нужных VM и контейнеров, задайте расписание и retention. Ожидаемый результат — успешная точка резервного копирования отображается на PBS и её можно выбрать для восстановления. Если задание завершается ошибкой, не исключайте VM из задания молча: проверьте доступность PBS, права, место, сеть и журнал задачи.
3
Проверьте восстановление
Восстановите тестовую копию в изолированное имя, ID и сеть либо выполните документированную проверку восстановления для своей схемы. Проверьте запуск, доступность дисков и приложения. Если восстановленная система не запускается, зафиксируйте причину до того, как исходная VM станет единственной рабочей копией.
4
Для переноса определите состав переносимых данных
Отдельно перечислите конфигурацию VM, все виртуальные диски, ISO или драйверы, сетевые зависимости, ключи и данные внешних сервисов. Выполните перенос поддерживаемым целевой платформой способом и протестируйте загрузку вне рабочей VM. Если требуется перенос между гипервизорами, используйте план из материала о V2V и P2V, а не только конвертацию файла диска.

Что не покрывает эта статья

Выбор RPO/RTO, внешние системы резервного копирования и хранение копий за пределами площадки рассматриваются в отдельных материалах о стратегии резервного копирования. Настройка iSCSI, NFS, SMB, FC, RAID и локальных носителей здесь также не рассматривается: в контексте Proxmox важно заранее выбрать хранилище, которое поддерживает нужный тип содержимого, способ доступа к данным и выбранный сценарий HA.

Термины в статье

Виртуальная машина: Изолированная вычислительная среда с виртуальными процессорами, памятью, дисками и сетевыми адаптерами, в которой под управлением гипервизора работает гостевая ОС.
Виртуальная сеть: Виртуальная сеть — логическая сеть, реализованная программными средствами для связи ВМ и других виртуальных нагрузок между собой и, при необходимости, с физической сетью.
Виртуальный сервер: Виртуальная машина, на которой работают серверная ОС, сетевые службы или приложения и которая предоставляет их другим системам и пользователям.
Высокая доступность: Высокая доступность (HA) — способность системы сохранять сервис или автоматически восстанавливать его с минимальным простоем при отказе компонентов.
Гипервизор: Программный слой, который абстрагирует ресурсы физического хоста, выполняет виртуальные машины и управляет ими.
Дистрибутив Linux: Дистрибутив Linux — готовая операционная система на базе ядра Linux, включающая набор программ, репозитории, пакетный менеджер и правила обновления и сопровождения.
Клонирование виртуальной машины: Создание копии виртуальной машины как отдельной ВМ; полный клон независим от исходной ВМ, а связанный использует её базовые виртуальные диски.
Процесс: Процесс — экземпляр выполняемой программы в Linux с PID, виртуальным адресным пространством, состоянием и связанными с ним ресурсами.
Ceph: Ceph — распределённая программно-определяемая система хранения, объединяющая диски серверов в масштабируемое объектное, блочное и файловое хранилище.
Cloud-Init: Cloud-Init — система начальной настройки облачных экземпляров, применяющая метаданные и пользовательские данные при первом запуске виртуальной машины.
Datastore: Логический контейнер хранилища в VMware для размещения файлов виртуальных машин (диски, конфигурации, логи)
Guest OS: Операционная система, установленная в виртуальной машине и работающая под управлением гипервизора; не следует путать с хостовой ОС гипервизора типа 2.
KVM: Подсистема аппаратной виртуализации ядра Linux, предоставляющая пользовательским мониторам ВМ, обычно QEMU, интерфейс для запуска изолированных виртуальных машин.
Live Migration: Перенос работающей виртуальной машины между хостами без выключения гостевой ОС; переключение обычно вызывает краткую паузу, а сохранение соединений зависит от сети и платформы.
LXC: LXC — набор инструментов и библиотек для создания и запуска системных Linux-контейнеров, изолирующих процессы, сеть и файловую систему при общем ядре с хостом.
pmxcfs: pmxcfs — конфигурационная FUSE-файловая система Proxmox VE, публикующая настройки в /etc/pve и в кластере реплицирующая их между узлами.
Proxmox: Открытая платформа серверной виртуализации на базе Debian, использующая QEMU/KVM для виртуальных машин и LXC для системных Linux-контейнеров.
Proxmox Backup Server: Proxmox Backup Server — серверная платформа резервного копирования Proxmox с дедупликацией, инкрементальной передачей данных и проверкой целостности резервных копий.
Proxmox VE HA Manager: Proxmox VE HA Manager — компонент высокой доступности Proxmox VE, перезапускающий HA-ресурсы при их неожиданной остановке и восстанавливающий их после отказа узла кластера.
QEMU: QEMU — открытый эмулятор вычислительных систем и монитор виртуальных машин; в Linux он может использовать KVM для виртуализации с аппаратным ускорением.
QEMU Guest Agent: QEMU Guest Agent — служба в гостевой ОС, через которую QEMU или система управления получает сведения о госте и выполняет в нём разрешённые операции по настроенному каналу связи.
RAID: Технология объединения нескольких накопителей в логические блочные устройства для повышения производительности и/или отказоустойчивости в зависимости от RAID-уровня.
Uplink: Uplink — соединение или интерфейс, ведущий от устройства либо локального сегмента к вышестоящей сети; в виртуализации — подключение виртуального коммутатора к физической сети.
vCPU: vCPU — виртуальный логический процессор, предоставляемый виртуальной машине; гипервизор планирует его выполнение на процессорных ресурсах хоста.
ZFS: ZFS — файловая система и менеджер томов с пулами хранения, контрольными суммами и копированием при записи, объединяющий управление дисками и данными.