Установка Proxmox VE Server на новый хост или мини-ПК в большинстве случаев — простая задача. Этот процесс обычно не вызывает проблем: достаточно записать ISO на USB-накопитель с помощью Rufus или Ventoy. Затем нужно загрузить машину и пройти через установщик, чтобы установить компоненты на хост. Однако появление экрана входа в консоль Proxmox не обязательно означает, что можно переносить важные виртуальные машины или LXC-контейнеры на этот хост. Прежде чем доверить новому хосту Proxmox реальные рабочие нагрузки, стоит проверить как минимум 7 областей. Далее рассматриваются эти области.
1. Проверка имени хоста, DNS и конфигурации времени
Это одна из первых проверок на новом хосте. В первую очередь необходимо убедиться, что идентичность хоста корректна. Имя хоста может казаться незначительной деталью при установке, но оно используется во всей остальной платформе. Поэтому стоит быстро проверить его и обратить внимание на несколько моментов.
Эта конфигурация становится важной частью платформы, особенно для конфигурации кластера, и находится в файлах по пути:
|
1 |
/etc/pve/nodes |
Перед добавлением хоста в кластер Proxmox VE необходимо окончательно зафиксировать имя хоста и убедиться, что полное доменное имя (FQDN) разрешается в правильный управляющий адрес. Также стоит проверить корректность обратного DNS. Убедиться, что в файле указано правильное имя, можно так:
|
1 |
/etc/hosts |
Краткий список команд для проверки хоста:
Эти команды позволяют убедиться, что машина готова и имя хоста согласовано:
|
1 2 3 4 |
hostnamectl hostname —f getent hosts «$(hostname -f)» cat /etc/hosts |

Проверка конфигурации времени на хосте Proxmox
Ещё одна важная конфигурация на хосте Proxmox VE Server — корректная настройка времени. Время используется для самых разных целей. Особенно в кластере хостов PVE необходимо, чтобы время было синхронизировано, поскольку оно используется для проверки сертификатов, связи между узлами кластера, журналирования и аутентификации. Разница во времени между хостами может привести к самым разным проблемам.
Проверить это можно с помощью:
|
1 2 |
timedatectl systemctl status chrony —no—pager |

2. Проверка репозиториев, обновлений и версии ядра
При установке свежей копии Proxmox VE Server установщик не устанавливает последние пакеты. Могут отсутствовать обновления ядра, микрокода, прошивки или исправления безопасности. Поэтому перед запуском каких-либо рабочих нагрузок в первую очередь необходимо проверить конфигурацию репозиториев обновлений. Затем сервер обновляется до актуального состояния, чтобы получить хорошую стартовую точку.
При поддержке Proxmox VE Server в производственной среде с корпоративной подпиской репозиторий enterprise остаётся настроенным из установки по умолчанию. Затем достаточно применить ключ — и всё готово. В домашней лаборатории ситуация обычно иная.
Первым делом выполняется переключение с репозиториев enterprise на репозитории no-subscription. Если этого не сделать, при попытке применить обновления к серверам домашней лаборатории возникнут ошибки авторизации. После настройки репозиториев — enterprise или no-subscription — можно применять обновления.

После настройки нужных репозиториев можно обновить список пакетов и посмотреть доступные обновления, затем применить их и проверить версию после обновления:
|
1 2 3 |
apt update apt full—upgrade pveversion —v |
После обновления, особенно заменяющего ядро на более новую версию, хост перезагружается. После возврата хоста к работе проверяются версия работающего ядра и установленные пакеты Proxmox.
|
1 2 |
uname —r pveversion —v |

Кроме того, после перезагрузки хоста выполняется несколько финальных проверок. Необходимо убедиться, что управляющий интерфейс снова доступен для веб-интерфейса на порту 8006, и что все хранилища снова смонтированы.
3. Проверка структуры хранилища и состояния физических дисков
Одна из важнейших областей хоста Proxmox VE Server — хранилище. Не следует выходить из установки и сразу запускать виртуальные машины на конкретном хосте Proxmox, если хранилище нездорово. Proxmox может успешно установиться в конце процесса, однако это не гарантирует, что корневая файловая система имеет правильный размер или что диски виртуальных машин размещены в правильном хранилище.
Кроме того, необходимо убедиться, что NVMe-диски, которые должны быть здоровыми, действительно здоровы и готовы к работе.
Структура хранилища
Отличная отправная точка — составить полную карту структуры хранилища вплоть до конфигурации хранилища Proxmox:
|
1 2 3 |
lsblk —o NAME,SIZE,FSTYPE,MOUNTPOINTS,MODEL df —h pvesm status |
Необходимо убедиться, что видимое соответствует ожидаемому. Эта небольшая команда помогает определить, какой физический диск (бренд, модель) поддерживает конкретное хранилище:

Состояние дисков
Одно из действительно полезных действий, позволяющих доверять хосту Proxmox VE Server перед вводом его в «продакшн», — проверка состояния дисков. Особенно это актуально для домашних лабораторий, где могут использоваться подержанные диски. Необходимо убедиться, что они достаточно здоровы и имеют ожидаемый остаточный ресурс, а также что отсутствуют очевидные грубые ошибки.
Вот несколько команд, которые для этого используются:
|
1 2 |
smartctl —a /dev/sdX nvme smart—log /dev/nvme0 |

Для ZFS можно также напрямую посмотреть пул:
|
1 2 3 |
zpool status zpool list zfs list |
Следует обращать внимание на любые отклонения: ошибки носителя, критические предупреждения, очень высокий износ, деградацию пула и ёмкость, не соответствующую ожидаемой.
Наконец, стоит учитывать домены отказов применительно к хранилищу, включая хранилище на отдельном хосте. Например, два раздела на одном NVMe-диске не считаются независимыми хранилищами. Если резервные копии хранятся на том же NVMe-диске, но в другом разделе, существует риск потери резервных копий вместе с основным устройством хранения.
При использовании хранилищ iSCSI или NFS стоит обратить внимание на недавний выпуск нативного плагина TrueNAS, интегрирующегося с Proxmox: TrueNAS Just Fixed One of Proxmox’s Biggest Storage Headaches.
4. Проверка всех мостов, VLAN, агрегатов и MTU
Это ещё один крайне важный набор проверок, которые необходимо выполнить, прежде чем доверять хосту Proxmox VE Server. Иногда проблема не в самом хосте, а в конфигурации, в том числе на сетевом коммутаторе, которая не согласована. Поэтому крайне важно выполнить несколько простых проверок на стороне хоста до ввода его в «продакшн». Это может быть как отдельный хост, так и узел кластера в домашней лаборатории.
Jumbo frames
Несколько месяцев назад у некоторых пользователей использование jumbo frames в домашней лаборатории привело к странным проблемам. Jumbo frames могут работать на «части» сетевого пути, но не работать на остальном пути, вызывая фрагментацию или потерю трафика.
Один из самых простых тестов для проверки jumbo frames — следующая команда ping:
|
1 |
ping —M do —s 8972 —c 4 |

Тест скорости сети
Кроме того, при внедрении 10-гигабитной сети между хостами Proxmox VE важно проверить соединения между хостами. Часто 10-гигабитное соединение не работает как ожидалось и фактически обеспечивает скорость 1 гигабит по разным причинам.
Простой тест, позволяющий убедиться, что хост работает на этой скорости, — использование iperf3. С помощью iperf3 можно настроить один сервер как «сервер», а другой как «клиент»; они будут передавать пакеты друг другу и измерять пропускную способность между двумя узлами.

Также обязательно проверьте файл /etc/network/interfaces и сравните его с тем, что Proxmox показывает в конфигурации сети узла. Вот несколько дополнительных полезных команд. Нужно убедиться в правильности таких параметров, как интерфейсы и VLAN.
|
1 2 3 4 5 |
ip —br address ip route bridge link bridge vlan show cat /etc/network/interfaces |
5. Стандартизация настроек оборудования виртуальных машин в домашней лаборатории
Эта настройка может оказаться более важной, чем кажется, и способна вызывать проблемы. Первая виртуальная машина на новом хосте может стать своего рода «шаблоном» для всех последующих. Если создать её с неправильными аппаратными настройками, можно случайно распространить их на десятки виртуальных машин.
Одна из областей, которая может доставить проблемы, особенно при переходе от отдельного хоста к кластерной конфигурации, — тип CPU. Многие склонны устанавливать для типа CPU значение host. Действительно, этот тип может открыть больше возможностей и повысить производительность (при определённых обстоятельствах). Но он также может ограничить возможности живой миграции.

При перемещении виртуальной машины между двумя разными хостами Proxmox VE тип CPU важен. Если это разные поколения CPU или даже разные типы CPU (Intel и AMD), живая миграция не удастся. Но если использовать виртуальные типы CPU, предоставляемые Proxmox из коробки, это позволит добиться гораздо большего успеха. Можно перемещать виртуальные машины между разнородным оборудованием, которое часто встречается в домашней лаборатории.

6. Настройка резервного копирования, хранения и уведомлений о сбоях
Это важный момент. Не следует ждать, пока хост Proxmox заполнится важными рабочими нагрузками, прежде чем начинать думать о резервном копировании. Как только первый «бит» данных попадает в хранилище среды Proxmox, необходимо, чтобы резервные копии уже были настроены и могли как можно скорее захватывать копии этих данных. В нативной экосистеме Proxmox VE Server предпочтение отдается Proxmox Backup Server. Однако в среде также работает Veeam Backup & Replication, который отлично справляется с резервным копированием Proxmox.
Proxmox Backup Server можно запустить на отдельном хранилище, например, на Beelink ME Pro 2-bay NAS с двумя зеркальными дисками по 8 ТБ. Этого достаточно для текущих рабочих нагрузок Proxmox. PBS также выполняет инкрементальные резервные копии и дедупликацию. Таким образом, хранящиеся резервные копии эффективно размещаются на диске.
Поэтому внешний NAS — идеальный сервер резервного копирования Proxmox.

Также следует учитывать, что если используется программно-определяемое хранилище, такое как Ceph или Microceph, оно не предоставляется так же, как обычное файловое хранилище. Если виртуальная машина имеет доступ к хранилищу Ceph, полная резервная копия этой ВМ не позволит получить данные «внутри» тома Ceph или тома CephFS.
Поэтому для таких случаев требуется агентное резервное копирование, которое работает внутри виртуальной машины, имеет доступ к этим данным и может передавать их наружу из среды хранилища.
Необходимо убедиться, что включены уведомления о сбоях резервного копирования или любых других сбоях в среде, связанных с резервными копиями. Худшее время для обнаружения проблемы с резервным копированием — когда действительно требуется восстановить данные.

7. Проверка BIOS, настроек виртуализации и конфигурации питания
Существует несколько других параметров, которые проверяются и не находятся в интерфейсе Proxmox. Чтобы получить к ним доступ, необходимо проверить системное микропрограммное обеспечение, настройки BIOS. Обычно многие из этих параметров уже включены и соответствуют необходимым с завода. Но не следует делать предположений. Необходимо всегда проверять.
Прежде всего, необходимо убедиться, что Intel VT-x или AMD-V включены, в зависимости от используемой процессорной платформы. Иногда Proxmox устанавливается без этих опций, включенных в BIOS, но тогда недоступна аппаратная виртуализация, которая критически важна для хорошей производительности. Кроме того, если планируется использовать PCI passthrough, необходимо включить IOMMU в BIOS.

Если Ваш сервер построен на китайской материнской плате, Вам может быть полезны статья про настройку BIOS китайских материнских плат на сокете 2011-3.
Также можно проверить некоторые параметры в оболочке Proxmox. Можно убедиться в поддержке виртуализации:
|
1 |
lscpu | grep Virtualization |
Чтобы убедиться и проверить, что IOMMU появился в журнале ядра, можно использовать:
|
1 |
dmesg | grep —Ei «DMAR|IOMMU|AMD-Vi» |
Также можно проверить, создал ли Linux группы IOMMU:
|
1 |
find /sys/kernel/iommu_groups/ —type l |
Наконец, необходимо убедиться, что используется последняя версия BIOS на сервере Proxmox. Обновления BIOS могут содержать исправления проблем, которые проявляются только при определенных условиях или под нагрузкой.
Заключение
Неоптимальные настройки всегда лучше обнаружить до запуска рабочих нагрузок, чем выявлять их, когда сервер уже работает под нагрузкой и на нём запущено множество ВМ и LXC.
Читайте про Свой умный дом локально:
Сайт
Телеграм
Дзен




Добавить комментарий