Product SiteDocumentation Site

Альт Виртуализация редакция PVE 11.2

Документация

Руководство пользователя

Редакция октябрь, 2026

Елена Мишина

ООО «Базальт СПО»

Юридическое уведомление

Данный документ распространяется на условиях свободной лицензии FDL (Free Documentation License) версии 1.3.
Данный документ не содержит текста, помещаемого на первой или последней странице обложки. Данный документ не содержит неизменяемого текста.

Аннотация

Добро пожаловать в документацию дистрибутива Альт Виртуализация редакция PVE. Данное руководство предназначено как для начинающих, так и для опытных пользователей. Руководство описывает подготовку системы для установки, процесс установки дистрибутива, а также процедуру настройки и использования системы.
Названия компаний и продуктов, встречающихся в руководстве, могут являться торговыми знаками соответствующих компаний.
Данное руководство соответствует текущему состоянию сведений, но какие-либо окончательные правки могли не попасть в него. В случае обнаружения ошибок и неточностей в руководство вносятся изменения.
I. Что такое Альт Виртуализация редакция PVE?
1. Что такое Альт Виртуализация редакция PVE
2. Что такое Linux
3. Что такое системы Альт
II. Установка дистрибутива
4. Подготовка установочного диска
5. Сохранение данных и меры предосторожности
6. Начало установки: загрузка системы
7. Последовательность установки
8. Язык
9. Лицензионное соглашение
10. Дата и время
11. Подготовка диска
12. Установка системы
13. Сохранение настроек
14. Установка загрузчика
15. Ethernet-интерфейсы
16. Администратор системы
17. Системный пользователь
18. Завершение установки
19. Обновление системы до актуального состояния
20. Первая помощь
III. Начало использования Альт Виртуализация редакция PVE
21. Загрузка системы
22. Вход в систему
IV. Средство управления виртуальными окружениями PVE
23. Системные требования
24. Краткое описание возможностей
25. Создание кластера PVE
26. Системы хранения PVE
27. Репликация хранилища
28. Сетевая подсистема
29. Управление ISO-образами и шаблонами LXC
30. Виртуальные машины на базе KVM
31. Создание и настройка контейнера LXC
32. Программно-определяемые сети (SDN)
33. Миграция ВМ и контейнеров
34. Клонирование ВМ
35. Шаблоны ВМ
36. Теги (метки) ВМ
37. Резервное копирование (Backup)
38. Уведомления
39. Встроенный мониторинг PVE
40. Высокая доступность в PVE
41. Межсетевой экран PVE (firewall)
42. Пользователи и их права
43. Просмотр задач и журналов PVE
44. PVE API
45. Основные службы PVE
46. Обновление системы
V. Установка пакетов для опытных пользователей
Введение
47. Источники программ (репозитории)
48. Обновление информации о репозиториях
49. Поиск пакетов
50. Установка или обновление пакета
51. Удаление установленного пакета
52. Обновление системы
VI. Основы администрирования Linux
53. Общие принципы работы ОС
54. Средства управления дискреционными правами доступа
55. Режим суперпользователя
56. Управление пользователями
57. Система инициализации systemd
58. Что происходит в системе
59. Документация
VII. Техническая поддержка продуктов «Базальт СПО»
60. Покупателям нашей продукции
61. Пользователям нашей продукции

⁠Часть I. Что такое Альт Виртуализация редакция PVE?

В этой части рассматривается что такое Linux и Альт Виртуализация редакция PVE.

⁠Глава 1. Что такое Альт Виртуализация редакция PVE

Операционная система Альт Виртуализация редакция PVE — комплексное решение для управления виртуальной инфраструктурой на основе открытого программного обеспечения. PVE поддерживает виртуальные машины на основе KVM и системные контейнеры LXC, а также предоставляет веб-интерфейс, средства управления, резервного копирования и кластеризации.
Основные возможности PVE:
  • Полноценная поддержка KVM и LXC — создание и запуск виртуальных машин и системных контейнеров в единой среде;
  • Кластеризация и высокая доступность (High Availability, HA) — объединение узлов в кластер и автоматический перезапуск настроенных для HA виртуальных машин и контейнеров при отказе узла при соблюдении необходимых условий;
  • Интеграция с хранилищами — поддержка локальных и сетевых хранилищ, в том числе LVM, ZFS, Btrfs, NFS, iSCSI и Ceph;
  • Резервное копирование и восстановление — создание резервных копий виртуальных машин и контейнеров и их восстановление; для поддерживаемых конфигураций также доступна репликация;
  • Настройка сети — поддержка VLAN, сетевых мостов, агрегирования интерфейсов (bonding) и программно определяемых сетей (Software-Defined Networking, SDN).
Для управления PVE доступны следующие интерфейсы:
  • Веб-интерфейс — управление виртуальными машинами, контейнерами, хранилищами, сетями и кластерами. С его помощью можно выполнять операции создания, запуска, миграции и резервного копирования виртуальных машин и контейнеров. Подключение к веб-интерфейсу выполняется по HTTPS. Разграничение доступа поддерживает ролевую модель (Role-Based Access Control, RBAC);
  • Командная строка (CLI) — управление с помощью утилиты pvesh и стандартных команд Linux;
  • REST API — программный интерфейс для управления PVE посредством HTTP-запросов. Может использоваться для интеграции с внешними системами, например Ansible, Terraform и Zabbix.
PVE можно использовать для создания частных облаков, тестовых сред, серверов приложений и другой виртуальной инфраструктуры.

⁠1.1. Системные требования

Для установки Альт Виртуализация редакция PVE требуется физический сервер или ВМ со следующими характеристиками:
  • Процессор:
    • архитектура Intel 64 или AMD64;
    • поддержка аппаратной виртуализации Intel VT-x или AMD-V.
  • Оперативная память:
    • минимальный объём для операционной системы и служб PVE — 2 ГБ, без учёта памяти, выделяемой виртуальным машинам и контейнерам;
    • рекомендуемый объём — от 4 ГБ, без учёта памяти, выделяемой виртуальным машинам и контейнерам.
  • Количество процессорных ядер:
    • не менее 2.
  • Дисковое пространство для установки PVE, без учёта виртуальных машин и контейнеров:
    • при ручной разметке диска — от 10 ГБ;
    • при автоматической разметке диска — от 20 ГБ.

⁠1.2. Ограничения для логических объектов виртуализации

  • Максимальное число узлов в кластере — явного ограничения нет (на практике максимальное количество узлов зависит от производительности хостов и пропускной способности сети).
  • Максимальные лимиты на хост:
    • CPU — до 8192 ядер (с учетом Hyper-Threading). Например, на двухпроцессорном сервере с включённым Hyper-Threading могут быть установлены два 2048-ядерных процессора (8192 ÷ 2 ÷ 2 = 2048);
    • RAM — 32 ТБ;
    • HDD — ограничений со стороны PVE нет (доступный размер зависит от хранилища, файловой системы и формата виртуального диска);
    • NIC — ограничений нет.
  • Максимальные лимиты на ВМ:
    • CPU — 240 виртуальных процессоров;
    • RAM — 4 ТБ. Поддерживает максимальную объём памяти, который вы можете выделить ВМ. 32-разрядные ВМ с поддержкой расширения физических адресов (PAE) могут получить доступ только к 64 ГБ — это ограничение виртуального оборудования;
    • HDD — ограничений со стороны PVE нет (максимальный размер зависит от формата диска, типа хранилища и ограничений соответствующих компонентов);
    • NIC — 32;
    • PCI — 16.

Примечание

Указанные ограничения основаны на предельных значениях, определённых в исходном коде проекта PVE. Они не являются гарантированными — фактические пределы могут отличаться в зависимости от оборудования, конфигурации и рабочей нагрузки.

⁠Глава 2. Что такое Linux

⁠2.1. Свободные программы

Операционная система (далее — ОС) Linux — ядро, основные компоненты системы и большинство её пользовательских приложений — свободные программы. Свободные программы можно:
  • запускать на любом количестве компьютеров;
  • распространять бесплатно или за деньги без каких-либо ограничений;
  • получать исходные тексты этих программ и вносить в них любые изменения.
Свобода программ обеспечила их широкое использование и интерес к ним со стороны тысяч разработчиков. Основные программы для Linux выходят под лицензией GNU General Public License (далее — GPL). Лицензия GNU не только гарантирует свободу, но и защищает её. Она допускает дальнейшее распространение программ только под той же лицензией, поэтому исходный код ядра Linux, компиляторов, библиотеки glibc, пользовательских графических оболочек не может быть использован для создания приложений с закрытым кодом. В этом принципиальное отличие Linux от свободных ОС семейства BSD (FreeBSD, NetBSD, OpenBSD), фрагменты которых вошли в Microsoft Windows и даже стали основой OS X. Linux включает в себя многие разработки BSD, но его компиляторы и системные библиотеки разработаны в рамках проекта GNU (http://www.gnu.org/home.ru.html).

⁠2.2. Разработка Linux

В отличие от распространённых несвободных ОС, Linux не имеет географического центра разработки. Нет фирмы, которая владела бы этой ОС, нет и единого координационного центра. Программы для Linux — результат работы тысяч проектов. Большинство из них объединяет программистов из разных стран, связанных друг с другом только перепиской. Лишь некоторые проекты централизованы и сосредоточены в фирмах. Создать свой проект или присоединиться к уже существующему может любой программист, и, в случае успеха, результаты этой работы станут известны миллионам пользователей. Пользователи принимают участие в тестировании свободных программ, общаются с разработчиками напрямую. Это позволяет за короткий срок добавлять в программное обеспечение новые возможности, оперативно находить ошибки и исправлять их.
Именно гибкая и динамичная система разработки, невозможная для проектов с закрытым кодом, определяет исключительную экономическую эффективность Linux. Низкая стоимость свободных разработок, отлаженные механизмы тестирования и распространения, привлечение независимых специалистов, обладающих индивидуальным, самостоятельным видением проблем, защита исходного текста программ лицензией GPL — всё это стало причиной успеха свободных программ.
Такая высокая эффективность разработки не могла не заинтересовать крупные фирмы. Они стали создавать свои свободные проекты, основывающиеся на тех же принципах. Так появились Mozilla, LibreOffice, свободный клон Interbase, SAP DB. IBM способствовала переносу Linux на свои мейнфреймы.
Открытый код программ значительно снизил себестоимость разработки закрытых систем для Linux и позволил снизить цену решения для пользователя. Вот почему Linux стала платформой, часто рекомендуемой для таких продуктов, как Oracle, DB2, Informix, Sybase, SAP ERP, Lotus Domino.

⁠2.3. Защищённость

ОС Linux унаследовала от UNIX надёжность и отличную систему защиты. Система разграничения доступа к файлам позволяет не бояться вирусов. Но всё же, программ без ошибок не бывает, и Linux не исключение. Благодаря открытости исходного кода программ, аудит системы может осуществить любой специалист без подписок о неразглашении и без необходимости работы в стенах нанявшей его компании. Сообщества разработчиков и пользователей свободных программ создали множество механизмов оповещения об ошибках и их исправления. Сообщить об ошибке и принять участие в её исправлении независимому программисту или пользователю так же просто, как специалисту фирмы-разработчика или автору проекта. Благодаря этому ошибки защиты эффективно выявляются и быстро исправляются.

⁠2.4. Дистрибутивы Linux

Большинство пользователей для установки Linux используют дистрибутивы. Дистрибутив — это не просто набор программ, а готовое решение для выполнения различных задач пользователя, обладающее идентичностью установки, управления, обновления, а также едиными системами настройки и поддержки.

⁠2.5. Новичку

Linux — самостоятельная операционная система. Все операционные системы разные: Linux — не Windows, не OS X и не FreeBSD. В Linux свои правила, их необходимо изучить и к ним необходимо привыкнуть. Терпение и настойчивость в изучении Linux обернётся значительным повышением эффективности и безопасности вашей работы. То, что сегодня кажется странным и непривычным, завтра понравится и станет нормой.
Не стесняйтесь задавать вопросы, ведь самый простой способ найти ответ — совет опытного специалиста. Взаимопомощь и общение — традиция в мире Linux. Всегда можно обратиться за помощью к сообществу пользователей и разработчиков Linux. Большинство вопросов повторяются, поэтому для начала стоит поискать ответ на свой вопрос в документации, затем в сети Интернет. Если вы не нашли ответа в перечисленных источниках, не стесняйтесь, пишите на форум или в списки рассылки так, как писали бы своим друзьям, и вам обязательно помогут.

⁠Глава 3. Что такое системы Альт

⁠3.1. ALT Linux Team

Команда ALT Linux (https://www.altlinux.org/ALT_Linux_Team) — это интернациональное сообщество, насчитывающее более 300 разработчиков свободного программного обеспечения.

⁠3.2. Сизиф

Sisyphus (https://packages.altlinux.org) — наш ежедневно обновляемый банк программ (часто называемый репозиторием). Поддерживаемая ALT Linux Team целостность Sisyphus, оригинальная технология сборки программ и утилита apt-get позволяют пользователям легко обновлять свои системы и быть в курсе актуальных новинок мира свободных программ.
Ежедневно изменяющийся репозиторий содержит самое новое программное обеспечение со всеми его преимуществами и недостатками (иногда ещё неизвестными). Поэтому, перед обновлением вашей системы из Sisyphus, мы советуем взвесить преимущества новых возможностей, реализованных в последних версиях программ, и вероятность возникновения неожиданностей в работе с ними (https://www.altlinux.org/Sisyphus_changes).
Разработка Sisyphus полностью открыта. У нас нет секретных изменений кода и закрытого тестирования с подписками о неразглашении. Всё, что мы сделали сегодня, завтра вы найдёте в сети. По сравнению с другими аналогичными банками программ (Debian unstable, Mandriva Cooker, PLD, Fedora), в Sisyphus есть немало самобытного. Особое внимание уделяется защите системы, локализации на русский язык, полноте и корректности зависимостей.
Название Sisyphus (Сизиф) заимствовано из греческой мифологии. С кропотливым Сизифом, непрерывно закатывающим в гору камни, команду ALT Linux Team объединяет постоянная работа над усовершенствованием технологий, заложенных в репозиторий.
Sisyphus, в первую очередь, — открытая лаборатория решений. Если вам это интересно, если вы хотите дополнить Sisyphus новыми решениями, если вы считаете, что можете собрать какую-то программу лучше — присоединяйтесь к проекту ALT Linux Team (https://www.altlinux.org/Join).

⁠3.3. Что такое одиннадцатая платформа

Как уже говорилось ранее, Sisyphus — это часто обновляемый репозиторий, ориентированный прежде всего для разработчиков. Для пользователей, которым стабильность и предсказуемость работы системы важнее расширенной функциональности (а это в первую очередь начинающие и корпоративные пользователи), предназначены дистрибутивы Альт. Такие дистрибутивы базируются на стабильном срезе репозитория Sisyphus. Эти срезы называются платформами.
Одиннадцатая платформа (p11) была создана в июне 2024 года и её поддержка продлится до июля 2027 года.

⁠3.3.1. Основные новшества одиннадцатой платформы

  • Одиннадцатая платформа основана на ядре Linux 6.12 (LTS) с расширенной поддержкой современного оборудования: процессорных архитектур Intel, включая Intel Meteor Lake, Intel Xeon Sapphire Rapids, AMD Ryzen 7000 (Zen 4) и EPYC Genoa; аппаратных интерфейсов — PCI Express Gen5, USB4, Thunderbolt 4, Wi-Fi 6/6E, NVMe 1.4/2.0; улучшенной поддержкой виртуализации;
  • Программное обеспечение на одиннадцатой платформе использует обновленный OpenSSL 3.1. Платформа сохраняет поддержку OpenSSL 1.1 для совместимости с устаревшим ПО;
  • Произошел переход на Python 3.12;
  • Добавлены PHP 8.3 и 8.4;
  • Системный интерпретатор сценариев /bin/sh теперь основан на Bash 5.2;
  • Обновлены основные системные библиотеки и компиляторы: glibc 2.38, компилятор GCC 13 и LLVM/Clang 19;
  • Пакет systemd обновлён до версии 255;
  • Подсистема начальной загрузки установщика propagator заменена на altboot;
  • Основным фрэймворком приложений графической подсистемы стал Qt6, с поддержкой Qt5 для обратной совместимости приложений. Qt6 в качестве основного стека также использует системный установщик;
  • Включена поддержка нового Kerberos 1.21, полностью совместимого с Samba 4.20+. В дистрибутивах 11 платформы также доступны и ключевые изменения Samba 4.20+;
  • Существенно обновлён Альтератор в качестве Центра Управления Системой — новый интерфейс, взаимодействие с D-Bus, модульная архитектура. Новый Альтератор поддерживает модули предыдущих версий;
  • ALT Diagnostic Tool — графическая утилита диагностики ОС. ADT использует заранее подготовленный набор проверок, предоставляет возможность пользователю выполнить тесты без дополнительных привилегий и единый вид отчета по проверкам;
  • Копидел — средство тиражирования установленной системы (alterator-kopidel);
  • Платформа доступна для архитектур x86_64 и ARM64.

⁠Часть II. Установка дистрибутива

⁠Глава 4. Подготовка установочного диска

Установочный образ дистрибутива можно записать на USB-накопитель или DVD-диск.
Установочные образы являются гибридными (Hybrid ISO/IMG), что позволяет устанавливать систему после записи образа на USB-накопитель. В этой главе описаны способы записи установочного образа на USB-накопитель и DVD-диск.

⁠4.1. Запись установочного образа на USB-накопитель

Предупреждение

Запись образа дистрибутива непосредственно на USB-накопитель изменяет таблицу разделов и содержимое накопителя. Все данные, находящиеся на накопителе, будут уничтожены.
Если после использования накопитель необходимо вернуть в состояние обычного накопителя данных, потребуется заново создать таблицу разделов и разделы.
Для создания загрузочного USB-накопителя потребуется ISO-образ дистрибутива.

⁠4.1.1. В операционной системе Windows

Для создания загрузочного USB-накопителя в операционной системе MS Windows можно использовать специальные программы, например ALT Media Writer, Win32 Disk Imager, HDD Raw Copy Tool и другие.

⁠4.1.1.1. ALT Media Writer

ALT Media Writer — инструмент для записи образов ALT на USB-накопители. Он может автоматически загружать образы из Интернета и записывать их на накопитель.
Для записи образа на USB-накопитель необходимо:
  1. Скачать и установить ALT Media Writer.
  2. Вставить USB-накопитель в USB-порт.
  3. Запустить ALT Media Writer.
  4. Выбрать дистрибутив и нажать кнопку Создать Live USB…. Начнётся загрузка образа из Интернета:
    ALT Media Writer (altmediawriter)
    Также можно выбрать локальный ISO-файл, нажав кнопку Другой образ.
  5. Выбрать USB-накопитель.
  6. После окончания загрузки нажать кнопку Записать на диск.

⁠4.1.1.2. Win32 Disk Imager

Для записи образа с помощью Win32 Disk Imager необходимо:
  1. Скачать и установить программу Win32 Disk Imager.
  2. Скачать образ дистрибутива.
  3. Вставить USB-накопитель в USB-порт. Размер накопителя должен быть не меньше размера записываемого образа.
  4. Запустить Win32 Disk Imager.
  5. В открывшемся окне выбрать ISO-образ дистрибутива и USB-накопитель:
    Win32 Disk Imager
  6. Нажать кнопку Write для записи образа на USB-накопитель.

⁠4.1.1.3. HDD Raw Copy Tool

Для записи образа на USB-накопитель также можно использовать утилиту HDD Raw Copy Tool.
На первом шаге необходимо выбрать файл с образом диска:
Выбор файла с образом диска
На втором шаге нужно выбрать USB-накопитель, на который будет записан образ:
Выбор USB-накопителя

Предупреждение

Будьте внимательны при выборе USB-устройства. Запись образа по ошибке на жёсткий диск или другой накопитель приведёт к потере находящихся на нём данных.
После проверки правильности выбранных параметров нажмите кнопку Continue, а затем кнопку START.
После успешного завершения записи окно с индикатором процесса записи закроется. После этого можно закрыть окно программы.

⁠4.1.2. В операционной системе Linux

Для записи образа на USB-накопитель можно использовать программы с графическим интерфейсом:
  • ALT Media Writer (altmediawriter):
    ALT Media Writer (altmediawriter)
    ALT Media Writer может автоматически загружать образы из Интернета и записывать их на USB-накопитель, при необходимости предварительно извлекая сжатые образы (img.xz).
  • Impression (impression):
    Impression
  • SUSE Studio Imagewriter (imagewriter):
    SUSE Studio Imagewriter (imagewriter)

Предупреждение

Будьте внимательны при выборе USB-устройства. Запись образа по ошибке на жёсткий диск или другой накопитель приведёт к потере находящихся на нём данных.

Предупреждение

Не указывайте номер раздела устройства. Образ записывается непосредственно на устройство целиком, начиная с его начала.
Для записи установочного образа можно воспользоваться утилитой командной строки dd:
# dd oflag=direct if=<файл-образа.iso> of=/dev/sdX bs=1M status=progress;sync
где <файл-образа.iso> — ISO-образ дистрибутива, а /dev/sdX — устройство, соответствующее USB-накопителю.
Для отображения прогресса записи можно установить пакет pv и использовать команду:
# pv <файл-образа.iso> | dd oflag=direct of=/dev/sdX bs=1M;sync
где <файл-образа.iso> — ISO-образ дистрибутива, а /dev/sdX — устройство, соответствующее USB-накопителю.
Просмотреть список блочных устройств можно с помощью команды lsblk:
$ lsblk | grep disk
sda      8:0    0 931,5G  0 disk
sdb      8:16   0 931,5G  0 disk
sdc      8:32   1   7,4G  0 disk
В данном примере USB-накопителю соответствует устройство /dev/sdc.
Затем записать образ:
# dd oflag=direct if=/iso/alt-virtualization-pve-11.2-x86_64.iso of=/dev/sdc bs=1M status=progress; sync
или:
# pv /iso/alt-virtualization-pve-11.2-x86_64.iso | dd oflag=direct of=/dev/sdc bs=1M;sync
dd: warning: partial read (524288 bytes); suggest iflag=fullblock
3GiB 0:10:28 [4,61MiB/s] [===================================>  ] 72% ETA 0:04:07
После завершения команды dd выполнится sync, который обеспечит запись буферизованных данных на накопитель.

Предупреждение

Не извлекайте USB-накопитель до завершения записи. После выполнения команды с dd дождитесь возврата приглашения командной строки.
О завершении записи можно судить по прекращению мигания индикатора USB-накопителя или по состоянию устройства в виджете Безопасное извлечение съемных устройств.

⁠4.1.3. В операционной системе OS X

В операционной системе OS X для создания загрузочного USB-накопителя можно использовать команду:
sudo dd if=alt-virtualization-pve-11.2-x86_64.iso of=/dev/rdiskX bs=10M
sync
где alt-virtualization-pve-11.2-x86_64.iso — ISO-образ дистрибутива, а /dev/rdiskX — устройство USB-накопителя.
Просмотреть список доступных устройств можно с помощью команды:
diskutil list

Предупреждение

Будьте внимательны при указании имени USB-устройства. Запись образа по ошибке на жёсткий диск приведёт к потере данных, хранящихся на нём.

⁠4.2. Запись ISO-образа дистрибутива на DVD

⁠4.2.1. Запись образа диска в операционной системе MS Windows

ISO-образ диска — это файл специального формата, содержащий образ файловой системы диска и предназначенный для записи на оптический диск.
Для записи ISO-образа в операционной системе MS Windows можно использовать специальные программы, например Nero BurningROM.
Для записи рекомендуется использовать качественные чистые диски от известных производителей. Запись образа на неисправный или низкокачественный диск может привести к ошибкам при установке системы.

⁠4.2.1.1. Запись образа диска с помощью Nero BurningROM

Процесс записи установочного диска с помощью Nero BurningROM состоит из следующих шагов:
  1. Скачать образ дистрибутива.
  2. Скачать программу Nero BurningROM с сайта производителя (http://www.nero.com) и установить её.
  3. Запустить программу и выбрать в списке устройств необходимый для записи CD/DVD-привод.
  4. Нажать кнопку Открыть в главном окне. В открывшемся окне выбрать ISO-образ для записи и нажать кнопку Открыть.
  5. В окне Записать проект на вкладке Запись установить отметку в поле Запись и выбрать необходимые параметры записи.
  6. Записать ISO-образ на диск, нажав кнопку Прожиг.

⁠4.2.2. Запись образа диска в операционной системе Linux

Для записи ISO-образов можно использовать различные утилиты и программы с графическим или текстовым интерфейсом. Например, можно использовать программы K3b или Brasero.

⁠4.2.2.1. Запись образа диска с помощью K3b

Процесс записи установочного диска с помощью K3b состоит из следующих шагов:
  1. Если программа k3b не установлена, необходимо установить её с помощью стандартных для используемого дистрибутива средств управления пакетами.
  2. Запустить программу k3b.
  3. В меню главного окна Сервис (Service) выбрать пункт Записать образ… (Burn image…).
  4. В открывшемся окне Записать образ (Burn image) нажать кнопку Выбор файла для записи. В открывшемся диалоге выбрать ISO-образ для записи и нажать кнопку ОК.
  5. Проверить сведения об ISO-образе и, при необходимости, его контрольную сумму.
  6. Вставить чистый диск в привод.
  7. Нажать кнопку Начать (Start).

⁠4.3. Проверка целостности записанного образа

Для проверки целостности записанного образа необходимо выполнить следующие шаги:
  1. Определить размер образа в байтах:
    $ du -b alt-virtualization-pve-11.2-x86_64.iso | cut -f1
    2676996096
    
  2. Вычислить контрольную сумму ISO-образа (или использовать контрольную сумму, опубликованную в файле MD5SUM на сервере FTP):
    $ md5sum alt-virtualization-pve-11.2-x86_64.iso
    a203f4d656ebacd34053a845dc6b68a3  alt-virtualization-pve-11.2-x86_64.iso
    
  3. Вычислить контрольную сумму записанного образа на DVD или USB-накопителе (команду необходимо выполнять с правами суперпользователя):
    # head -c 2676996096 /dev/sdd | md5sum
    a203f4d656ebacd34053a845dc6b68a3
    
    где 2676996096 — размер ISO-образа в байтах, полученный на первом шаге, а /dev/sdd — устройство, на которое был записан образ.

⁠Глава 5. Сохранение данных и меры предосторожности

Если необходимо установить ОС Альт Виртуализация редакция PVE и при этом сохранить уже установленную на компьютере операционную систему (например, другую версию GNU/Linux или Microsoft Windows), необходимо предварительно подготовить компьютер к установке второй системы и обеспечить сохранность важных данных.
Если у вас нет загрузочного носителя для уже установленной операционной системы, создайте его. В случае прерывания установки ОС Альт Виртуализация редакция PVE или неправильной настройки загрузчика может оказаться невозможной загрузка ранее установленной ОС.
Если на диске, выбранном для установки ОС Альт Виртуализация редакция PVE, нет свободного раздела, установщику потребуется изменить размер существующего раздела. Эта операция может привести к потере данных, поэтому перед её выполнением рекомендуется:
  1. Проверить раздел, размер которого планируется уменьшить. Для этого используйте соответствующее программное обеспечение (далее — ПО), входящее в состав уже установленной ОС. Установщик Альт Виртуализация редакция PVE может обнаружить некоторые ошибки файловой системы при изменении размера раздела, однако специализированное ПО установленной ОС может предоставить более полную проверку.
  2. При необходимости выполнить дефрагментацию раздела. Для некоторых файловых систем, например NTFS, дефрагментация может помочь переместить занятые области в начало раздела перед его уменьшением. Необходимость и способ выполнения дефрагментации зависят от используемой файловой системы.

Предупреждение

Резервное копирование важных данных — наиболее надёжный способ защиты от их потери при изменении разделов.

⁠Глава 6. Начало установки: загрузка системы

⁠6.1. Способы первоначальной загрузки

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

⁠6.2. Загрузка системы

Для того чтобы начать установку ОС Альт Виртуализация редакция PVE, достаточно загрузиться с носителя, на котором записан дистрибутив.

Примечание

Предварительно следует включить в BIOS опцию загрузки с оптического привода или с USB-устройства.
В большинстве случаев указание способа входа в BIOS отображается на вашем мониторе непосредственно после включения компьютера. Способ входа в меню BIOS и информация о расположении настроек определяются производителем используемого оборудования. За информацией можно обратиться к документации на ваше оборудование.
Начальный загрузчик EFI
Загрузка с установочного диска или специально подготовленного USB-накопителя начинается с меню, в котором перечислено несколько вариантов загрузки:
  • Install ALT Virtualization PVE 11.2 — установка операционной системы;
  • VNC install (edit to set server IP address) — установка по VNC, при которой устанавливаемая машина подключается к серверу VNC с указанным IP-адресом. Параметры установки по VNC передаются как аргументы ядра. Нажатие клавиши E позволяет задать IP-адрес сервера (чтобы принять подключение, на сервере VNC следует запустить, например, vncviewer --listen):
    Параметры установки по VNC (в сторону VNC-сервера)
  • ⁠ VNC install (edit to set password and connect here) — установка по VNC, при которой управляющий компьютер подключается к устанавливаемой машине. Параметры установки по VNC передаются как аргументы ядра. Нажатие клавиши E позволяет задать пароль (по умолчанию — VNCPWD):
    Параметры установки по VNC (в сторону устанавливаемой машины)
  • Rescue LiveCD — восстановление уже установленной, но так или иначе поврежденной ОС Linux путем запуска небольшого образа ОС в оперативной памяти. Восстановление системы потребует некоторой квалификации. Этот пункт также может быть использован для сбора информации об оборудовании компьютера, которую можно отправить разработчикам, если ОС Альт Виртуализация редакция PVE устанавливается и работает неправильно. Загрузка восстановительного режима заканчивается запросом на ввод логина суперпользователя (root):
    Log in as root
    localhost login:
    
  • Change serial console — позволяет выбрать последовательный порт для консольного подключения (например, COM1/ttyS0):
    Выбор последовательного порта
    Подробнее об установке через последовательный порт см. Загрузка с использованием последовательного порта.
  • Memory Test (may not work with Secure Boot) — проверка целостности оперативной памяти. Процесс диагностики заключается в проведении нескольких этапов тестирования каждого отдельного модуля ОЗУ (данный процесс будет выполняться бесконечно, пока его не остановят; необходимо дождаться окончания хотя бы одного цикла проверки);
  • UEFI Shell (may not work with Secure Boot) — оболочка/терминал для прошивки, позволяющий запускать EFI-приложения, в том числе загрузчики UEFI;
  • UEFI Firmware Settings — позволяет получить доступ к настройкам UEFI.

Примечание

Начальный загрузчик в режиме Legacy:
Начальный загрузчик в режиме Legacy
Пункт Boot from hard drive позволяет запустить уже установленную на жёсткий диск операционную систему.

Примечание

Мышь на этом этапе установки не поддерживается. Для выбора опций установки и различных вариантов необходимо использовать клавиатуру.
Нажатием клавиши E можно вызвать редактор параметров текущего пункта загрузки. Если система настроена правильно, редактировать их нет необходимости.
Чтобы начать установку, нужно клавишами перемещения курсора вверх и вниз выбрать пункт меню Install ALT Virtualization PVE 11.2 и нажать Enter. Начальный этап установки не требует вмешательства пользователя: происходит автоматическое определение оборудования и запуск компонентов программы установки. Сообщения о происходящем на данном этапе можно просмотреть, нажав клавишу ESC.

Примечание

В начальном загрузчике установлено небольшое время ожидания: если в этот момент не предпринимать никаких действий, то будет загружена та система, которая уже установлена на жестком диске. Если вы пропустили нужный момент, перезагрузите компьютер и вовремя выберите пункт Install ALT Virtualization PVE 11.2.

⁠6.3. Загрузка с использованием последовательного порта

Для установки ОС Альт Виртуализация редакция PVE через последовательный порт выполните следующие действия:
  1. В меню загрузчика выберите пункт Change serial console и укажите порт для консольного подключения:
    Выбор последовательного порта
  2. Выберите скорость передачи данных:
    Скорость передачи данных
  3. Запустите установку, выбрав в меню вариантов загрузки пункт VNC install (edit to set password).

    Примечание

    При необходимости можно изменить пароль для VNC-подключения (см. VNC install).
  4. Подключитесь к последовательному порту с помощью терминала. В окне консоли отобразится процесс загрузки и инициализации установщика, а также IP-адрес, порт и пароль для подключения по VNC:
    …
    Running initinstall script [85-start-multipath.sh] [ DONE ] 11:19:59
    Running initinstall script [90-alteratord.sh] [ DONE ] 11:19:59
    Running initinstall script [90-date.sh] [ DONE ] 11:19:59
    Running initinstall script [90-pkg.sh] [ DONE ] 11:20:00
    Running initinstall script [91-pkg-size.sh] [ DONE ] 11:20:01
    Running initinstall script [95-virt-env.sh] [ DONE ] 11:20:01
    Running initinstall script [98-oem.sh] [ DONE ] 11:20:01
    Open debug shell on tty2 [ DONE ] 11:20:01
    Open debug shell on tty3 [ DONE ] 11:20:01
    ** IP(s): 192.168.0.95
    ** VNC cmdline: vncpassword=Pa$$word
    
    The VNC desktop is:      localhost.localdomain:0
    PORT=5900
    
  5. Для продолжения установки подключитесь по VNC, например:
    $ vncviewer 192.168.0.95
    

    Примечание

    Дальнейшая установка выполняется в обычном режиме (см. Последовательность установки).
После завершения графической части установки в окне последовательной консоли появится запрос на ввод логина:
Welcome to ALT Virtualization PVE Edition 11.2 (Nimbostratus)!

Hostname: pve01.test.alt
IP: 192.168.0.186
Use https://192.168.0.186:8006/ to manage your PVE server.
pve01 login:

⁠Глава 7. Последовательность установки

До установки базовой системы на жёсткий диск программа установки работает с образом системы, загруженным в оперативную память компьютера.
Если инициализация оборудования завершилась успешно, запускается графический интерфейс программы установки.
Процесс установки разделён на шаги. Каждый шаг посвящён настройке или установке определённого свойства системы. Шаги нужно проходить последовательно. Переход к следующему шагу происходит по нажатию кнопки Далее. При помощи кнопки Назад можно вернуться к уже пройденному шагу и изменить настройки. Однако возможность перехода к предыдущему шагу ограничена шагами, не зависящими от данных, введенных ранее.
В случае необходимости отменить установку следует нажать кнопку <Reset> на корпусе системного блока компьютера.

Примечание

Безопасно отменить установку можно только до шага Подготовка диска, поскольку до этого момента изменения на жестком диске не производятся. Если прервать установку между шагами Подготовка диска и Установка загрузчика, существует вероятность, что после этого с жёсткого диска не сможет загрузиться ни одна из установленных систем (если такие имеются).
Технические сведения о ходе установки можно посмотреть, нажав клавиши Ctrl+Alt+F1, а вернуться к программе установки — Ctrl+Alt+F7. При нажатии клавиш Ctrl+Alt+F2 открывается отладочная виртуальная консоль.
Каждый шаг сопровождается краткой справкой, которую можно вызвать, щёлкнув кнопку Справка или нажав клавишу F1.
Нажатие кнопки позволяет показать или скрыть панель со списком шагов установки:
Список шагов

⁠Глава 8. Язык

Язык
Установка Альт Виртуализация редакция PVE начинается с выбора основного языка — языка интерфейса программы установки и устанавливаемой системы. В списке, помимо доступных языков региона (выбранного на этапе начальной загрузки), указан и английский язык.
На этом же этапе выбирается вариант переключения раскладки клавиатуры. Раскладка клавиатуры — это соответствие букв, цифр и специальных символов клавишам на клавиатуре. Помимо ввода символов на основном языке, в любой системе Linux необходимо иметь возможность вводить латинские символы (имена команд, файлов и т.п.). Для этого обычно используется стандартная английская раскладка клавиатуры. Переключение между раскладками осуществляется при помощи специально зарезервированных для этого клавиш. Для русского языка доступны следующие варианты переключения раскладки:
  • клавиши Alt и Shift одновременно;
  • клавиша CapsLock;
  • клавиши Control и Shift одновременно;
  • клавиша Control;
  • клавиша Alt.
Если выбранный основной язык имеет только одну раскладку (например, при выборе английского языка в качестве основного), эта раскладка будет выбрана автоматически.

⁠Глава 9. Лицензионное соглашение

Лицензионное соглашение
Перед продолжением установки следует внимательно прочитать условия лицензии. В лицензии говорится о ваших правах. В частности, за вами закрепляются права на:
  • эксплуатацию программ на любом количестве компьютеров и в любых целях;
  • распространение программ (сопровождая их копией авторского договора);
  • получение исходных текстов программ.
Если вы приобрели дистрибутив, то данное лицензионное соглашение прилагается в печатном виде к вашей копии дистрибутива. Лицензия относится ко всему дистрибутиву Альт Виртуализация редакция PVE. Если вы согласны с условиями лицензии, отметьте пункт Да, я согласен с условиями и нажмите кнопку Далее.

⁠Глава 10. Дата и время

На данном этапе выполняется выбор региона и города, по которым определяются часовой пояс и системные часы.
Дата и время (выбор часового пояса)
Для корректной установки даты и времени достаточно правильно указать часовой пояс и выставить требуемые значения для даты и времени.
На этом шаге следует выбрать часовой пояс, по которому нужно установить часы. Для этого в соответствующих списках выберите регион, а затем город. Поиск по списку можно ускорить, набирая на клавиатуре первые буквы искомого слова.
Пункт Хранить время в BIOS по Гринвичу задает хранение системного времени в BIOS по времени Гринвича и добавляет к местному времени часовую поправку для выбранного региона.
После выбора часового пояса будут предложены значения системной даты и времени по умолчанию.
Для ручной установки текущих даты и времени нужно нажать кнопку Изменить…. Откроется окно ручной настройки системных параметров даты и времени.
Дата и время
По умолчанию для синхронизации системных часов (NTP) с удаленным сервером по сети Интернет отмечен пункт Получать точное время с NTP-сервера и указан сервер 2.ru.pool.ntp.org.
Если выбрана опция Получать точное время с NTP-сервера, компьютер также может выступать в качестве сервера точного времени. Для работы компьютера в качестве сервера точного времени внутри локальной сети необходимо отметить пункт Работать как NTP-сервер.
Для сохранения настроек и продолжения установки системы в окне ручной установки даты и времени необходимо нажать кнопку ОК, а затем в окне Дата и время — кнопку Далее.

Примечание

Если ОС Альт Виртуализация редакция PVE устанавливается как вторая ОС, необходимо снять отметку с пункта Хранить время в BIOS по Гринвичу, иначе время в уже установленной ОС может отображаться некорректно.

⁠Глава 11. Подготовка диска

На данном этапе установки необходимо выбрать конфигурацию хранилища будущей системы.
Возможные варианты разметки:
  • установка на LVM (с тонким пулом для хранения образов виртуальных машин);
  • программный RAID-массив на Btrfs.
Профиль разбиения диска можно выбрать в поле Схема разметки:
Возможные варианты разметки в режиме UEFI
В режиме BIOS Legacy доступны следующие варианты разметки: установка на LVM и Btrfs Single:
Возможные варианты разметки в режиме BIOS Legacy

⁠11.1. Профиль LVM

Профиль LVM соответствует пункту ext4 (LVM). При данной схеме разбиения создаётся группа томов (VG) с именем pve. Также создаются следующие логические тома (LV):
  • root — корневой том ('/') с файловой системой ext4;
  • swap — том подкачки (рекомендуемый размер тома — не менее 2 ГиБ);
  • data — логический том с тонким пулом (Thin Pool) для хранения образов виртуальных дисков и данных контейнеров.
Размеры перечисленных логических томов автоматически подбираются на основе общего доступного дискового пространства.
По умолчанию используется весь диск, при этом в группе томов сохраняется 1–2 ГиБ свободного пространства. Это пространство может быть использовано, например, при создании снимков (snapshots) системы.

Примечание

При установке системы в режиме UEFI раздел EFI создаётся автоматически.
Установка системы на LVM
Для установки системы на LVM необходимо:
  1. В списке Схема разметки выбрать файловую систему ext4 (LVM).
  2. В списке Диск для установки выбрать диск, на который будет установлена система.
  3. В поле Общее выделяемое пространство на диске при необходимости указать размер выделяемого пространства (по умолчанию используется весь диск).
В таблице будут показаны планируемые логические тома.
Для добавления дополнительного тома необходимо:
  1. Нажать кнопку Добавить.
  2. В открывшемся окне:
    • в списке Том (точка монтирования) выбрать одну из предложенных точек монтирования либо выбрать пункт Указать произвольную точку монтирования и задать её в поле Путь монтирования;
    • в списке Тип размещения выбрать:
      • Логический том LVM — для размещения тома как дополнительного LV в VG;
      • Отдельный раздел — для размещения тома в отдельном разделе на диске (например, для /boot);
    • в поле Размер указать размер тома;
    • в поле Опции монтирования при необходимости задать параметры монтирования.
Добавление дополнительного тома LVM

Примечание

Для добавления новых томов может потребоваться уменьшить размер уже существующего тома.
Все дополнительные тома будут использовать файловую систему ext4 (как и корневой том).
Для изменения или удаления тома необходимо выбрать его и нажать кнопку Изменить или Удалить.

Примечание

Корневой том удалить нельзя.
Для продолжения установки нажмите кнопку Далее. Появится окно с предупреждением о том, что данные на выбранном диске будут уничтожены. Если вы уверены, что диск выбран верно, подтвердите переход к следующему шагу нажатием кнопки ОК.
Подготовка диска. Предупреждение об удалении данных на диске

Предупреждение

С выбранного диска будут удалены все данные без возможности восстановления.

Примечание

Пример результата автоматического разбиения диска (100 ГБ) при выборе схемы разметки ext4 (LVM):
# lsblk
NAME               MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
sda                  8:0    0  100G  0 disk
├─sda1               8:1    0  600M  0 part /boot/efi
└─sda2               8:2    0 99,4G  0 part
  ├─pve-swap       253:0    0    2G  0 lvm  [SWAP]
  ├─pve-root       253:1    0   14G  0 lvm  /
  ├─pve-data_tmeta 253:2    0   84M  0 lvm
  │ └─pve-data     253:4    0 81,8G  0 lvm
  └─pve-data_tdata 253:3    0 81,8G  0 lvm
    └─pve-data     253:4    0 81,8G  0 lvm
sr0                 11:0    1  2,5G  0 rom

⁠11.2. Профиль Btrfs RAID

При установке дистрибутива можно выбрать Btrfs в качестве корневой файловой системы и указать тип RAID:
  • RAID 0 — чередование без отказоустойчивости. Доступная ёмкость определяется суммарной ёмкостью дисков. RAID0 не обеспечивает избыточности, поэтому отказ одного из дисков приводит к потере всех данных;
  • RAID 1 — зеркалированный массив. Данные записываются с избыточностью на несколько дисков. Для работы требуется не менее двух дисков. Эффективная ёмкость ограничивается возможностями распределения данных и размером меньшего диска;
  • RAID 10 (RAID 1 + RAID 0) — зеркалирование с чередованием. Данные записываются последовательно на несколько дисков, как в RAID 0, но каждый блок зеркалируется, как в RAID 1. Требуется не менее четырёх дисков;
  • Single — режим без избыточности.

Примечание

При установке системы в режиме UEFI раздел EFI создаётся автоматически.
Установка системы на Btrfs RAID
Для установки системы на Btrfs RAID необходимо:
  1. В списке Схема разметки выбрать файловую систему Btrfs и нужный тип RAID.
  2. В списке Диски для установки выбрать диски, на которых будет создан массив и установлена система.
В результате такого разбиения создаётся файловая система Btrfs с выбранным профилем RAID и корневым подтомом (subvolume). Для PVE также автоматически создаётся дополнительный подтом, который монтируется в /var/lib/pve/local-btrfs. Он используется для хранения данных, необходимых для работы виртуализации.
Для добавления дополнительного тома или подтома необходимо:
  1. Нажать кнопку Добавить.
  2. В открывшемся окне:
    • в списке Том (точка монтирования) выбрать одну из предложенных точек монтирования либо выбрать пункт Указать произвольную точку монтирования и задать её в поле Путь монтирования;
    • в списке Тип размещения выбрать:
      • Дополнительный btrfs подтом — подтом создаётся внутри корневого тома и использует его пространство;
      • Отдельный btrfs том — создаётся отдельный RAID-том на новых разделах. Это позволяет ограничить его размер и сделать его независимым от корневого;
    • если выбран вариант Отдельный btrfs том, в поле Размер указать размер тома;
    • в поле Опции монтирования при необходимости задать параметры монтирования.
Добавление дополнительного тома Btrfs

Примечание

Для добавления новых томов может потребоваться уменьшить размер корневого раздела.
Для изменения или удаления тома необходимо выбрать его и нажать кнопку Изменить или Удалить.

Примечание

Корневой том удалить нельзя.

Примечание

Установщик автоматически разбивает диски на разделы и создает дополнительный подтом в /var/lib/pve/local-btrfs. Для того чтобы использовать данный подтом инструментами PVE, в /etc/pve/storage.cfg будет создана следующая конфигурация:
dir: local
        path /var/lib/vz
        content iso,vztmpl,backup
        disable # стандартное хранилище отключено

btrfs: local-btrfs
        path /var/lib/pve/local-btrfs
        content iso,vztmpl,backup,images,rootdir
Таким образом, хранилище local будет отключено в пользу local-btrfs, расположенного на дополнительном подтоме. Хранилище local-btrfs поддерживает все типы данных (образы, шаблоны, резервные копии и т.д).
После установки вывести список всех подтомов можно, выполнив команду:
# btrfs subvolume list /
ID 256 gen 160 top level 5 path var_lib_pve_local-btrfs
ID 257 gen 196 top level 5 path root
ID 258 gen 134 top level 257 path var/lib/machines
Для продолжения установки нажмите кнопку Далее. Появится окно с предупреждением о том, что данные на выбранных дисках будут уничтожены. Если вы уверены, что диски выбраны верно, подтвердите переход к следующему шагу нажатием кнопки ОК.
Подготовка диска. Предупреждение об удалении данных на дисках

Предупреждение

С выбранных дисков будут удалены все данные без возможности восстановления.

⁠Глава 12. Установка системы

На данном этапе выполняются распаковка ядра и установка набора программ, необходимых для работы ОС Альт Виртуализация редакция PVE.
Установка системы
Установка происходит автоматически в два этапа:
  • получение пакетов;
  • установка пакетов.
Получение пакетов осуществляется из источника, выбранного на этапе начальной загрузки. При сетевой установке время выполнения этого шага зависит от скорости соединения и может быть значительно больше по сравнению с локальной установкой.

⁠Глава 13. Сохранение настроек

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

⁠Глава 14. Установка загрузчика

Загрузчик ОС — это программа, которая позволяет загружать ОС Альт Виртуализация редакция PVE и другие ОС, если они установлены на данной машине.
При установке в режиме EFI модуль установки загрузчика предложит вариант установить загрузчик в специальный раздел «EFI» (рекомендуется выбрать автоматическое разбиение на этапе разметки диска для создания необходимых разделов для загрузки с EFI):
Установка загрузчика при установке в режиме EFI
Варианты установки загрузчика при установке в режиме EFI:
  • EFI (для съёмных устройств) — этот вариант следует выбирать, если ОС устанавливается на съёмный накопитель, при размещении раздела ESP на RAID1 с суперблоком версии 1.0, а также при наличии иных причин не создавать запись в NVRAM;
  • EFI (рекомендуемый) — при установке загрузчика в NVRAM добавляется запись, без которой большинство компьютеров не смогут загрузиться во вновь установленную ОС;
  • EFI (сначала очистить NVRAM) — перед добавлением записи всё содержимое NVRAM сохраняется в /root/.install-log, после чего из NVRAM удаляются все загрузочные записи. Это освобождает место в NVRAM и гарантирует, что система загрузится в установленную ОС;
  • EFI (запретить запись в NVRAM) — этот вариант следует выбирать, только если установщик не может создать запись в NVRAM или если заранее известно, что запись в NVRAM может привести к неработоспособности компьютера. В этом случае запись в NVRAM, возможно, потребуется создать после установки ОС средствами BIOS Setup;
Выбор варианта установки загрузчика зависит от вашего оборудования. Если один вариант не работает, попробуйте использовать другой.

Примечание

Установка загрузчика при установке в режиме Legacy:
Установка загрузчика
Программа установки автоматически определяет раздел жёсткого диска, в котором следует разместить загрузчик для корректного запуска ОС Альт Виртуализация редакция PVE. При необходимости расположение загрузчика можно изменить в списке Устройство, выбрав другой раздел.

Примечание

Если планируется использовать и другие операционные системы, уже установленные на этом компьютере, то имеет значение, на каком жёстком диске или в каком разделе будет расположен загрузчик.
Для ограничения доступа к параметрам загрузки можно установить пароль на загрузчик. Для этого необходимо отметить пункт Установить или сбросить пароль и задать пароль в появившихся полях для ввода.
Установка загрузчика

Примечание

При необходимости изменения параметров загрузки при старте компьютера потребуется ввести имя пользователя «boot» и пароль, заданный на этом шаге.
Для подтверждения выбора и продолжения работы программы установки необходимо нажать кнопку Далее.

⁠Глава 15. Ethernet-интерфейсы

На этом этапе выполняется настройка сети для PVE с созданием моста vmbr0.

Примечание

Для установки PVE должен быть настроен сетевой мост vmbr0 с указанием статического IP-адреса. Это обусловлено тем, что сетевые интерфейсы виртуальных окружений должны подключаться к какому-то виртуальному устройству, обеспечивающему соединение с общей сетью передачи данных.
Настройка сети
Для настройки сети необходимо выполнить следующие действия:
  1. В поле Имя хоста (FQDN) указать полное имя компьютера с доменом (FQDN).
  2. В списке Интерфейсы выбрать интерфейс, который будет входить в мост.
  3. В поле IP-адрес (CIDR) ввести IP-адрес и выбрать в раскрывающемся списке предпочтительную маску сети.
  4. В поле Шлюз по умолчанию указать адрес шлюза, который будет использоваться сетью по умолчанию.
  5. При необходимости в поле DNS-серверы можно указать список (через пробел) предпочтительных DNS-серверов, которые будут использоваться для разрешения имён, маршрутизации запросов и других сетевых операций.
  6. В поле Домены поиска можно указать список предпочтительных доменов, по которым будет выполняться поиск.
  7. Если на выбранный сетевой интерфейс приходит тегированный трафик, в поле VLAN ID можно указать номер VLAN.

Примечание

Остальные интерфейсы можно будет настроить после установки системы в веб-интерфейсе PVE.
Для сохранения настроек и продолжения работы программы установки необходимо нажать кнопку Далее.

⁠Глава 16. Администратор системы

На данном этапе создаётся учетная запись администратора. В открывшемся окне необходимо ввести пароль учетной записи администратора (root). Чтобы исключить опечатки при вводе пароля, пароль учетной записи вводится дважды.
Администратор системы

Примечание

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

Важно

Необходимо запомнить пароль root — он потребуется для получения прав на изменение настроек системы с помощью стандартных средств настройки Альт Виртуализация редакция PVE. Более подробная информация о режиме суперпользователя приведена в главе Режим суперпользователя.
Чтобы подтвердить введённый (или сгенерированный) пароль учётной записи администратора (root) и продолжить установку, необходимо нажать кнопку Далее.

⁠Глава 17. Системный пользователь

На данном этапе создаётся учётная запись обычного пользователя ОС Альт Виртуализация редакция PVE.
Системный пользователь
Помимо учётной записи администратора (root) в систему необходимо добавить по меньшей мере одного обычного пользователя. Для повседневной работы рекомендуется использовать учётную запись с ограниченными правами, а не учётную запись root.
При добавлении пользователя необходимо ввести имя учётной записи. Имя учётной записи должно состоять только из строчных латинских букв, цифр и символа подчёркивания _. Имя не может начинаться с цифры или символа подчёркивания.
Для исключения опечаток пароль пользователя вводится дважды. Пароль можно создать автоматически.
Для автоматической генерации пароля необходимо отметить пункт Создать автоматически. Система предложит пароль, сгенерированный в соответствии с требованиями к стойкости паролей.
В процессе установки предлагается создать только одну учётную запись обычного пользователя. Эту учётную запись можно использовать для выполнения задач, не требующих привилегий суперпользователя. Учётные записи других пользователей системы можно создать в любой момент после установки операционной системы.
Чтобы подтвердить введённый (или сгенерированный) пароль учётной записи пользователя и продолжить установку, необходимо нажать кнопку Далее.

⁠Глава 18. Завершение установки

На экране последнего шага установки отображается информация о завершении установки Альт Виртуализация редакция PVE.
Завершение установки
После нажатия кнопки Завершить и перезагрузки компьютера выполняется штатная загрузка установленной ОС.
Если компьютер продолжает загружаться с установочного носителя, извлеките его или измените порядок загрузки в BIOS/UEFI, установив диск с установленной ОС первым в списке загрузочных устройств.

⁠Глава 19. Обновление системы до актуального состояния

После установки системы рекомендуется сразу установить последние доступные обновления. Если система не будет подключаться к сети или Интернету и дополнительные программы устанавливаться не будут, обновление можно выполнить позднее.
Для обновления системы необходимо выполнить следующие команды (с правами суперпользователя):
# apt-get update
# apt-get dist-upgrade
# update-kernel
# apt-get clean
После завершения обновления перезагрузите систему:
# reboot

Примечание

Получить права суперпользователя можно, выполнив команду:
$ su -
или выполнив вход в систему от имени пользователя root.
Подробнее о режиме суперпользователя см. в главе Режим суперпользователя.

Примечание

Подробнее про обновление пакетов можно прочитать в главах Обновление всех установленных пакетов и Обновление ядра.

⁠Глава 20. Первая помощь

Важно

В случае возникновения каких-либо неприятностей не паникуйте, а спокойно разберитесь в сложившейся ситуации. Linux не так уж просто довести до полной неработоспособности и утраты ценных данных. Поспешные действия отчаявшегося пользователя могут привести к плачевным результатам. Помните, что решение есть, и оно обязательно найдётся!

⁠20.1. Проблемы при установке системы

Важно

При возникновении проблем с UEFI или Legacy/CSM рекомендуется изменить используемый режим прошивки на другой. Не следует выбирать режим смешанной загрузки Legacy/UEFI! Рекомендуется временно отключить всевозможные оптимизации и ускорение UEFI-загрузки, а также отключить на время установки SecureBoot.
Если в системе не произошла настройка какого-либо компонента после стадии установки пакетов, не отчаивайтесь, доведите установку до конца, загрузитесь в систему и попытайтесь в спокойной обстановке повторить настройку.
Если установить систему не удалось вовсе, попробуйте изменить параметры загрузки.
Нажатием клавиши E можно вызвать редактор параметров текущего пункта загрузки. В открывшемся редакторе следует найти строку, начинающуюся с linux /boot/vmlinuz, в её конец дописать требуемые параметры, отделив их пробелом, и нажать F10.
Редактор параметров пункта загрузки
Можно использовать следующие параметры загрузки:
  • nomodeset — отключает автозагрузку графических драйверов. Используется для предотвращения проблем с отображением на этапе загрузки, например при появлении чёрного экрана;
  • nosplash — отключает графический экран загрузки, позволяя видеть сообщения консоли;
  • vga=normal — отключает графический экран загрузки установщика;
  • xdriver=vesa — позволяет явно указать видеодрайвер vesa. Может применяться при проблемах с загрузкой графической подсистемы;
  • module_blacklist=nouveau,nvidia,ast — запрещает загрузку указанных модулей ядра;
  • bc_debug — включает режим расширенной диагностики на этапе stage1 и копирует журнал в stage2;
  • irqpoll — заставляет ядро опрашивать IRQ (аппаратные прерывания) вручную;
  • pci=nomsi — отключает использование MSI/MSI-X (Message Signaled Interrupts) для PCI-устройств. Может применяться при проблемах с обработкой аппаратных прерываний на некоторых контроллерах и материнских платах, которые могут приводить к зависаниям, нестабильной работе устройств или невозможности загрузки системы;
  • pci=noaer — отключает AER (Advanced Error Reporting) для PCI-устройств. Может применяться при проблемах с PCIe-контроллерами, чтобы подавить избыточные сообщения в журнале и предотвратить сбои при загрузке;
  • acpi=off — отключает ACPI (Advanced Configuration and Power Interface). Может применяться, если оборудование или прошивка некорректно поддерживают ACPI;
  • noapic — отключает использование APIC (Advanced Programmable Interrupt Controller). Может применяться при проблемах с обработкой аппаратных прерываний;
  • mce=off — отключает Machine Check Exception (MCE), механизм обнаружения аппаратных ошибок процессора и других компонентов;
  • barrier=off — отключает барьеры записи, используемые для обеспечения порядка операций записи. Может применяться при проблемах с определёнными устройствами или драйверами;
  • oldinst — применяет более медленный метод копирования файлов вместо распаковки с помощью unsquashfs (актуально только для образов, использующих SquashFS).
Если установка не выполняется или не завершается на этапе установки пакетов, попробуйте повторить установку в безопасном режиме, добавив следующие параметры:
apm=off acpi=off mce=off barrier=off vga=normal
В этом режиме отключаются некоторые функции управления питанием, обработки аппаратных ошибок, барьеры записи и графический режим загрузки. Кроме того, отключается использование APIC.
Если проблемы сохраняются, можно дополнительно попробовать параметры nomodeset, pci=nomsi, pci=noaer или irqpoll в зависимости от характера проблемы.
Если вы хотите получить точный ответ, то сообщите, пожалуйста, подробный состав вашего оборудования и подробное описание возникшей проблемы в нашей системе отслеживания ошибок.

⁠20.2. Проблемы с загрузкой системы

Если не загружается ни одна из установленных операционных систем, значит, проблема заключается в начальном загрузчике. Такие проблемы могут возникнуть после установки системы, если загрузчик не был установлен или установлен с ошибкой. При установке или переустановке Windows на вашем компьютере загрузчик Linux будет перезаписан в принудительном порядке, и станет невозможно запускать Linux.
Повреждение или перезапись загрузчика никак не затрагивает остальные данные на жёстком диске, поэтому в такой ситуации очень легко вернуть работоспособность: для этого достаточно восстановить загрузчик.
Если у вас исчез загрузчик другой операционной системы или другого производителя, обратитесь к соответствующему официальному руководству по восстановлению загрузчика. Но в большинстве случаев вам это не потребуется, так как загрузчик, входящий в состав Альт Виртуализация редакция PVE, поддерживает загрузку большинства известных операционных систем.
Для восстановления загрузчика достаточно любым доступным способом загрузить Linux и получить доступ к тому жёсткому диску, на котором находится повреждённый загрузчик. Для этого проще всего воспользоваться восстановительным режимом, который предусмотрен на установочном диске дистрибутива (пункт Rescue LiveCD).
Загрузка восстановительного режима заканчивается запросом на ввод логина суперпользователя (root):
Log in as root
localhost login:
После ввода логина суперпользователя (root) появится приглашение командной строки: [root@localhost /]#. Начиная с этого момента, система готова к вводу команд.
Восстановительный режим
В большинстве случаев для восстановления загрузчика можно просто воспользоваться командой fixmbr без параметров. Программа попытается переустановить загрузчик в автоматическом режиме.

⁠20.3. Полезные ссылки

Если у вас что-то не получается, вы всегда можете поискать решение на ресурсах, указанных в разделе Техническая поддержка продуктов «Базальт СПО».

⁠Часть III. Начало использования Альт Виртуализация редакция PVE

В этой части рассматривается загрузка установленной операционной системы.

⁠Глава 21. Загрузка системы

Запуск ОС Альт Виртуализация редакция PVE выполняется автоматически после включения компьютера и завершения работы программ начальной загрузки, выполняемых BIOS или UEFI. После этого управление передаётся загрузчику ОС.
Загрузчик настраивается автоматически и обнаруживает установленные на компьютере операционные системы. Поэтому загрузчик может использоваться для выбора и запуска других операционных систем, если они установлены на компьютере.
При стандартной установке ОС Альт Виртуализация редакция PVE в начальном меню загрузчика доступны несколько вариантов загрузки:
Варианты загрузки

Важно

При первом запуске системы, если на компьютере установлено несколько ОС, в загрузочном меню могут отсутствовать пункты для некоторых из них. В этом случае соответствующие пункты могут быть добавлены в загрузочное меню после перезагрузки системы.
С помощью клавиш со стрелками Вверх и Вниз выберите нужную операционную систему. Помимо обычной загрузки ОС, из этого меню можно выбрать загрузку Linux в режиме восстановления или запустить проверку оперативной памяти с помощью Memtest86+.
По умолчанию, если не нажимать клавиши на клавиатуре, загрузка ОС Альт Виртуализация редакция PVE автоматически начнётся после небольшого времени ожидания (обычно несколько секунд). Нажатием клавиши Enter можно начать загрузку немедленно.
Нажатием клавиши E можно вызвать редактор параметров текущего пункта загрузки. Если система настроена правильно, изменять параметры загрузки не требуется.
В процессе загрузки ОС Альт Виртуализация редакция PVE на экране монитора отображается информация о процессе загрузки, включая сообщения о запуске различных служб и программных компонентов.
Информация о процессе загрузки системы
В зависимости от используемых компонентов и настроек системы в процессе загрузки могут отображаться сообщения о результате выполнения отдельных операций. Например, сообщения FAILED и OK обозначают соответственно неудачное и успешное завершение операции.
Наличие сообщения FAILED не всегда означает необходимость вмешательства администратора: значение сообщения зависит от того, какая именно операция завершилась неудачно. Если после загрузки система работает штатно, отдельное сообщение об ошибке не обязательно свидетельствует о неисправности системы.
Загрузка операционной системы может занять некоторое время в зависимости от производительности компьютера. Основные этапы загрузки операционной системы — загрузка ядра, подключение (монтирование) файловых систем и запуск системных служб — в некоторых случаях могут дополняться проверкой файловых систем на наличие ошибок. В этом случае загрузка может занять больше времени, чем обычно.
Подробную информацию о шагах загрузки можно получить, нажав клавишу Esc.

⁠Глава 22. Вход в систему

Стандартная установка Альт Виртуализация редакция PVE включает базовую систему, работающую в консольном режиме.
После загрузки будут показаны имя и IP-адрес компьютера, а также адрес доступа к панели управления:
IP адрес компьютера и адрес панели управления PVE
При загрузке в консольном режиме система отображает запрос на ввод имени пользователя и пароля учётной записи.
После успешной аутентификации пользователя выполняется вход в систему. ОС Альт Виртуализация редакция PVE переходит в штатный режим работы и предоставляет доступ к консоли.
В процессе работы ОС Альт Виртуализация редакция PVE доступны несколько виртуальных консолей. Каждая виртуальная консоль доступна при одновременном нажатии клавиш Alt и соответствующей функциональной клавиши от F1 до F6.
На первых шести виртуальных консолях (от Alt+F1 до Alt+F6) пользователь может зарегистрироваться в системе и работать в текстовом режиме. Двенадцатая виртуальная консоль (Alt+F12) используется как системная консоль — на нее выводятся сообщения о происходящих в системе событиях.

⁠Часть IV. Средство управления виртуальными окружениями PVE

Proxmox Virtual Environment (PVE) — средство управления виртуальными окружениями на базе гипервизора KVM и системы контейнерной изоляции LXC. Основными компонентами среды являются:
  • физические серверы, на которых запускаются виртуальные машины (KVM) и контейнеры (LXC);
  • хранилища данных для образов установочных носителей, дисков виртуальных машин (KVM) и корневых файловых систем контейнеров (LXC);
  • виртуальные сетевые мосты (bridges), к которым подключаются сетевые интерфейсы виртуальных машин и контейнеров.
PVE включает веб-интерфейс, распределённую файловую систему для хранения конфигураций (pmxcfs) и набор утилит командной строки для управления. Все эти компоненты служат исключительно для управления виртуальными машинами и контейнерами. Функционирование PVE зависит от базовых компонентов хост-системы, не входящих в его состав: сетевой и дисковой подсистем, а также механизмов аутентификации.

⁠Глава 23. Системные требования

Требования к аппаратным ресурсам узла виртуализации зависят от количества, типа и ресурсоёмкости размещаемых ВМ.
Минимальная конфигурация (для тестирования):
  • CPU: 64-битный процессор (Intel 64 или AMD64) с поддержкой аппаратной виртуализации Intel VT-x или AMD-V, не менее 2 ядер;
  • 2 Гб ОЗУ;
  • один жёсткий диск;
  • сетевой адаптер.
Рекомендуемая конфигурация для эксплуатации:
  • многоядерный 64-битный CPU с поддержкой аппаратной виртуализации Intel VT-x или AMD-V, рекомендуется не менее 4 ядер;
  • не менее 4 Гб ОЗУ для ОС и сервисов PVE, а также дополнительная память для гостевых систем. Для Ceph или ZFS требуется дополнительная память, примерно 1 ГБ ОЗУ на каждый ТБ используемого хранилища;
  • хранилище для ОС: аппаратный RAID;
  • хранилище для ВМ:
    • аппаратный RAID при использовании локального хранилища;
    • non-RAID при использовании ZFS;
    • совместно используемые хранилища (NFS, iSCSI);
    • распределенные хранилища (Ceph);
  • диски SAS 15K RPM в конфигурации RAID10 (для высокой производительности);
  • сетевой адаптер.
Реальные системные требования определяются количеством и ресурсоёмкостью гостевых систем.

⁠Глава 24. Краткое описание возможностей

⁠24.1. Веб-интерфейс

Веб-интерфейс PVE предназначен для выполнения следующих задач:
  • создание, удаление, настройка виртуальных машин и контейнеров;
  • управление физическими серверами;
  • мониторинг активности виртуальных сред и использования ресурсов среды;
  • создание снимков (snapshots), резервных копий и шаблонов, а также восстановление из резервных копий.
Кроме решения пользовательских задач, веб-интерфейс PVE можно использовать еще и для встраивания в интегрированные системы управления — например, в панели управления хостингом. Для этого он имеет развитый RESTful API с JSON в качестве основного формата данных.
Для аутентификации можно использовать как встроенные механизмы PVE, так и PAM, что позволяет, например, интегрировать PVE в домен.
Благодаря использованию кластерной файловой системы (pmxcfs), веб-интерфейс доступен с любого узла кластера и позволяет управлять всей инфраструктурой.
Веб-интерфейс PVE доступен по адресу https://<имя-компьютера>:8006. Для входа требуется аутентификация (логин по умолчанию: root, пароль указывается в процессе установки ОС):
Аутентификация в веб-интерфейсе PVE
Пользовательский интерфейс PVE состоит из четырех областей:
  • заголовок — верхняя часть окна, в которой отображаются общая информация о состоянии системы и кнопки основных действий;
  • дерево ресурсов — навигационная панель слева, предназначенная для выбора объектов;
  • панель контента — центральная область, в которой отображаются конфигурация и состояние выбранного объекта;
  • панель журнала — нижняя область, в которой отображаются сведения о недавно выполненных задачах. Для получения подробной информации или прерывания задачи следует дважды щёлкнуть по соответствующей записи.
Веб-интерфейс PVE

Примечание

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

⁠24.2. Хранилище данных

При локальной установке PVE можно использовать локальную файловую систему сервера без дополнительной настройки хранилища. Однако в кластере из нескольких серверов рекомендуется настроить сетевую или распределённую файловую систему, обеспечивающую параллельный доступ ко всем данным со всех узлов. В качестве таких систем могут использоваться, например, NFS или Ceph.

⁠24.3. Сетевая подсистема

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

⁠Глава 25. Создание кластера PVE

Рекомендации:
  • для работы Corosync все узлы должны иметь возможность обмениваться трафиком через UDP-порты 5405-5412;
  • дата и время на всех узлах должны быть синхронизированы;
  • для взаимодействия между узлами используется SSH через TCP-порт 22;
  • для работы механизма высокой доступности (HA) и формирования кворума необходимо как минимум три узла. На всех узлах должна быть установлена одна версия PVE;
  • рекомендуется использовать выделенный сетевой адаптер для трафика кластера, особенно если используется общее хранилище.

Примечание

Для небольших кластеров из двух узлов можно использовать QDevice для обеспечения третьего голоса.
Кластер не создается автоматически на только что установленном узле PVE. В настоящее время создание кластера может быть выполнено либо в консоли (вход через SSH), либо в веб-интерфейсе.

Важно

PVE при создании кластера включает автоматически парольную аутентификацию для root в sshd. В целях повышения безопасности, после добавления всех узлов в кластер, рекомендуется отключить парольную аутентификацию для root в sshd:
# control sshd-permit-root-login without_password
# systemctl restart sshd
При добавлении в кластер нового узла можно временно включить парольную аутентификацию:
# control sshd-permit-root-login enabled
# systemctl restart sshd
А после того, как сервер будет добавлен, снова отключить.
Кластеры используют ряд определённых портов для различных функций. Важно обеспечить доступность этих портов и отсутствие их блокировки межсетевыми экранами.
⁠

Таблица 25.1. Используемые порты

Порт
Функция
TCP 8006
Веб-интерфейс PVE
TCP 5900-5999
Доступ к консоли VNC
TCP 3128
Доступ к консоли SPICE
TCP 22
SSH-доступ
UDP 5405-5412
Трафик кластера Corosync
TCP 60000-60050
Живая миграция (память ВМ и данные локального диска)

⁠25.1. Настройка узлов кластера

PVE должен быть установлен на всех узлах. Следует убедиться, что каждый узел установлен с окончательным и уникальным именем хоста, а также корректной IP-конфигурацией. Изменение имени хоста или IP-адреса после создания кластера невозможно и приведёт к нарушению его работы.
Необходимо обеспечить взаимно однозначное прямое и обратное преобразование имен для всех узлов кластера. Рекомендуется использовать DNS. В крайнем случае можно добавить соответствующие записи в локальные файлы /etc/hosts:
# echo "192.168.0.186 pve01.test.alt pve01" >> /etc/hosts
# echo "192.168.0.90 pve02.test.alt pve02" >> /etc/hosts
# echo "192.168.0.70 pve03.test.alt pve03" >> /etc/hosts

Примечание

В PVE добавить записи в файл /etc/hosts можно в панели управления: выбрать узел, перейти в Система → Хосты, добавить все узлы, которые будут включены в состав кластера и нажать кнопку Сохранить:
Редактирование записей в файле /etc/hosts

Примечание

Имя машины не должно быть указано в файле /etc/hosts с адресом 127.0.0.1.

⁠25.2. Создание кластера в веб-интерфейсе

Для создания кластера необходимо выполнить следующие действия:
  1. В панели управления любого узла кластера выбрать Центр обработки данных → Кластер и нажать кнопку Создать кластер:
    Создание кластера в веб-интерфейсе
  2. В открывшемся окне задать название кластера, выбрать IP-адрес интерфейса, на котором узел кластера будет работать, и нажать кнопку Создать:
    Название кластера
  3. При успешном создании кластера будет выведена соответствующая информация:
    Информация о создании кластера
⁠ Для добавления узла в кластер необходимо выполнить следующие действия:
  1. В панели управления узла, на котором был создан кластер, выбрать Центр обработки данных → Кластер и нажать кнопку Данные присоединения:
    Создание кластера в веб-интерфейсе. Получить данные присоединения
  2. В открывшемся окне, нажав кнопку Копировать данные, скопировать данные присоединения:
    Создание кластера. Данные присоединения
  3. Перейти в панель управления узла, который следует присоединить к кластеру. Выбрать Центр обработки данных → Кластер и нажать кнопку Присоединить к кластеру:
    Узел, который следует присоединить к кластеру
  4. В поле Информация вставить данные присоединения, поля Адрес сервера и Отпечаток при этом будут заполнены автоматически. В поле Пароль ввести пароль пользователя root первого узла и нажать кнопку Присоединить <имя_кластера>:
    Присоединение узла к кластеру
    Чтобы ввести все необходимые данные вручную, следует снять отметку с поля Быстрое подключение.
  5. После завершения синхронизации конфигурации узел будет присоединён к кластеру:
    Узлы кластера в веб-интерфейсе
    Продолжительность операции зависит от конфигурации кластера и состояния узлов.
После присоединения узла к кластеру текущий сертификат узла будет заменен сертификатом, подписанным центром сертификации кластера (CA). Все активные соединения с узлом будут разорваны через несколько секунд после замены сертификата и веб-интерфейс перестанет отвечать. Необходимо обновить страницу в браузере и снова войти в систему.

Примечание

При присоединении узла к кластеру всё содержимое каталога /etc/pve на присоединяемом узле будет полностью перезаписано конфигурацией кластера. В частности, присоединяющийся узел не должен содержать гостевые системы, так как это может привести к конфликтам идентификаторов ВМ. Если на узле уже есть ВМ, рекомендуется перед присоединением создать резервные копии всех ВМ (используя vzdump) и восстановить их с новыми идентификаторами после присоединения к кластеру.
Присоединяемый узел автоматически получает конфигурацию хранилищ кластера. Если локальная схема хранения узла отличается, после присоединения потребуется вручную добавить хранилища узла и настроить ограничения хранилищ, указав, на каких узлах они доступны.
Сразу после инициализации кластера в пределах каждого из узлов доступны локальные хранилища данных:
Локальные хранилища данных

Примечание

Количество и тип локальных хранилищ данных зависит от схемы разбиения диска, выбранного на этапе установки Альт Виртуализация редакция PVE (см. Подготовка диска).

⁠25.3. Создание кластера в консоли

Команда создания кластера:
# pvecm create <cluster_name>
На «головном» узле кластера необходимо выполнить команду инициализации конкретного кластера PVE, в данном случае — «pve-cluster»:
# pvecm create pve-cluster
Проверка:
# pvecm status
Cluster information
-------------------
Name:             pve-cluster
Config Version:   1
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Mon May  5 13:59:31 2025
Quorum provider:  corosync_votequorum
Nodes:            1
Node ID:          0x00000001
Ring ID:          1.5
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   1
Highest expected: 1
Total votes:      1
Quorum:           1
Flags:            Quorate

Membership information
----------------------
Nodeid      Votes Name
0x00000001      1 192.168.0.186 (local)
Команда создания кластера создает файл настройки /etc/pve/corosync.conf. По мере добавления узлов в кластер файл настройки будет автоматически пополняться информацией об узлах.
Команда для добавления узла в кластер:
# pvecm add <existing_node_in_cluster>
где existing_node_in_cluster — адрес уже добавленного узла (рекомендуется указывать самый первый).

Примечание

При добавлении узла в кластер с разделенной кластерной сетью необходимо использовать параметр link0 для установки адреса узла в этой сети:
# pvecm add <existing_node_in_cluster> --link0 <IP_link0>
Для добавления узлов в кластер необходимо на «подчинённых» узлах выполнить команду:
# pvecm add pve01
где pve01 — имя или IP-адрес «головного» узла.
При добавлении узла в кластер потребуется ввести пароль администратора главного узла кластера:
# pvecm add pve01
Please enter superuser (root) password for 'pve01': ***
Establishing API connection with host 'pve01'

Login succeeded.
Request addition of this node
Join request OK, finishing setup locally
stopping pve-cluster service
backup old database to '/var/lib/pve-cluster/backup/config-1625747072.sql.gz'
waiting for quorum...OK
(re)generate node files
generate new node certificate
merge authorized SSH keys and known hosts
generated new node certificate, restart pveproxy and pvedaemon services
successfully added node 'pve03' to cluster.
После добавления узлов в кластер файл конфигурации кластера в /etc/pve/corosync.conf должен содержать информацию об узлах кластера.
На всех узлах кластера должны быть запущены и добавлены в список служб, запускаемых при старте узла, службы:
# systemctl start pve-cluster pveproxy pvedaemon pvestatd pve-firewall pvefw-logger pve-ha-crm pve-ha-lrm spiceproxy lxc lxcfs lxc-net lxc-monitord qmeventd pvescheduler pve-lxc-syscalld
# systemctl enable pve-cluster pveproxy pvedaemon pvestatd pve-firewall corosync pvefw-logger pve-guests pve-ha-crm pve-ha-lrm spiceproxy lxc lxcfs lxc-net lxc-monitord qmeventd pvescheduler pve-lxc-syscalld

⁠25.4. Удаление узла из кластера

Перед удалением узла из кластера необходимо перенести с него ВМ и контейнеры, а также убедиться, что на узле не осталось локальных данных или резервных копий, которые необходимо сохранить.
Для удаления узла из кластера необходимо выполнить следующие шаги:
  1. Войти в узел кластера, не подлежащий удалению (в примере pve01).
  2. Ввести команду pvecm nodes, чтобы определить идентификатор узла, который следует удалить:
    # pvecm nodes
    
    Membership information
    ----------------------
        Nodeid      Votes Name
             1          1 pve01 (local)
             2          1 pve02
             3          1 pve03
    
  3. Остановить (выключить) узел, который необходимо удалить (в данном случае pve02).
  4. Удалить узел из кластера, выполнив команду:
    # pvecm delnode pve02
    

    Примечание

    На этом этапе возможно получение сообщения:
    Could not kill node (error = CS_ERR_NOT_EXIST)
    Это сообщение можно игнорировать. Оно возникает, если узел уже недоступен, и не влияет на корректность удаления.
  5. Убедиться, что узел удален (в разделе Membership information команда отобразит список узлов кластера без удаленного узла):
    # pvecm status
    …
    Membership information
    ----------------------
        Nodeid      Votes Name
    0x00000001      1 192.168.0.186 (local)
    0x00000003      1 192.168.0.70
    

Важно

Перед удалением узла крайне важно отключить его и убедиться, что он больше не будет включён в сеть действующего кластера с текущей конфигурацией. В противном случае кластер может выйти из строя, и восстановить его до рабочего состояния может быть сложно.
После удаления узла из кластера его каталог конфигурации /etc/pve/nodes/<имя_узла> не удаляется автоматически. Он может содержать конфигурации ВМ, хранилищ и другие данные, которые при необходимости можно сохранить или перенести.
После проверки и сохранения нужной информации данный каталог рекомендуется удалить вручную, чтобы избежать путаницы и возможных конфликтов при повторном добавлении узла с тем же именем.

Примечание

Если кворум в кластере нарушен, для удаления недоступного узла можно использовать следующую последовательность команд:
# pvecm expected 1
# pvecm delnode <недоступный_узел>
Команда pvecm expected 1 применяется в ситуациях, когда:
  • кворум утрачен;
  • восстановление одного или нескольких узлов невозможно или не планируется;
  • требуется удалить недоступный узел из конфигурации кластера.
Следует учитывать, что использование pvecm expected 1 является аварийной мерой управления кластером, а не штатной операцией, и должно применяться только при осознанном принятии риска потери отказоустойчивости.
Если необходимо вернуть удалённый узел обратно в кластер, следует выполнить следующие действия:
  • переустановить PVE на этом узле (это гарантирует, что все секретные ключи кластера/SSH и любые данные конфигурации будут уничтожены);
  • присоединиться к кластеру.

⁠25.5. Выделенная сеть кластера

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

Примечание

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

⁠25.5.1. Изоляция при создании кластера

Изолировать кластерный трафик можно при создании кластера с помощью параметров --linkX команды pvecm create, используемой для инициализации нового кластера.
Например, если на узле настроен дополнительный сетевой интерфейс со статическим адресом 10.10.100.150/24 и требуется направлять весь кластерный трафик через него, для создания кластера можно выполнить команду:
# pvecm create pve-cluster --link0 10.10.100.150
Параметр --link0 указывает IP-адрес интерфейса, который будет использоваться для обмена сообщениями между узлами кластера.
Создание кластера с выделенной сетью
При необходимости можно указать несколько сетевых каналов:
# pvecm create pve-cluster --link0 10.10.100.150 --link1 10.10.101.150
В этом случае будет настроено несколько каналов обмена Corosync, что повышает отказоустойчивость кластера.
Добавлять узлы в кластер можно, указывая их адреса в той же выделенной подсети:
# pvecm add 192.168.0.186 --link0 10.10.100.151
Добавление узла в кластер с выделенной сетью

⁠25.5.2. Изоляция после создания кластера

Если кластер уже создан, его можно перенастроить на использование другой сети без полного пересоздания. Следует учитывать, что при последовательном переключении узлов возможна кратковременная потеря кворума.
Для перенастройки кластера на использование другой сети необходимо:
  1. Открыть файл /etc/pve/corosync.conf:
    logging {
      debug: off
      to_syslog: yes
    }
    
    nodelist {
      node {
        name: pve01
        nodeid: 1
        quorum_votes: 1
        ring0_addr: 192.168.0.186
      }
      node {
        name: pve02
        nodeid: 2
        quorum_votes: 1
        ring0_addr: 192.168.0.90
      }
      node {
        name: pve03
        nodeid: 3
        quorum_votes: 1
        ring0_addr: 192.168.0.70
      }
    }
    
    quorum {
      provider: corosync_votequorum
    }
    
    totem {
      cluster_name: pve-cluster
      config_version: 3
      interface {
        linknumber: 0
      }
      ip_version: ipv4-6
      link_mode: passive
      secauth: on
      version: 2
    }
    

    Примечание

    Параметр ringX_addr определяет IP-адрес интерфейса, используемого для обмена сообщениями между узлами кластера.
  2. Убедиться, что у каждого узла указано свойство name, совпадающее с именем узла.
  3. Заменить все значения ring0_addr на новые IP-адреса из выделенной подсети (например, 10.10.100.0/24).
  4. Увеличить значение config_version (например, с 3 до 4).
    Пример обновлённого файла:
    logging {
      debug: off
      to_syslog: yes
    }
    
    nodelist {
      node {
        name: pve01
        nodeid: 1
        quorum_votes: 1
        ring0_addr: 10.10.100.150
      }
      node {
        name: pve02
        nodeid: 2
        quorum_votes: 1
        ring0_addr: 10.10.100.151
      }
      node {
        name: pve03
        nodeid: 3
        quorum_votes: 1
        ring0_addr: 10.10.100.152
      }
    }
    
    quorum {
      provider: corosync_votequorum
    }
    
    totem {
      cluster_name: pve-cluster
      config_version: 4
      interface {
        linknumber: 0
      }
      ip_version: ipv4-6
      link_mode: passive
      secauth: on
      version: 2
    }
    
  5. Сохранить файл и применить изменения.

Примечание

Изменения применяются динамически, поэтому перезапуск службы Corosync обычно не требуется. Однако при возникновении ошибок можно перезапустить службу на одном из узлов:
# systemctl restart corosync
После проверки работоспособности (systemctl status corosync) необходимо повторить операцию на остальных узлах.

⁠25.5.3. Резервирование сети (Redundancy)

Corosync поддерживает избыточные сетевые соединения через встроенный транспорт Kronosnet.
Для включения резервирования необходимо указать несколько каналов связи:
  • через параметры --link0, --link1 в команде pvecm;
  • либо добавив параметры ring0_addr, ring1_addr в файле corosync.conf.

Примечание

Для эффективного отказоустойчивого переключения каждый канал должен использовать отдельное физическое соединение.
Каналы используются в порядке приоритета:
# pvecm create CLUSTER \
  --link0 10.10.100.105,priority=15 \
  --link1 10.20.20.1,priority=20
В данном случае будет использоваться канал link1, поскольку его приоритет выше.
Если приоритеты не заданы, предпочтение отдаётся каналу с меньшим номером (link0 имеет более высокий приоритет, чем link1).
В штатном режиме трафик передаётся только через канал с наивысшим приоритетом. Остальные каналы используются только при отказе основного.
Для добавления резервного канала в существующий кластер необходимо внести изменения в файл /etc/pve/corosync.conf:
  1. Добавить параметр ringX_addr для каждого узла. Например:
    nodelist {
      node {
        name: pve01
        nodeid: 1
        quorum_votes: 1
        ring0_addr: 192.168.0.186
        ring1_addr: 192.168.1.10
      }
      node {
        name: pve02
        nodeid: 2
        quorum_votes: 1
        ring0_addr: 192.168.0.90
        ring1_addr: 192.168.1.11
      }
      node {
        name: pve03
        nodeid: 3
        quorum_votes: 1
        ring0_addr: 192.168.0.70
        ring1_addr: 192.168.1.12
      }
    }
    

    Важно

    • Номер кольца (ringX) должен быть одинаковым для всех узлов.
    • IP-адреса должны быть уникальными для каждого узла в рамках одного кольца.
  2. В секции totem добавить блок interface для нового кольца (номер ссылки должен соответствовать числу X, выбранному выше):
    interface {
      linknumber: 1
    }
    
  3. Увеличить значение config_version.
После применения конфигурации рекомендуется проверить загрузку нового канала:
# journalctl -b -u corosync
Для тестирования можно временно отключить основной канал на одном из узлов и убедиться, что кластер остаётся в состоянии ONLINE:
# pvecm status
Состояние всех каналов Corosync можно просмотреть, выполнив команду:
# corosync-cfgtool -s

⁠25.6. Кворум

Для обеспечения согласованного состояния среди всех узлов кластера PVE использует метод на основе кворума.
Кворум — минимальное количество голосов, необходимое для того, чтобы кластер считался имеющим кворум. По умолчанию каждому узлу PVE назначается один голос.
Проверить состояние кворума можно командой:
# pvecm status
…
Votequorum information
----------------------
Expected votes:   5
Highest expected: 5
Total votes:      5
Quorum:           3
Flags:            Quorate
…
В выводе команды видно, что в кластере пять узлов (Expected votes), из них для кворума необходимо не менее трёх (Quorum), сейчас все пять узлов активны (Total votes), кворум соблюден (Flags: Quorate).
При потере кворума кластерная файловая система PVE переходит в режим «только для чтения» (read-only). Уже запущенные ВМ и контейнеры могут продолжать работу, но операции, требующие изменения кластерной конфигурации, могут стать недоступными.

⁠25.7. Поддержка внешнего арбитра Corosync

Внешний арбитр позволяет повысить устойчивость кластера к отказам узлов.
Для работы арбитра задействованы две службы:
  • Corosync Quorum (QDevice) — служба, которая работает на каждом узле кластера PVE. Она предоставляет настроенное количество голосов подсистеме кворума на основе решения внешнего управляющего арбитра. Основное назначение этой службы — позволить кластеру выдержать большее количество отказов узлов, чем это позволяют стандартные правила кворума. Арбитр видит все узлы и может выбрать только один набор узлов, чтобы отдать свой голос (это будет сделано только в том случае, если указанный набор узлов при получении голоса арбитра сможет иметь кворум).
  • Внешний арбитр, который работает на независимом сервере. Единственное требование к арбитру — наличие сетевого доступа к кластеру.

Примечание

В настоящее время Qdevices для кластеров с нечетным числом узлов не поддерживается. Это связано с разницей в количестве голосов, которые QDevice предоставляет для кластера.
Кластеры с чётным числом узлов получают один дополнительный голос, что только увеличивает доступность, поскольку сбой самого QDevice не влияет на работоспособность кластера.
Для кластера с нечётным числом узлов QDevice предоставляет (N-1) голосов, где N — количество узлов кластера. Этот алгоритм допускает сбой всех узлов, кроме одного и самого QDevice. При этом есть два недостатка:
  • если произойдет сбой арбитра, ни один другой узел не может выйти из строя, или кластер немедленно потеряет кворум. Например, в кластере с 15 узлами 7 могут выйти из строя, прежде чем кластер станет неработоспособным. Но если в этом кластере настроен QDevice и он сам выйдет из строя, ни один узел из 15 не может выйти из строя. В этом случае QDevice действует почти как единая точка отказа;
  • возможность выхода из строя всех узлов, кроме одного, плюс QDevice, может привести к массовому восстановлению служб высокой доступности (HA), что может привести к перегрузке единственного оставшегося узла. Кроме того, сервер Ceph прекратит предоставлять услуги, если в сети останется только ((N-1)/2) узлов или меньше.

Важно

При настройке QDevice PVE копирует ключи кластера на внешний сервер. Для добавления QDevice можно временно включить парольную аутентификацию для root в sshd на внешнем сервере:
# control sshd-permit-root-login enabled
# systemctl restart sshd
А после того, как QDevice будет добавлен, отключить:
# control sshd-permit-root-login without_password
# systemctl restart sshd
Для настройки работы арбитра необходимо выполнить следующие действия:
  1. На внешнем сервере:
    • установить пакет corosync-qnetd (из репозитория):
      # apt-get install corosync-qnetd
      
    • для работы TLS создать базу данных NSS:
      # corosync-qnetd-certutil -i
      

      Примечание

      Если TLS не нужен, следует в файле /etc/sysconfig/corosync-qnetd изменить значение опции COROSYNC_QNETD_OPTIONS:
      COROSYNC_QNETD_OPTIONS="-s off"
    • запустить и добавить в автозагрузку службу corosync-qnetd:
      # systemctl enable --now corosync-qnetd
      
  2. На всех узлах PVE установить пакет corosync-qdevice (из репозитория):
    # apt-get install corosync-qdevice
    
  3. На одном из узлов PVE настроить QDevice, выполнив команду:
    # pvecm qdevice setup 192.168.0.88
    
    где 192.168.0.88 — IP-адрес арбитра (внешнего сервера).
    SSH-ключи из кластера будут автоматически скопированы в QDevice.
  4. На любом узле PVE проверить статус кластера:
    # pvecm status
    …
    Votequorum information
    ----------------------
    Expected votes:   5
    Highest expected: 5
    Total votes:      5
    Quorum:           3
    Flags:            Quorate Qdevice
    
    Membership information
    ----------------------
        Nodeid      Votes    Qdevice Name
    0x00000001          1    A,V,NMW 192.168.0.186 (local)
    0x00000002          1    A,V,NMW 192.168.0.90
    0x00000003          1    A,V,NMW 192.168.0.70
    0x00000004          1    A,V,NMW 192.168.0.91
    0x00000000          1            Qdevice
    
Для добавления нового узла или удаления существующего из кластера с настроенным QDevice, сначала необходимо удалить QDevice. После можно добавлять или удалять узлы в обычном режиме.
Команда удаления QDevice:
# pvecm qdevice remove

⁠25.8. Кластерная файловая система PVE (pmxcfs)

Кластерная файловая система PVE (pmxcfs) предназначена для хранения конфигурационных файлов PVE и синхронизации конфигурации между узлами кластера с помощью Corosync. Данные хранятся в базе данных, а их копия поддерживается в оперативной памяти. Поэтому размер конфигурационных данных ограничен.
Основные особенности pmxcfs:
  • мгновенная репликация и обновление конфигурации на все узлы в кластере;
  • исключается вероятность дублирования идентификаторов виртуальных машин;
  • при потере кворума файловая система становится доступной только для чтения.
Все файлы и каталоги принадлежат пользователю root и имеют группу www-data. Только root имеет права на запись, но пользователи из группы www-data могут читать большинство файлов. Файлы в каталогах /etc/pve/priv/ и /etc/pve/nodes/${NAME}/priv/ доступны только root.
Файловая система смонтирована в /etc/pve/.

⁠Глава 26. Системы хранения PVE

Образы ВМ могут храниться в одном или нескольких локальных хранилищах или в общем (совместно используемом) хранилище, например, NFS или iSCSI (NAS, SAN). Система не накладывает ограничений на количество настраиваемых хранилищ — их можно создавать столько, сколько необходимо.
В кластерной среде PVE наличие общего хранилища не является обязательным, однако оно значительно упрощает управление. Преимущества общего хранилища:
  • Live-миграция ВМ;
  • гибкое расширение пространства хранения за счёт нескольких узлов;
  • централизованное резервное копирование;
  • многоуровневое кеширование данных;
  • единая точка управления хранилищем.

⁠26.1. Типы хранилищ в PVE

В PVE различают два основных типа хранилищ:
  • файловые — предоставляют доступ к данным в виде файлов и каталогов. Они предоставляют доступ к полноценной POSIX-совместимой файловой системе. Как правило, такие хранилища более гибкие, чем блочные, и позволяют хранить контент любого типа: ISO-образы, резервные копии, шаблоны и т.д.;
  • блочные — предоставляют блочные устройства для хранения образов виртуальных дисков. Обычно в них нельзя хранить произвольные файлы (например, ISO или резервные копии). Однако большинство современных блочных хранилищ поддерживают моментальные снимки и клонирование.
Управление хранилищами удобно осуществлять через веб-интерфейс. В качестве бэкенда PVE может использовать:
  • сетевые файловые системы, в том числе распределенные: NFS, CEPH;
  • локальные системы управления дисковыми томами: LVM, ZFS, BTRFS;
  • удалённые и локальные блочные устройства: iSCSI, FC, локальные диски;
  • локальные каталоги на существующих файловых системах.
⁠

Таблица 26.1. Доступные типы хранилищ

Хранилище
PVE тип
Уровень
Общее (shared)
Снимки (snapshots)
ZFS (локальный)
zfspool
файл
нет
да
dir
файл
нет
нет (возможны в формате qcow2)
btrfs
файл
нет
да
NFS
nfs
файл
да
нет (возможны в формате qcow2)
cifs
файл
да
нет (возможны в формате qcow2)
cephfs
файл
да
да
LVM
lvm
блок
нет*
да
lvmthin
блок
нет
да
iscsi
блок
да
нет
iscsidirect
блок
да
нет
rbd
блок
да
да
ZFS over iSCSI
zfs
блок
да
да
pbs
файл/блок
да
-
esxi
-
да
-

Примечание

LVM можно размещать поверх iSCSI или Fibre Channel, получая таким образом общее LVM-хранилище.

⁠26.2. Конфигурация хранилища

Вся конфигурация хранилищ PVE хранится в файле /etc/pve/storage.cfg. Поскольку этот файл находится в каталоге /etc/pve/, он автоматически реплицируется на все узлы кластера. Таким образом, все узлы имеют одинаковую конфигурацию хранилищ.
Единая конфигурация особенно полезна для общих хранилищ, доступных с нескольких узлов кластера. Для локальных хранилищ конфигурация также едина, но фактическое содержимое и доступность хранилищ могут различаться на разных узлах.
Каждое хранилище определяется своим типом и уникальным идентификатором <STORAGE_ID>. Формат записи:
<type>: <STORAGE_ID>
        <property> <value>
        <property> <value>
        ...
Строка <type>: <STORAGE_ID> определяет хранилище, затем следует список свойств.
Пример файла /etc/pve/storage.cfg:
# cat /etc/pve/storage.cfg
# Локальное файловое хранилище
dir: local
    path /var/lib/vz
    content iso,vztmpl,snippets,backup,rootdir
    shared 0

# хранилище образов по умолчанию при установке на LVM
lvmthin: local-lvm
    thinpool data
    vgname pve
    content images,rootdir

# NFS-хранилище
nfs: nfs-storage
    export /export/storage
    path /mnt/pve/nfs-storage
    server 192.168.0.105
    content images,iso,backup,vztmpl
    options vers=3,nolock,tcp
В этом примере:
  • local — ссылается на каталог /var/lib/vz;
  • local-lvm — использует группу томов pve;
  • nfs-storage — подключает NFS-экспорт.
⁠

Таблица 26.2. Параметры хранилищ

Свойство
Описание
nodes
Список узлов кластера, на которых доступно хранилище. Позволяет ограничить его использование
content
Типы данных, поддерживаемые хранилищем:
  • images — образы виртуальных дисков;
  • rootdir — данные контейнеров;
  • vztmpl — шаблоны контейнеров;
  • backup — резервные копии (VZDump);
  • iso — ISO-образы;
  • import — файлы OVF/OVA;
  • snippets — файлы фрагментов (сниппетов), например, скрипты-ловушки гостевой системы.
shared
Указывает, что хранилище физически одно и то же на всех узлах (или на перечисленных в опции nodes). Не делает локальное хранилище общим автоматически — только помечает уже общее хранилище
disable
Отключает хранилище
maxfiles
Устарело, следует использовать свойство prune-backups
prune-backups
Параметры хранения резервных копий
format
Формат образа по умолчанию: raw, qcow2, vmdk
preallocation
Режим предварительного выделения для образов raw и qcow2 в файловых хранилищах: off, metadata, falloc, full. По умолчанию — metadata (для raw эквивалентно off). На сетевых хранилищах рекомендуется off для больших qcow2, чтобы избежать таймаутов.

Примечание

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

⁠26.3. Идентификатор тома

Для обращения к данным хранилищ используется специальная нотация. Том идентифицируется по <STORAGE_ID>, за которым через двоеточие следует имя тома, зависящее от типа хранилища. Примеры <VOLUME_ID>:
local:iso/slinux-11.0-x86_64.iso
local:101/vm-101-disk-0.qcow2
local:backup/vzdump-qemu-100-2024_08_22-21_12_33.vma.zst
nfs-storage:vztmpl/alt-p10-rootfs-systemd-x86_64.tar.xz
Чтобы получить реальный путь к файловой системе для <VOLUME_ID>, используется команда:
# pvesm path <VOLUME_ID>
Например:
# pvesm path local:iso/slinux-11.0-x86_64.iso
/var/lib/vz/template/iso/slinux-11.0-x86_64.iso
# pvesm path nfs-storage:vztmpl/alt-p11-rootfs-systemd-x86_64.tar.xz
/mnt/pve/nfs-storage/template/cache/alt-p11-rootfs-systemd-x86_64.tar.xz
Для томов типа image существует отношение владения. Каждый такой том принадлежит конкретной ВМ или контейнеру. Например, том local:101/vm-101-disk-0.qcow2 принадлежит ВМ с ID 101. При удалении ВМ или контейнера все связанные с ним тома удаляются автоматически.

⁠26.4. Работа с хранилищами в PVE

⁠26.4.1. Использование командной строки

Утилита pvesm (PVE Storage Manager) позволяет управлять хранилищами.
Команды добавления (подключения) хранилища:
# pvesm add <TYPE> <STORAGE_ID> <OPTIONS>
# pvesm add dir <STORAGE_ID> --path <PATH>
# pvesm add nfs <STORAGE_ID> --path <PATH> --server <SERVER> --export <EXPORT>
# pvesm add lvm <STORAGE_ID> --vgname <VGNAME>
# pvesm add iscsi <STORAGE_ID> --portal <HOST[:PORT]> --target <TARGET>
Включение/отключение:
# pvesm set <STORAGE_ID> --disable 1 # отключить

# pvesm set <STORAGE_ID> --disable 0 # включить
Изменение параметров:
# pvesm set <STORAGE_ID> <OPTIONS>
# pvesm set <STORAGE_ID> --shared 1
# pvesm set local --format qcow2
# pvesm set <STORAGE_ID> --content iso
Удаление (только конфигурации, данные не удаляются)
# pvesm remove <STORAGE_ID>
Работа с томами:
# pvesm alloc <STORAGE_ID> <VMID> <name> <size> [--format <raw|qcow2>]
Выделить том 4 ГБ в локальном хранилище (имя будет сгенерировано):
# pvesm alloc local <VMID> '' 4G
Освободить место (уничтожает все данные тома):
# pvesm free <VOLUME_ID>
Список хранилищ:
# pvesm status
Вывести список содержимого хранилища:
# pvesm list <STORAGE_ID> [--vmid <VMID>]
Вывести список ISO-образов:
# pvesm list <STORAGE_ID> --content iso

⁠26.4.2. Добавление хранилища в веб-интерфейсе PVE

В веб-интерфейсе PVE можно добавить следующие типы хранилищ:
  • Локальные хранилища:
    • Каталог — хранение на существующей файловой системе;
    • LVM — локальные устройства, такие как FC, DRBD и т.д.;
    • LVM-Thin;
    • ZFS;
    • BTRFS;
  • Сетевые хранилища:
    • LVM (поверх iSCSI);
    • NFS;
    • CIFS;
    • iSCSI;
    • CephFS;
    • RBD;
    • ZFS over iSCSI;
    • Proxmox Backup Server;
    • ESXi.
Выбор типа добавляемого хранилища
При создании хранилищу назначаются роли (типы содержимого): образы ВМ, ISO, резервные копии и т.д. Список доступных ролей зависит от типа хранилища. Например, для NFS или каталога локальной файловой системы доступны любые роли или наборы ролей, а хранилища на базе RBD можно использовать только для хранения образов дисков и контейнеров:
Выбор ролей для хранилища

Примечание

Можно добавить локальные хранилища (ZFS, LVM и LVM-Thin), расположенные на других узлах кластера. Для этого в мастере добавления хранилища следует выбрать целевой узел для сканирования:
LVM хранилище. Выбор узла для сканирования

⁠26.4.3. Каталог

PVE может использовать локальные каталоги или локально смонтированные сетевые ресурсы для организации файлового хранилища. Поскольку это файловое хранилище, в нём можно хранить данные любого типа: образы виртуальных дисков, контейнеры, шаблоны, ISO-образы, резервные копии и другие файлы.
Для хранения данных разных типов используется предопределённая структура подкаталогов. Эта структура применяется ко всем файловым хранилищам PVE.
⁠

Таблица 26.3. Структура каталогов

Тип данных
Подкаталог
Образы дисков ВМ
images/<VMID>/
ISO-образы
template/iso/
Шаблоны контейнеров
template/cache/
Резервные копии VZDump
dump/
Фрагменты (сниппеты)
snippets/
Импорт
import/

Примечание

Дополнительные хранилища можно подключить через /etc/fstab, а затем определить в PVE хранилище типа каталог для этой точки монтирования. Таким образом можно использовать любую файловую систему (ФС), поддерживаемую Linux.

Примечание

Большинство ФС «из коробки» не поддерживают моментальные снимки. Чтобы обойти это ограничение, хранилище типа каталог может использовать внутренние снимки формата qcow2.
Для создания нового хранилища типа каталог необходимо перейти в Центр обработки данных → Хранилище, нажать кнопку Добавить и в раскрывающемся списке выбрать пункт Каталог.
Диалог создания хранилища local-iso типа каталог для хранения ISO-образов и шаблонов контейнеров, смонтированного в /mnt/iso:
Добавление хранилища типа Каталог
Хранилище типа каталог поддерживает все общие свойства хранилищ PVE, а также дополнительные параметры:
  • path — абсолютный путь к каталогу на файловой системе;
  • snapshot-as-volume-chain — снимки как цепочки томов. Включает поддержку создания снимков для ВМ через механизм цепочек томов (подробнее см. в описании хранилища LVM). Технология в статусе preview;
  • content-dirs (опционально) — позволяет изменить стандартную структуру каталогов. Значение представляет собой список в формате:
    vtype=path
    где vtype — тип содержимого (images, backup, и т.д.), а path — путь относительно точки монтирования.
Пример конфигурации (/etc/pve/storage.cfg):
dir: backup
    path /mnt/backup
    content backup
    prune-backups keep-last=7
    shared 0
    content-dirs backup=custom/backup
Данная конфигурация определяет пул для хранения резервных копий с автоматическим удалением всех, кроме последних 7 копий на каждую ВМ. Фактический путь к файлам — /mnt/backup/custom/backup.

Примечание

Флаг shared (Общий доступ) следует включать только для хранилищ, содержимое которых доступно с нескольких узлов кластера и является общим для этих узлов. Например, это могут быть хранилища на основе кластерных файловых систем OCFS2 или сетевые хранилища NFS и CIFS. Установка флага shared сама по себе не обеспечивает совместный доступ к хранилищу.
Хранилище типа каталог использует следующую схему именования образов ВМ:
VM-<VMID>-<NAME>.<FORMAT>
где:
  • <VMID> — идентификатор ВМ;
  • <NAME> — произвольное имя (ASCII, без пробелов); по умолчанию — disk-[N], где [N] — целое число;
  • <FORMAT> — формат образа: raw, qcow2 или vmdk.
Пример:
# ls /var/lib/vz/images/101
vm-101-disk-0.qcow2  vm-101-disk-1.qcow2
При создании шаблона виртуальной машины все её диски переименовываются в формат:
base-<VMID>-<NAME>.<FORMAT>
Это означает, что образ становится доступен только для чтения и может использоваться как базовый для клонирования.

⁠26.4.4. NFS

Хранилище NFS аналогично хранилищу типа каталог, но с возможностью совместного доступа с нескольких узлов и поддержкой live-миграции. Структура каталогов и соглашения об именовании файлов идентичны.
Основное преимущество — автоматическое монтирование общего ресурса без ручного редактирования /etc/fstab.
Хранилище NFS поддерживает все общие свойства хранилищ, кроме флага shared, который для NFS всегда установлен. Дополнительные параметры:
  • server — IP-адрес или DNS-имя сервера (рекомендуется использовать IP для избежания задержек, связанных с разрешением DNS-имён);
  • export — совместный ресурс с сервера NFS (список можно получить, выполнив команду pvesm scan nfs <server>);
  • path — локальная точка монтирования (по умолчанию: /mnt/pve/<STORAGE_ID>/);
  • content-dirs (опционально) — позволяет изменить стандартную структуру каталогов. Значение представляет собой список в формате:
    vtype=path
    где vtype — тип содержимого (images, backup, и т.д.), а path — путь относительно точки монтирования;
  • options — параметры монтирования NFS (см. man nfs).
Пример конфигурации (/etc/pve/storage.cfg):
nfs: nfs-storage
    export /export/storage
    path /mnt/pve/nfs-storage
    server 192.168.0.105
    content images,backup,vztmpl,iso
    options vers=3,nolock,tcp

Примечание

По умолчанию NFS использует «жёсткое» (hard) поведение: при недоступности сервера запросы повторяются бесконечно, что может вызывать зависания. Для данных, доступных только для чтения, рекомендуется использовать опцию soft, при которой после трёх неудачных попыток операция завершится с ошибкой.

Примечание

Для возможности монтирования NFS-хранилища должен быть запущен клиент NFS:
# systemctl enable --now nfs-client.target
Диалог добавления хранилища NFS с именем nfs-storage с сервера 192.168.0.105:
Создание хранилища NFS
После ввода IP-адреса сервера доступные экспортные ресурсы автоматически сканируются и отображаются в раскрывающемся списке Export. В данном примере обнаружен экспорт /export/storage.
Добавление хранилища NFS через командную строку:
# pvesm add nfs nfs-storage  \
    --path /mnt/pve/nfs-storage \
    --server 192.168.0.105 \
    --options vers=3,nolock,tcp  \
    --export /export/storage \
    --content images,iso,vztmpl,backup
Просмотр доступных ресурсов на сервере NFS:
# pvesm nfsscan <server>

⁠26.4.5. BTRFS

Хранилище BTRFS похоже на хранилище типа каталог, но с ключевым отличием: сырые (raw) диски ВМ размещаются в подтомах (subvolumes), что позволяет использовать моментальные снимки и обеспечивает переносимость снимков при миграции.

Примечание

ФС BTRFS учитывает флаг O_DIRECT при открытии файлов. Поэтому ВМ не должны использовать режим кеширования none, иначе возможны ошибки контрольных сумм.
Данное хранилище настраивается аналогично хранилищу типа каталог.

Примечание

Если в качестве хранилища указывается подкаталог, а не точка монтирования BTRFS, необходимо явно задать параметр is_mountpoint, указав реальную точку монтирования.
Пример конфигурации (/etc/pve/storage.cfg):
btrfs: btrfs-storage
    path /mnt/data/btrfs-storage
    content rootdir,images
    is_mountpoint /mnt/data
    nodes pve02
    prune-backups keep-all=1
В данном примере файловая система BTRFS смонтирована в /mnt/data, а пулом данных служит её подкаталог btrfs-storage/.
Диалог создания хранилища btrfs-storage типа BTRFS для хранения образов дисков и контейнеров:
Создание хранилища BTRFS
Пример добавления хранилища BTRFS в командной строке:
# pvesm add btrfs btrfs-storage  \
    --path /mnt/data/btrfs-storage  \
    --is_mountpoint /mnt/data/ \
    --content images,rootdir

⁠26.4.5.1. Администрирование BTRFS

В этом разделе приведены некоторые примеры работы с ФС BTRFS.
Создание файловой системы BTRFS на /dev/sdd:
# mkfs.btrfs -m single -d single -L My-Storage /dev/sdd
Параметры -m и -d задают профиль для метаданных и данных соответственно. -L задаёт метку.
Создание RAID1 на двух разделах /dev/sdb1 и /dev/sdc1:
# mkfs.btrfs -m raid1 -d raid1 -L My-Storage /dev/sdb1 /dev/sdc1
Монтирование:
# mkdir /mnt/data
# mount /dev/sdd /mnt/data
Автоматическое монтирование (в /etc/fstab):
UUID=5a556184-43b2-4212-bc21-eee3798c8322 /mnt/data btrfs defaults 0 0
Проверка монтирования:
# mount -a
Результатом выполнения команды должен быть пустой вывод без ошибок.

Примечание

Рекомендуется использовать значение UUID (выведенное командой mkfs.btrfs).
UUID можно также получить, выполнив команду:
# blkid
/dev/sdd: LABEL="My-Storage" UUID="5a556184-43b2-4212-bc21-eee3798c8322" BLOCK_SIZE="4096" TYPE="btrfs"
Создание подтома (файловая система BTRFS должна быть примонтирована):
# btrfs subvolume create /mnt/data/btrfs-storage
Создание снимка (снимок — это подтом, который имеет общие данные и метаданные с другим подтомом):
# btrfs subvolume snapshot -r /mnt/data/btrfs-storage /mnt/data/new
Будет создан доступный только для чтения «клон» подтома /mnt/data/btrfs-storage. Чтобы из снимка, доступного только для чтения, создать его версию, доступную для записи, следует просто создать его снимок без опции -r.
Просмотр использования пространства:
# btrfs subvolume list /mnt/data
ID 256 gen 17 top level 5 path btrfs-storage
ID 257 gen 14 top level 5 path new
Удаление подтома:
# btrfs subvolume delete /mnt/data/btrfs-storage
Просмотр использования пространства:
# btrfs filesystem usage /mnt/data
или:
$ btrfs filesystem df /mnt/data

⁠26.4.6. CIFS

Хранилище SMB/CIFS расширяет функциональность хранилища типа каталог и автоматически управляет монтированием — ручная настройка не требуется.

Примечание

Для сканирования общих ресурсов на каждом узле кластера необходимо установить пакет samba-client.
Хранилище CIFS поддерживает все общие свойства хранилищ, кроме флага shared, который всегда установлен. Дополнительные параметры:
  • server — IP-адрес или DNS-имя сервера (рекомендуется использовать IP для избежания задержек, связанных с разрешением DNS-имён);
  • share — совместный ресурс с сервера CIFS (список можно просмотреть, выполнив команду pvesm scan cifs <server>);
  • snapshot-as-volume-chain — снимки как цепочки томов. Включает поддержку создания снимков для ВМ через механизм цепочек томов (подробнее см. в описании хранилища LVM). Технология в статусе preview;
  • username — имя пользователя для хранилища CIFS (опционально, по умолчанию «guest»);
  • password — пароль пользователя (опционально). Пароль хранится в файле /etc/pve/priv/storage/<STORAGE-ID>.pw, доступном только пользователю root;
  • domain — рабочая группа или домен (опционально);
  • smbversion — версия протокола SMB (опционально, по умолчанию 3; версия 1 не поддерживается);
  • path — локальная точка монтирования (по умолчанию: /mnt/pve/<STORAGE_ID>/);
  • content-dirs (опционально) — позволяет изменить стандартную структуру каталогов. Значение представляет собой список в формате:
    vtype=path
    где vtype — тип содержимого (images, backup, и т.д.), а path — путь относительно точки монтирования;
  • options — дополнительные параметры монтирования CIFS (см. man mount.cifs). Некоторые параметры устанавливаются автоматически, и их не следует задавать в этом параметре. PVE всегда устанавливает опцию soft;
  • subdir — подкаталог внутри общего ресурса (по умолчанию — корень).
Пример конфигурации (/etc/pve/storage.cfg):
cifs: newCIFS
    path /mnt/pve/newCIFS
    server 192.168.0.105
    share smb_data
    smbversion 2.1
Просмотр доступных ресурсов на сервере CIFS:
# pvesm cifsscan <server> [--username <username>] [--password]
Добавление общего ресурса в качестве хранилища:
# pvesm add cifs <storagename> --server <server> --share <share> [--username <username>] [--password]
Подключение хранилища SMB/CIFS с именем newCIFS с сервера 192.168.0.105:
Добавление SMB/CIFS-хранилища
После ввода IP-адреса сервера доступные экспортные ресурсы автоматически сканируются и отображаются в раскрывающемся списке Share.

Примечание

В веб-интерфейсе PVE по умолчанию используется SMBv3. Если сервер поддерживает другую версию (например, 2.1), хранилище следует создавать через командную строку, например:
# pvesm add cifs newCIFS \
    --server 192.168.0.105 \
    --share smb_data \
    --smbversion 2.1

⁠26.4.7. Локальный ZFS

Примечание

Для работы с локальным ZFS необходимо установить модуль ядра (например, kernel-modules-zfs-6.12) и загрузить его:
# modprobe zfs
Чтобы модуль загружался автоматически, следует раскомментировать строку:
#zfs
в файле /etc/modules-load.d/zfs.conf.
Локальный ZFS позволяет получить доступ к локальным пулам ZFS (или файловым системам ZFS внутри таких пулов).
Данное хранилище поддерживает общие свойства хранилищ PVE (content, nodes, disable). Кроме того, для его настройки используются следующие параметры:
  • pool — имя пула или файловой системы ZFS;
  • blocksize — размер блока;
  • sparse — использовать тонкое выделение ресурсов;
  • mountpoint — точка монтирования пула/файловой системы ZFS. Изменение этого параметра не влияет на свойство mountpoint в ZFS. По умолчанию /<pool>.
Пул ZFS поддерживает следующие типы RAID:
  • RAID-0 (Single Disk) — размер такого пула — сумма емкостей всех дисков. RAID0 не добавляет избыточности, поэтому отказ одного диска делает том не пригодным для использования (минимально требуется один диск);
  • пул RAID-1 (Mirror) — данные зеркалируются на все диски (минимально требуется два диска);
  • пул RAID-10 — сочетание RAID0 и RAID1 (минимально требуется четыре диска);
  • пул RAIDZ-1 — одинарный паритет (аналог RAID-5, минимально требуется три диска);
  • пул RAIDZ-2 — двойной паритет; допускает отказ двух дисков в одной группе RAIDZ (минимально требуется четыре диска);
  • пул RAIDZ-3 — тройной паритет; допускает отказ трёх дисков в одной группе RAIDZ (минимально требуется пять дисков).
Пример конфигурации (/etc/pve/storage.cfg):
zfspool: vmdata
    pool vmdata
    content images,rootdir
    mountpoint /vmdata
    nodes pve03
Допустимые типы содержимого:
  • rootdir — данные контейнеров LXC;
  • images — образы виртуальных дисков в формате raw или как subvol.
Используется следующая схема именования:
  • vm-<VMID>-<NAME> — диск ВМ;
  • base-<VMID>-<NAME> — шаблон (только для чтения);
  • subvol-<VMID>-<NAME> — файловая система ZFS для контейнеров.

Примечание

Если на ZFS-диске ВМ созданы разделы LVM, гипервизор не сможет удалить такой диск. Пример ошибки:
cannot destroy 'data/vm-101-disk-0': dataset is busy
Чтобы избежать конфликта, следует исключить ZFS-диски из области сканирования LVM, добавив в конфигурацию LVM (файл /etc/lvm/lvm.conf) в секцию devices{} строки:
# Do not scan ZFS zvols (to avoid problems on ZFS zvols snapshots)
filter = [ "r|^/dev/zd*|" ]
global_filter = [ "r|^/dev/zd*|" ]

⁠26.4.7.1. Создание локального ZFS-хранилища в веб-интерфейсе

Для создания локального ZFS-хранилища:
  1. Выбрать узел, на котором будет создано хранилище.
  2. В разделе Диски выбрать пункт ZFS и нажать кнопку Создать: ZFS:
    Добавление ZFS хранилища
  3. В открывшемся окне задать параметры ZFS хранилища: имя хранилища, выбрать диски, уровень RAID и нажать кнопку Создать:
    Параметры ZFS хранилища
Статус пула можно просмотреть, выбрав его в списке и нажав кнопку Подробно:
Локальное ZFS хранилище
Для изменения параметров хранилища следует перейти в Центр обработки данных → Хранилище, выбрать нужное хранилище и нажать кнопку Редактировать:
Выбор хранилища для редактирования
В открывшемся окне можно изменить тип содержимого контейнера, включить/отключить хранилище, включить дисковое резервирование:
Редактирование ZFS хранилища

⁠26.4.7.2. Администрирование ZFS

Основными командами для управления ZFS являются zfs и zpool.
Для создания нового пула необходим как минимум один пустой диск.
Создание пула RAID-0 (минимум 1 диск):
# zpool create -f -o ashift=12 <pool> <device1> <device2>
Создание пула RAID-1 (минимум 2 диска):
# zpool create -f -o ashift=12 <pool> mirror <device1> <device2>
Создание пула RAID-10 (минимум 4 диска):
# zpool create -f -o ashift=12 <pool> mirror <device1> <device2> mirror <device3> <device4>
Создание пула RAIDZ-1 (минимум 3 диска):
# zpool create -f -o ashift=12 <pool> raidz1 <device1> <device2> <device3>
Создание пула RAIDZ-2 (минимум 4 диска):
# zpool create -f -o ashift=12 <pool> raidz2 <device1> <device2> <device3> <device4>
Замена диска:
# zpool replace -f <pool> <old device> <new device>
Включить сжатие:
# zfs set compression=on <pool>
Просмотр списка доступных файловых систем ZFS:
# pvesm zfsscan
Пример создания зеркала :
# zpool create -f vmdata mirror sdb sdc
Просмотр пулов:
# zpool list
NAME     SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
vmdata  17,5G   492K  17,5G        -         -     0%     0%  1.00x    ONLINE  -
Статус пула:
# zpool status
  pool: vmdata
 state: ONLINE
config:

    NAME        STATE     READ WRITE CKSUM
    vmdata      ONLINE       0     0     0
      mirror-0  ONLINE       0     0     0
        sdb     ONLINE       0     0     0
        sdc     ONLINE       0     0     0

errors: No known data errors

⁠26.4.8. LVM

LVM (Logical Volume Management) — это система управления дисковым пространством. Она позволяет объединить несколько физических томов (PV) в одну группу томов (VG), из которой затем можно выделять логические тома (LV), доступные для использования.
LVM позволяет создавать и удалять логические тома, а также переносить их данные между физическими устройствами хранения при соблюдении требований к конфигурации и доступности свободного пространства. Если группа томов LVM размещена на общем хранилище, доступном со всех узлов PVE (например, через общий iSCSI LUN или реплицированном через DRBD), все узлы могут получать доступ к образам ВМ, что делает возможной live-миграцию.
Хранилище типа lvm поддерживает общие свойства хранилищ PVE (content, nodes, disable). Кроме того, для его настройки используются следующие параметры:
  • vgname — имя группы томов LVM (должна существовать в системе);
  • base — базовый том. Этот том автоматически активируется перед доступом к хранилищу. Параметр особенно полезен, если группа томов LVM находится на удалённом iSCSI-сервере;
  • saferemove — безопасное удаление томов (соответствует опции Стереть удалённые тома в веб-интерфейсе). При удалении LVM-тома все его данные полностью затираются нулями, что исключает возможность восстановления остаточных данных при последующем создании томов на тех же физических экстентах;
  • saferemove_throughput — скорость операции безопасного удаления (значение параметра cstream -t утилиты cstream);
  • snapshot-as-volume-chain — снимки как цепочки томов. Включает поддержку создания снимков для ВМ в LVM через механизм цепочек томов:
    • при создании снимка текущее состояние виртуального диска сохраняется как отдельный том с именем снимка;
    • для дальнейшей работы создаётся новый том, который использует снимок в качестве базового (backing volume) и сохраняет только изменения;
    • таким образом формируется цепочка томов:
      snapshot1 → snapshot2 → active-volume
    Преимущества по сравнению с нативными LVM-снимками (COW):
    • отсутствует значительное снижение производительности;
    • исключён риск аварийного завершения при исчерпании выделенного пространства;
    • работает на любом блочном хранилище, включая SAN (iSCSI, Fibre Channel).
    Эта опция применяется только к вновь создаваемым дискам.
Пример файла конфигурации (/etc/pve/storage.cfg):
lvm: vg
    vgname vg
    content images,rootdir
    saferemove 0
    shared 0
    snapshot-as-volume-chain 1
    nodes pve03
Допустимые типы содержимого:
  • rootdir — данные контейнеров LXC;
  • images — образы виртуальных дисков в формате raw.

⁠26.4.8.1. Создание локального LVM-хранилища в веб-интерфейсе

Примечание

Для создания локального LVM-хранилища в системе должен быть как минимум один пустой диск.
Для создания локального LVM-хранилища в веб-интерфейсе следует выбрать узел, на котором будет создано хранилище, в разделе Диски выбрать пункт LVM и нажать кнопку Создать: Volume Group:
Пункт LVM в разделе Диски
В открывшемся окне следует выбрать диск, задать имя группы томов, отметить пункт Добавить хранилище (если этот пункт не отмечен, будет создана только группа томов без подключения к хранилищу PVE) и нажать кнопку Создать:
Создание группы томов
Для изменения параметров хранилища следует перейти в Центр обработки данных → Хранилище, выбрать нужное хранилище и нажать кнопку Редактировать. В открывшемся окне можно изменить тип содержимого контейнера, включить/отключить хранилище и настроить другие параметры:
Редактирование LVM-хранилища
Одним из преимуществ хранилища LVM является возможность его использования поверх общего блочного хранилища, например, iSCSI LUN. В таком случае бэкенд (например, кластерный менеджер блокировок) обеспечивает корректную координацию доступа между узлами.
Добавление хранилища типа LVM (на базе iSCSI)

⁠26.4.8.2. Создание LVM-хранилища в командной строке

Пример создания LVM-хранилища на пустом диске /dev/sdd:
  1. Создание физического тома (PV):
    # pvcreate /dev/sdd
      Physical volume "/dev/sdd" successfully created.
    
  2. Создание группы томов (VG) с именем vg:
    # vgcreate vg /dev/sdd
      Volume group "vg" successfully created
    
  3. Просмотр информации о физических томах:
    # pvs
      PV         VG        Fmt  Attr PSize   PFree
      /dev/sdd   vg        lvm2 a--  <18,00g <3,00g
    
  4. Просмотр информации о группах томов:
    # vgs
      VG        #PV #LV #SN Attr   VSize   VFree
      vg          1   2   0 wz--n- <18,00g <3,00g
    
  5. Получение списка доступных групп томов PVE:
    # pvesm lvmscan
    vg
    
  6. Создание LVM-хранилища с именем myspace:
    # pvesm add lvm myspace --vgname vg --nodes pve03
    

⁠26.4.9. LVM-Thin

LVM-Thin (тонкое выделение, thin provision) — технология, позволяющая создавать логические тома, которые изначально выглядят как полные копии базового тома, но физически хранят только изменённые данные. При чтении данные берутся с исходного тома (или с предыдущего слоя цепочки), а при записи — сохраняются в новый том.
Эта функция полезна, например, при развёртывании множества однотипных ВМ: все они могут использовать один базовый образ, но иметь собственное изменяемое пространство.
Хранилище типа lvmthin поддерживает все общие свойства хранилищ PVE, а также следующие специфические параметры:
  • vgname — имя группы томов LVM (должна существовать в системе);
  • thinpool — название тонкого пула LVM.
Пример файла конфигурации (/etc/pve/storage.cfg):
lvmthin: vmstore
    thinpool vmstore
    vgname vmstore
    content rootdir,images
    nodes pve03
Допустимые типы содержимого:
  • rootdir — данные контейнеров LXC;
  • images — образы виртуальных дисков в формате raw.
LVM-Thin является блочным хранилищем и полностью поддерживает моментальные снимки и клонирование. Все новые тома автоматически инициализируются нулевыми значениями.
Тонкие пулы LVM не поддерживают одновременный доступ с нескольких узлов. Поэтому их можно использовать только как локальное хранилище.

⁠26.4.9.1. Создание локального LVM-Thin-хранилища в веб-интерфейсе

Примечание

Для создания локального LVM-Thin-хранилища в системе должен быть как минимум один пустой диск.
Для создания локального LVM-Thin-хранилища в веб-интерфейсе следует выбрать узел, на котором будет создано хранилище, в разделе Диски выбрать пункт LVM-Thin и нажать кнопку Создать: Thinpool:
Пункт LVM-Thin в разделе Диски
В открывшемся окне следует выбрать диск, задать имя группы томов, отметить пункт Добавить хранилище (если этот пункт не отмечен будет создана только группа томов) и нажать кнопку Создать:
Создание LVM-Thin хранилища
Для изменения параметров хранилища следует перейти в Центр обработки данных → Хранилище, выбрать нужное хранилище и нажать кнопку Редактировать. В открывшемся окне можно изменить тип содержимого контейнера, включить/отключить хранилище:
Редактирование LVM-Thin-хранилища

⁠26.4.9.2. Создание LVM-Thin-хранилища в командной строке

Тонкий пул LVM создаётся внутри существующей группы томов.
Пример создания тонкого пула размером 80 ГБ с именем vmstore в группе томов vg (предполагается, что группа томов LVM с именем vg уже существует):
# lvcreate -L 80G -T -n vmstore vg
Просмотр доступных тонких пулов в группе vg:
# pvesm lvmthinscan vg
vmstore
Создание LVM-Thin-хранилища с именем vmstore на узле pve03:
# pvesm add lvmthin vmstore --thinpool vmstore --vgname vg --nodes pve03

⁠26.4.10. iSCSI

iSCSI (Internet Small Computer System Interface) — широко распространённая технология блочного хранения, позволяющая подключать удалённые дисковые устройства через сеть.
Хранилище типа iscsi поддерживает все общие свойства хранилищ PVE (content, nodes, disable), а также следующие параметры:
  • portal — IP-адрес или DNS-имя iSCSI-сервера;
  • target — iSCSI-цель (target).
Пример файла конфигурации (/etc/pve/storage.cfg):
iscsi: test1-iSCSI
    portal 192.168.0.105
    target iqn.2021-7.local.omv:test
    content images
Допустимый тип содержимого:
  • images — образы виртуальных дисков в формате raw.
iSCSI является блочным хранилищем и не предоставляет встроенных средств управления томами. Поэтому рекомендуется экспортировать один большой LUN и размещать на нём, например, LVM или LVM-Thin.

Примечание

Если планируется использовать LVM поверх iSCSI, рекомендуется указать:
content none
В этом случае напрямую создавать ВМ на таком хранилище будет невозможно — оно будет служить только «основой» для других уровней.

Примечание

На всех узлах, использующих iSCSI, должен быть установлен пакет open-iscsi, а служба iscsid — включена и запущена:
# systemctl enable --now iscsid
Пример добавления iSCSI-цели с именем test1-iSCSI, которая настроена на удаленном узле 192.168.0.105:
Добавление iSCSI-хранилища
Параметр Использовать LUN напрямую следует отключать. Прямое использование LUN может привести к повреждению данных при одновременном доступе с нескольких узлов.
Просмотр доступных iSCSI-целей:
# pvesm scan iscsi <IP-адрес сервера[:порт]>
Команда создания iSCSI-хранилища:
# pvesm add iscsi <ID> --portal <Сервер iSCSI> --target <Цель iSCSI> --content none

⁠26.4.11. iSCSI (libiscsi)

Хранилище типа iscsidirect предоставляет ту же базовую функциональность, что и стандартное iSCSI-хранилище, но реализовано с использованием библиотеки пользовательского уровня libiscsi. Поскольку при этом не задействуются драйверы ядра Linux, такое подключение проще в настройке и отладке. Однако поверх такого LUN нельзя размещать LVM — управление распределением пространства должно осуществляться на стороне сервера хранения.

Примечание

Для использования этого типа хранилища необходимо установить пакет libiscsi.
Хранилище iscsidirect поддерживает те же свойства, что и iscsi.
Пример конфигурации (/etc/pve/storage.cfg):
iscsidirect: test1-iSCSi
    portal 192.168.0.191
    target dc1.test.alt:server.target
Допустимый тип содержимого:
  • images — образы виртуальных дисков в формате raw.

⁠26.4.12. Ceph RBD

Хранилище RBD (RADOS Block Device) основано на распределённой системе хранения Ceph. Оно предоставляет блочные устройства, доступные по сети, и поддерживает только формат образов .raw.
Хранилище типа rbd поддерживает все общие свойства хранилищ PVE, а также следующие дополнительные параметры:
  • monhost — список IP-адресов мониторов Ceph (указывается только при подключении к внешнему кластеру Ceph);
  • pool — название пула Ceph (по умолчанию rbd);
  • username — имя пользователя Ceph (только для внешних кластеров);
  • krbd (опционально) — использовать драйвер ядра krbd для монтирования образов (по умолчанию — отключено).

Примечание

Контейнеры LXC всегда используют krbd, независимо от значения параметра krbd.
Пример конфигурации (/etc/pve/storage.cfg):
rbd: new
    content images
    krbd 0
    monhost 192.168.0.105
    pool rbd
    username admin
Допустимые типы содержимого:
  • rootdir — данные контейнеров LXC;
  • images — образы виртуальных дисков в формате raw.
Добавление хранилища RBD:
Добавление хранилища типа RBD
Если используется аутентификация cephx (включена по умолчанию), необходимо предоставить файл ключа (keyring) из внешнего кластера Ceph.
При настройке хранилища в командной строке, предварительно следует сделать доступным файл ключа. Один из способов — скопировать файл из внешнего кластера Ceph непосредственно на один из узлов PVE. Например, скопировать файл в каталог /root узла:
# scp <external cephserver>:/etc/ceph/ceph.client.admin.keyring /root/rbd.keyring
Команда настройки внешнего хранилища RBD:
# pvesm add rbd <name>  \
    --monhost "10.1.1.20 10.1.1.21 10.1.1.22"  \
    --content images  \
    --keyring /root/rbd.keyring
При настройке RBD в веб-интерфейсе файл ключа указывается в поле Keyring. Он будет сохранён в: /etc/pve/priv/ceph/<STORAGE_ID>.keyring.
Пример добавления хранилища RBD, использующего пул Ceph под управлением PVE (см. Кластер Ceph):
Добавление хранилища типа RBD
Файл ключа в этом случае копируется автоматически.

⁠26.4.13. CephFS

CephFS — это POSIX-совместимая файловая система, работающая поверх кластера Ceph. Она наследует ключевые свойства Ceph: избыточность, масштабируемость, самовосстановление и высокую доступность.

Примечание

PVE может управлять собственным кластером Ceph (см. Кластер Ceph), что упрощает развёртывание CephFS. Современное оборудование позволяет запускать службы хранения и ВМ на одних и тех же узлах без значительного влияния на производительность.
Хранилище типа cephfs поддерживает все общие свойства хранилищ PVE, а также:
  • monhost — IP-адреса мониторов (только для внешнего Ceph);
  • path — локальная точка монтирования (по умолчанию: /mnt/pve/<STORAGE_ID>/);
  • username — пользователь Ceph (только для внешнего кластера);
  • subdir — подкаталог CephFS для монтирования (по умолчанию — корень /);
  • fuse — доступ к CephFS через FUSE (по умолчанию 0).
Пример конфигурации (/etc/pve/storage.cfg):
cephfs: cephfs-external
    content backup
    monhost 192.168.0.105
    path /mnt/pve/cephfs-external
    username admin
Допустимые типы содержимого:
  • backup — резервные копии;
  • iso — ISO-образы;
  • vztmpl — шаблоны контейнеров;
  • мини-сценарии — фрагменты конфигурации;
  • import — импорт данных.
Добавление хранилища CephFS:
Добавление хранилища CephFS

Примечание

Имя файловой системы CephFS можно узнать командой:
# ceph fs ls
Если используется аутентификация cephx (включена по умолчанию), необходимо предоставить файл ключа (keyring) из внешнего кластера Ceph.
При настройке хранилища в командной строке, предварительно сделать файл с ключом доступным. Один из способов — скопировать файл из внешнего кластера Ceph непосредственно на один из узлов PVE. Например, скопировать файл в каталог /root узла:
# scp <external cephserver>:/etc/ceph/cephfs.secret /root/cephfs.secret
Команда настройки внешнего хранилища CephFS:
# pvesm add cephfs <name>  \
    --monhost "10.1.1.20 10.1.1.21 10.1.1.22" \
    --content backup --keyring \
    /root/cephfs.secret
При настройке внешнего хранилища CephFS в веб-интерфейсе файл ключа указывается в поле Секретный ключ. Он будет сохранён в: /etc/pve/priv/ceph/<STORAGE_ID>.secret.
Ключ можно получить из кластера Ceph:
# ceph auth get-key client.userid > cephfs.secret

⁠26.4.14. Proxmox Backup Server

Proxmox Backup Server позволяет напрямую интегрировать сервер резервного копирования в PVE.
Этот тип хранилища поддерживает только резервные копии:
  • на уровне блоков — для ВМ;
  • на уровне файлов — для контейнеров LXC.
Хранилище pbs поддерживает все общие свойства хранилищ, кроме флага shared, который всегда установлен. Дополнительные параметры:
  • server — IP-адрес или DNS-имя сервера резервного копирования;
  • username — имя пользователя на сервере резервного копирования (например, root@pam, backup_u@pbs);
  • password — пароль пользователя. (сохраняется в /etc/pve/priv/storage/<STORAGE-ID>.pw, доступен только суперпользователю);
  • datastore — имя хранилища на сервере PBS;
  • fingerprint — отпечаток TLS-сертификата PBS. (обязателен при использовании самоподписанного сертификата). Отпечаток можно получить в веб-интерфейсе сервера резервного копирования или с помощью команды proxmox-backup-manager cert info;
  • encryption-key (опционально) — ключ для шифрования резервной копии. В настоящее время поддерживаются только те файлы, которые не защищены паролем (без функции получения ключа (kdf)). Сохраняется в /etc/pve/priv/storage/<STORAGE-ID>.enc, доступен только суперпользователю;
  • master-pubkey (опционально) — открытый ключ RSA для шифрования копии ключа шифрования (encryption-key). Зашифрованная копия будет добавлена к резервной копии и сохранена на сервере резервного копирования для целей восстановления.
Пример конфигурации (/etc/pve/storage.cfg):
pbs: pbs_backup
    datastore store2
    server 192.168.0.123
    content backup
    fingerprint 42:5d:29:20:…:d1:be:bc:c0:c0:a9:9b:b1:a8:1b
    prune-backups keep-all=1
    username root@pam

⁠26.4.14.1. Подключение хранилища

Добавление хранилища Proxmox Backup Server с именем pbs_backup с сервера 192.168.0.123:
Добавление хранилища Proxmox Backup Server
Добавление хранилища Proxmox Backup Server в командной строке:
# pvesm add pbs pbs_backup  \
    --server 192.168.0.123  \
    --datastore store2  \
    --username root@pam  \
    --fingerprint 42:5d:29:20:…:d1:be:bc:c0:c0:a9:9b:b1:a8:1b  \
    --password

⁠26.4.14.2. Шифрование

Шифрование резервных копий выполняется на стороне клиента с использованием AES-256 в режиме GCM.
Шифрование можно настроить либо в командной строке с помощью опции encryption-key, либо через веб-интерфейс:
Сгенерировать клиентский ключ шифрования
Необходимо сохранить ключ шифрования:
Сохранить клиентский ключ шифрования
Шифрование настроено:
Используется клиентское шифрование
Ключ будет сохранен в файле /etc/pve/priv/storage/<STORAGE-ID>.enc, который доступен только пользователю root.

Примечание

Для работы с ключами в командной строке используется команда proxmox-backup-client key. Например, сгенерировать ключ:
# proxmox-backup-client key create --kdf none <path>
Сгенерировать мастер-ключ:
# proxmox-backup-client key create-master-key

Важно

Без ключа шифрования восстановить резервные копии невозможно. Ключ необходимо хранить в безопасном, но доступном месте: в менеджере паролей, на USB-накопителе.
Для централизованного восстановления можно использовать мастер-ключ. Открытая часть (master-pubkey) добавляется в конфигурацию PBS-хранилища. Закрытая часть позволяет расшифровать любую резервную копию, даже если клиентская система утеряна.

Важно

Закрытый мастер-ключ должен храниться с той же степенью защиты, что и клиентские ключи. Без копии закрытого ключа восстановление невозможно!

Примечание

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

⁠26.4.15. ESXi

Хранилище типа esxi предназначено для автоматического импорта ВМ из VMware ESXi в PVE.
Для ESXi доступны следующие параметры:
  • server — IP-адрес или DNS-имя ESXi-хоста;
  • username — имя администратора;
  • password — пароль администратора. (сохраняется в /etc/pve/priv/storage/<STORAGE-ID>.pw, доступно только суперпользователю);
  • skip-cert-verification — отключить проверку TLS-сертификата (использовать только в доверенных сетях).
Пример конфигурации (/etc/pve/storage.cfg):
esxi: myESXi
    server 192.168.0.130
    username root
    skip-cert-verification 1
Подключение хранилища ESXi с именем myESXi с удаленного сервера 192.168.0.130:
Добавление хранилища ESXi
Если на ESXi используется самоподписанный сертификат, необходимо добавить его в доверенные сертификаты системы или включить опцию Пропустить проверку сертификата.
Добавление хранилища ESXi в командной строке:
# pvesm add esxi myESXi  \
    --server 192.168.0.130 \
    --username root \
    --skip-cert-verification 1 \
    --password

⁠26.5. FC/iSCSI SAN

Данная конфигурация предполагает, что узлы кластера имеют доступ к устройствам хранения (LUN), экспортируемым сервером сети хранения данных (SAN) по протоколам iSCSI или Fibre Channel (FC).
Соединение узла PVE с хранилищем называется путём. Если в подсистеме хранения данных существует несколько путей к устройству хранения данных (LUN), это называется многопутевым подключением (multipath). Необходимо использовать как минимум два выделенных сетевых адаптера для iSCSI/FC, использующих отдельные сети (и коммутаторы для защиты от сбоев коммутатора).
Основная цель многопутевого подключения (multipath) — обеспечить резервный доступ к устройству хранения данных. Еще одним преимуществом многопутевого доступа является увеличение пропускной способности за счет балансировки нагрузки. Типичным примером использования нескольких путей является добавление избыточности и получение максимальной производительности от устройства FC/iSCSI SAN.

Примечание

В данном разделе приведена общая информация. Для настройки конкретной системы хранения данных (СХД) следует обращаться к документации производителя.

⁠26.5.1. Подключение СХД

⁠26.5.1.1. Особенности подключения СХД по FC

Алгоритм подключения:
  1. Подготовить СХД (создать LUNы).
  2. Установить FC HBA и соответствующие драйверы на сервер.
  3. Настроить сетевое подключение.
  4. Подключить СХД к серверу.
  5. Настроить зональность (zoning) на коммутаторах FC, предоставив серверу доступ по его WWPN (World Wide Port Name).

Примечание

Глобальные имена портов (WWPN) можно определить с помощью утилиты systool из пакета sysfsutils.
Пакет sysfsutils необходимо установить из репозитория:
# apt-get install sysfsutils
Чтобы найти WWPN, следует ввести следующую команду:
# systool -c fc_host -A port_name
Class = "fc_host"
Class Device = "host1"
port_name = "0x10000090fa59a61a"
Device = "host1"
Class Device = "host16"
port_name = "0x10000090fa59a61b"
Device = "host16"
После подключения LUN будет виден как несколько блочных устройств (по одному на путь). Их можно проверить командой:
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 59G 0 disk
sdb 8:16 0 931,3G 0 disk
└─mpatha 253:0 0 931,3G 0 mpath
sdc 8:32 0 931,3G 0 disk
└─mpatha 253:0 0 931,3G 0 mpath
sdd 8:48 0 931,3G 0 disk
└─mpatha 253:0 0 931,3G 0 mpath
sde 8:64 0 931,3G 0 disk
└─mpatha 253:0 0 931,3G 0 mpath
В этом примере один LUN объёмом ~931 ГБ доступен по четырём путям.

⁠26.5.1.2. Особенности подключения СХД по ISCSI

Для корректной работы в кластере необходимо, чтобы iSCSI-сессии устанавливались автоматически при загрузке. Сделать это можно, установив для параметра node.startup значение automatic. Значение по умолчанию для параметра node.session.timeo.replacement_timeout составляет 120 секунд. Рекомендуется использовать значение — 15 секунд.
Эти параметры можно указать в файле в /etc/iscsi/iscsid.conf (по умолчанию). Если iSCSI target уже подключен, то необходимо изменить настройки по умолчанию для конкретной цели в файле /etc/iscsi/nodes/<TARGET>/<PORTAL>/default.
На всех узлах PVE необходимо:
  1. Установить пакет open-iscsi, запустить и добавить в автозагрузку сервис iscsid:
    # apt-get install open-iscsi
    # systemctl enable --now iscsid
    
  2. Указать следующие параметры в файле /etc/iscsi/iscsid.conf:
    node.startup = automatic
    node.session.timeo.replacement_timeout = 15
    
  3. Присоединить iSCSI-хранилище к кластеру:
    # iscsiadm -m discovery -t sendtargets -p <iscsi-target-1-ip>
    # iscsiadm -m discovery -t sendtargets -p <iscsi-target-2-ip>
    # iscsiadm -m node --login
    
  4. Настроить автоматическое подключение iSCSI-target-ов. Для этого необходимо поменять следующие параметры:
    • в файле /etc/iscsi/iscsid.conf:
      node.startup = automatic
    • в файлах /var/lib/iscsi/send_targets/<TargetServer>,<Port>/st_config:
      discovery.sendtargets.use_discoveryd = Yes
      
  5. После перезагрузки LUN должен быть виден через lsblk — аналогично FC-примеру:
    # lsblk
    NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
    sda 8:0 0 59G 0 disk
    sdb 8:16 0 931,3G 0 disk
    └─mpatha 253:0 0 931,3G 0 mpath
    sdc 8:32 0 931,3G 0 disk
    └─mpatha 253:0 0 931,3G 0 mpath
    sdd 8:48 0 931,3G 0 disk
    └─mpatha 253:0 0 931,3G 0 mpath
    sde 8:64 0 931,3G 0 disk
    └─mpatha 253:0 0 931,3G 0 mpath
    

Примечание

Примеры использования команды iscsiadm:
  • отключить хранилище (отключить все цели):
    # iscsiadm -m node --logout
    
  • отключить только определенную цель:
    # iscsiadm -m node --targetname "iscsi-target-1.test.alt:server.target1" --logout
    
  • переопросить устройства на ISCSI:
    # iscsiadm -m node -R
    
  • посмотреть все текущие подключения iSCSI:
    # iscsiadm -m session
    

⁠26.5.2. Настройка Multipath

Многопутевой ввод-вывод (Multipath I/O) — технология подключения узлов СХД с использованием нескольких маршрутов. В случае отказа одного из контроллеров, ОС будет использовать другой для доступа к устройству. Это повышает отказоустойчивость системы и позволяет распределять нагрузку.
Multipath устройства объединяются в одно устройство с помощью специализированного ПО в новое устройство. Multipath обеспечивает выбор пути и переключение на новый маршрут при отказе текущего. Кроме того, Multipath позволяет увеличить пропускную способность за счет балансировки нагрузки.
На всех узлах должен быть установлен пакет для multipath:
# apt-get install multipath-tools
И запущена служба multipathd:
# systemctl enable --now multipathd && sleep 5; systemctl status multipathd

⁠26.5.2.1. Конфигурация multipath

Примечание

Команда multipath используется для обнаружения и объединения нескольких путей к устройствам.
Некоторые параметры команды multipath:
  • -l — показать текущую multipath-топологию, полученную из sysfs и устройства сопоставления устройств;
  • -ll — показать текущую multipath-топологию, собранную из sysfs, устройства сопоставления устройств и всех других доступных компонентов системы;
  • -f device — удалить указанное multipath-устройство;
  • -F — удалить все неиспользуемые multipath-устройства;
  • -w device — удалить WWID указанного устройства из файла wwids;
  • -W — сбросить файл wwids, чтобы включить только текущие многопутевые устройства;
  • -r — принудительная перезагрузка multipath-устройства.
После подключения, устройство хранения данных должно автоматически определиться как multipath-устройство:
# multipath -ll
mpatha (3600c0ff00014f56ee9f3cf6301000000) dm-0 HP,P2000 G3 FC
size=931G features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| |- 1:0:0:1 sdb 8:16 active ready running
| `- 16:0:1:1 sde 8:64 active ready running
`-+- policy='service-time 0' prio=10 status=enabled
|- 1:0:1:1 sdc 8:32 active ready running
`- 16:0:0:1 sdd 8:48 active ready running
Вывод этой команды можно разделить на три части:
  • Информация о multipath-устройстве:
    • mpatha (3600c0ff00014f56ee9f3cf6301000000): алиас
    • dm-0: имя устройства dm
    • HP,P2000 G3 FC: поставщик, продукт
    • size=931G: размер
    • features='1 queue_if_no_path': функции
    • hwhandler='1 alua': аппаратный обработчик
    • wp=rw: права на запись
  • Информация о группе путей:
    • policy='service-time 0': политика планирования
    • prio=50: приоритет группы путей
    • status=active: статус группы путей
  • Информация о пути:
    • 16:0:1:1: хост:канал:идентификатор:Lun
    • sde: диск
    • 8:64: номера major:minor
    • active: статус dm
    • ready: статус пути
    • running: online статус
Для получения дополнительной информации об используемых устройствах можно выполнить команду:
# multipath -v3
Настройки multipath содержатся в файле /etc/multipath.conf:
defaults {
    find_multipaths         yes
    user_friendly_names     yes
}
Если для параметра user_friendly_names установлено значение no, то для имени multipath-устройства задается значение World Wide Identifier (WWID). Имя устройства будет /dev/mapper/WWID и /dev/dm-X:
# ls /dev/mapper/
3600c0ff00014f56ee9f3cf6301000000

# lsblk
NAME                                        MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sda                                           8:0    0    59G  0 disk
sdb                                           8:16   0 931,3G  0 disk
└─3600c0ff00014f56ee9f3cf6301000000         253:0    0 931,3G  0 mpath
sdc                                           8:32   0 931,3G  0 disk
└─3600c0ff00014f56ee9f3cf6301000000         253:0    0 931,3G  0 mpath
sdd                                           8:48   0 931,3G  0 disk
└─3600c0ff00014f56ee9f3cf6301000000         253:0    0 931,3G  0 mpath
sde                                           8:64   0 931,3G  0 disk
└─3600c0ff00014f56ee9f3cf6301000000         253:0    0 931,3G  0 mpath
Если для параметра user_friendly_names установлено значение yes, то для имени multipath-устройства задаётся алиас (псевдоним), в форме mpathХ. Имя устройства будет /dev/mapper/mpathХ и /dev/dm-X:
# ls /dev/mapper/
mpatha

# lsblk
NAME             MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sda                8:0    0    59G  0 disk
sdb                8:16   0 931,3G  0 disk
└─mpatha         253:0    0 931,3G  0 mpath
sdc                8:32   0 931,3G  0 disk
└─mpatha         253:0    0 931,3G  0 mpath
sdd                8:48   0 931,3G  0 disk
└─mpatha         253:0    0 931,3G  0 mpath
sde                8:64   0 931,3G  0 disk
└─mpatha         253:0    0 931,3G  0 mpath
Однако не гарантируется, что имя устройства будет одинаковым на всех узлах, использующих это multipath-устройство.
ОС при загрузке определяет пути к устройствам в изменяющейся среде выполнения (например, при новой загрузке в среде выполнения ОС появились новые устройства хранения или исчезли старые, и т.п.) по отношению к предыдущей загрузке или по отношению к заданной ранее конфигурации. Это может приводить к противоречиям при именовании устройств. Для того чтобы избежать такого поведения, рекомендуется:
  • Сделать явное исключение для устройства (раздела) хранения (например, для 3600c0ff00014f56ee9f3cf6301000000, которое в настоящее время определяется как /dev/mapper/mpatha). Для этого в файл /etc/multipath.conf добавить секции:
    blacklist {
            wwid .*
    }
    
    blacklist_exceptions {
            wwid "3600c0ff00014f56ee9f3cf6301000000"
    }
    
    Данная настройка предписывает внести в черный список любые найденные устройства хранения данных, за исключением нужного.
  • Создать еще одну секцию:
    multipaths {
      multipath {
            wwid "3600c0ff00014f56ee9f3cf6301000000"
            alias mpatha
      }
    }
    
    В этом случае устройство всегда будет доступно только по имени /dev/mapper/mpatha. Вместо mpatha можно вписать любое желаемое имя устройства.

Примечание

Получить WWID конкретного устройства можно, выполнив команду:
# /lib/udev/scsi_id -g -u -d /dev/sdb
3600c0ff00014f56ee9f3cf6301000000
Для устройств в одном multipath WWID будут совпадать.
В файл /etc/multipath.conf может также потребоваться внести рекомендованные производителем СХД параметры.
После внесения изменений в файл /etc/multipath.conf необходимо перезапустить службу multipathd для активации настроек:
# systemctl restart multipathd.service

Примечание

Проверить файл /etc/multipath.conf на наличие ошибок можно, выполнив команду:
# multipath -t

⁠26.5.3. Multipath в веб-интерфейсе PVE

Устройства multipath отображаются в разделе Диски веб-интерфейса PVE:
Multipath в веб-интерфейсе PVE
Поверх хранилища на базе iSCSI или FC можно использовать LVM или хранилище файлового типа.

⁠26.5.4. LVM/LVM-Thin хранилища на multipath

Примечание

Multipath-устройства не отображаются в мастере создания LVM в веб-интерфейсе PVE, поэтому нужно использовать CLI.

Примечание

LVM при запуске сканирует все устройства на предмет поиска конфигурации LVM, и если настроен multipath-доступ, он найдет конфигурацию LVM как на (виртуальных) multipath-устройствах, так и на базовых (физических) дисках. Поэтому рекомендуется создать фильтр LVM для фильтрации физических дисков и разрешить LVM сканировать только multipath-устройства.
Сделать это можно, добавив фильтр в раздел device в файле /etc/lvm/lvm.conf, например:
filter = [ "a|/dev/mapper/|", "a|/dev/sda.*|", "r|.*|" ]
В данном примере принимаются только multipath-устройства и /dev/sda.*, все остальные устройства отклоняются:
  • a|/dev/mapper/| — принять устройства /dev/mapper;
  • a|/dev/sda.*| — принять устройство /dev/sda;
  • r|.*| — отклонить все остальные устройства.
Пример создания LVM на multipath:
  1. Вывести список разделов /dev/mapper/mpatha:
    # fdisk -l /dev/mapper/mpatha
    Disk /dev/mapper/mpatha: 931.32 GiB, 999999995904 bytes, 1953124992 sectors
    Units: sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 1048576 bytes
    Disklabel type: dos
    Disk identifier: 0x2221951e
    
    Device Boot Start End Sectors Size Id Type
    /dev/mapper/mpatha-part1 2048 1953124991 1953122944 931.3G 83 Linux
    
  2. Создать физический том (PV) на /dev/mapper/mpatha-part1:
    # pvcreate /dev/mapper/mpatha-part1
    Physical volume "/dev/mapper/mpatha-part1" successfully created.
    
  3. Создать группу томов (VG) с именем VG1:
    # vgcreate VG1 /dev/mapper/mpatha-part1
    Volume group "VG1" successfully created
    
  4. Вывести информацию о физических томах:
    # pvs
    PV                       VG  Fmt  Attr PSize   PFree
    /dev/mapper/mpatha-part1 VG1 lvm2 a--  931.32g 931.32g
    

⁠26.5.4.1. LVM-хранилище

Получить список доступных PVE групп томов:
# pvesm lvmscan
VG1
Список доступных PVE групп томов можно также увидеть в веб-интерфейсе:
Список LVM томов
Пример создания LVM-хранилища с именем mpath-lvm:
# pvesm add lvm mpath-lvm --vgname VG1 --content images,rootdir
Пример создания LVM-хранилища в веб-интерфейсе (Центр обработки данных → Хранилище, нажать кнопку Добавить → LVM):
LVM хранилище на multipath

⁠26.5.4.2. LVM-Thin хранилище

Создать тонкий пул LVM на multipath:
  1. Вывести информацию о физических томах:
    # pvs
      PV                       VG  Fmt  Attr PSize   PFree
      /dev/mapper/mpatha-part1 VG1 lvm2 a--  931.32g 931.32g
    
  2. Вывести информацию о группах томов:
    # vgs
      VG  #PV #LV #SN Attr   VSize   VFree
      VG1   1   0   0 wz--n- 931.32g 931.32g
    
  3. Создать тонкий пул LVM (размер 100 ГБ) с именем vmstore:
    # lvcreate -L 100G -T -n vmstore VG1
    Logical volume "vmstore" created.
    
Получить список доступных PVE LVM-thin пулов в группе томов VG1:
# pvesm lvmthinscan VG1
vmstore
Список доступных PVE LVM-thin пулов можно также увидеть в веб-интерфейсе:
Список LVM-thin пулов
Пример создания LVM-Thin хранилища с именем mpath-lvmthin:
# pvesm add lvmthin mpath-lvmthin --thinpool vmstore --vgname VG1 --nodes pve01
Пример создания LVM-Thin хранилища в веб-интерфейсе (Центр обработки данных → Хранилище, нажать кнопку Добавить → LVM-Thin):
LVM хранилище на multipath

⁠26.5.5. Изменение размера multipath-устройства

Для изменения размера multipath-устройства необходимо:
  • Изменить размер физического устройства;
  • Определить пути к номеру логического устройства (LUN):
    # multipath -l
    mpatha (3600c0ff00014f56ee9f3cf6301000000) dm-0 HP,P2000 G3 FC
    size=465G features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
    |-+- policy='service-time 0' prio=0 status=active
    | |- 1:0:1:1  sdc 8:32 active undef running
    | `- 16:0:1:1 sde 8:64 active undef running
    `-+- policy='service-time 0' prio=0 status=enabled
    |- 1:0:0:1  sdb 8:16 active undef running
    `- 16:0:0:1 sdd 8:48 active undef running
    
  • Изменить размер путей, выполнив команду:
    # echo 1 > /sys/block/<path_device>/device/rescan
    
    Данную команду необходимо выполнить для каждого диска, входящего в multipath-устройство:
    # echo 1 > /sys/block/sdb/device/rescan
    # echo 1 > /sys/block/sdc/device/rescan
    # echo 1 > /sys/block/sdd/device/rescan
    # echo 1 > /sys/block/sde/device/rescan
    
  • Убедиться, что ядро увидело новый размер, выполнив команду:
    # dmesg -wHT
    
    Новый размер диска в выводе команды dmesg
  • Изменить размер multipath-устройства:
    # multipathd -k"resize map 3600c0ff00014f56ee9f3cf6301000000"
    
    где 3600c0ff00014f56ee9f3cf6301000000 — WWID multipath-устройства;
  • Изменить размер блочного устройства (если используется LVM):
    # pvresize /dev/mapper/mpatha
    
  • Изменить размер файловой системы (если разделы LVM или DOS не используются):
    # resize2fs /dev/mapper/mpatha
    

Примечание

Данную процедуру следует выполнить на каждом узле, к которому присоединён этот LUN.

⁠26.6. Кластер Ceph

PVE позволяет использовать одни и те же физические узлы в кластере как для вычислений (обработка виртуальных машин и контейнеров), так и для размещения реплицированного хранилища.
Ceph — программная объектная отказоустойчивая система хранения данных. Она обеспечивает файловый и блочный доступ к данным. Ceph интегрирован в PVE, поэтому запуск и управление хранилищем Ceph возможны непосредственно на узлах гипервизора.
Преимущества использования Ceph в PVE:
  • простая настройка и управление через веб-интерфейс и командную строку;
  • гибкое резервирование данных;
  • поддержка моментальных снимков;
  • самовосстановление;
  • масштабируемость до уровня эксабайт;
  • настройка пулов с различными характеристиками производительности и избыточности;
  • репликация данных для обеспечения отказоустойчивости;
  • работа на стандартном оборудовании;
  • отсутствие необходимости в аппаратных RAID-контроллерах;
  • открытый исходный код.
pveceph — инструмент для установки и управления службами Ceph на узлах PVE.
Кластерная система хранения данных Ceph состоит из нескольких демонов:
  • Монитор Ceph (ceph-mon) — хранит информацию о состоянии кластера, карту всех узлов и правила распределения данных (CRUSH-карту). Мониторы также отвечают за управление аутентификацией между демонами и клиентами. Для обеспечения резервирования и высокой доступности требуется не менее трех мониторов;
  • Менеджер Ceph (ceph-mgr) — собирает информацию о состоянии всего кластера и работает совместно с демонами мониторов. Он обеспечивает расширенный мониторинг, взаимодействует с внешними системами управления и мониторинга, а также предоставляет дополнительные сервисы. Для обеспечения высокой доступности требуется по крайней мере два менеджера.
  • OSD Ceph (ceph-osd; демон хранилища объектов) — управляет устройствами хранения объектов, которые представляют собой физические или логические единицы хранения (жесткие диски или разделы). Демон также отвечает за репликацию данных и перебалансировку при добавлении или удалении узлов. Демоны OSD взаимодействуют с мониторами и передают им информацию о своём состоянии. OSD являются основными демонами кластера и несут основную нагрузку. Для обеспечения резервирования и высокой доступности требуется не менее трёх OSD.
  • Сервер метаданных Ceph (Metadata Server) — хранит метаданные файловой системы CephFS (блочные устройства Ceph и объектное хранилище Ceph MDS не используют). Разделение метаданных и пользовательских данных значительно повышает производительность кластера. Серверы метаданных позволяют клиентам файловой системы POSIX выполнять базовые операции (например, ls, find и т.д.) без создания избыточной нагрузки на кластер хранения.

⁠26.6.1. Системные требования

Для построения гиперконвергентного кластера PVE + Ceph рекомендуется использовать не менее трёх идентичных серверов.
Требования к оборудованию Ceph могут варьироваться в зависимости от размера кластера, ожидаемой нагрузки и других факторов.
⁠

Таблица 26.4. Системные требования к оборудованию для Ceph

Процесс
Критерий
Требования
Монитор Ceph
Процессор
2 ядра минимум, 4 рекомендуется
ОЗУ
5ГБ+ (большим/производственным кластерам нужно больше)
Жёсткий диск
100 ГБ на демон, рекомендуется SSD
Сеть
1 Гбит/с (рекомендуется 10+ Гбит/с)
Менеджер Ceph
Процессор
1 ядро
ОЗУ
1 ГБ
OSD Ceph
Процессор
  • 1 ядро минимум, 2 рекомендуется
  • 1 ядро на пропускную способность 200-500 МБ/с
  • 1 ядро на 1000-3000 IOPS
  • SSD OSD, особенно NVMe, выиграют от дополнительных ядер на OSD
ОЗУ
  • 4 ГБ+ на демон (больше – лучше)
  • 1 ГБ на 1 ТБ данных OSD
Жёсткий диск
1 SSD накопитель на демон
Сеть
1 Гбит/с (рекомендуется агрегированная сеть 10+ Гбит/с)
Сервер метаданных Ceph
Процессор
2 ядра
ОЗУ
2 ГБ+ (для производственных кластеров больше)
Жёсткий диск
1 ГБ на демон, рекомендуется SSD
Сеть
1 Гбит/с (рекомендуется 10+ Гбит/с)
Серверу в целом требуется не менее суммы ресурсов всех демонов, размещённых на нём, а также дополнительные ресурсы для журналов и других компонентов ОС. Следует учитывать, что потребность в ОЗУ и хранилище возрастает при запуске кластера, а также во время отказов, добавления компонентов и перебалансировки данных.
Дополнительные рекомендации:
  • Память: при гиперконвергентной конфигурации необходимо тщательно контролировать потребление памяти. Помимо потребностей ВМ и контейнеров, следует обеспечить достаточный объём ОЗУ для работы Ceph.
  • Сеть: рекомендуется использовать выделенную сеть со скоростью не менее 10 Гбит/с исключительно для Ceph. Объем трафика, особенно во время восстановления данных, может негативно влиять на другие службы в той же сети и даже нарушать работу кластера PVE. Необходимо заранее оценить потребность в пропускной способности: один жёсткий диск, как правило, не заполняет канал 1 Гбит/с, однако несколько OSD на одном узле — могут, а современные NVMe-накопители способны быстро насытить и 10 Гбит/с. Использование сетей 25, 40 или 100 Гбит/с позволяет избежать подобных узких мест.
  • Жесткие диски: OSD-диски ёмкостью значительно менее 1 ТБ используют заметную часть пространства под метаданные, а диски объёмом менее 100 ГБ практически неэффективны. Настоятельно рекомендуется использовать SSD как миниму для узлов мониторов и менеджеров Ceph, а также для пулов метаданных CephFS и индексов Ceph Object Gateway (RGW), даже если для хранения пользовательских данных применяются жёсткие диски.
    Ceph наиболее эффективно работает при равномерном распределении одинаковых по размеру дисков между узлами. Например, конфигурация из четырёх дисков по 500 ГБ на каждом узле предпочтительнее смешанной конфигурации с одним диском на 1 ТБ и тремя по 250 ГБ.
    Необходимо также балансировать количество OSD и их ёмкость. Большая ёмкость увеличивает плотность хранения, но при отказе одного OSD системе потребуется восстанавливать больший объём данных одновременно.
    Поскольку Ceph самостоятельно управляет избыточностью и параллельной записью данных, использование RAID-контроллеров обычно не повышает производительность или надёжность. Напротив, RAID-контроллеры могут ухудшать работу Ceph из-за собственных алгоритмов записи и кеширования.

Важно

Следует избегать использования RAID-контроллеров — Ceph самостоятельно управляет избыточностью. Вместо них рекомендуется использовать HBA-адаптеры.

Примечание

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

⁠26.6.2. Начальная конфигурация Ceph

Для создания начальной конфигурации Ceph рекомендуется использовать мастер установки PVE Ceph. Для этого необходимо перейти в раздел Центр обработки данных → Ceph и нажать кнопку Настроить Ceph:
Инициализация кластера Ceph
В открывшемся окне необходимо выбрать открытую сеть в поле Public Network и сеть кластера в поле Cluster Network:
  • Public Network — клиентский трафик. Настоятельно рекомендуется выделить трафик Ceph в отдельную сеть;
  • Cluster Network — репликация OSD и heartbeat. (опционально, но рекомендуется для больших кластеров).
Настройка сетевых параметров Ceph

Примечание

Поле Cluster Network можно не заполнять — по умолчанию используется сеть, указанная в Public Network.
В расширенных настройках есть возможность настроить ещё два параметра (эти параметры следует изменять только в том случае, если вы знаете, что делаете):
  • Number of replicas — количество реплик (по умолчанию 3);
  • Minimum replicas — минимальное число реплик для подтверждения записи (по умолчанию 2).
После нажатия кнопки Далее будет выведено сообщение об успешной установке:
Сообщение об успешной установке Ceph
Начальную конфигурацию Ceph также можно создать из командной строки выполнив на любом узле PVE следующую команду:
# pveceph init --network 192.168.0.0/24
В результате инициализации будет создан файл конфигурации /etc/pve/ceph.conf с выделенной сетью для Ceph. Этот файл автоматически распространяется на все узлы PVE с помощью pmxcfs. Будет также создана символическая ссылка /etc/ceph/ceph.conf, указывающая на основной файл конфигурации, что позволяет выполнять команды Ceph без явного указания пути к конфигурации.
При инициализации создаётся только один монитор Ceph. Для обеспечения отказоустойчивости необходимо вручную добавить дополнительные мониторы, менеджеры, OSD и как минимум один пул.

⁠26.6.3. Монитор Ceph

Монитор Ceph хранит основную копию карты кластера (CRUSH-карта, состояние OSD и т.д.). Для обеспечения отказоустойчивости рекомендуется развернуть не менее трёх мониторов. При использовании мастера установки один монитор создаётся автоматически.

Примечание

Для небольших и средних кластеров достаточно трёх мониторов. Крупные развёртывания могут требовать большего количества.

⁠26.6.3.1. Создание монитора

Создание монитора в веб-интерфейсе:
  1. Выберите любой узел в дереве и перейдите на вкладку Ceph → Монитор.
  2. Нажмите кнопку Создать в разделе Монитор.
  3. В открывшемся окне выберите имя узла, на котором будет создан монитор:
    Создание монитора на узле pve02
Создание монитора в командной строке (команда выполняется на узле, где требуется разместить монитор):
# pveceph mon create

⁠26.6.3.2. Удаление монитора

Удаление монитора в веб-интерфейсе:
  1. Выберите любой узел в дереве и перейдите на вкладку Ceph → Монитор.
  2. Выберите монитор и нажмите кнопку Уничтожить.
Удаление монитора в командной строке (команда выполняется на узле, на котором запущен монитор):
# pveceph mon destroy <mon_id>

Примечание

Для обеспечения отказоустойчивости и корректной работы кворума требуется нечётное число мониторов (минимум три).

⁠26.6.4. Менеджер Ceph

Менеджер Ceph предоставляет интерфейс для мониторинга кластера и взаимодействия с внешними системами. Для работы кластера требуется как минимум один демон ceph-mgr.

Примечание

Рекомендуется размещать менеджеры Ceph на тех же узлах, что и мониторы. Для высокой доступности следует развернуть не менее двух менеджеров (одновременно активен только один):
Активный менеджер на узле pve01

⁠26.6.4.1. Создание менеджера

Создание менеджера в веб-интерфейсе:
  1. Выберите любой узел в дереве и перейдите на вкладку Ceph → Монитор.
  2. Нажмите кнопку Создать в разделе Диспетчер.
  3. В открывшемся окне выберите имя узла, на котором будет создан менеджер Ceph:
    Создание менеджера на узле pve02
Создание менеджера в командной строке (команда выполняется на узле, где нужно разместить менеджер):
# pveceph mgr create

⁠26.6.4.2. Удаление менеджера

Удаление менеджера в веб-интерфейсе:
  1. Выберите любой узел в дереве и перейдите на вкладку Ceph → Монитор.
  2. Выберите менеджер и нажмите кнопку Уничтожить.
Удаление менеджера Ceph в командной строке (команда выполняется на узле, на котором запущен менеджер):
# pveceph mgr destroy <mgr_id>

⁠26.6.5. Ceph OSD

Рекомендуется использовать один OSD на каждый физический диск.

⁠26.6.5.1. Создание OSD

Для обеспечения отказоустойчивости кластера рекомендуется использовать не менее трёх узлов и 12 OSD, равномерно распределённых между узлами.
Если диск использовался ранее (например, для ZFS или в качестве OSD), перед повторным использованием необходимо удалить все следы предыдущей конфигурации. Для удаления таблицы разделов, загрузочного сектора и других остатков OSD можно использовать команду:
# ceph-volume lvm zap /dev/[X] --destroy

Предупреждение

Эта команда безвозвратно удаляет все данные на диске.
Создание OSD в веб-интерфейсе:
  1. Перейдите на вкладку Узел → Ceph → OSD.
  2. Нажмите кнопку Создать: OSD.
  3. В открывшемся окне выберите локальный диск, который будет включен в Сeph-кластер. При необходимости можно указать отдельные диски для метаданных (Диск базы данных) и журналирования (Диск WAL):
    Создание OSD
Создание OSD в командной строке:
# pveceph osd create /dev/[X]
Указать отдельные устройства для метаданных (DB) и журналирования (WAL) для OSD можно с помощью параметров -db_dev и -wal_dev:
# pveceph osd create /dev/[X] -db_dev /dev/[Y] -wal_dev /dev/[Z]
Если устройство для WAL не указано, журнал размещается вместе с DB.
Размеры DB и WAL можно задать вручную с помощью параметров -db_size и -wal_size. Если параметры не заданы, используются следующие значения (в указанном порядке):
  • bluestore_block_{db,wal}_size из конфигурации Ceph:
    • база данных, раздел [osd];
    • база данных, раздел [global];
    • файл конфигурации, раздел [osd];
    • файл конфигурации, раздел [global];
  • автоматическое определение размеров (по умолчанию: 10 % для DB и 1 % для WAL от размера OSD).

Примечание

В DB хранятся внутренние метаданные BlueStore, а WAL представляет собой внутренний журнал предварительной записи BlueStore. Для достижения наилучшей производительности рекомендуется размещать DB и WAL на высокопроизводительных накопителях.

⁠26.6.5.2. Удаление OSD

Если возникли проблемы с OSD или его диском, сначала рекомендуется попытаться устранить неисправности, чтобы определить, действительно ли требуется удаление или замена OSD.
Перед удалением OSD необходимо убедиться, что в кластере достаточно свободного пространства для перебалансировки данных:
  • В веб-интерфейсе Ceph → OSD, если удаляемый OSD всё ещё активен и находится в состоянии AVAIL (ненулевое значение), убедитесь, что показатель Использовано (%) для всех OSD значительно ниже значения nearfull_ratio, (по умолчанию — 85 %).
    Показатель Использовано (%)
  • Аналогичную информации можно получить, выполнив команду:
    # ceph osd df tree
    
    Пример вывода:
    ID  CLASS  WEIGHT   REWEIGHT  AVAIL    %USE  VAR   PGS  STATUS  TYPE NAME
    -1         0.40585         -  415 GiB  0.07  1.00    -          root default
    -7         0.11279         -  115 GiB  0.06  0.91    -              host pve01
     3    ssd  0.11279   1.00000  115 GiB  0.06  0.91   65      up          osd.3
    -3         0.19537         -  200 GiB  0.07  1.03    -              host pve02
     0    ssd  0.09769   1.00000  100 GiB  0.08  1.11   31      up          osd.0
     2    ssd  0.09769   1.00000  100 GiB  0.06  0.94   34      up          osd.2
    -5         0.09769         -  100 GiB  0.07  1.05    -              host pve03
     1    ssd  0.09769   1.00000  100 GiB  0.07  1.05   65      up          osd.1
                           TOTAL  415 GiB  0.07
    MIN/MAX VAR: 0.91/1.11  STDDEV: 0.01
    

Примечание

Это позволяет снизить риск переполнения OSD в процессе перебалансировки, что в противном случае может привести к блокировке операций ввода-вывода в пулах Ceph.
Процедура удаления OSD в веб-интерфейсе:
  1. Выберите узел PVE и перейдите на панель Ceph → OSD.
  2. Выберите OSD, который нужно удалить, и нажмите кнопку Out:
    Выбор OSD, который нужно удалить
  3. После смены статуса с in на out нажмите кнопку Остановка:
    Остановка OSD
  4. После смены статуса с up на down выберите в раскрывающемся списке Дополнительно → Уничтожить:
    Уничтожить OSD
  5. Нажмите кнопку Удалить:
    Удаление OSD
Удаление OSD в консоли:
  1. Пометьте OSD как out:
    # ceph osd out <ID>
    
    Эта команда указывает Ceph не включать OSD в распределение данных.
  2. Дождитесь завершения перебалансировки данных, чтобы кластер всегда сохранял необходимое количество реплик. После завершения перебалансировки OSD станет пустым и будет содержать 0 PG.
    Для проверки возможности безопасной остановки OSD можно использовать команду:
    # ceph osd ok-to-stop <ID>
    
  3. На узле с удаляемым OSD остановите службу OSD:
    # systemctl stop ceph-osd@<ID>.service
    
    До этого момента данные не теряются.
  4. Для окончательного удаления OSD выполните команду (на узле с удаляемым OSD):
    # pveceph osd destroy <ID> [--cleanup]
    
    Параметр --cleanup уничтожает таблицу разделов на диске.

    Предупреждение

    Эта команда безвозвратно уничтожает все данные на диске, используемом данным OSD.
Пример удаления osd.2:
# ceph osd out 2
marked out osd.2.

# ceph osd ok-to-stop 2
{"ok_to_stop":true,"osds":[2],"num_ok_pgs":0,"num_not_ok_pgs":0}

# systemctl stop ceph-osd@2.service

# pveceph osd destroy 2 --cleanup
destroy OSD osd.2
Remove osd.2 from the CRUSH map
Remove the osd.2 authentication key.
Remove OSD osd.2
…

⁠26.6.6. Пулы Ceph

Пул — это логическая группа для хранения объектов. Каждый пул состоит из групп размещения (PG, Placement Groups), которые распределяют данные по OSD.

⁠26.6.6.1. Создание и редактирование пула

Создавать и редактировать пулы можно как в командной строке, так и в веб-интерфейсе любого узла PVE в разделе Узел → Ceph → Пулы.
Создание пула
При создании пула (а также частично при его редактировании) доступны следующие параметры (в скобках приведены соответствующие опции команды pveceph pool create):
  • Имя — уникальное имя пула (не может быть изменено после создания);
  • Размер (-size) — количество реплик на объект. Ceph всегда пытается поддерживать указанное количество копий каждого объекта (по умолчанию 3);
  • Режим автоматического масштабирования групп размещения — режим автоматического масштабирования PG для пула. При значении warn выводится предупреждение, если количество PG в пуле неоптимально (по умолчанию on);
  • Добавить как хранилище (-add_storages) — автоматическое создание хранилища. Доступно только при создании пула (по умолчанию true);
  • Мин. Размер (-min_size) — минимальное количество реплик, необходимое для записи. Ceph отклонит операции ввода-вывода, если в PG доступно меньше реплик, чем указано (по умолчанию 2);
  • Crush Rule (Crush-правило) (-crush_rule) — правило размещения данных в кластере;
  • # of PGs (Количество PG) (-pg_num) — начальное количество групп размещения (по умолчанию 128);
  • Целевое соотношение (-target_size_ratio) — доля пула в общем объёме кластера. Автомасштабирование PG использует это соотношение относительно других пулов. Параметр имеет приоритет над целевым размером, если заданы оба;
  • Целевой размер (-target_size) — ожидаемый объём данных пула (используется для автомасштабирования);
  • Min # of PGs (Мин. количество PG) (-pg_num_min) — минимальное число PG при автомасштабировании. Используется для задания нижней границы количества PG; autoscaler не будет объединять PG ниже этого значения.

Примечание

Не рекомендуется устанавливать min_size=1, так как это приведёт к потере данных при отказе одного OSD.
Рекомендуется либо включить режим автоматического масштабирования PG (PG autoscaler), либо рассчитать количество PG вручную.
PG autoscaler может автоматически изменять количество PG для пула в фоновом режиме. Установка параметров Целевой размер или Целевое соотношение помогает autoscaler принимать более точные решения.
Команда для создания пула:
# pveceph pool create <pool-name> -add_storages

⁠26.6.6.2. Пулы с коррекцией ошибок (EC)

Erasure coding (EC) — метод коррекции ошибок, применяемый для повышения надёжности и восстановления данных в системах хранения. Основная цель EC — повысить эффективность использования дискового пространства за счёт снижения избыточного копирования данных.
Пулы EC обеспечивают больше полезного пространства по сравнению с реплицированными пулами, однако достигается это за счёт снижения производительности.
В реплицированных пулах хранится несколько полных копий данных (size), тогда как в пулах EC данные разбиваются на k фрагментов данных и m фрагментов кодирования (проверки). Фрагменты кодирования используются для восстановления данных при утрате фрагментов данных.
Количество фрагментов кодирования m определяет, сколько OSD может выйти из строя без потери данных. Общее количество хранимых объектов равно k + m.
Пулы EC создаются с помощью команды pveceph. При их планировании следует учитывать, что они работают иначе, чем реплицированные пулы.
По умолчанию значение min_size для EC-пула зависит от параметра m:
  • если m = 1, min_size = k;
  • если m > 1, min_size = k + 1.
В документации Ceph рекомендуется использовать более консервативное значение min_size = k + 2.
Если доступно меньше OSD, чем указано вmin_size, все операции ввода-вывода в пуле будут заблокированы до восстановления достаточного количества доступных OSD.

Примечание

При планировании EC-пула следует особенно внимательно выбирать min_size, так как он определяет минимальное число доступных OSD, необходимое для работы пула.
Примеры:
  • k = 2, m = 1 → size = 3, min_size = 2 (выдерживает 1 отказ);
  • k = 2, m = 2 → size = 4, min_size = 3 (выдерживает 2 отказа).
Команда для создания EC-пула:
# pveceph pool create <pool-name> --erasure-coding k=<integer> ,m=<integer> \
  [,device-class=<class>] [,failure-domain=<domain>] [,profile=<profile>]
В результате будет создан EC-пул для данных и сопутствующий реплицированный пул для хранения метаданных (<pool name>-data и <pool name>-metada). По умолчанию также создаётся соответствующее хранилище.
Если создание хранилища не требуется, его можно отключить, указав параметр --add_storages 0. При ручной настройке хранилища необходимо задать параметр data-pool, чтобы EC-пул использовался для хранения.

Примечание

Параметры --size, --min_size и --crush_rule применяются только к пулу метаданных. Параметры size и crush_rule нельзя изменить для EC-пулов. Значение min_size для пула данных можно изменить после создания.
Изменить профиль EC после создания пула невозможно — для этого требуется создать новый пул.
Для расширенной настройки EC-профиля его можно создать вручную с помощью инструментов Ceph и указать через параметр profile, например:
# pveceph pool create <pool-name> --erasure-coding profile=<profile-name>
Добавление EC-пула как хранилища:
# pvesm add rbd <storage-name> --pool <replicated-pool> --data-pool <ec-pool>

Примечание

Для внешних кластеров Ceph, не управляемых локальным кластером PVE, необходимо дополнительно указывать параметры keyring и monhost.

⁠26.6.6.3. Удаление пула

Удаление пула в веб-интерфейсе:
  1. Перейдите на вкладку Узел → Ceph → Пулы.
  2. Выберите пул и нажмите кнопку Уничтожить.
  3. Подтвердите удаление, введя имя пула, и нажмите кнопку Удалить.
    Удаление пула
Удаление пула в командной строке:
# pveceph pool destroy <name>
Следующая команда уничтожит OSD (можно указать параметр -cleanup, чтобы дополнительно уничтожить таблицу разделов):
# pveceph osd destroy <ID>
Чтобы также удалить связанное хранилище, следует указать параметр -remove_storages.

Примечание

Удаление пула выполняется в фоновом режиме и может занять некоторое время.

⁠26.6.6.4. Автомасштабирование PG

Модуль pg_autoscaler автоматически подбирает оптимальное количество PG.

Примечание

Активация модуля pg_autoscaler:
# ceph mgr module enable pg_autoscaler
Список загруженных модулей:
# ceph mgr module ls
Автомасштабирование настраивается индивидуально для каждого пула и имеет следующие режимы:
  • warn — выводится предупреждение, если предлагаемое значение pg_num значительно отличается от текущего;
  • on — pg_num настраивается автоматически без ручного вмешательства;
  • off — автоматическая корректировка pg_num отключена, предупреждения не выводятся.
Коэффициенты масштабирования задаются с помощью параметров target_size, target_size_ratio и pg_num_min.
Пример включения автомасштабирования:
# ceph osd pool set <pool> pg_autoscale_mode on

⁠26.6.7. Ceph CRUSH и классы устройств

CRUSH (Controlled Replication Under Scalable Hashing) — алгоритм, определяющий размещение данных в кластере. Он позволяет однозначно вычислить местоположение объекта на основе хеша его имени и карты CRUSH, сформированной с учётом физической и логической структуры кластера.
Карта CRUSH не содержит информации о фактическом расположении данных. Каждый клиент самостоятельно вычисляет путь к объекту, используя CRUSH-алгоритм и актуальную карту, полученную от монитора. При добавлении дисков или выходе узлов из строя карта автоматически обновляется.
Карта CRUSH
Карту CRUSH можно модифицировать, чтобы отражать различные иерархии репликации, например домены отказов, при сохранении равномерного распределения данных.
Ceph автоматически определяет классы устройств (SSD, NVMe) и создаёт для них отдельные теневые деревья. Эти классы можно увидеть в выводе дерева OSD:
# ceph osd crush tree --show-shadow
ID   CLASS  WEIGHT   TYPE NAME
 -6   nvme  0.09760  root default~nvme
 -5   nvme        0      host pve01~nvme
 -9   nvme  0.04880      host pve02~nvme
  1   nvme  0.04880          osd.1
-12   nvme  0.04880      host pve03~nvme
  2   nvme  0.04880          osd.2
 -2    ssd  0.04880  root default~ssd
 -4    ssd  0.04880      host pve01~ssd
  0    ssd  0.04880          osd.0
 -8    ssd        0      host pve02~ssd
-11    ssd        0      host pve03~ssd
 -1         0.14639  root default
 -3         0.04880      host pve01
  0    ssd  0.04880          osd.0
 -7         0.04880      host pve02
  1   nvme  0.04880          osd.1
-10         0.04880      host pve03
  2   nvme  0.04880          osd.2
Чтобы ограничить размещение данных пула определённым классом устройств, необходимо создать соответствующее CRUSH-правило:
# ceph osd crush rule create-replicated <rule-name> <root> <failure-domain> <class>
Где:
  • rule-name — имя правила;
  • root — корень дерева (значение default — корень Ceph);
  • failure-domain — домен отказа, на котором должны распределяться объекты (как правило, host);
  • class — класс устройств (например, nvme, ssd).
Пример создания правила для NVMe-дисков:
# ceph osd crush rule create-replicated my_rule default host nvme
Просмотр существующих правил:
# ceph osd crush rule dump
Назначение правила пулу:
# ceph osd pool set <pool-name> crush_rule <rule-name>

Примечание

Изменение CRUSH-правила для существующего пула приводит к перемещению данных и создаёт дополнительную нагрузку на кластер.

⁠26.6.8. Клиент Ceph

Пулы Ceph могут использоваться для создания хранилищ RBD (см. раздел Ceph RBD).
Для подключения внешнего кластера Ceph:
  1. Скопируйте файл ключа в каталог /etc/pve/priv/ceph/<storage_id>.keyring.
  2. Убедитесь, что имя файла соответствует формату <storage_id>.keyring, где <storage_id> — идентификатор хранилища RBD.

Примечание

Если Ceph развёрнут на узлах PVE, ключи копируются автоматически.

⁠26.6.9. CephFS

CephFS — POSIX-совместимая файловая система, работающая поверх объектного хранилища RADOS. Сервер метаданных (MDS) преобразует объекты RADOS в файлы и каталоги, обеспечивая:
  • кластерную архитектуру;
  • высокую доступность;
  • равномерное распределение нагрузки (в отличие от NFS, где один сервер может стать узким местом).
PVE поддерживает как создание гиперконвергентной CephFS, так и использование существующей CephFS в качестве хранилища для резервных копий, ISO-файлов и шаблонов контейнеров.

⁠26.6.9.1. Сервер метаданных (MDS)

В кластере может быть несколько серверов метаданных (MDS), однако активным в каждый момент времени является только один. При отказе активного MDS управление автоматически передаётся резервному.
Ускорить передачу состояния между активным и резервным MDS можно, используя параметр hotstandby при создании сервера либо, после его создания, установив в соответствующем разделе MDS файла /etc/pve/ceph.conf параметр:
mds standby replay = true
Если этот параметр включён, указанный MDS будет находиться в состоянии warm standby, опрашивая активный сервер, что позволяет быстрее принять управление в случае сбоя.

Примечание

Активный опрос (standby replay) создаёт дополнительную нагрузку на активный MDS и сеть.
⁠ Создание MDS в веб-интерфейсе:
  1. Перейдите на вкладку Узел+Ceph → CephFS.
  2. Нажмите кнопку Создать:
    Создание сервера метаданных Ceph
Создание MDS в командной строке:
# pveceph mds create

⁠26.6.9.2. Создание CephFS

Предварительные требования:
Создание CephFS в веб-интерфейсе:
  1. Перейдите на вкладку Узел+Ceph → CephFS.
  2. Нажмите кнопку Создать CephFS:
    Создание CephFS
Создание CephFS в командной строке:
# pveceph fs create --pg_num 128 --add-storage
В результате будет создана файловая система CephFS с именем cephfs, пул данных cephfs_data со 128 группами размещения и пул метаданных cephfs_metadata с 32 группами размещения.
CephFS

Примечание

Параметр --add-storage (опция Добавить как хранилище) автоматически добавляет CephFS в конфигурацию хранилищ PVE.

⁠26.6.9.3. Удаление CephFS

Предупреждение

Удаление CephFS безвозвратно уничтожает все данные.
Для корректного удаления CephFS выполните следующие шаги:
  1. Отключите всех клиентов, не являющихся узлами PVE (например, размонтируйте CephFS в гостевых системах).
  2. Отключите все связанные записи хранилища CephFS в PVE, чтобы предотвратить автоматическое монтирование.
  3. Удалите все используемые ресурсы из гостевых систем (например, ISO-образы), размещённые на удаляемой CephFS.
  4. Размонтируйте хранилища CephFS на всех узлах кластера:
    # umount /mnt/pve/<STORAGE-NAME>
    
    где <STORAGE-NAME> — имя хранилища CephFS в PVE.
  5. Остановите все MDS (сначала резервные, затем активный):
    # pveceph stop --service mds.NAME
    
    # pveceph mds destroy NAME
    
  6. Уничтожьте CephFS:
    # pveceph fs destroy NAME --remove-storages --remove-pools
    
Это автоматически удалит соответствующие пулы Ceph и записи хранилищ из конфигурации PVE. После удаления резервные MDS можно повторно использовать для других файловых систем.

⁠26.6.10. Техническое обслуживание Ceph

⁠26.6.10.1. Замена OSD

Одной из наиболее распространенных задач технического обслуживания Ceph является замена диска OSD. Если диск уже находится в состоянии сбоя, можно выполнить шаги, описанные в разделе Удаление OSD. Ceph воссоздаст копии данных на оставшихся OSD, если это возможно. Перебалансировка начнётся сразу после обнаружения сбоя или остановки OSD.

Примечание

При настройках по умолчанию (size=3, min_size=2) для восстановления требуется минимум 4 (домен отказа — хост).
Для замены исправного диска через веб-интерфейс следует выполнить шаги, указанные в разделе Удаление OSD. Единственное дополнение — дождаться, пока состояние кластера не станет HEALTH_OK, прежде чем останавливать OSD для его уничтожения.
Замена исправного диска:
  1. Выведите OSD из кластера:
    # ceph osd out osd.<id>
    
  2. Дождитесь состояния HEALTH_OK.
  3. Проверьте возможность удаления:
    # ceph osd safe-to-destroy osd.<id>
    
  4. Остановите и удалите OSD:
    # systemctl stop ceph-osd@<id>.service
    # pveceph osd destroy <id>
    
Замените диск новым (того же типа и размера) и выполните процедуру, описанную в разделе Создание OSD.
После завершения автоматической перебалансировки состояние кластера должно вернуться к HEALTH_OK. Оставшиеся отчёты об авариях можно подтвердить командой:
# ceph crash archive-all

⁠26.6.10.2. Trim/Discard

Рекомендуется регулярно запускать fstrim (discard) на ВМ и контейнерах. Это освобождает блоки данных, которые файловая система больше не использует, снижая нагрузку на ресурсы хранения.
Большинство современных ОС выполняют discard автоматически. Необходимо лишь убедиться, что для ВМ включена опция Discard (Отклонить).

⁠26.6.10.3. Очистка (scrubbing)

Ceph обеспечивает целостность данных, выполняя очистку (scrubbing) групп размещения. В ходе этой операции проверяется работоспособность каждого объекта в PG.
По умолчанию Ceph выполняет проверки:
  • ежедневно — метаданные;
  • еженедельно — контрольные суммы данных.

Примечание

Если очистка влияет на производительность, можно настроить расписание с помощью параметров:
osd scrub begin hour = 2
osd scrub end hour = 6

⁠26.6.11. Мониторинг и устранение неполадок Ceph

Рекомендуется регулярно проверять состояние кластера Ceph с помощью:
  • встроенных инструментов Ceph;
  • API и веб-интерфейса PVE.
Команды для проверки состояния кластера:
# watch ceph -s # постоянный мониторинг (обновление каждые 2 сек)
# ceph --watch # однократный вывод + поток событий
Состояния кластера:
  • HEALTH_OK — кластер в исправном состоянии;
  • HEALTH_WARN — имеются предупреждения;
  • HEALTH_ERR — обнаружены ошибки.
Если кластер находится в неработоспособном состоянии, указанные команды позволят просмотреть текущие события и получить рекомендации по дальнейшим действиям.

Примечание

Для остановки выполнения команды нажмите Ctrl+C.

⁠26.6.11.1. Устранение неполадок

Логи на проблемном узле:
  • системные логи (за последние 2 дня):
    # journalctl --since "2 days ago"
    
    или в веб-интерфейсе: Система → Системный журнал;
  • логи IPMI и RAID-контроллеров — через интерфейс соответствующего оборудования.
Аварии служб Ceph:
  • просмотр списка зарегистрированных аварий:
    # ceph crash ls
    
  • подробная информация об аварии:
    # ceph crash info <ID_аварии>
    
  • подтверждение обработки всех аварий:
    # ceph crash archive-all
    
Подробные журналы служб Ceph находятся в /var/log/ceph/. Уровень детализации журналов можно настроить в конфигурации Ceph.

⁠26.6.11.2. Типичные проблемы Ceph

⁠

Таблица 26.5. Возможные причины проблем

Категория
Примеры
Сетевые проблемы
Перегрузка сети, неисправный коммутатор, отключённый интерфейс, блокировка брандмауэром
Проблемы с дисками
Неисправные диски, ненадёжное подключение, недостаточная производительность (HDD, потребительские контроллеры)
Несоответствие рекомендациям
Нарушение требований к оборудованию или конфигурации Ceph
⁠26.6.11.2.1. OSD не работают/зависают
Неисправный OSD помечается как down, а примерно через 10 минут — как out. В некоторых случаях OSD может автоматически вернуться в рабочее состояние.
Ручное восстановление:
  • в веб-интерфейсе: Любой узел → Ceph → OSD → выбрать OSD → кнопки Запуск, In, Перезагрузить.
  • в консоли (на проблемном узле):
    # ceph-volume lvm activate --all
    
Для восстановления неисправного OSD может потребоваться безопасная перезагрузка соответствующего узла или, в крайнем случае, повторное создание либо замена OSD.

⁠26.6.12. Остановка кластера PVE + Ceph HCI

Для корректной остановки всего кластера PVE + Ceph выполните следующие действия:
  1. Остановите все клиенты Ceph:
    • ВМ и контейнеры;
    • дополнительные клиенты, использующие Ceph FS или RADOS Gateway (если применимо).

    Примечание

    Высокодоступные ВМ перейдут в состояние «остановлено» при выключении через инструменты PVE.
  2. Убедитесь, что кластер Ceph находится в исправном состоянии (через веб-интерфейс или CLI):
    # ceph -s
  3. Включите флаг noout, чтобы избежать ненужных операций восстановления при остановке и последующем запуске кластера:
    # ceph osd set noout
    Также флаг можно включить через веб-интерфейс (Ceph → OSD → Manage Global Flags):
    Управление глобальными флагами Ceph
  4. Выключите узлы в следующем порядке:
    • сначала — узлы без мониторов (MON);
    • затем — узлы с мониторами.
Запуск кластера:
  1. Включите узлы в обратном порядке:
    • сначала — узлы с мониторами (MON);
    • затем — узлы без мониторов.
  2. После полного запуска убедитесь, что все службы Ceph работают. Единственное допустимое предупреждение должно быть связано с флагом noout.
  3. Отключите флаг noout:
    # ceph osd unset noout
    Или через веб-интерфейс (Ceph → OSD → Manage Global Flags).
  4. Запустите ВМ и контейнеры.

⁠Глава 27. Репликация хранилища

Репликация хранилища в PVE позволяет создавать реплики дисков ВМ и контейнеров на других узлах кластера без использования общего хранилища. Репликация упрощает восстановление гостевых систем после отказа узла и может сокращать время последующей миграции. Поскольку репликация выполняется по расписанию, изменения, внесённые после последней успешной синхронизации, могут быть потеряны.
Управление репликацией осуществляется с помощью утилиты командной строки pvesr.
Репликация использует моментальные снимки ZFS: после первоначальной полной синхронизации передаются только изменения, накопленные с момента предыдущей синхронизации.
Репликация выполняется автоматически по настраиваемому расписанию. Минимальный интервал составляет одну минуту, максимальный — одну неделю. Формат расписания представляет собой подмножество формата календарных событий systemd (см. раздел Формат расписания).
Для одной гостевой системы можно настроить репликацию на несколько целевых узлов, но не более одного задания для каждого целевого узла. При необходимости можно ограничить скорость передачи данных, чтобы уменьшить нагрузку на хранилище и сеть.
Если гостевая система мигрирует на узел, куда уже настроена репликация, то при последующей миграции (например, обратно) передаются только изменения с момента последней синхронизации. Это значительно ускоряет процесс. Направление репликации автоматически переключается, если гостевая система мигрировала на целевой узел репликации.
Например, если ВМ с идентификатором 100 размещена на узле pve02 и реплицируется на узел pve03, то после миграции ВМ на узел pve03 направление репликации автоматически изменяется: данные реплицируются с узла pve03 на узел pve02.
Если гостевая система мигрирует на узел, не указанный в качестве целевого ни в одном задании репликации, существующие задания репликации сохраняются. Репликация на настроенные целевые узлы продолжается с учётом текущего размещения гостевой системы и состояния заданий.

Примечание

Репликацию можно использовать совместно с механизмами высокой доступности (HA). Однако при отказе узла возможна потеря данных, изменённых после последней успешной синхронизации.
Репликация поддерживается только для хранилищ типа zfspool (Локальный ZFS).
Для использования репликации должны быть выполнены следующие условия:
  • исходный и целевой узлы входят в один кластер;
  • все диски ВМ или контейнера размещены в хранилище ZFS;
  • на исходном и целевом узлах настроены ZFS-хранилища с одинаковым идентификатором (именем);
  • на целевом узле достаточно свободного места для размещения реплики.

⁠27.1. Настройка сети репликации

По умолчанию трафик репликации передаётся через ту же сеть, которая используется для миграции гостевых систем. Если сеть миграции не настроена, используется сеть управления узлами.
При необходимости для трафика репликации можно выделить отдельную подсеть и настроить соответствующие сетевые интерфейсы на узлах кластера.
Настроить сеть репликации можно двумя способами:
  • через веб-интерфейс (Центр обработки данных → Параметры → Параметры репликации → Редактировать):
    Настройка сети репликации
  • в файле /etc/pve/datacenter.cfg, добавив параметр:
    replication: network=10.10.10.150/24,type=secure
В параметре network указывается подсеть в формате CIDR. Параметр type=secure означает использование SSH-туннеля для передачи данных репликации.

Важно

На каждом узле кластера должны быть настроены сетевые интерфейсы, обеспечивающие связь с использованием адресов из указанной подсети. Выделенная сеть должна обеспечивать достаточную пропускную способность и низкую задержку.
После настройки сети репликация будет автоматически использовать интерфейсы с IP-адресами из соответствующей подсети.

⁠27.2. Управление заданиями

Управлять заданиями репликации можно как в веб-интерфейсе, так и с помощью инструмента командной строки (CLI) pvesr.
Панель репликации можно найти на всех уровнях (центр обработки данных, узел, ВМ/CT). В зависимости от уровня на панели репликации отображаются все задания (центр обработки данных) или задания, специфичные для узла или гостевой системы.
Список заданий репликации узла pve02
Добавление нового задания репликации в веб-интерфейсе:
  1. Перейти в раздел Репликация (центра обработки данных, узла, ВМ или контейнера, для которых настраивается репликация).
  2. Нажать кнопку Добавить.
  3. В открывшемся окне указать:
    • CT/VM ID — идентификатор гостевой системы (если он ещё не выбран);
    • Цель — целевой узел;
    • Расписание — расписание репликации;
    • Ограничение скорости (MB/s) — максимальная скорость передачи данных при репликации (необязательный параметр);
  4. Нажать кнопку Создать.
Создание задания репликации
Каждое задание имеет уникальный идентификатор, состоящий из идентификатора гостевой системы и номера задания, разделённых дефисом (<VMID>-<номер задания>). При использовании CLI идентификатор указывается вручную.
Примеры работы с заданиями репликации в командной строке:
  • создать задание репликации для ВМ 214 с репликацией каждые 10 минут и ограничением скорости передачи данных 10 МБ/с:
    # pvesr create-local-job 214-0 pve03 --schedule "*/10" --rate 10
    
  • отключить активное задание с идентификатором 214-0:
    # pvesr disable 214-0
    
  • просмотреть список заданий репликации:
    # pvesr list
    JobID                Target                 Schedule  Rate  Enabled
    213-0                local/pve02              */1:00     -      yes
    214-0                local/pve03                */10    10       no
    
  • просмотреть состояние заданий репликации:
    # pvesr status
    JobID     Enabled    Target                      LastSync             NextSync   Duration  FailCount State
    213-0     Yes        local/pve02      2025-02-26_10:10:48  2025-02-26_11:00:00   2.455654          0 OK
    
  • включить задание:
    # pvesr enable 214-0
    
  • изменить расписание на один раз в час:
    # pvesr update 214-0 --schedule '*/1:00'
    

⁠27.3. Обработка ошибок

При возникновении ошибки задание репликации приостанавливается, и повторные попытки выполняются каждые 30 минут. После успешной синхронизации расписание восстанавливается.
Типичные причины ошибок:
  • проблемы с сетью;
  • недостаточно места в целевом хранилище репликации;
  • на целевом узле недоступно хранилище с тем же идентификатором.

Примечание

Подробную информацию об ошибке можно найти в журнале репликации.

⁠27.4. Восстановление после отказа узла

Если исходный узел вышел из строя и восстановить его работоспособность невозможно, гостевые системы, для которых имеются актуальные реплики на другом узле, можно запустить на целевом узле. Перед выполнением операций необходимо убедиться, что исходный узел не выполняет гостевые системы и не сможет одновременно возобновить их работу. Восстановление выполняется вручную и требует проверки состояния кластера, кворума, конфигурации гостевых систем и доступности реплицированных дисков.
Пример: ВМ 100 и контейнер 200 работают на узле pve02 и реплицируются на узел pve03. Узел pve02 вышел из строя и не может вернуться в сеть. Нужно вручную перенести гостевые системы на узел pve03:
  1. Подключиться к узлу pve03 по SSH или открыть его оболочку в веб-интерфейсе.
  2. Проверить состояние кластера:
    # pvecm status
    Если кворум потерян, настоятельно рекомендуется сначала восстановить кворум и снова сделать узел работоспособным. Только если в данный момент это невозможно, можно временно установить ожидаемое число узлов:
    # pvecm expected 1

    Примечание

    Этот режим крайне опасен: в нём запрещено вносить любые изменения в конфигурацию кластера (добавлять и удалять узлы, ВМ, хранилища). Этот режим можно использовать только для запуска критически важных гостевых систем или восстановления кворума.
  3. Переместить конфигурационные файлы с узла pve02 на узел pve03:
    # mv /etc/pve/nodes/pve02/qemu-server/100.conf /etc/pve/nodes/pve03/qemu-server/100.conf
    # mv /etc/pve/nodes/pve02/lxc/200.conf /etc/pve/nodes/pve03/lxc/200.conf
    
  4. Запустить гостевые системы:
    # qm start 100
    # pct start 200
    

⁠Глава 28. Сетевая подсистема

В PVE v9 для управления сетью используется сетевая подсистема ifupdown2.

Примечание

В ОС «Альт Виртуализация» 10.x (на базе PVE v7) использовалась сетевая подсистема etcnet. При обновлении системы с платформы p10 (PVE v7) до p11 (PVE v9) необходимо установить пакет ifupdown2, отключить etcnet и включить ifupdown2 и перезагрузить узел:
# apt-get install ifupdown2
# systemctl disable network
# systemctl mask network
# systemctl enable networking.service
# reboot
PVE использует сетевой стек Linux, что обеспечивает большую гибкость в настройке сети на узлах PVE. Настроить сеть можно через веб-интерфейс PVE (Хост → Система → Сеть) или вручную, отредактировав файл /etc/network/interfaces, в котором хранится конфигурация сети.
Сетевые интерфейсы узла pve01

Примечание

Подробнее о настройках в файле /etc/network/interfaces см. в man interfaces(5)

Примечание

В типовой конфигурации интерфейс vmbr0 используется для подключения гостевых систем к базовой физической сети. Это мост Linux, который можно рассматривать как виртуальный коммутатор, к которому подключены гостевые системы и физические интерфейсы.
Ниже приведены примеры настройки сети. Для организации более сложных виртуальных сетей в кластерах PVE используется программно-определяемая сеть (см. Программно-определяемые сети (SDN)).

⁠28.1. Применение изменений сетевых настроек

Все изменения конфигурации сети, выполненные в веб-интерфейсе PVE, не записываются напрямую в файл /etc/network/interfaces. Сначала они сохраняются во временный файл /etc/network/interfaces.new, что позволяет выполнить несколько связанных изменений одновременно. Такой подход также позволяет убедиться в корректности конфигурации, поскольку ошибочные сетевые настройки могут сделать узел недоступным.
Чтобы применить изменения сетевых настроек, выполненные в веб-интерфейсе PVE, следует нажать кнопку Применить конфигурацию. В результате содержимое файла interfaces.new будет перенесено в файл /etc/network/interfaces, а изменения будут применены без перезагрузки узла.
Если изменения вносились непосредственно в файл /etc/network/interfaces, применить их можно, выполнив команду:
# ifreload -a
Ещё один способ применить новую конфигурацию сети — перезагрузить узел. В этом случае служба systemd pvenetcommit активирует файл interfaces.new до запуска сетевой службы, которая затем применит конфигурацию.

Предупреждение

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

⁠28.2. Имена сетевых устройств

В PVE используются следующие соглашения об именах устройств:
  • Ethernet-устройства — en* (предсказуемые имена сетевых интерфейсов systemd);
  • мосты — обычно vmbrN, где 0 ≤ N ≤ 4094 (от vmbr0 до vmbr4094) допускается также использовать другие имена длиной не более 10 символов, состоящие из букв и цифр и начинающиеся с буквы;
  • агрегированные интерфейсы (bond) — bondN, где N ≥ 0 (bond0, bond1, …);
  • VLAN-интерфейсы — номер VLAN добавляется к имени устройства через точку (например, eno1.50, bond1.30).
Systemd использует префикс en для сетевых устройств Ethernet. Следующие символы зависят от драйвера устройства и того, какая схема именования применяется первой:
  • o<index>[n<phys_port_name>|d<dev_port>] — встроенные устройства;
  • s<slot>[f<function>][n<phys_port_name>|d<dev_port>] — устройства, определяемые по идентификатору слота (горячее подключение);
  • [P<domain>]p<bus>s<slot>[f<function>][n<phys_port_name>|d<dev_port>] — устройства, определяемые по идентификатору шины;
  • x<MAC> — устройство, именуемое по MAC-адресу.
Наиболее распространенные шаблоны:
  • eno1 — первая встроенная сетевая карта;
  • enp0s3 — сетевая карта на PCI-шине 0, слот 3;
  • enp3s0f1 — сетевая карта на PCI-шине 3, слот 0, функция 1.

⁠28.3. Конфигурирование сети в PVE

Новый сетевой интерфейс
Виды сетевых соединений в PVE:
  • Linux Bridge — способ соединения двух сегментов Ethernet на канальном уровне;
  • Linux Bond — реализация агрегации нескольких сетевых интерфейсов в единый логический интерфейс (bond) средствами ядра Linux;
  • Linux VLAN — реализация VLAN средствами ядра Linux.
  • OVS Bridge — реализация моста на базе Open vSwitch. Мосты Open vSwitch могут включать физические устройства Ethernet, а также виртуальные интерфейсы OVSBond или OVSIntPort. Такие мосты могут передавать несколько VLAN и разделяться на «внутренние порты» для использования в качестве VLAN-интерфейсов на хосте. Все интерфейсы, входящие в мост, должны быть перечислены в параметре ovs_ports;
  • OVS Bond — реализация агрегации сетевых интерфейсов на базе Open vSwitch. Отличается от Linux Bond поддерживаемыми режимами балансировки нагрузки;
  • OVS IntPort — виртуальный сетевой интерфейс, предназначенный для взаимодействия узла PVE с определённой VLAN через OVS-мост.

Важно

Не следует смешивать Linux Bridge, Linux Bond и интерфейсы Open vSwitch (OVS) в одной сетевой схеме без предварительной проверки совместимости. Физические сетевые интерфейсы, режимы агрегации и мосты должны быть настроены в соответствии с выбранной сетевой подсистемой. Перед применением конфигурации необходимо проверить совместимость используемых интерфейсов, режимов агрегации и мостов, а также соответствие настройки физического коммутатора выбранной схеме.

⁠28.4. Конфигурация сети с использованием моста

Сетевой мост (bridge) — это программный аналог физического коммутатора уровня L2. Мост объединяет виртуальные и физические интерфейсы в единый широковещательный домен и позволяет ВМ и контейнерам взаимодействовать друг с другом и с внешней сетью.
Все виртуальные системы могут использовать один общий мост. При необходимости можно создать несколько мостов для организации отдельных сетевых доменов. На каждом узле кластера можно создать до 4094 мостов.

⁠28.4.1. Конфигурация с одним мостом

По умолчанию после установки на каждом узле PVE создаётся один мост (vmbr0), связанный с физическим сетевым интерфейсом, выбранным на этапе установки системы:
Узлы PVE с мостом vmbr0
При такой конфигурации ВМ ведут себя так, как если бы они были напрямую подключены к физической сети. Каждая ВМ будет видна в сети со своим MAC-адресом.
Соответствующая конфигурация в /etc/network/interfaces может выглядеть следующим образом:
auto lo
iface lo inet loopback

iface eno1 inet manual

iface enp0s20f0u1 inet manual

auto vmbr0
iface vmbr0 inet static
        address 192.168.0.186/24
        gateway 192.168.0.1
        bridge-ports eno1
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094
        dns-nameservers 8.8.8.8

⁠28.4.2. Внутренняя сеть для ВМ

Если необходимо объединить несколько ВМ во внутреннюю изолированную сеть, можно создать дополнительный мост.
Для создания моста в разделе Сеть необходимо нажать кнопку Создать и в раскрывающемся списке выбрать пункт Linux Bridge или OVS Bridge:
Создать мост
В открывшемся окне в поле Имя следует указать имя моста и нажать кнопку Создать:
PVE. Создание Linux Bridge
Создание моста Open vSwitch отличается возможностью указания дополнительных параметров Open vSwitch (поле Параметры OVS):
PVE. Создание OVS Bridge

Примечание

IP-адрес мосту можно не назначать. В этом случае мост будет выполнять функции коммутатора уровня L2, обеспечивая обмен трафиком между подключёнными к нему интерфейсами. Если же указать IPv4 и/или IPv6-адрес, он будет назначен самому мосту и станет доступен через интерфейсы, перечисленные в поле Порты сетевого моста.
Для применения изменений следует нажать кнопку Применить конфигурацию.
После этого мост (например, vmbr1) можно назначать ВМ:
PVE. Назначение моста vmbr1 ВМ

⁠28.5. Объединение (агрегация) интерфейсов

Объединение (агрегация) интерфейсов (bonding) — это объединение двух и более сетевых интерфейсов в один логический интерфейс (bondX) для обеспечения отказоустойчивости или увеличения пропускной способности. Поведение логического интерфейса определяется выбранным режимом работы.
Агрегация сетевых интерфейсов позволяет повысить отказоустойчивость сетевого подключения и, в зависимости от режима агрегации и характера нагрузки, увеличить суммарную пропускную способность. Это может сократить время онлайн-миграции виртуальных машин и репликации данных между узлами кластера.
Кластерную сеть (Corosync) рекомендуется настраивать с использованием нескольких независимых сетей. При этом Corosync не требует агрегации интерфейсов для резервирования, поскольку поддерживает собственный механизм переключения между сетями.

⁠28.5.1. Параметры Linux Bond

⁠

Таблица 28.1. Режимы агрегации Linux Bond

Режим
Название
Описание
Отказоустойчивость
Балансировка нагрузки
balance-rr или mode=0
Round-robin
Режим циклического выбора активного интерфейса для трафика. Пакеты последовательно передаются и принимаются через каждый интерфейс один за другим. Данный режим не требует применения специальных коммутаторов.
Да
Да
active-backup или mode=1
Active Backup
В этом режиме активен только один интерфейс, остальные находятся в режиме горячей замены. Если активный интерфейс выходит из строя, его заменяет резервный. MAC-адрес интерфейса виден извне только на одном сетевом адаптере, что предотвращает путаницу в сетевом коммутаторе. Это самый простой режим, работает с любым оборудованием, не требует применения специальных коммутаторов.
Да
Нет
balance-xor или mode=2
XOR
Один и тот же интерфейс работает с определённым получателем. Передача пакетов распределяется между интерфейсами на основе формулы ((MAC-адрес источника) XOR (MAC-адрес получателя)) % число интерфейсов. Режим не требует применения специальных коммутаторов. Этот режим обеспечивает балансировку нагрузки и отказоустойчивость.
Да
Да
broadcast или mode=3
Широковещательный
Трафик идёт через все интерфейсы одновременно.
Да
Нет
LACP (802.3ad) или mode=4
Агрегирование каналов по стандарту IEEE 802.3ad
В группу объединяются одинаковые по скорости и режиму интерфейсы. Все физические интерфейсы используются одновременно в соответствии со спецификацией IEEE 802.3ad. Для реализации этого режима необходима поддержка на уровне драйверов сетевых карт и коммутатор, поддерживающий стандарт IEEE 802.3ad (коммутатор требует отдельной настройки).
Да
Да
balance-tlb или mode=5
Адаптивная балансировка нагрузки при передаче
Исходящий трафик распределяется в соответствии с текущей нагрузкой (с учетом скорости) на интерфейсах (для данного режима необходима его поддержка в драйверах сетевых карт). Входящие пакеты принимаются только активным сетевым интерфейсом.
Да
Да (исходящий трафик)
balance-alb или mode=6
Адаптивная балансировка нагрузки
Включает в себя балансировку исходящего трафика, плюс балансировку на приём (rlb) для IPv4 трафика и не требует применения специальных коммутаторов (балансировка на приём достигается на уровне протокола ARP, перехватом ARP ответов локальной системы и перезаписью физического адреса на адрес одного из сетевых интерфейсов, в зависимости от загрузки).
Да
Да
В следующей таблице приведены алгоритмы выбора каналов (распределения пакетов между физическими каналами, входящими в многоканальное соединение) для режимов balance-xor и 802.3ad (значение параметра xmit_hash_policy).
⁠

Таблица 28.2. Режимы выбора каналов при организации балансировки нагрузки

Режим
Описание
layer2
Канал для отправки пакета однозначно определяется комбинацией MAC-адреса источника и MAC-адреса назначения. Весь трафик между определённой парой узлов всегда идёт по определённому каналу. Алгоритм совместим с IEEE 802.3ad. Этот режим используется по умолчанию.
layer2+3
Канал для отправки пакета определяется по совокупности MAC- и IP-адресов источника и назначения. Трафик между определённой парой IP-хостов всегда идёт по определённому каналу (обеспечивается более равномерная балансировка трафика, особенно в случае, когда большая его часть передаётся через промежуточные маршрутизаторы). Для протоколов сетевого уровня, отличных от IP, данный алгоритм равносилен layer2. Алгоритм совместим с IEEE 802.3ad.
layer3+4
Канал для отправки пакета определяется по совокупности IP-адресов и номеров портов источника и назначения (трафик определённого узла может распределяться между несколькими каналами, но пакеты одного и того же TCP/UDP-соединения всегда передаются по одному и тому же каналу). Для фрагментированных пакетов TCP и UDP, а также для всех прочих протоколов 4 уровня, учитываются только IP-адреса. Для протоколов 3 уровня, отличных от IP, данный алгоритм равносилен layer2. Алгоритм не полностью совместим с IEEE 802.3ad.

⁠28.5.2. Параметры OVS Bond

⁠

Таблица 28.3. Параметры OVS Bond

Параметр
Описание
bond_mode=active-backup
Обеспечивает переключение между активным и резервным интерфейсами: при отказе активного соединения резервный сетевой интерфейс начинает передавать и принимать сетевой трафик. Физическому коммутатору представляется только один MAC-адрес. Режим не требует специальной поддержки или настройки коммутатора и позволяет подключать каналы к разным коммутаторам. Балансировка нагрузки в этом режиме не выполняется
bond_mode=balance-slb
Распределяет потоки трафика на основе MAC-адреса источника и выходного идентификатора VLAN, периодически перераспределяя их при изменении характера трафика. Режим balance-slb обеспечивает ограниченную балансировку нагрузки без необходимости поддержки или участия удалённого коммутатора. Параметр bond-rebalance-interval определяет, как часто OVS должен выполнять измерение нагрузки трафика
bond_mode=balance-tcp
Обеспечивает балансировку нагрузки с учётом данных уровней 2–4 модели OSI, например MAC-адреса назначения, IP-адреса и TCP-порта. Кроме того, для работы balance-tcp необходимо настроить протокол LACP на коммутаторе. Этот режим аналогичен режиму mode=4 Linux Bond. По возможности рекомендуется использовать balance-tcp, поскольку LACP обеспечивает наиболее надёжное обнаружение отказов каналов связи и предоставляет дополнительные диагностические сведения об агрегированном интерфейсе.
lacp=[active|passive|off]
Управляет поведением протокола управления агрегацией каналов (LACP). На коммутаторе должен быть настроен протокол LACP. Если коммутатор не поддерживает LACP, необходимо использовать bond_mode=balance-slb или bond_mode=active-backup.
other-config:lacp-fallback-ab=true
Позволяет использовать режим bond_mode=active-backup в качестве резервного, если коммутатор временно не поддерживает LACP
other_config:lacp-time=[fast|slow]
Управляет частотой отправки LACP-пакетов (heartbeat): каждую секунду (fast) или каждые 30 секунд (slow). По умолчанию slow
other_config:bond-detect-mode=[miimon|carrier]
Режим обнаружения состояния канала связи: проверка с помощью механизма miimon (периодической проверки состояния канала) или мониторинг несущего сигнала (carrier)
other_config:bond-miimon-interval=100
Если используется miimon, задаёт интервал проверки состояния канала связи в миллисекундах
other_config:bond_updelay=1000
Время в миллисекундах, в течение которого канал связи должен оставаться активным, прежде чем он будет задействован. Параметр позволяет предотвратить частые переключения состояния канала
other_config:bond-rebalance-interval=10000
Интервал в миллисекундах между перераспределениями потоков трафика между физическими интерфейсами, входящими в состав агрегированного интерфейса (bond). Значение 0 отключает перераспределение. По умолчанию 10 секунд

⁠28.5.3. Агрегированный bond-интерфейс с фиксированным IP-адресом

Агрегированный bond-интерфейс с фиксированным IP-адресом
Конфигурация с агрегированным bond-интерфейсом с фиксированным IP-адресом может использоваться, например,для сети хранения. Преимущества такой конфигурации:
  • увеличенная пропускная способность;
  • отказоустойчивость;
  • снижение задержек при доступе к общему хранилищу.
Для настройки Linux Bond необходимо выполнить следующие действия:
  1. Перейти в раздел Сеть, нажать кнопку Создать и в раскрывающемся списке выбрать пункт Linux Bond:
    Создать Linux Bond
  2. В открывшемся окне:
    • указать имя агрегированного интерфейса;
    • в списке Режим выбрать режим агрегации (например, balance-rr);
    • в поле Устройства указать сетевые интерфейсы, которые будут входить в объединение;
    • в поле IPv4/CIDR указать IP-адрес объединения;
    • нажать кнопку Создать:
    Редактирование параметров объединения bond0

    Примечание

    В зависимости от выбранного режима агрегации набор доступных параметров может отличаться.
  3. Для применения изменений нажать кнопку Применить конфигурацию.
Получившаяся конфигурация:
Агрегированный bond-интерфейс с фиксированным IP-адресом
Настройка Linux Bond в файле /etc/network/interfaces:
auto lo
iface lo inet loopback

iface enp0s3 inet manual

auto enp0s9
iface enp0s9 inet manual

auto enp0s8
iface enp0s8 inet manual

auto bond0
iface bond0 inet static
        address 192.168.200.20/24
        bond-slaves enp0s8 enp0s9
        bond-miimon 100
        bond-mode balance-rr

auto vmbr0
iface vmbr0 inet static
        address 192.168.0.90/24
        gateway 192.168.0.1
        bridge-ports enp0s3
        bridge-stp off
        bridge-fd 0
        dns-nameservers 8.8.8.8

⁠28.5.4. Агрегированный bond-интерфейс в качестве порта моста

Чтобы обеспечить отказоустойчивость гостевой сети, можно использовать bond-интерфейс непосредственно в качестве порта сетевого моста:
Агрегированный bond-интерфейс в качестве порта моста
Для настройки Linux Bond необходимо выполнить следующие действия:
  1. Перейти в раздел Сеть, выбрать существующий мост vmbr0 и нажать кнопку Редактировать:
    Мост vmbr0
  2. В открывшемся окне очистить поле Порты сетевого моста и нажать кнопку ОК:
    Редактирование параметров моста vmbr0
  3. Нажать кнопку Создать и в раскрывающемся списке выбрать пункт Linux Bond.
  4. В открывшемся окне:
    • в списке Режим выбрать режим агрегации (например, LACP);
    • в поле Устройства указать сетевые интерфейсы, которые будут входить в объединение;
    • при необходимости выбрать политику хеширования в списке Политика хеширования;
    • нажать кнопку Создать:
    Редактирование параметров объединения bond0

    Примечание

    В зависимости от выбранного режима агрегации набор доступных параметров может отличаться.
  5. Выбрать мост vmbr0 и нажать кнопку Редактировать.
  6. В поле Порты сетевого моста указать bond0 и нажать кнопку ОК:
    Редактирование параметров моста vmbr0
  7. Для применения изменений нажать кнопку Применить конфигурацию.
Получившаяся конфигурация:
bond в качестве порта моста
Настройка Linux Bond в качестве порта моста в файле /etc/network/interfaces:
auto lo
iface lo inet loopback

auto enp0s3
iface enp0s3 inet manual

auto enp0s9
iface enp0s9 inet manual

auto enp0s8
iface enp0s8 inet manual

auto bond0
iface bond0 inet manual
        bond-slaves enp0s3 enp0s8
        bond-miimon 100
        bond-mode 802.3ad
        bond-xmit-hash-policy layer2+3

auto vmbr0
iface vmbr0 inet static
        address 192.168.0.90/24
        gateway 192.168.0.1
        bridge-ports bond0
        bridge-stp off
        bridge-fd 0
        dns-nameservers 8.8.8.8
Для настройки OVS Bond необходимо выполнить следующие действия:
  1. Перейти в раздел Сеть, выбрать существующий мост vmbr0 и нажать кнопку Редактировать:
    Мост vmbr0
  2. В открывшемся окне очистить поле Порты сетевого моста и нажать кнопку ОК:
    Редактирование параметров моста vmbr0
  3. Нажать кнопку Создать и выбрать пункт OVS Bond.
  4. В открывшемся окне:
    • указать имя агрегированного интерфейса;
    • в списке Режим выбрать режим агрегации;
    • в поле Устройства указать сетевые интерфейсы, которые будут входить в объединение;
    • в списке OVS Bridge выбрать мост, в который должен быть добавлен созданный интерфейс;
    • нажать кнопку Создать:
    Редактирование параметров OVS Bond
  5. Для применения изменений нажать кнопку Применить конфигурацию.
Получившаяся конфигурация:
OVS Bond в качестве порта моста
Настройка OVS Bond в качестве порта моста в файле /etc/network/interfaces:
auto lo
iface lo inet loopback

auto enp0s3
iface enp0s3 inet manual

auto enp0s9
iface enp0s9 inet manual

auto enp0s8
iface enp0s8 inet manual

auto bond0
iface bond0 inet manual
        ovs_bonds enp0s3 enp0s8
        ovs_type OVSBond
        ovs_bridge vmbr0
        ovs_options bond_mode=balance-slb

auto vmbr0
iface vmbr0 inet static
        address 192.168.0.90/24
        gateway 192.168.0.1
        ovs_type OVSBridge
        ovs_ports bond0
Проверка конфигурации:
# ovs-vsctl show
20dc0ada-cbb5-4518-a437-0bd6909d088a
    Bridge vmbr0
        Port vmbr0
            Interface vmbr0
                type: internal
        Port bond0
            Interface enp0s3
            Interface enp0s8
    ovs_version: "3.3.2"

⁠28.6. Настройка VLAN

Виртуальные локальные сети (VLAN) — это сетевой стандарт IEEE 802.1Q, позволяющий создавать логически изолированные сегменты сети на одном физическом интерфейсе для разделения трафика между разными сетями. Каждая VLAN идентифицируется уникальным тегом (ID от 1 до 4094).

Примечание

На стороне физического коммутатора порт должен быть настроен в режиме trunk — по нему должен передаваться тегированный трафик 802.1Q.
Если на коммутаторе настроена агрегация портов (Port-Channel или EtherChannel), передачу тегированного трафика VLAN необходимо настроить на соответствующем логическом агрегированном интерфейсе коммутатора в соответствии с его конфигурацией.
Теги VLAN можно применять к любому сетевому устройству (NIC, Bond, Bridge). Рекомендуется настраивать VLAN на интерфейсе с минимальным уровнем абстракции.

⁠28.6.1. Мост с поддержкой VLAN

PVE поддерживает настройку VLAN для гостевых систем «из коробки». Тег VLAN указывается при создании ВМ и становится частью конфигурации её сетевого интерфейса.
Если используется Linux Bridge, для возможности применения тегов VLAN в настройках ВМ необходимо включить поддержку VLAN для моста. Для этого в веб-интерфейсе в настройках моста следует установить отметку в поле Поддержка VLAN:
Настройка сетевой конфигурации vmbr1
Если используется OVS Bridge, дополнительные настройки не требуются.
Тег VLAN можно указать в настройках сетевого интерфейса при создании ВМ либо отредактировав параметры уже созданного сетевого устройства:
Тег VLAN в настройках сетевого интерфейса ВМ

⁠28.6.2. Мост на VLAN

Можно создать конфигурацию VLAN вида <интерфейс>.<vlan tag> (например, enp0s8.100), затем включить этот VLAN-интерфейс в Linux Bridge и указать данный мост в настройках сетевого интерфейса ВМ.
Для создания такой конфигурации необходимо выполнить следующие действия:
  1. Перейти в раздел Сеть, нажать кнопку Создать и в раскрывающемся списке выбрать пункт Linux VLAN:
    Создать Linux VLAN
  2. В открывшемся окне в поле Имя указать имя интерфейса с добавлением номера VLAN и нажать кнопку Создать:
    Настройка VLAN с ID 100 на интерфейсе enp0s8
  3. В разделе Сеть нажать кнопку Создать и в раскрывающемся списке выбрать пункт Linux Bridge:
    Создать Linux VLAN
  4. В открывшемся окне:
    • указать имя моста;
    • в поле Порты сетевого моста указать интерфейс VLAN;
    • в поле IPv4/CIDR ввести IP-адрес моста;
    • нажать кнопку Создать:
    Настройка Ethernet-моста vmbr1
  5. Для применения изменений нажать кнопку Применить конфигурацию.
Получившаяся конфигурация:
Мост vmbr1 на VLAN
Эта же конфигурация в файле /etc/network/interfaces:
auto lo
iface lo inet loopback

iface enp0s3 inet manual

auto enp0s9
iface enp0s9 inet manual

iface enp0s8 inet manual

auto enp0s8.100
iface enp0s8.100 inet manual

auto vmbr0
iface vmbr0 inet static
        address 192.168.0.90/24
        gateway 192.168.0.1
        bridge-ports enp0s3
        bridge-stp off
        bridge-fd 0
        dns-nameservers 8.8.8.8

auto vmbr1
iface vmbr1 inet static
        address 10.10.10.2/24
        bridge-ports enp0s8.100
        bridge-stp off
        bridge-fd 0
Теперь в настройках сетевого интерфейса ВМ можно указать сетевой мост vmbr1 (трафик через этот интерфейс будет автоматически помечаться тегом 100):
Настройки сетевого интерфейса ВМ

⁠Глава 29. Управление ISO-образами и шаблонами LXC

Если используются только локальные хранилища, ISO-образы и шаблоны контейнеров LXC необходимо загружать в каждое хранилище на тех узлах кластера, где они должны быть доступны. Если используется общее хранилище, образы и шаблоны можно хранить в одном месте, доступном с нескольких узлов, что позволяет сократить использование локального дискового пространства.
⁠

Таблица 29.1. Каталоги локальных хранилищ

Хранилище
Каталог
Содержимое
local
/var/lib/vz/template/iso/
ISO-образы
local
/var/lib/vz/template/cache/
Шаблоны контейнеров LXC
local-btrfs
/var/lib/pve/local-btrfs/template/iso/
ISO-образы
local-btrfs
/var/lib/pve/local-btrfs/template/cache/
Шаблоны контейнеров LXC
⁠

Таблица 29.2. Каталоги общих хранилищ

Каталог
Содержимое
/mnt/pve/<storage_name>/template/iso/
ISO-образы
/mnt/pve/<storage_name>/template/cache/
Шаблоны контейнеров LXC

Примечание

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

⁠29.1. Загрузка ISO-образов и шаблонов LXC

ISO-образы и шаблоны контейнеров LXC можно загрузить в хранилище PVE с локального компьютера или скачать с удалённого сервера по URL-адресу.
Для загрузки ISO-образа или шаблона контейнера LXC с локального компьютера выполните следующие действия:
  1. Выберите хранилище.
  2. Перейдите на вкладку:
    • ISO-образы — для загрузки ISO-образа;
    • Шаблоны контейнеров — для загрузки шаблона LXC:
    Локальное хранилище. Вкладка ISO-образы
  3. Нажмите кнопку Отправить.
  4. Нажмите кнопку Выбрать файл, укажите файл ISO-образа или шаблона и нажмите Отправить:
    Выбор файла с ISO-образом

    Примечание

    При загрузке можно указать алгоритм хеширования и контрольную сумму файла. В этом случае после загрузки PVE проверит целостность файла, сравнив вычисленную контрольную сумму с указанной.
Для загрузки ISO-образа или шаблона контейнера LXC по URL-адресу выполните следующие действия:
  1. Выберите хранилище.
  2. Перейдите на вкладку:
    • ISO-образы — для загрузки ISO-образа;
    • Шаблоны контейнеров — для загрузки шаблона LXC:
    Локальное хранилище. Вкладка ISO-образы
  3. Нажмите кнопку Скачать по URL-адресу.
  4. В поле URL-адрес укажите ссылку на файл.
  5. Нажмите кнопку Запрос URL-адреса, проверить ссылку и получить информацию о файле.
  6. Нажмите кнопку Скачивание, чтобы начать загрузку файла в выбранное хранилище:
    Выбор образа для загрузки файла с сервера

⁠29.2. Удаление ISO-образов и шаблонов LXC

Для удаления ISO-образа или шаблона контейнера LXC выполните следующие действия:
  1. Выберите хранилище и перейдите на соответствующую вкладку: ISO-образы или Шаблоны контейнеров.
  2. Выберите файл в списке.
  3. Нажмите кнопку Удалить.
  4. Подтвердите удаление.

⁠29.3. Работа с официальными шаблонами Proxmox

PVE позволяет загружать официальные шаблоны контейнеров из репозитория Proxmox.

Примечание

Перед загрузкой образа может потребоваться обновить список доступных шаблонов. Для обновления списка выполните команду в командной оболочке узла:
# pveam update
Загрузка базового шаблона через веб-интерфейс:
  1. Выберите хранилище, поддерживающее содержимое типа шаблонов контейнеров.
  2. Перейдите на вкладку Шаблоны контейнеров.
  3. Нажмите кнопку Шаблоны:
    Локальное хранилище. Вкладка Шаблоны контейнеров
  4. Выберите нужный шаблон и нажмите кнопку Скачивание:
    Выбор шаблона контейнера
Загрузка шаблона через командную строку:
  1. Обновите список доступных шаблонов:
    # pveam update
    update successful
    
  2. Просмотрите доступные шаблоны:
    # pveam available
    mail            proxmox-mail-gateway-8.2-standard_8.2-1_amd64.tar.zst
    mail            proxmox-mail-gateway-9.1-standard_9.1-1_amd64.tar.zst
    system          almalinux-10-default_20250930_amd64.tar.xz
    system          almalinux-9-default_20240911_amd64.tar.xz
    system          alpine-3.22-default_20250617_amd64.tar.xz
    …
    

    Примечание

    Чтобы ограничить вывод определённым разделом, укажите его с помощью параметра --section. Например, для просмотра базовых шаблонов операционных систем выполните команду:
    # pveam available --section system
    system          almalinux-10-default_20250930_amd64.tar.xz
    system          almalinux-9-default_20240911_amd64.tar.xz
    system          alpine-3.22-default_20250617_amd64.tar.xz
    system          centos-9-stream-default_20240828_amd64.tar.xz
    system          debian-12-standard_12.12-1_amd64.tar.zst
    …
    
  3. Загрузите выбранный шаблон в хранилище (например, local):
    # pveam download local almalinux-9-default_20240911_amd64.tar.xz
    
  4. Проверьте список загруженных шаблонов:
    # pveam list local
    NAME                                                         SIZE
    local:vztmpl/almalinux-9-default_20240911_amd64.tar.xz       99.60MB
    

⁠29.4. Загрузка OCI-образа

PVE позволяет создавать контейнеры LXC на основе OCI-образов (Open Container Initiative), полученных из реестра или загруженных вручную. OCI-образ можно использовать в качестве шаблона при создании контейнера.
Для загрузки OCI-образа из реестра через веб-интерфейс выполните следующие действия:
  1. Выберите хранилище.
  2. Перейдите на вкладку Шаблоны контейнеров.
  3. Нажмите кнопку Загрузка образа из OCI-реестра:
    Локальное хранилище. Кнопка Загрузка образа из OCI-реестра
  4. В открывшемся окне укажите следующие параметры:
    • Ссылка — адрес образа в реестре (например, registry.basealt.ru/alt/alt);
    • Метка — тег образа (например, p11);
    • Имя файла — имя файла, в котором будет сохранён образ. По умолчанию имя формируется автоматически на основе имени образа и его тега по шаблону <имя_образа>_<тег>.
    Загрузка OCI-образа

    Примечание

    Чтобы получить список доступных тегов выбранного образа, нажмите кнопку Запросить теги:
    Выбор тега
  5. Нажмите кнопку Скачивание.

⁠Глава 30. Виртуальные машины на базе KVM

Виртуальные машины (ВМ) позволяют запускать гостевые операционные системы в виртуальной среде.

⁠30.1. Создание виртуальной машины на базе KVM

Перед созданием ВМ в веб-интерфейсе PVE необходимо определить:
  • источник установочного образа гостевой ОС;
  • узел кластера, на котором будет размещена ВМ;
  • хранилище, в котором будут размещены виртуальные диски.
Остальные параметры конфигурации можно задать в процессе создания ВМ. Для ряда параметров предусмотрены значения по умолчанию.
Для установки гостевой ОС необходимо обеспечить доступ к её установочному образу. Загрузите ISO-образ в локальное хранилище выбранного узла или в общее хранилище, доступное с этого узла. Подробнее см. раздел Управление ISO-образами и шаблонами LXC.
Чтобы начать создание ВМ, нажмите кнопку Создать ВМ, расположенную в правом верхнем углу веб-интерфейса PVE:
Кнопка Создать ВМ
Создание ВМ выполняется с помощью мастера настройки.

⁠30.1.1. Общие настройки

На вкладке Общее укажите следующие параметры:
  • Узел — узел кластера, на котором будет размещена ВМ;
  • VM ID — уникальный числовой идентификатор ВМ в кластере. По умолчанию идентификаторы назначаются автоматически, начиная с 100 (100, 101, 102 и т.д.). Идентификатор используется при выполнении операций с ВМ (резервное копирование, работа через интерфейс командной строки, просмотр журналов и т. д.);
  • Имя — имя ВМ;
  • Добавить в HA — добавление ВМ в качестве ресурса высокой доступности (подробнее см. раздел Кластер высокой доступности);

    Примечание

    Для добавления ВМ в качестве ресурса высокой доступности при её создании пользователь должен иметь право доступа Sys.Console.
  • Пул ресурсов — пул, в который необходимо включить ВМ. Пулы позволяют объединять ВМ для управления доступом и ресурсами. Чтобы выбрать пул, его необходимо предварительно создать.
Вкладка Общее

Примечание

Диапазон идентификаторов, из которого PVE выбирает свободный ID при создании виртуальных машин и контейнеров, можно настроить на вкладке Центр обработки данных → Параметры, выбрав пункт Следующий свободный диапазон ID виртуальных машин:
Настройка диапазона VM ID
Если значение параметра Нижний предел установить равным значению Верхний предел, автоподстановка VM ID будет полностью отключена.

⁠30.1.2. Настройки ОС

На вкладке ОС необходимо указать источник и тип гостевой ОС:
Вкладка ОС
В качестве источника установки можно выбрать:
  • Использовать файл образа CD/DVD (iso) — использовать ISO-образ, предварительно загруженный в хранилище:
    Выбор ISO-образа для установки ОС
  • Использовать физический привод CD/DVD — использовать физический привод CD/DVD узла PVE;
  • Не использовать носители — создать ВМ без подключённого установочного носителя.
Выбор типа гостевой ОС при создании ВМ позволяет PVE настроить отдельные параметры виртуального оборудования с учётом особенностей этой ОС.

⁠30.1.3. Настройка системных компонентов

На вкладке Система настраиваются параметры виртуального оборудования ВМ, включая видеокарту, контроллер SCSI, тип прошивки и тип машины:
Вкладка Система
На вкладке Система доступны следующие параметры:
  • Видеокарта — тип виртуального графического устройства, определяющий совместимость с гостевой ОС и доступные графические возможности;

    Примечание

    Подробнее о выборе видеокарты см. Настройки дисплея.
  • Контроллер SCSI — тип виртуального контроллера дисков. Для современных гостевых ОС рекомендуется VirtIO SCSI;
  • Агент QEMU — позволяет PVE:
    • корректно выполнять выключение и перезагрузку ВМ;
    • создавать снапшоты с согласованием файловой системы (quiesce);
    • получать дополнительные сведения о гостевой ОС, в том числе IP-адреса и информацию об использовании файловых систем.
    Для использования этих возможностей необходимо установить и настроить QEMU Guest Agent в гостевой ОС;
  • Добавить доверенный платформенный модуль — добавление виртуального TPM. Подробнее см. раздел Доверенный платформенный модуль (TPM).

⁠30.1.3.1. Прошивка (Firmware)

PVE поддерживает два типа прошивки:
  • SeaBIOS — классическая эмуляция BIOS (по умолчанию);
  • OVMF — UEFI-совместимая прошивка.
Прошивку OVMF (UEFI) рекомендуется выбирать в следующих случаях:
  • планируется проброс PCIe-устройств (GPU, NVMe и др.);
  • требуется запуск ОС, поддерживающих только UEFI (например, Windows 11);
  • необходима поддержка Secure Boot (при соответствующей конфигурации).
При использовании OVMF для сохранения переменных прошивки и настройки загрузки требуется EFI-диск:
Выбор прошивки OVMF
Параметры EFI-диска зависят от конфигурации ВМ. Подробнее см. раздел BIOS и UEFI.

⁠30.1.3.2. Тип машины

Тип машины определяет модель виртуальной материнской платы и набор эмулируемых аппаратных устройств.
Доступны следующие варианты:
  • i440fx — модель с традиционной шиной PCI, обеспечивающая совместимость с рядом старых гостевых ОС (по умолчанию);
  • Q35 — модель с поддержкой PCI Express, рекомендуемая для современных гостевых ОС и конфигураций, использующих PCIe-устройства. Обязателен при использовании проброса PCI(e)-устройств.

⁠30.1.4. Диски

Вкладка Диски содержит параметры настройки виртуальных дисков ВМ.
Основные параметры:
  • Шина/Устройство — тип виртуального интерфейса подключения диска. Допустимые значения: IDE, SATA, VirtIO Block и SCSI (по умолчанию). Можно также указать идентификатор устройства;
  • Хранилище — хранилище, в котором будет размещён виртуальный диск. Тип хранилища определяет доступные форматы образов и поддерживаемые функции (thin provisioning, снапшоты и т. д.);
  • Размер диска (ГиБ) — ёмкость виртуального диска в гибибайтах;
  • Формат — формат образа виртуального диска. Доступные варианты: Несжатый образ диска (raw), Формат образа QEMU (qcow2) и Формат образа Vmware (vmdk). Формат raw обычно создаётся как полностью выделяемый (thick provisioning), то есть весь объём резервируется сразу (в зависимости от типа хранилища). qcow2 и vmdk поддерживают динамическое выделение пространства (thin provisioning) — объём файла растёт по мере записи данных;
  • Кеш — режим кеширования операций ввода-вывода. Он определяет, как QEMU взаимодействует с кешем хоста и когда сообщает гостевой ОС о завершении операций записи. По умолчанию используется режим Нет кеша: подтверждение записи возвращается гостю после передачи данных на уровень физического устройства, минуя кеш хоста. Это обеспечивает хороший баланс между производительностью и надёжностью;

    Примечание

    Режим Write Back может повысить производительность за счёт кеширования операций записи, но при сбое питания или отказе системы возможна потеря данных, которые ещё не были записаны на устойчивый носитель.
  • Отклонить (Discard) — разрешает передавать хранилищу сведения об освобождённых блоках, если эту функцию поддерживают виртуальный контроллер, гостевая ОС и хранилище. Это позволяет:
    • освобождать место на thin-хранилищах;
    • уменьшать размер образов (в зависимости от типа хранилища);
    • корректно работать с SSD;
  • IO Thread (Поток ввода-вывода) — включает отдельный поток обработки операций ввода-вывода для контроллера дисков (поддерживается для VirtIO SCSI и VirtIO Block).

    Примечание

    Рекомендуется включать для ВМ с высокой дисковой нагрузкой (базы данных, файловые серверы).
Вкладка Жёсткий диск
Для повышения производительности и использования современных возможностей рекомендуется использовать:
  • VirtIO SCSI — современный паравиртуализированный контроллер с поддержкой многопоточности, hot-plug и расширенных функций;
  • VirtIO Block — упрощённый паравиртуализированный контроллер для базовых задач.
Оба контроллера требуют установки соответствующих драйверов в гостевой ОС. В большинстве современных Linux-дистрибутивов драйверы включены по умолчанию. Для Windows необходимо установить драйверы VirtIO.

⁠30.1.4.1. Добавление нескольких дисков

В мастере создания ВМ можно добавить несколько виртуальных дисков с помощью кнопки Добавить:
Вкладка Жёсткий диск. Создание нескольких дисков
В мастере создания ВМ можно добавить до 31 диска SCSI, 16 дисков VirtIO, 6 дисков SATA и 4 дисков IDE.

⁠30.1.4.2. Ограничение пропускной способности

В разделе Пропускная способность можно ограничить интенсивность операций ввода-вывода виртуального диска, задав предельную скорость передачи данных и/или количество операций чтения и записи в секунду:
Скорость чтения/записи с диска
Эти параметры позволяют ограничивать нагрузку, создаваемую отдельными ВМ, и снижать риск перегрузки хранилища.

⁠30.1.4.3. Дополнительные параметры

Опция Эмуляция SSD сообщает гостевой ОС, что виртуальный диск является твердотельным накопителем. Физический носитель при этом может быть любого типа. Настройка влияет на то, как гостевая ОС определяет устройство и выбирает стратегии работы с ним. Это может:
  • изменить поведение файловых систем (например, отключить дефрагментацию);
  • оптимизировать алгоритмы планирования ввода-вывода в гостевой ОС.
Эмуляция SSD не поддерживается для дисков VirtIO Block.
Параметр Асинхронный ввод-вывод определяет механизм выполнения операций ввода-вывода:
  • io_uring — современный механизм асинхронного ввода-вывода Linux (рекомендуется);
  • native — интерфейс Linux AIO;
  • threads — выполнение операций с использованием потоков.
Выбор механизма зависит от ядра Linux, типа хранилища и характера нагрузки.
Для дисков SCSI и VirtIO можно включить атрибут read-only (отметка Только для чтения). Этот режим запрещает запись на виртуальный диск со стороны гостевой ОС.
Отметка Только для чтения
Снятие отметки с пункта Резервная копия исключает диск из стандартных заданий резервного копирования ВМ.
Установка отметки в пункте Пропустить репликацию исключает диск из заданий репликации.

Примечание

Репликация PVE поддерживается для дисков на хранилищах типа zfspool. Если для ВМ настроена репликация, диски, размещённые на хранилищах других типов, необходимо исключить из репликации с помощью параметра Пропустить репликацию.

⁠30.1.5. Настройка процессора (CPU)

На этом этапе настраиваются параметры виртуального процессора ВМ:
  • Сокеты — количество процессорных сокетов;
  • Ядра — виртуальных ядер на один сокет;
  • Тип — модель процессора, которую гипервизор предоставляет гостевой ОС.
Вкладка ЦП

Примечание

С точки зрения производительности конфигурации с одним сокетом и четырьмя ядрами и с двумя сокетами по два ядра обычно сопоставимы. Однако некоторые программные лицензии учитывают количество сокетов, а не ядер. В таких случаях следует выбирать конфигурацию с учётом лицензионных требований

⁠30.1.5.1. Тип процессора

QEMU поддерживает различные модели процессоров — от устаревших (например, 486) до современных моделей (Xeon). Выбор модели определяет набор инструкций и возможностей процессора, доступных гостевой ОС, включая AES, AVX и SSE.
Рекомендации по выбору:
  • host — модель, максимально соответствующая физическому процессору хоста. Позволяет предоставить гостевой ОС доступ к поддерживаемым хостом возможностям CPU, но может ограничить live-миграцию между хостами с различающимися процессорами;
  • x86-64-v2-AES (по умолчанию) — модель из семейства x86-64-vX с набором инструкций уровня v2 и поддержкой AES. Требует CPU Intel не ниже Westmere или AMD не ниже Opteron_G4;
  • kvm64 — устаревшая универсальная модель процессора с ограниченным набором инструкций. Может использоваться для совместимости, но не предоставляет гостевой ОС многие современные возможности CPU.

Примечание

Возможность live-миграции между хостами с процессорами Intel и AMD зависит от используемых моделей CPU и доступных гостевой ОС возможностей. Совместимость не гарантируется.

⁠30.1.5.2. Пользовательские типы CPU

Пользовательские модели CPU позволяют определить базовую модель процессора, производителя, число бит физического адреса и дополнительные флаги. После создания такую модель можно назначать ВМ так же, как встроенную модель CPU. В конфигурации ВМ имя пользовательской модели указывается с префиксом custom-.
Управление пользовательскими моделями CPU осуществляется в разделе Центр обработки данных → Custom CPU Models.
Создание пользовательской модели CPU
В диалоговом окне управления моделями доступна таблица флагов с поиском по имени и описанию, переключателем акселератора (KVM/TCG) и возможностью выбрать узлы кластера. При выборе узлов интерфейс показывает, какие флаги поддерживаются на этих узлах. Это позволяет оценить совместимость модели с узлами кластера до её сохранения.
Эта же таблица используется в диалоговом окне настройки процессора ВМ, но в нём отображаются только флаги, которые можно задавать на уровне ВМ. Если конфигурация содержит неизвестные флаги или флаги, не поддерживаемые выбранным акселератором, они отображаются в верхней части окна вместе с предупреждением.
Дополнительные параметры ЦП
Пользовательские модели CPU хранятся в конфигурационном файле /etc/pve/virtual-guest/cpu-models.conf. Управлять ими можно также через интерфейс командной строки. Подробнее о формате файла см. в файле /usr/share/pve-doc-generator/cpu-models.conf.adoc.
Доступ к каждой пользовательской модели контролируется отдельно с помощью пути ACL /mapping/cpu/<имя>. Привилегия Mapping.Audit позволяет просматривать модель в списках, Mapping.Modify — создавать, изменять и удалять модели через веб-интерфейс, а Mapping.Use — назначать модель ВМ.
Наличие привилегии Mapping.Use проверяется при создании, изменении и клонировании ВМ. Поэтому даже если пользователь обладает правами на клонирование ВМ, использующей пользовательскую модель CPU, для выполнения этой операции ему также потребуется привилегия Mapping.Use для соответствующего пути ACL данной модели.

⁠30.1.5.3. Ограничение CPU-ресурсов

Ограничение CPU-ресурсов
Увеличение количества виртуальных процессоров (vCPU) может повысить производительность многопоточных приложений, если их нагрузка допускает параллельную обработку и хост располагает достаточными ресурсами. При планировании конфигурации следует учитывать число vCPU, характер нагрузки и доступные вычислительные ресурсы хоста. Если требования приложения неизвестны, можно начать с двух vCPU, а затем оценить фактическую нагрузку.
Параметр Лимит загрузки (cpulimit) задаёт максимальное суммарное потребление CPU-времени ВМ в единицах, соответствующих загрузке одного логического процессора:
  • 1.0 — эквивалент полной загрузки одного логического процессора;
  • 4.0 — эквивалент полной загрузки четырёх логических процессоров (например, четыре ядра по 100 % или восемь ядер по 50 %).
Этот параметр полезен в случаях, когда ВМ требуется несколько vCPU для параллельной обработки, но при этом она не должна полностью загружать все ядра хоста одновременно.

Примечание

ВМ с 8 vCPU и cpulimit=4.0 при полной загрузке получит максимум 50 % времени каждого физического ядра (эквивалент четырёх полностью загруженных ядер). Если активно используются только 4 vCPU, они могут работать на 100 %.
Следует учитывать, что QEMU может использовать дополнительные потоки для сетевых и I/O-операций, поэтому реальное потребление CPU может немного отличаться от ожидаемого. Для строгого ограничения рекомендуется устанавливать cpulimit, равный количеству vCPU.
Параметр Процессорные единицы (cpuunits, по умолчанию — 100) задаёт относительный вес ВМ при распределении CPU-времени между ВМ, конкурирующими за ресурсы хоста. Чем выше значение, тем большую долю доступного CPU-времени может получить ВМ при прочих равных условиях. Например, если у ВМ A значение cpuunits=100, а у ВМ B — cpuunits=200, то при одинаковых условиях конкуренции ВМ B может получить примерно вдвое большую долю CPU-времени, чем ВМ A. Фактическое распределение зависит от нагрузки и настроек планировщика. Подробнее см. man systemd.resource-control (параметр CPUWeight соответствует cpuunits).
Параметр Привязка к ядрам ЦП (affinity) ограничить выполнение процессов ВМ указанными логическими CPU хоста. Значение задаётся в виде списка CPU (например, 0-1,8-11).

Примечание

Привязку следует использовать только при необходимости (например, для низколатентных задач или real-time-задач). Она усложняет миграцию ВМ и может привести к неравномерной загрузке ядер хоста.

⁠30.1.5.4. Дополнительные флаги ЦП

⁠

Таблица 30.1. Дополнительные флаги ЦП

Флаг
Описание
Примечание
nested-virt
Управление вложенной виртуализацией: svm для AMD и vmx для Intel
Требует включения в BIOS/UEFI. Live-миграция возможна только при совпадении флага на обоих хостах. Рекомендуется использовать модель CPU того же производителя, что и хост (не x86-64-vX)
md-clear
Сообщает гостевой ОС о доступности механизма очистки буферов, используемого для смягчения MDS (Microarchitectural Data Sampling)
Используется современными механизмами смягчения MDS-уязвимостей
pcid
Снижает накладные расходы исправления Meltdown (KPTI) на CPU Intel Westmere, Sandy Bridge и Ivy Bridge
Актуально только для указанных поколений Intel
spec-ctrl
Включает расширенные механизмы защиты от Spectre v1/v2 на процессорах Intel
Улучшает эффективность mitigation Spectre v1/v2
ssbd
Защита от уязвимости Speculative Store Bypass (Spectre v4) для Intel
Требуется поддержка со стороны CPU и ОС
ibpb
Механизм защиты, связанный с Spectre v1/v2 в соответствующих сценариях
Обычно используется совместно с amd-ssbd
amd-ssbd
Оптимизированная защита от Spectre v4 на AMD
Рекомендуется включать вместе с virt-ssbd
amd-no-ssb
Указывает гостевой ОС, что хост не уязвим к Spectre v4 (AMD)
Используется для отключения лишних mitigations внутри гостя
pdpe1gb
Разрешает гостевой ОС использовать страницы памяти размером 1 ГБ (если поддерживается аппаратно)
Улучшает производительность при работе с большими объёмами RAM
hv-tlbflush
Улучшает производительность Windows-гостей при избыточном выделении CPU (overcommit)
На старых CPU может вызывать BSOD
hv-evmcs
Повышает производительность вложенной виртуализации в Windows-гостях
Поддерживается только на процессорах Intel
aes
Включает набор инструкций AES для аппаратного ускорения шифрования
Рекомендуется для ВМ, использующих шифрование (VPN, TLS, дисковое шифрование)

Примечание

Флаги hv-* предоставляют гостевой ОС возможности Hyper-V. Они предназначены прежде всего для Windows-гостей; их использование и эффект зависят от гостевой ОС и конфигурации виртуальной машины.
Для смягчения уязвимостей Meltdown и Spectre необходимо включить соответствующие CPU-флаги (если они поддерживаются хостом и гостевой ОС).
  • Intel:
    • pcid — снижает накладные расходы KPTI (Meltdown);
    • spec-ctrl — защита от Spectre v1/v2;
    • ssbd — защита от Spectre v4.
  • AMD:
    • ibpb — защита от Spectre v1/v2;
    • virt-ssbd, amd-ssbd — защита от Spectre v4;
    • amd-no-ssb — указывает, что CPU не уязвим к Spectre v4.

Примечание

При использовании типа host флаги virt-ssbd и amd-no-ssb не включаются автоматически — при необходимости их следует добавить вручную.

Примечание

Проверка уязвимостей хоста:
$ for f in /sys/devices/system/cpu/vulnerabilities/*; do echo "${f##*/} -" $(cat "$f"); done

⁠30.1.5.5. NUMA

Если физический хост использует архитектуру NUMA, включение NUMA в настройках ВМ может улучшить соответствие между размещением виртуальных процессоров и выделением памяти.

Примечание

При включённом NUMA рекомендуется задавать количество сокетов ВМ равным числу NUMA-узлов хоста.

⁠30.1.5.6. Горячее подключение CPU (vCPU hot-plug)

Горячее подключение виртуальных процессоров (vCPU hot-plug) позволяет добавлять виртуальные процессоры без перезагрузки ВМ, если такая возможность поддерживается конфигурацией ВМ и гостевой ОС.
Максимальное число vCPU определяется как:
cores × sockets
Параметр vcpus задаёт начальное количество активных виртуальных процессоров.
Для автоматического включения новых CPU в гостевой системе можно создать правило udev:
# /etc/udev/rules.d/99-hotplug-cpu.rules
SUBSYSTEM=="cpu", ACTION=="add", TEST=="online", ATTR{online}=="0", ATTR{online}="1"

Примечание

Возможность горячего отключения CPU (hot-unplug) зависит от конфигурации ВМ и гостевой ОС и не всегда поддерживается.

⁠30.1.6. Память

На вкладке Память необходимо указать объем оперативной памяти, выделяемой ВМ:
Вкладка Память

⁠30.1.6.1. Фиксированное выделение памяти

Если значения параметров Память и Минимум памяти совпадают, PVE выделяет ВМ фиксированный объём оперативной памяти.
Даже при фиксированном объёме к ВМ автоматически подключается устройство баллонирования (ballooning). Оно позволяет отслеживать фактическое потребление памяти гостевой ОС. Отключать его рекомендуется только в целях отладки. Отключить устройство баллонирования можно:
  • через веб-интерфейс: сняв отметку Динамическое изменение размера памяти;
  • указав в конфигурационном файле ВМ:
    balloon: 0

⁠30.1.6.2. Динамическое выделение памяти (Autoallocate)

Если значение параметра Минимум памяти меньше значения параметра Память, PVE может динамически изменять объём памяти, выделяемый ВМ:
  • Минимум памяти — нижняя граница объёма памяти, задаваемая для ВМ;
  • Память — максимальный объём памяти, который может быть выделен ВМ;
  • Целевой объём ОЗУ для динамического изменения объёма памяти — целевой уровень использования памяти хоста, по умолчанию 80 %; значение настраивается в параметрах узла.
Динамическое выделение памяти
Когда хост испытывает нехватку памяти, баллон-драйвер в гостевой ОС может освободить часть памяти, возвращая её хосту. При недостатке памяти могут также использоваться подкачка (swap) и механизмы OOM killer. Это может привести к снижению производительности ВМ и хоста.

Примечание

Рекомендуется оставлять не менее 1 ГБ оперативной памяти для нужд хоста (без учёта ВМ).
При динамическом распределении памяти между несколькими ВМ можно использовать параметр Общие ресурсы (Shares). Он задаёт относительный приоритет ВМ при распределении памяти в условиях конкуренции за ресурсы. Фактическое распределение зависит от текущей нагрузки и настроек узла.
Пример. Хост располагает 32 ГБ ОЗУ, из которых 16 ГБ занято. Если в качестве упрощённой оценки принять целевой уровень использования памяти за 80 %, то расчётный резерв составит:
32 × 0,8 − 16 = 9,6 ГБ
Параметры:
  • Сервер баз данных: Shares = 3000;
  • Три веб-сервера: Shares = 1000 для каждого.
Относительные доли составляют:
  • Сервер баз данных — 50 %;
  • Каждый веб-сервер — 16,7 %.
При условном распределении всего расчётного резерва пропорционально этим значениям сервер баз данных получил бы 9.6 × 3000 / (3000 + 3×1000) = 4.8 ГБ ГБ, а каждый веб-сервер — 1,6 ГБ.

Примечание

Для динамического изменения объёма памяти в Windows требуется совместимый balloon-драйвер VirtIO. Работа баллонирования может создавать дополнительные накладные расходы. Для систем с жёсткими требованиями к задержкам и предсказуемости производительности конфигурацию памяти следует выбирать после нагрузочного тестирования.

⁠30.1.6.3. KSM

Параметр Разрешить KSM (по умолчанию включено) управляет использованием механизма KSM (Kernel Samepage Merging), который позволяет объединять идентичные страницы памяти, используемые разными процессами, в том числе процессами разных ВМ.
Использование KSM может снизить суммарное потребление оперативной памяти хостом при наличии одинаковых страниц памяти. При этом поиск и объединение страниц могут увеличивать нагрузку на процессор.

⁠30.1.7. Сеть

Вкладка Сеть содержит параметры настройки виртуальных сетевых интерфейсов ВМ.
Вкладка Сеть
Основные параметры:
  • Нет сетевого устройства — позволяет пропустить настройку сетевого интерфейса на данном этапе;
  • Сетевой мост — указывает мост, к которому подключается виртуальный сетевой интерфейс ВМ (по умолчанию — vmbr0). Каждый виртуальный сетевой адаптер (NIC) связывается с TAP-устройством на хосте, которое добавляется в указанный мост. В этом режиме виртуальная машина получает прямой доступ к локальной сети и работает как физическое устройство;

    Примечание

    Режим NAT настраивается только через CLI или API.
    При использовании NAT применяется встроенный стек QEMU (user networking). ВМ получает IP-адрес из диапазона 10.0.2.0/24 через встроенный DHCP-сервер. Такой режим подходит для тестирования, но не рекомендуется для производственной среды.
  • Тег VLAN — задаёт идентификатор VLAN для виртуального интерфейса (требуется поддержка VLAN на мосте/физическом интерфейсе);
  • Сетевой экран — включает применение правил встроенного межсетевого экрана PVE к сетевому интерфейсу ВМ;
  • Модель — задаёт модель виртуального сетевого адаптера (см. Модель сетевого интерфейса). Для максимальной производительности ВМ рекомендуется использовать VirtIO (паравиртуализированно);
  • MAC-адрес — по умолчанию PVE автоматически генерирует уникальный MAC-адрес для интерфейса. При необходимости можно указать собственный адрес, который должен быть уникальным в соответствующем сетевом сегменте.
⁠

Таблица 30.2. Модель сетевого интерфейса

Тип
Описание
Рекомендации
Intel E1000
Эмулируемый сетевой адаптер Intel Gigabit Ethernet
Может использоваться для совместимости с гостевыми ОС, не поддерживающими VirtIO
Intel E1000E
Эмулируемый сетевой адаптер Intel Gigabit Ethernet
Может использоваться, если требуется совместимость с соответствующей моделью адаптера
VirtIO
Паравиртуализированный сетевой адаптер
Рекомендуется для высокой производительности. Требуется поддержка VirtIO в гостевой ОС
Realtek RTL8139
Эмулируемый сетевой адаптер Fast Ethernet со скоростью до 100 Мбит/с
Может использоваться для совместимости со старыми гостевыми ОС
VMware vmxnet3
Паравиртуализированный сетевой адаптер VMware
Может использоваться при импорте ВМ из VMware при наличии поддержки драйвера в гостевой ОС

⁠30.1.7.1. Дополнительные настройки

Дополнительные настройки:
  • Отключить — позволяет временно отключить сетевой интерфейс ВМ без удаления его конфигурации;
  • Ограничение скорости — задаёт ограничение пропускной способности сетевого интерфейса (rate limit). Используется для ограничения сетевого трафика отдельных ВМ и предотвращения перегрузки канала;
  • MTU — позволяет для адаптеров VirtIO вручную задать максимальный размер передаваемого сетевого пакета (MTU). Если поле оставить пустым или указать mtu=1, будет использовано значение MTU, заданное на базовом мосте (например, vmbr0).
  • Multiqueue (Мультиочередность) — позволяет обрабатывать сетевые пакеты через несколько очередей, что может повысить пропускную способность при высокой сетевой нагрузке.
Требования к Multiqueue:
  • используется с паравиртуализированным адаптером адаптером VirtIO;
  • гостевая ОС должна поддерживать соответствующий драйвер и работу с несколькими очередями.
Настройка Multiqueue:
  1. В PVE укажите количество очередей, равное числу vCPU ВМ (vCPU = сокеты × ядра);
  2. В гостевой ОС активируйте поддержку RSS (Receive Side Scaling):
    • Linux:
      # ethtool -L ens1 combined <число_vCPU>
    • Windows:
      1. Установите драйверы VirtIO Ethernet Adapter.
      2. Откройте Диспетчер устройств → свойства сетевого адаптера.
      3. На вкладке «Дополнительно» включите параметр Receive Side Scaling и установите значение Maximum number of RSS Queues равным числу vCPU.

Важно

Multiqueue может увеличить нагрузку на процессор хоста и гостевой ОС. Используйте эту функцию, если она необходима для повышения производительности при высокой сетевой нагрузке, например на виртуальных маршрутизаторах, reverse proxy или нагруженных веб-серверах.

⁠30.1.8. Подтверждение

На вкладке Подтверждение отображаются введённые и выбранные параметры создаваемой ВМ:
Вкладка Подтверждение
Для создания ВМ нажмите кнопку Завершить. Если необходимо внести изменения в параметры ВМ, можно вернуться на соответствующие вкладки.
Если отметить пункт Запуск после создания, ВМ будет запущена сразу после завершения создания.

⁠30.2. Запуск и остановка ВМ

⁠30.2.1. Изменение состояния ВМ в веб-интерфейсе

Запустить ВМ можно одним из следующих способов:
  • выбрать пункт Запуск в контекстном меню ВМ:
    Контекстное меню ВМ
  • нажать кнопку Запуск:
    Кнопки управления состоянием ВМ
  • нажать кнопку Start Now в консоли гостевой машины:
    Кнопка Start Now в консоли ВМ
Запущенная ВМ обозначается зелёной стрелкой на её значке.
Для запущенной ВМ доступны следующие действия:
  • Приостановить — временно приостановить выполнение ВМ с сохранением её состояния в оперативной памяти;
  • Гибернация — сохранить состояние ВМ на диск и остановить её выполнение;
  • Отключить — отправить запрос на корректное завершение работы гостевой ОС;
  • Остановка — принудительно остановить ВМ без штатного завершения работы гостевой ОС;
  • Перезагрузить — запросить перезагрузку гостевой ОС;
  • Сброс — принудительно перезапустить ВМ без штатного завершения работы гостевой ОС (аналог аппаратного сброса).
Контекстное меню запущенной ВМ

Примечание

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

⁠30.2.2. Автоматический запуск ВМ

Чтобы ВМ запускалась автоматически при загрузке хост-системы, необходимо включить параметр Запуск при загрузке на вкладке Параметры выбранной ВМ либо выполнить команду:
# qm set <vmid> -onboot 1
Если требуется задать порядок запуска ВМ, например когда одна ВМ выполняет функции межсетевого экрана или DHCP-сервера для других гостевых систем, настройте параметр Порядок запуска и отключения на вкладке Параметры выбранной ВМ.
Доступны следующие параметры:
  • Порядок запуска и отключения — задаёт порядок запуска ВМ. Меньшее значение соответствует более раннему запуску. При выключении узла порядок обратный: ВМ с порядком запуска 1 выключается последней. Если для нескольких ВМ задан одинаковый порядок, PVE дополнительно упорядочивает их по возрастанию VMID;
  • Задержка запуска — задаёт интервал в секундах между запуском данной ВМ и запуском последующих ВМ;
  • Задержка отключения — задаёт время в секундах, в течение которого PVE ожидает завершения работы ВМ после отправки запроса на выключение. Значение по умолчанию — 180 секунд. Если по истечении этого времени ВМ продолжает работать, PVE принудительно останавливает её.
Настройка порядка запуска и выключения ВМ

Примечание

Виртуальные машины, управляемые стеком HA, не используют параметры автоматического запуска и порядка запуска и отключения. Запуск и остановку таких ВМ обеспечивает диспетчер HA.
ВМ, для которых порядок запуска не задан, запускаются после ВМ с заданным порядком. Этот параметр применяется только к ВМ, работающим на одном узле, и не задаёт порядок запуска на уровне кластера.

⁠30.2.3. Массовый запуск и остановка ВМ

Для массового запуска или остановки ВМ необходимо выбрать в контекстном меню узла пункт Массовый запуск или Массовое отключение соответственно:
Контекстное меню узла
В открывшемся окне отметьте нужные ВМ и нажмите кнопку Запуск или Отключить. При массовой остановке можно дополнительно задать параметры Время ожидания и Принудительная остановка:
Массовое отключение ВМ

Примечание

Массовые действия также доступны в режиме просмотра В виде меток.
Например, чтобы запустить все ВМ с определённым тегом, откройте контекстное меню этого тега и выберите пункт Массовый запуск:
Контекстное меню тега

⁠30.3. Управление ВМ с помощью qm

Если веб-интерфейс PVE недоступен, управлять ВМ можно из командной строки узла PVE, подключившись к нему по SSH или используя его локальную консоль.
Утилита qm — это инструмент для управления ВМ на базе Qemu/KVM в PVE. С её помощью можно:
  • создавать и удалять ВМ;
  • управлять состоянием ВМ (запуск, остановка, приостановка, возобновление);
  • изменять параметры конфигурации;
  • создавать и управлять виртуальными дисками.
Общий синтаксис:
qm <КОМАНДА> [АРГУМЕНТЫ] [ОПЦИИ]
Получить список доступных команд можно, выполнив команду:
# qm help
В таблице Команды qm приведены основные команды qm.

Примечание

В командах vmid — идентификатор ВМ, который может принимать значение из диапазона 100 — 999999999.
⁠

Таблица 30.3. Команды qm

Команда
Описание
qm agent
Псевдоним для qm guest cmd
qm block <vmid>
Заблокировать ВМ.
  • vmid — идентификатор ВМ.
qm cleanup <vmid> <clean-shutdown> <guest-requested>
Очистить ресурсы ВМ, например виртуальные сетевые устройства TAP и vGPU. Команда вызывается после завершения работы или аварийного завершения ВМ.
  • vmid — идентификатор ВМ;
  • clean-shutdown — указывает, корректно ли была завершена работа QEMU;
  • guest-requested — указывает, было ли завершение работы запрошено гостем или через qmp.
qm clone <vmid> <newid> [ОПЦИИ]
Создать копию ВМ/шаблона.
  • vmid — идентификатор ВМ;
  • newid — VMID для клона;
  • --bwlimit <целое число> — переопределить ограничение пропускной способности ввода-вывода (в КиБ/с) (0–N);
  • --description <строка> — описание новой ВМ;
  • --format <qcow2 | raw | vmdk> — целевой формат хранения файлов (действительно только для полного клона);
  • --full <логическое значение> — создать полную копию всех дисков (используется по умолчанию при клонировании ВМ). Для шаблонов ВМ по умолчанию пытается создать связанный клон;
  • --name <строка> — имя новой ВМ;
  • --pool <строка> — пул, в который будет добавлена ВМ;
  • --snapname <строка> — имя снимка;
  • --storage <строка> — целевое хранилище для полного клона;
  • --target <строка> — целевой узел (доступно в случае, если исходная ВМ находится в общем хранилище).
qm cloudinit dump <vmid> <type>
Получить автоматически сгенерированную конфигурацию cloud-init.
  • vmid — идентификатор ВМ;
  • type — тип конфигурации (meta | network | user).
qm cloudinit pending <vmid>
Получить конфигурацию cloud-init с текущими и ожидающими значениями.
  • vmid — идентификатор ВМ.
qm cloudinit update <vmid>
Восстановить и изменить диск конфигурации cloud-init.
  • vmid — идентификатор ВМ.
qm config <vmid> <ОПЦИИ>
Вывести конфигурацию ВМ с применёнными ожидающими изменениями конфигурации. Для вывода текущей конфигурации следует указать параметр current.
  • vmid — идентификатор ВМ;
  • --current <логическое значение> — вывести текущие значения вместо ожидающих (по умолчанию 0);
  • --snapshot <строка> — вывести значения конфигурации из данного снимка.
qm create <vmid> <ОПЦИИ>
Создать или восстановить ВМ.
Некоторые опции:
  • vmid — идентификатор ВМ;
  • --acpi <логическое значение> — включить/отключить ACPI (по умолчанию 1);
  • --affinity <строка> — список ядер хоста, используемых для выполнения гостевых процессов, например: 0,5,8-11;
  • --agent [enabled=]<1|0> [,freeze-fs=<1|0>] [,fstrim_cloned_disks=<1|0>] [,type=<virtio|isa>] — включить/отключить связь с гостевым агентом QEMU;
  • --allow-ksm <логическое значение> — разрешить слияние страниц памяти этой гостевой системы с помощью KSM (по умолчанию 1);
  • --amd-sev [type=]<sev-type> [,allow-smt=<1|0>] [,kernel-hashes=<1|0>] [,no-debug=<1|0>] [,no-key-sharing=<1|0>] — функции защищенной зашифрованной виртуализации (SEV) процессоров AMD;
  • --arch <aarch64 | x86_64> — архитектура виртуального процессора;
  • --archive <строка> — создать ВМ из архива. Указывается либо путь к файлу .tar или .vma, либо идентификатор тома резервной копии хранилища PVE;
  • --args <строка> — передача произвольных аргументов в KVM;
  • --audio0 device=<ich9-intel-hda|intel-hda|AC97>[,driver=<spice|none>] — настройка аудиоустройства;
  • --autostart <логическое значение> (по умолчанию 0) — автоматический перезапуск после сбоя (в настоящее время игнорируется);
  • --balloon <целое число> — объём целевой оперативной памяти для ВМ в МиБ (0 отключает Balloon Driver);
  • --bios <ovmf | seabios> — реализация BIOS (по умолчанию seabios);
  • --boot [order=<устройство[;устройство...]>] — порядок загрузки ВМ;
  • --bwlimit <целое число> — переопределить ограничение пропускной способности ввода-вывода (в КиБ/с);
  • --cdrom <volume> — псевдоним опции ide2;
  • --cicustom [meta=<volume>] [,network=<volume>] [,user=<volume>] [,vendor=<volume>] — cloud-init: указать пользовательские файлы для замены автоматически созданных;
  • --cipassword <пароль> — cloud-init: пароль для пользователя. Рекомендуется использовать ключи SSH вместо пароля;
  • --citype <configdrive2 | nocloud | opennebula> — формат конфигурации cloud-init;
  • --ciupgrade <логическое значение> — cloud-init: выполнить автоматическое обновление пакета после первой загрузки (по умолчанию 1);
  • --ciuser <строка> — cloud-init: имя пользователя для изменения пароля и ключей SSH вместо настроенного пользователя по умолчанию;
  • --cores <целое число> — количество ядер на сокет (по умолчанию 1);
  • --cpu <тип> — эмулируемый тип процессора;
  • --cpulimit <целое число (0–128)> — ограничение использования процессора (по умолчанию 0);
  • --cpuunits <целое число (1–262144)> — вес ЦП для ВМ будет ограничен значением [1, 10000] в cgroup v2 (по умолчанию cgroup v1: 1024, cgroup v2: 100);
  • --description <строка> — описание ВМ;
  • --efidisk0 [file=]<том> [,efitype=<2m|4m>] [,format=<enum>] [,import-from=<исходный том>] [,ms-cert=<2011|2023|2023w>] [,pre-enrolled-keys=<1|0>] [,size=<размер диска>] — диск для хранения переменных EFI;
  • --force <логическое значение> — разрешить перезапись существующей ВМ (требуется опция --archive);
  • --freeze <логическое значение> — заморозить процессор при запуске;
  • --ha-managed <логическое значение> — добавить ВМ в качестве ресурса подсистемы высокой доступности после её создания (по умолчанию 0);
  • --hookscript <строка> — скрипт, который будет выполняться на разных этапах жизненного цикла ВМ;
  • --hostpci[n] [[host=]<HOSTPCIID[;HOSTPCIID2...]>] ,device-id=<hex id>] [,legacy-igd=<1|0>] [,mapping=<mapping-id>] [,mdev=<строка>] [,pcie=<1|0>] [,rombar=<1|0>] [,romfile=<строка>] [,sub-device-id=<hex id>] [,sub-vendor-id=<hex id>] [,vendor-id=<hex id>] [,x-vga=<1|0>] — сопоставить устройства PCI хоста с гостевой системой;
  • --hotplug <строка> — выборочно включить функции горячего подключения (по умолчанию = network,disk,usb). Это список функций горячего подключения, разделенных запятыми: network, disk, cpu, memory, usb и cloudinit. Чтобы полностью отключить горячее подключение следует использовать 0. Использование 1 в качестве значения является псевдонимом для значения по умолчанию (network,disk,usb). Горячее подключение USB возможно для гостевых систем с версией машины >= 7.1 и ostype l26 или windows > 7;
  • --hugepages <1024 | 2 | any> — включить/отключить память hugepages;
  • --ide[n] [описание] — использовать в качестве жёсткого диска IDE или компакт-диск (n от 0 до 3). Для выделения нового тома используется синтаксис STORAGE_ID:SIZE_IN_GiB. Для импорта из существующего тома используется STORAGE_ID:0 и параметр import-from;
  • --import-working-storage <идентификатор хранилища> — файловое хранилище с включенным типом содержимого изображений, которое используется в качестве промежуточного хранилища для извлечения во время импорта. По умолчанию используется исходное хранилище;
  • --intel-tdx [type=]<tdx-type> ,attestation=<1|0> [,vsock-cid=<целое число>] [,vsock-port=<целое число>] — функции расширения доверенного домена (TDX) для процессоров Intel;
  • --ipconfig[n] [gw=<GatewayIPv4>] [,gw6=<GatewayIPv6>] [,ip=<IPv4Format/CIDR>] [,ip6=<IPv6Format/CIDR>] — cloud-init: указать IP-адрес и шлюз для соответствующего интерфейса;
  • --ivshmem size=<целое число> [,name=<строка>] — общая память между виртуальными машинами. Полезно для прямого взаимодействия между ВМ или с хостом;
  • --keephugepages <логическое значение> — следует использовать вместе с hugepages (по умолчанию 0). Если включено, hugepages не будут удалены после выключения виртуальной машины и могут использоваться для последующих запусков;
  • --kvm <логическое значение> — включить/отключить аппаратную виртуализацию KVM (по умолчанию 1);
  • --live-restore <логическое значение> — запустить ВМ из резервной копии и восстановить её в фоновом режиме (только PBS). Требуется опция --archive;
  • --localtime <логическое значение> — установить часы реального времени (RTC) на местное время;
  • --lock <backup | clone | create | migrate | rollback | snapshot | snapshot-delete | suspended | suspending> — заблокировать/разблокировать ВМ;
  • --machine [[type=]<тип>] [,viommu=<intel|virtio>] — тип машины QEMU;
  • --memory [current=]<целое число> — свойства памяти;
  • --migrate_downtime <число> — максимально допустимое время простоя (в секундах) для миграции (по умолчанию 0,1);
  • --migrate_speed <целое число> — максимальная скорость (в МБ/с) для миграции (по умолчанию 0 — не ограничивать скорость);
  • --name <строка> — имя ВМ;
  • --nameserver <строка> — cloud-init: устанавливает IP-адрес DNS-сервера для гостевой системы;
  • --net[n] <сеть> — сетевые устройства;
  • --numa <логическое значение> — включить/отключить NUMA (по умолчанию 0);
  • --numa[n] <топология> — топология NUMA;
  • --onboot <логическое значение> — запускать ВМ во время загрузки системы (по умолчанию 0);
  • --ostype <l24 | l26 | other | solaris | w2k | w2k3 | w2k8 | win10 | win11 | win7 | win8 | wvista | wxp> — гостевая ОС;
  • --parallel[n] /dev/parport\d+|/dev/usb/lp\d+ — cопоставить параллельные устройства хоста (n от 0 до 2);
  • --pool <строка> — добавить ВМ в указанный пул;
  • --protection <логическое значение> — установить флаг защиты ВМ (по умолчанию 0). Флаг предотвращает случайное удаление ВМ и её дисковых данных;
  • --reboot <логическое значение> — разрешить перезагрузку (по умолчанию 1). Если установлено значение 0, ВМ завершит работу при перезагрузке;
  • --rng0 [source=] </dev/urandom|/dev/random|/dev/hwrng> [,max_bytes=<целое число>] [,period=<целое число>] — настроить генератор случайных чисел на основе VirtIO;
  • --sata[n] <описание> — использовать в качестве жёсткого диска SATA или компакт-диск (n от 0 до 5). Для выделения нового тома используется синтаксис STORAGE_ID:SIZE_IN_GiB. Для импорта из существующего тома используется STORAGE_ID:0 и параметр import-from;
  • --scsi[n] <описание> — использовать в качестве жёсткого диска SCSI или компакт-диск (n от 0 до 30). Для выделения нового тома используется синтаксис STORAGE_ID:SIZE_IN_GiB. Для импорта из существующего тома используется STORAGE_ID:0 и параметр import-from;
  • --scsihw <lsi | lsi53c810 | megasas | pvscsi | virtio-scsi-pci | virtio-scsi-single> — модель контроллера SCSI (по умолчанию lsi);
  • --searchdomain <строка> — cloud-init: установить домены поиска DNS для гостевой системы;
  • --serial[n] (/dev/.+|socket) — последовательное устройство внутри ВМ (n от 0 до 3);
  • --shares <целое число (0–50000)> — объем разделяемой памяти (по умолчанию 1000);
  • --smbios1 [base64=<1|0>] [,family=<cтрока в кодировке Base64>] [,manufacturer=<cтрока в кодировке Base64>] [,product=<cтрока в кодировке Base64>] [,serial=<cтрока в кодировке Base64>] [,sku=<cтрока в кодировке Base64>] [,uuid=<UUID>] [,version=<cтрока в кодировке Base64>] — поля SMBIOS типа 1;
  • --sockets <целое число> — количество сокетов процессора (по умолчанию 1);
  • --spice_enhancements [foldersharing=<1|0>] [,videostreaming=<off|all|filter>] — настройки для SPICE;
  • --sshkeys <путь к файлу> — cloud-init: настройка публичных ключей SSH (по одному ключу в строке, формат OpenSSH);
  • --start <логическое значение> — запустить ВМ после создания (по умолчанию 0);
  • --startdate (now | YYYY-MM-DD | YYYY-MM-DDTHH:MM:SS) — установить начальную дату часов реального времени (RTC). Допустимый формат даты: now, 2006-06-17T16:01:21 или 2006-06-17 (по умолчанию = now);
  • --startup `[[order=]\d+] [,up=\d+] [,down=\d+] ` — поведение при запуске и выключении. order — неотрицательное число, определяющее общий порядок запуска. Выключение выполняется в обратном порядке. up/down — задержка включения/выключения в секундах;
  • --storage <строка> — хранилище;
  • --tablet <логическое значение> — включить/отключить USB-планшет (по умолчанию 1);
  • --tags <строка> — теги ВМ;
  • --template <логическое значение> — включить/отключить шаблон (по умолчанию 0);
  • --tdf <логическое значение> — включить/отключить исправление дрейфа времени (time drift) (по умолчанию 0);
  • --tpmstate0 [file=]<том> [,format=<raw|qcow2|vmdk>] [,import-from=<исходный том>] [,size=<размер диска>] [,version=<v1.2|v2.0>] — настроить диск для хранения состояния TPM;
  • --unique <логическое значение> — назначить уникальный случайный адрес Ethernet;
  • --usb[n] [[host=]<HOSTUSBDEVICE|spice>] [,mapping=<mapping-id>] [,usb3=<1|0>] — настройка USB-устройства (n — от 0 до 4, для версии машины >= 7.1 и ostype l26 или windows > 7, n может достигать 14);
  • --vcpus <целое число> — количество виртуальных процессоров с горячим подключением;
  • --vga [[type=]<enum>] [,clipboard=<vnc>] [,memory=<целое число>] — настройка VGA;
  • --virtio[n] <описание> — использовать жёсткий диск VIRTIO (n от 0 до 15);
  • vmgenid <UUID> — установить идентификатор поколения ВМ. Значение 1 означает автоматическую генерацию идентификатора, а 0 позволяет явно отключить его (по умолчанию 1);
  • --vmstatestorage <строка>  — хранилище по умолчанию для томов/файлов состояния ВМ;
  • --watchdog [[model=]<i6300esb|ib700>] [,action=<enum>]  — создать сторожевое устройство виртуального оборудования.
qm delsnapshot <vmid> <snapname> <ОПЦИИ>
Удалить снимок ВМ.
  • vmid — идентификатор ВМ;
  • snapshot — имя снимка;
  • --force <логическое значение> — удалить из файла конфигурации, даже если удаление снимков диска не удалось.
qm destroy <vmid> [ОПЦИИ]
Уничтожить ВМ и все её тома (будут удалены все разрешения, специфичные для ВМ).
  • vmid — идентификатор ВМ;
  • --destroy-unreferenced-disks <логическое значение> — дополнительно уничтожить все диски, не указанные в конфигурации, но с совпадающим VMID из всех включенных хранилищ (по умолчанию 0);
  • --purge <логическое значение> — удалить VMID из конфигураций резервного копирования и высокой доступности;
  • --skiplock <логическое значение> — игнорировать блокировки (может использовать только root).
qm disk import <vmid> <source> <storage> [ОПЦИИ]
Импортировать образ внешнего диска в неиспользуемый диск ВМ. Формат образа должен поддерживаться утилитой qemu-img.
  • vmid — идентификатор ВМ;
  • source — путь к образу диска;
  • storage — идентификатор целевого хранилища;
  • --format <qcow2 | raw | vmdk> — целевой формат.
  • --target-disk <efidisk0 | ide0 | ide1 |…> — имя диска, на который будет импортирован том (например, scsi1).
qm disk move <vmid> <disk> <storage> [ОПЦИИ]
Переместить том в другое хранилище или в другую ВМ.
  • vmid — идентификатор ВМ;
  • disk — диск, который необходимо переместить (например, scsi1);
  • storage — целевое хранилище;
  • --bwlimit <целое число> — переопределить ограничение пропускной способности ввода-вывода (в КиБ/с);
  • --delete <логическое значение> — удалить исходный диск после успешного копирования. По умолчанию 0: исходный диск сохраняется в конфигурации ВМ как неиспользуемый;
  • --digest <строка> — запретить изменения, если текущий файл конфигурации отличается от указанного контрольного значения SHA-1 (можно использовать для предотвращения одновременных изменений);
  • --format <qcow2 | raw | vmdk> — целевой формат;
  • --target-digest <строка> — запретить изменения, если текущий файл конфигурации целевой ВМ отличается от указанного контрольного значения SHA-1 (можно использовать для обнаружения одновременных модификаций);
  • --target-disk <efidisk0 | ide0 | ide1| …| virtio9 > — ключ конфигурации, в который будет перемещен диск на целевой ВМ (например, ide0 или scsi1). По умолчанию используется ключ исходного диска;
  • --target-vmid <целое число> — идентификатор целевой ВМ.
qm disk rescan [ОПЦИИ]
Пересканировать все хранилища и обновить размеры дисков и неиспользуемые образы дисков.
  • --dryrun <логическое значение> — не записывать изменения в конфигурацию ВМ (по умолчанию 0);
  • --vmid <целое число> — идентификатор ВМ.
qm disk resize <vmid> <disk> <size> [ОПЦИИ]
Увеличить размер диска.
  • vmid — идентификатор ВМ;
  • disk — диск, размер которого необходимо увеличить (например, scsi1);
  • size — новый размер. Со знаком «+» значение прибавляется к фактическому размеру тома, а без него значение принимается как абсолютное. Уменьшение размера диска не поддерживается;
  • --digest <строка> — запретить изменения, если текущий файл конфигурации отличается от указанного контрольного значения SHA-1 (можно использовать для предотвращения одновременных изменений);
  • --skiplock <логическое значение> — игнорировать блокировки (может использовать только root).
qm disk unlink <vmid> --idlist <строка> [ОПЦИИ]
Отсоединить/удалить образы дисков.
  • vmid — идентификатор ВМ;
  • --idlist <строка> — список идентификаторов дисков, которые необходимо удалить;
  • --force <логическое значение> — принудительное физическое удаление (иначе диск будет удалён из файла конфигурации и будет создана дополнительная запись конфигурации с именем unused[n], которая содержит идентификатор тома).
qm guest cmd <vmid> <команда>
Выполнить команды гостевого агента QEMU.
  • vmid — идентификатор ВМ;
  • команда — команда QGA (fsfreeze-freeze | fsfreeze-status | fsfreeze-thaw | fstrim | get-fsinfo | get-host-name | get-memory-block-info | get-memory-blocks | get-osinfo | get-time | get-timezone | get-users | get-vcpus | info | network-get-interfaces | ping | shutdown | suspend-disk | suspend-hybrid | suspend-ram).
qm guest exec <vmid> [<extra-args>] [ОПЦИИ]
Выполнить данную команду через гостевой агент.
  • vmid — идентификатор ВМ;
  • extra-args — дополнительные аргументы в виде массива;
  • --pass-stdin <логическое значение> — если установлено, читать STDIN до EOF и пересылать гостевому агенту через входные данные (по умолчанию 0). Допускается максимум 1 МБ;
  • --synchronous <логическое значение> — если установлено значение 0, возвращает pid немедленно, не дожидаясь завершения команды или тайм-аута (по умолчанию 1);
  • --timeout <целое число> — максимальное время синхронного ожидания завершения команды. Если достигнуто, возвращается pid. Для отключения следует установить значение 0 (по умолчанию 30).
qm guest exec-status <vmid> <pid>
Получить статус данного pid, запущенного гостевым агентом.
  • vmid — идентификатор ВМ;
  • pid — PID для запроса.
qm guest passwd <vmid> <username> [ОПЦИИ]
Установить пароль для данного пользователя.
  • vmid — идентификатор ВМ;
  • username — пользователь, для которого устанавливается пароль;
  • crypted <логическое значение> — если пароль уже был передан через crypt(), следует установить значение 1 (по умолчанию 0).
qm help [extra-args] [ОПЦИИ]
Показать справку по указанной команде.
  • extra-args — показать справку по конкретной команде;
  • --verbose <логическое значение> — подробный формат вывода.
qm import <vmid> <source> --storage <строка> [ОПЦИИ]
Импортировать ВМ из поддерживаемого источника импорта, например, хранилища ESXi. Опции см. команду qm create
qm importdisk
Псевдоним для qm disk import.
qm importovf <vmid> <manifest> <storage> [ОПЦИИ]
Создать новую ВМ, используя параметры, считанные из манифеста OVF.
  • vmid — идентификатор ВМ;
  • manifest — путь до файла ovf;
  • storage — идентификатор целевого хранилища;
  • --format <qcow2 | raw | vmdk> — целевой формат.
qm list [ОПЦИИ]
Вывести список ВМ узла.
  • --full <логическое значение> — определить полный статус активных ВМ.
qm listsnapshot <vmid>
Вывести список снимков ВМ.
  • vmid — идентификатор ВМ;
qm migrate <vmid> <target> [ОПЦИИ]
Перенести ВМ на целевой узел. Создаётся задача миграции.
  • vmid — идентификатор ВМ;
  • target — целевой узел;
  • --bwlimit <целое число> — переопределить ограничение пропускной способности ввода-вывода (в КиБ/с);
  • --force <логическое значение> — разрешить миграцию ВМ, использующих локальные устройства (может использовать только root);
  • --migration_network <строка> — CIDR (под)сети, которая используется для миграции;
  • --migration_type <insecure | secure> — трафик миграции по умолчанию шифруется с использованием SSH-туннеля. В изолированных сетях, в которых шифрование трафика не требуется, эту функцию можно отключить для повышения производительности;
  • --online <логическое значение> — использовать онлайн-/живую миграцию, если ВМ запущена (игнорируется, если ВМ остановлена);
  • --targetstorage <строка> — сопоставление исходных и целевых хранилищ. Предоставление только одного идентификатора хранилища сопоставляет все исходные хранилища с этим хранилищем. Если указать специальное значение 1, каждое исходное хранилище будет сопоставлено самому себе;
  • --with-conntrack-state <логическое значение> — включить миграцию состояний Conntrack (по умолчанию 0);
  • --with-local-disks <логическое значение> — включить живую миграцию хранилища для локального диска.
qm monitor <vmid>
Войти в интерфейс монитора QEMU.
  • vmid — идентификатор ВМ.
qm move-disk
Псевдоним для qm disk move.
qm move_disk
Псевдоним для qm disk move.
qm nbdstop <vmid>
Остановить встроенный сервер NBD.
  • vmid — идентификатор ВМ.
qm pending <vmid>
Получить конфигурацию ВМ с текущими и ожидающими значениями.
  • vmid — идентификатор ВМ.
qm reboot <vmid> [ОПЦИИ]
Перезагрузить ВМ. Применяет ожидающие изменения.
  • vmid — идентификатор ВМ;
  • --timeout <целое число> — максимальное время ожидания для выключения.
qm remote-migrate <vmid> [<target-vmid>] <target-endpoint> --target-bridge <строка> --target-storage <строка> [ОПЦИИ]
Перенести ВМ в удалённый кластер. Создаёт новую задачу миграции. ЭКСПЕРИМЕНТАЛЬНАЯ функция!
  • vmid — идентификатор ВМ;
  • target-vmid — идентификатор целевой ВМ;
  • target-endpoint — удалённая целевая конечная точка. Удалённая точка указывается в формате: apitoken=<API-токен PVE, включая секретное значение> ,host=<имя или IP удалённого узла> [,fingerprint=<отпечаток сертификата удаленного хоста, если ему не доверяет системное хранилище>] [,port=<целое число>];
  • --bwlimit <целое число> — переопределить ограничение пропускной способности ввода-вывода (в КиБ/с);
  • --delete <логическое значение> — удалить исходную ВМ и связанные с ней данные после успешной миграции (по умолчанию 0). По умолчанию исходная ВМ остается в исходном кластере в остановленном состоянии;
  • --online <логическое значение> — использовать онлайн-/живую миграцию, если ВМ запущена (игнорируется, если ВМ остановлена);
  • --target-bridge <строка> — сопоставление исходных и целевых мостов. Предоставление только одного идентификатора моста сопоставляет все исходные мосты с этим мостом. Предоставление специального значения 1 сопоставит каждый исходный мост с самим собой;
  • --target-storage <строка> — сопоставление исходных и целевых хранилищ. Предоставление только одного идентификатора хранилища сопоставляет все исходные хранилища с этим хранилищем. Если указать специальное значение 1, каждое исходное хранилище будет сопоставлено самому себе
qm rescan
Псевдоним для qm disk rescan.
qm reset <vmid> [ОПЦИИ]
Сбросить ВМ.
  • vmid — идентификатор ВМ;
  • --skiplock <логическое значение> — игнорировать блокировки (может использовать только root).
qm resize
Псевдоним для qm disk resize.
qm resume <vmid> [ОПЦИИ]
Возобновить работу ВМ.
  • vmid — идентификатор ВМ;
  • --nocheck <логическое значение> — не проверять, запущена ли ВМ (предназначена для внутреннего использования при миграции; может использовать только root);
  • --skiplock <логическое значение> — игнорировать блокировки (может использовать только root).
qm rollback <vmid> <snapname> [ОПЦИИ]
Откатить состояние ВМ до указанного снимка.
  • vmid — идентификатор ВМ;
  • snapname — имя снимка;
  • --start <логическое значение> — запустить ВМ после отката (по умолчанию 0). ВМ будут запускаться автоматически, если снимок включает ОЗУ.
qm sendkey <vmid> <ключ> [ОПЦИИ]
Послать нажатия клавиш на ВМ.
  • vmid — идентификатор ВМ;
  • ключ — ключ (в кодировке qemu monitor, например, ctrl-shift);
  • --skiplock <логическое значение> — игнорировать блокировки (может использовать только root).
qm set <vmid> [ОПЦИИ]
Установить параметры ВМ.
Некоторые опции:
  • vmid — идентификатор ВМ;
  • --acpi <логическое значение> — включить/отключить ACPI (по умолчанию 1);
  • --affinity <строка> — список ядер хоста, используемых для выполнения гостевых процессов, например: 0,5,8-11;
  • --agent [enabled=]<1|0> [,freeze-fs=<1|0>] [,fstrim_cloned_disks=<1|0>] [,type=<virtio|isa>] — включить/отключить связь с гостевым агентом QEMU;
  • --allow-ksm <логическое значение> — разрешить слияние страниц памяти этой гостевой системы с помощью KSM (по умолчанию 1);
  • --amd-sev [type=]<sev-type> [,allow-smt=<1|0>] [,kernel-hashes=<1|0>] [,no-debug=<1|0>] [,no-key-sharing=<1|0>] — функции защищенной зашифрованной виртуализации (SEV) процессоров AMD;
  • --arch <aarch64 | x86_64> — архитектура виртуального процессора;
  • --args <строка> — передача произвольных аргументов в KVM;
  • --audio0 device=<ich9-intel-hda|intel-hda|AC97>[,driver=<spice|none>] — настройка аудиоустройства;
  • --balloon <целое число> — объём целевой оперативной памяти для ВМ в МиБ (0 отключает Balloon Driver);
  • --bios <ovmf | seabios> — реализация BIOS (по умолчанию seabios);
  • --boot [order=<устройство[;устройство...]>] — порядок загрузки ВМ;
  • --cdrom <volume> — псевдоним опции ide2;
  • --cicustom [meta=<volume>] [,network=<volume>] [,user=<volume>] [,vendor=<volume>] — cloud-init: указать пользовательские файлы для замены автоматически созданных;
  • --cipassword <пароль> — cloud-init: пароль для пользователя. Рекомендуется использовать ключи SSH вместо пароля;
  • --citype <configdrive2 | nocloud | opennebula> — формат конфигурации cloud-init;
  • --ciupgrade <логическое значение> — cloud-init: выполнить автоматическое обновление пакета после первой загрузки (по умолчанию 1);
  • --ciuser <строка> — cloud-init: имя пользователя для изменения пароля и ключей SSH вместо настроенного пользователя по умолчанию;
  • --cores <целое число> — количество ядер на сокет (по умолчанию 1);
  • --cpu <тип> — эмулируемый тип процессора;
  • --cpulimit <целое число (0–128)> — ограничение использования процессора (по умолчанию 0);
  • --cpuunits <целое число (1–262144)> — вес ЦП для ВМ будет ограничен значением [1, 10000] в cgroup v2 (по умолчанию cgroup v1: 1024, cgroup v2: 100);
  • --delete <строка> — список настроек, которые необходимо удалить;
  • --description <строка> — описание ВМ;
  • --digest <строка> — запретить изменения, если текущий файл конфигурации отличается от указанного контрольного значения SHA-1 (можно использовать для предотвращения одновременных изменений);
  • --efidisk0 [file=]<том> [,efitype=<2m|4m>] [,format=<enum>] [,import-from=<исходный том>] [,ms-cert=<2011|2023|2023w>] [,pre-enrolled-keys=<1|0>] [,size=<размер диска>] — диск для хранения переменных EFI;
  • --force <логическое значение> — разрешить перезапись существующей ВМ (требуется опция --archive);
  • --freeze <логическое значение> — заморозить процессор при запуске;
  • --hookscript <строка> — скрипт, который будет выполняться на разных этапах жизненного цикла ВМ;
  • --hostpci[n] [описание] — сопоставить PCI-устройства хоста с гостевыми устройствами;
  • --ide[n] [описание] — использовать в качестве жёсткого диска IDE или компакт-диск (n от 0 до 3). Для выделения нового тома используется синтаксис STORAGE_ID:SIZE_IN_GiB. Для импорта из существующего тома используется STORAGE_ID:0 и параметр import-from;
  • --intel-tdx [type=]<tdx-type> ,attestation=<1|0> [,vsock-cid=<целое число>] [,vsock-port=<целое число>] — функции расширения доверенного домена (TDX) для процессоров Intel;
  • --ipconfig[n] [gw=<GatewayIPv4>] [,gw6=<GatewayIPv6>] [,ip=<IPv4Format/CIDR>] [,ip6=<IPv6Format/CIDR>] — cloud-init: указать IP-адрес и шлюз для соответствующего интерфейса;
  • --kvm <логическое значение> — включить/отключить аппаратную виртуализацию KVM (по умолчанию 1);
  • --localtime <логическое значение> — установить часы реального времени (RTC) на местное время;
  • --lock <backup | clone | create | migrate | rollback | snapshot | snapshot-delete | suspended | suspending> — заблокировать/разблокировать ВМ;
  • --machine <тип> — тип машины QEMU;
  • --memory [current=]<целое число> — свойства памяти;
  • --migrate_downtime <число> — максимально допустимое время простоя (в секундах) для миграции (по умолчанию 0,1);
  • --migrate_speed <целое число> — максимальная скорость (в МБ/с) для миграции (по умолчанию 0 — не ограничивать скорость);
  • --name <строка> — имя ВМ;
  • --nameserver <строка> — cloud-init: устанавливает IP-адрес DNS-сервера для гостевой системы;
  • --net <сеть> — сетевые устройства;
  • --numa <логическое значение> — включить/отключить NUMA (по умолчанию 0);
  • --numa[n] <топология> — топология NUMA;
  • --onboot <логическое значение> — запускать ВМ во время загрузки системы (по умолчанию 0);
  • --ostype <l24 | l26 | other | solaris | w2k | w2k3 | w2k8 | win10 | win11 | win7 | win8 | wvista | wxp> — гостевая ОС;
  • --protection <логическое значение> — установить флаг защиты ВМ (по умолчанию 0). Флаг предотвращает случайное удаление ВМ и её дисковых данных;
  • --reboot <логическое значение> — разрешить перезагрузку (по умолчанию 1). Если установлено значение 0, ВМ завершит работу при перезагрузке;
  • --revert <строка> — отменить ожидающее изменение;
  • --rng0 [source=] </dev/urandom|/dev/random|/dev/hwrng> [,max_bytes=<целое число>] [,period=<целое число>] — настроить генератор случайных чисел на основе VirtIO;
  • --sata[n] <описание> — использовать в качестве жёсткого диска SATA или компакт-диск (n от 0 до 5). Для выделения нового тома используется синтаксис STORAGE_ID:SIZE_IN_GiB. Для импорта из существующего тома используется STORAGE_ID:0 и параметр import-from;
  • --scsi[n] <описание> — использовать в качестве жёсткого диска SCSI или компакт-диск (n от 0 до 30). Для выделения нового тома используется синтаксис STORAGE_ID:SIZE_IN_GiB. Для импорта из существующего тома используется STORAGE_ID:0 и параметр import-from;
  • --scsihw <lsi | lsi53c810 | megasas | pvscsi | virtio-scsi-pci | virtio-scsi-single> — модель контроллера SCSI (по умолчанию lsi);
  • --searchdomain <строка> — cloud-init: установить домены поиска DNS для гостевой системы;
  • --serial[n] (/dev/.+|socket) — последовательное устройство внутри ВМ (n от 0 до 3);
  • --shares <целое число (0–50000)> — объем разделяемой памяти (по умолчанию 1000);
  • --skiplock <логическое значение> — игнорировать блокировки (только root может использовать эту опцию);
  • --smbios1 [base64=<1|0>] [,family=<cтрока в кодировке Base64>] [,manufacturer=<cтрока в кодировке Base64>] [,product=<cтрока в кодировке Base64>] [,serial=<cтрока в кодировке Base64>] [,sku=<cтрока в кодировке Base64>] [,uuid=<UUID>] [,version=<cтрока в кодировке Base64>] — поля SMBIOS типа 1;
  • --sockets <целое число> — количество сокетов процессора (по умолчанию 1);
  • --spice_enhancements [foldersharing=<1|0>] [,videostreaming=<off|all|filter>] — настройки для SPICE;
  • --sshkeys <путь к файлу> — cloud-init: настройка открытых ключей SSH (по одному ключу в строке, формат OpenSSH);
  • --startdate (now | YYYY-MM-DD | YYYY-MM-DDTHH:MM:SS) — установить начальную дату часов реального времени (RTC). Допустимый формат даты: now, 2006-06-17T16:01:21 или 2006-06-17 (по умолчанию = now);
  • --startup `[[порядок=]\d+] [,up=\d+] [,down=\d+] ` — поведение при запуске и выключении. Порядок — неотрицательное число, определяющее общий порядок запуска. Выключение выполняется в обратном порядке. up/down — задержка включения/выключения в секундах;
  • --tablet <логическое значение> — включить/отключить USB-планшет (по умолчанию 1);
  • --tags <строка> — теги ВМ;
  • --template <логическое значение> — включить/отключить шаблон (по умолчанию 0);
  • --tdf <логическое значение> — включить/отключить исправление дрейфа времени (time drift) (по умолчанию 0);
  • --tpmstate0 [file=]<том> [,format=<raw|qcow2|vmdk>] [,import-from=<исходный том>] [,size=<размер диска>] [,version=<v1.2|v2.0>] — настроить диск для хранения состояния TPM;
  • --usb[n] [[host=]<HOSTUSBDEVICE|spice>] [,mapping=<mapping-id>] [,usb3=<1|0>] — настройка USB-устройства (n — от 0 до 4, для версии машины >= 7.1 и ostype l26 или windows > 7, n может достигать 14);
  • --vcpus <целое число> — количество виртуальных процессоров с горячим подключением;
  • --vga [[type=]<enum>] [,clipboard=<vnc>] [,memory=<целое число>] — настройка VGA;
  • --virtio[n] <описание> — использовать жёсткий диск VIRTIO (n от 0 до 15);
  • --vmgenid <UUID> — установить идентификатор поколения ВМ (по умолчанию 1 — генерировать автоматически);
  • --vmstatestorage <строка>  — хранилище по умолчанию для томов/файлов состояния ВМ;
  • --watchdog [[model=]<i6300esb|ib700>] [,action=<enum>]  — создать сторожевое устройство виртуального оборудования.
qm showcmd <vmid> [ОПЦИИ]
Показать командную строку, которая используется для запуска ВМ (информация для отладки).
  • vmid — идентификатор ВМ;
  • --pretty <логическое значение> — поместить каждый параметр на новой строке;
  • --snapshot <строка> — получить значения конфигурации из данного снимка.
qm shutdown <vmid> [ОПЦИИ]
Выключить ВМ, отправив гостевой ОС событие ACPI. ОС должна обработать это событие и корректно завершить работу.
  • vmid — идентификатор ВМ;
  • --forceStop <логическое значение> — убедиться, что ВМ остановлена (по умолчанию 0);
  • --keepActive <логическое значение> — не деактивировать тома хранения (по умолчанию 0);
  • --skiplock <логическое значение> — игнорировать блокировки (может использовать только root);
  • --timeout <целое число> — максимальный таймаут в секундах.
qm snapshot <vmid> <snapname> [ОПЦИИ]
Сделать снимок ВМ.
  • vmid — идентификатор ВМ;
  • snapname — имя снимка;
  • --description <строка> — описание или комментарий;
  • --vmstate <логическое значение> — учитывать ОЗУ.
qm start <vmid> [ОПЦИИ]
Запустить ВМ.
  • vmid — идентификатор ВМ;
  • --force-cpu <строка> — переопределить cpu QEMU заданной строкой;
  • --machine <тип> — указывает тип компьютера QEMU (например, pc+pve0);
  • --migratedfrom <строка> — имя узла кластера;
  • --migration_network <строка> — CIDR (под)сети, которая используется для миграции;
  • --migration_type <insecure | secure> — трафик миграции по умолчанию шифруется с использованием SSH-туннеля. В изолированных сетях, в которых шифрование трафика не требуется, эту функцию можно отключить для повышения производительности;
  • --keepActive <логическое значение> — не деактивировать тома хранения (по умолчанию 0);
  • --skiplock <логическое значение> — игнорировать блокировки (может использовать только root);
  • --stateuri <строка> — некоторые команды сохраняют/восстанавливают состояние из этого места;
  • --targetstorage <строка> — сопоставление исходных и целевых хранилищ. Предоставление только одного идентификатора хранилища сопоставляет все исходные хранилища с этим хранилищем. Если указать специальное значение 1, каждое исходное хранилище будет сопоставлено самому себе;
  • --timeout <целое число> — максимальный таймаут в секундах (по умолчанию max(30, память ВМ в ГБ)).
qm status <vmid> [ОПЦИИ]
Показать статус ВМ.
  • vmid — идентификатор ВМ;
  • --verbose <логическое значение> — подробный вывод.
qm stop <vmid> [ОПЦИИ]
Остановить ВМ (аналогично отключению питания работающего компьютера). Процесс QEMU немедленно завершается.
  • vmid — идентификатор ВМ;
  • --keepActive <логическое значение> — не деактивировать тома хранения (по умолчанию 0);
  • --migratedfrom <строка> — имя узла кластера;
  • --overrule-shutdown <логическое значение> — попытаться прервать активные задачи qmshutdown перед остановкой ВМ (по умолчанию 0);
  • --skiplock <логическое значение> — игнорировать блокировки (может использовать только root);
  • --timeout <целое число> — максимальный таймаут в секундах.
qm suspend <vmid> [ОПЦИИ]
Приостановить ВМ.
  • vmid — идентификатор ВМ;
  • --skiplock <логическое значение> — игнорировать блокировки (может использовать только root);
  • --statestorage <строка> — хранилище для сохранения состояния ВМ (должна быть указана опция --todisk);
  • --todisk <логическое значение> — сохранить состояние ВМ на диск для последующего возобновления работы при следующем запуске (по умолчанию 0).
qm template <vmid> [ОПЦИИ]
Создать шаблон.
  • vmid — идентификатор ВМ;
  • --disk <диск> — если в базовый образ нужно преобразовать только один диск (например, sata1).
qm terminal <vmid> [ОПЦИИ]
Открыть терминал с помощью последовательного устройства (на ВМ должно быть настроено последовательное устройство, например, serial0: socket).
  • vmid — идентификатор ВМ;
  • --escape <строка> — escape-символ (по умолчанию ^O);
  • --iface <serial0 | serial1 | serial2 | serial3> — последовательное устройство (по умолчанию используется первое подходящее устройство).
qm unlink
Псевдоним для qm disk unlink.
qm unlock <vmid>
Разблокировать ВМ.
  • vmid — идентификатор ВМ.
qm vncproxy <vmid>
Проксировать VNC-трафик ВМ на стандартный ввод/вывод.
  • vmid — идентификатор ВМ.
qm wait <vmid> [ОПЦИИ]
Подождать, пока ВМ не будет остановлена.
  • vmid — идентификатор ВМ;
  • --timeout <1-N> — максимальный таймаут в секундах (по умолчанию — не ограничено).
Примеры использования утилиты qm:
  • создать ВМ с диском IDE размером 21 ГиБ в хранилище local-lvm, подключив ISO-образ из хранилища nfs-storage:
    # qm create 109 -ide0 local-lvm:21 -net0 e1000 -cdrom nfs-storage:iso/alt-server-11.0-x86_64.iso
    
  • запуск ВМ с VM ID 109:
    # qm start 109
    
  • отправить запрос на отключение, и дождаться остановки ВМ:
    # qm shutdown 109 && qm wait 109
    
  • отправить сочетание клавиш CTRL+SHIFT на ВМ:
    # qm sendkey 109 ctrl-shift
    
  • войти в интерфейс монитора QEMU и вывести список доступных команд:
    # qm monitor 109
    qm> help
    

    Примечание

    Для выхода из интерфейса монитора нужно выполнить команду quit или последовательно нажать CTRL+O и CTRL+C.

⁠30.4. Сценарии перехвата (hookscripts)

выполнять скрипты на узле PVE на определённых этапах жизненного цикла ВМ или контейнера: перед запуском (pre-start), после запуска (post-start), перед остановкой (pre-stop), после остановки (post-stop).
Сценарии перехвата должны находиться в хранилище, поддерживающем содержимое типа snippets (фрагменты скриптов, «мини-сценарии»).
Чтобы использовать эту функцию, создайте исполняемый файл скрипта в каталоге сниппетов. Например, для хранилища local при стандартной конфигурации это каталог /var/lib/vz/snippets), а для хранилища local-btrfs — /var/lib/pve/local-btrfs/snippets. Затем укажите скрипт в конфигурации ВМ или контейнера.

Примечание

Перед миграцией ВМ или контейнера убедитесь, что сценарий перехвата доступен на целевом узле. Хранилище со сниппетами должно быть доступно на всех узлах, на которые может выполняться миграция, либо файл должен быть другим способом размещён на целевом узле
Добавить сценарий перехвата к ВМ или контейнеру можно с помощью параметра hookscript:
# qm set <vmid> --hookscript <storage>:snippets/<script_file>
# pct set <vmid> --hookscript <storage>:snippets/<script_file>
где <script_file> — исполняемый файл сценария.
Например:
# qm set 103 --hookscript snippet:snippets/guest-hookscript.pl
update VM 103: -hookscript snippet:snippets/guest-hookscript.pl

Примечание

В настоящее время добавить сценарий перехвата можно только в командной строке. В веб-интерфейсе можно только просмотреть список скриптов в хранилище:
Хранилище snippet на узле pve01
и скрипт, добавленный к ВМ:
Скрипт-ловушка для ВМ 103
Пример сценария перехвата на Perl (файл guest-hookscript.pl):
#!/usr/bin/perl

# Example hookscript for PVE guests

use strict;
use warnings;

print "GUEST HOOK: " . join(' ', @ARGV). "\n";

# Первый аргумент — VMID

my $vmid = shift;

# Второй аргумент — этап выполнения

my $phase = shift;

if ($phase eq 'pre-start') {

    # Первый этап 'pre-start' перед запуском ВМ
    # Выход с code != 0 отменит запуск ВМ

    print "$vmid is starting, doing preparations.\n";

    # print "preparations failed, aborting."
    # exit(1);

} elsif ($phase eq 'post-start') {

    # Второй этап 'post-start' выполняется после успешного
    # запуска ВМ
    system("/root/date.sh $vmid");
    print "$vmid started successfully.\n";

} elsif ($phase eq 'pre-stop') {

    # Третий этап 'pre-stop' выполняется перед остановкой ВМ через API.
    # Не вызывается, если ВМ выключена изнутри,
    # например, с помощью 'poweroff'

    print "$vmid will be stopped.\n";
} elsif ($phase eq 'post-stop') {

    # Последний этап 'post-stop' выполняется после остановки ВМ,
    # в том числе после аварийной остановки.

    print "$vmid stopped. Doing cleanup.\n";

} else {
    die "got unknown phase '$phase'\n";
}

exit(0);
В этом примере функция system() запускает сценарий /root/date.sh, передавая VMID отдельным аргументом. Скрипт должен существовать и быть доступен для выполнения от имени пользователя, запускающего сценарий перехвата.
Текст отладки выводится в «консоль»/stdout. Текст будет помещен в журналы задач ВМ и узла PVE. Сообщения pre-start, post-start и pre-stop будут опубликованы в обоих журналах. Сообщения post-stop будут публиковаться только в журналах задач узла PVE (поскольку ВМ уже остановлена).
Выполнение скрипта guest-hookscript.pl при запуске ВМ
Пример сценария перехвата на Bash:
#!/bin/bash
if [ $2 == "pre-start" ]
then
echo "Запуск ВМ $1" >> /root/test.txt
date >> /root/test.txt
fi
В этом примере $1 — VMID, а $2 — этап выполнения сценария. При запуске ВМ на этапе pre-start скрипт записывает сообщение и дату в файл /root/test.txt.

⁠30.5. Доступ к ВМ

По умолчанию PVE предоставляет доступ к ВМ через noVNC и/или SPICE. Выбор способа подключения зависит от требуемых функций и поддержки со стороны гостевой ОС.
SPICE поддерживает дополнительные возможности, включая перенаправление USB-устройств и смарт-карт, передачу звука, динамическое изменение разрешения экрана, а также интеграцию с буфером обмена гостевой ОС. Доступность отдельных функций зависит от конфигурации ВМ и используемого клиента.
Для подключения через SPICE:
  • на хосте, с которого выполняется подключение, должен быть установлен SPICE-клиент (например, пакет virt-viewer):
  • для параметра Экран ВМ должно быть установлено значение VirtIO, SPICE (qxl) (см. Настройки дисплея).
При подключении через noVNC консоль открывается во вкладке браузера, поэтому установка отдельного клиентского приложения не требуется.
Чтобы открыть консоль ВМ, выберите её в веб-интерфейсе, нажмите кнопку Консоль и выберите нужный способ подключения в раскрывающемся меню:
Кнопка Консоль
Консоль noVNC также можно открыть, выбрав вкладку Консоль для соответствующей ВМ:
Консоль noVNC
Если требуется подключение через внешний VNC-клиент, можно настроить отдельный VNC-сервер для ВМ. Для этого в конфигурационный файл ВМ /etc/pve/qemu-server/<VMID>.conf необходимо добавить строку с указанием номера дисплея VNC (в примере — 55):
args: -vnc 0.0.0.0:55
Если требуется включить парольную аутентификацию, параметр может выглядеть так:
args: -vnc 0.0.0.0:55,password=on
Если была включена парольная аутентификация, необходимо установить пароль (после запуска ВМ). Пароль можно установить на вкладке Монитор, выполнив команду:
set_password vnc newvnc -d vnc2
В этом примере при подключении будет запрашиваться пароль: newvnc. Максимальная длина пароля VNC: 8 символов. После перезапуска ВМ пароль необходимо установить повторно.

Примечание

Номер дисплея VNC можно выбрать произвольно, но каждый номер должен встречаться только один раз. Служба VNC прослушивает порт 5900+номер_дисплея. Соединения noVNC используют номер дисплея 0 и последующие, поэтому во избежание конфликтов рекомендуется использовать более высокие номера.
Для подключения клиента VNC следует указать IP-адрес хоста с ВМ и порт (в приведенном выше примере — 5955).

⁠30.6. Внесение изменений в ВМ

После создания ВМ её конфигурацию можно изменять.
Для внесения изменений в конфигурацию ВМ необходимо:
  1. Выбрать ВМ.
  2. Перейти на вкладку Оборудование.
  3. Выбрать ресурс и нажать кнопку Редактировать.
Оборудование ВМ

Примечание

Некоторые изменения конфигурации нельзя применить без перезапуска ВМ. Такие изменения отображаются в интерфейсе как ожидающие применения (выделяются цветом) и вступают в силу после перезапуска ВМ.
Изменения конфигурации, ожидающие применения

⁠30.6.1. Управление образами виртуальных дисков

Образ виртуального диска — это файл (или набор файлов), в котором хранятся данные ВМ.
Утилита qemu-img предназначена для управления образами дисков QEMU. Она позволяет:
  • создавать образы в различных форматах;
  • конвертировать файлы-образы между форматами;
  • изменять размер;
  • получать информацию об образах;
  • выполнять операции с цепочками образов и снимками в поддерживаемых форматах.
Примеры использования утилиты qemu-img:
  • преобразование (конвертация) образа виртуального диска VMware test.vmdk в формат QCOW2:
    # qemu-img convert -f vmdk test.vmdk -O qcow2 test.qcow2
    
  • создание образа test.raw в формате RAW размером 40 ГиБ:
    # qemu-img create -f raw test.raw 40G
    
  • изменение размера образа test.raw до 80 ГиБ:
    # qemu-img resize -f raw test.raw 80G
    
  • просмотр информации об образе:
    # qemu-img info test.raw
    
В веб-интерфейсе PVE управление дисками осуществляется на вкладке Оборудование. После выбора образа диска доступны действия: Добавить, Отключить, Редактировать, Переместить хранилище, Переназначить владельца, Изменить размер:
Управление образом виртуального диска

⁠30.6.1.1. Добавление виртуального диска в ВМ

Для добавления виртуального диска необходимо:
  1. Перейти на вкладку Оборудование.
  2. Нажать кнопку Добавить → Жесткий диск:
    Кнопка «Добавить» → «Жесткий диск»
  3. Указать параметры диска и нажать кнопку Добавить:
    Параметры добавления жесткого диска

⁠30.6.1.2. Удаление образа виртуального диска

Чтобы отключить виртуальный диск от ВМ, необходимо:
  1. Перейти на вкладку Оборудование.
  2. Выбрать виртуальный диск.
  3. Нажать кнопку Отключить.
  4. Подтвердите действие, нажав кнопку Да в окне подтверждения.
После отключения диск отсоединяется от ВМ, но его данные не удаляются. В списке оборудования ВМ он отображается как Неиспользуемый диск:
Неиспользуемый диск
Чтобы удалить неиспользуемый диск вместе с данными, необходимо выбрать его и нажать кнопку Удалить. Перед подтверждением операции следует убедиться, что диск больше не нужен: удаление может привести к безвозвратной потере данных.
Если диск был отключён по ошибке, его можно подключить повторно:
  1. Выбрать неиспользуемый диск.
  2. Нажать кнопку Редактировать.
  3. При необходимости изменить параметры Шина/Устройство:
    Подключение неиспользуемого диска
  4. Нажать кнопку Добавить.

⁠30.6.1.3. Изменение размера диска

Примечание

Операция изменения размера виртуального диска предназначена для увеличения его размера. Уменьшение размера таким способом не поддерживается.
При увеличении размера виртуального диска автоматически не расширяются разделы и файловые системы внутри гостевой ОС. После изменения размера диска при необходимости следует расширить разделы и файловые системы средствами гостевой ОС.
Для увеличения размера виртуального диска необходимо:
  1. Перейти на вкладку Оборудование.
  2. Выбрать виртуальный диск.
  3. Нажать кнопку Действие над диском → Изменить размер.
  4. В поле Увеличение размера (ГиБ) указать значение, на которое необходимо увеличить размер диска.
    Например, если размер диска составляет 20 ГиБ и его необходимо увеличить до 30 ГиБ, следует указать 10:
    Изменение размера диска
  5. Нажать кнопку Изменить размер диска.
Для изменения размера виртуального диска из командной строки используется команда:
# qm resize <vm_id> <virtual_disk> [+]<size>

Примечание

Если перед размером указать знак «+», заданное значение будет прибавлено к текущему размеру диска. Без знака «+» задаётся итоговый размер диска. Уменьшение размера диска не поддерживается.
Например:
  • изменение размера диска scsi1 ВМ с идентификатором 100 до 80 ГиБ:
    # qm resize 100 scsi1 80G
  • увеличение размера этого диска на 10 ГиБ:
    # qm resize 100 scsi1 +10G

⁠30.6.1.4. Перемещение диска в другое хранилище

Образы виртуальных дисков могут перемещаться из одного хранилища в другое в пределах одного кластера.
Для перемещения виртуального диска необходимо:
  1. Перейти на вкладку Оборудование.
  2. Выбрать виртуальный диск.
  3. Нажать кнопку Действие над диском → Переместить хранилище.
  4. В раскрывающемся списке Целевое хранилище выбрать хранилище, в которое необходимо переместить диск:
    Диалоговое окно перемещения диска
  5. В раскрывающемся списке Формат выбрать формат образа (этот параметр полезен для преобразования образа диска из одного формата в другой).
  6. При необходимости отметить пункт Удалить источник, чтобы удалить исходный диск после успешного перемещения.
  7. Нажать кнопку Переместить диск.
Для перемещения виртуального диска из командной строки используется команда:
# qm move-disk <vm_id> <virtual_disk> <storage>

⁠30.6.1.5. Переназначение диска другой ВМ

При переназначении виртуальный диск отсоединяется от исходной ВМ и подключается к целевой ВМ. Данные на диске при этом не должны изменяться, однако доступ к ним и возможность загрузки зависят от совместимости диска с целевой ВМ и установленной в ней ОС.
Для переназначения виртуального диска другой ВМ необходимо:
  1. Перейти на вкладку Оборудование.
  2. Выбрать виртуальный диск.
  3. Нажать кнопку Действие над диском → Переназначить владельца.
  4. В раскрывающемся списке Целевая гостевая система выбрать ВМ, к которой необходимо подключить диск:
    Диалоговое окно переназначения диска
  5. Выбрать параметры в раскрывающемся списке Шина/Устройство;
  6. Нажать кнопку Переназначить диск.
Команда переназначения образа диска другой ВМ:
# qm move-disk <vm_id> <virtual_disk> --target-vmid <vm_id> --target-disk <virtual_disk>
Пример переназначения диска scsi0 от ВМ с идентификатором 107 ВМ с идентификатором 10007 в качестве устройства scsi1:
# qm move-disk 107 scsi0 --target-vmid 10007 --target-disk scsi1

⁠30.6.2. Настройки дисплея

Настройки дисплея
QEMU поддерживает несколько типов виртуальных графических устройств, например:
  • std (Стандартный VGA) — эмулирует VGA-адаптер с расширениями Bochs VBE;
  • vmware (Совместим с VMware) — эмулирует графический адаптер VMware SVGA II;
  • qxl (SPICE) — паравиртуализированный графический адаптер. При выборе этого типа автоматически включается поддержка SPICE (протокол удалённого доступа к экрану ВМ);
  • virtio (VirtIO-GPU) — паравиртуализированный графический адаптер VirtIO;
  • virtio-gl (VirGL GPU) — графическое устройство с поддержкой 3D-ускорения, позволяющее использовать графические ресурсы хоста.

Примечание

Для типов дисплеев VirtIO и VirGL поддержка SPICE включена по умолчанию.

Примечание

Для подключения к SPICE-серверу можно использовать SPICE-совместимый клиент (например, remote-viewer из пакета virt-viewer).
В настройках дисплея можно изменить объём памяти, выделяемой виртуальному графическому устройству (поле Память (MiB)). Доступный объём видеопамяти влияет поддерживаемые разрешения экрана (особенно при использовании SPICE/QXL) и работу нескольких мониторов.
Поскольку память резервируется каждым устройством дисплея, выбор режима нескольких мониторов для SPICE (например, qxl2 для двух мониторов) имеет следующие особенности:
  • ВМ с ОС Windows
    Для каждого монитора требуется отдельное устройство. Поэтому PVE добавляет дополнительное устройство на каждый монитор, и каждому устройству выделяется указанный объём памяти.
  • ВМ с ОС Linux
    Используется одно устройство с поддержкой нескольких виртуальных мониторов, однако при выборе многомониторного режима объём памяти устройства умножается на количество мониторов.
Выбор типа дисплея serialX (Терминал) отключает графический VGA-выход и перенаправляетконсоль ВМ на соответствующий последовательный порт. В этом режиме параметр видеопамяти не используется.

⁠30.6.3. Дополнительные функции SPICE

В PVE можно включить дополнительные функции SPICE:
  • общий доступ к папкам — позволяет получить доступ из ВМ к папке, выбранной на компьютере, с которого выполняется подключение к ВМ через SPICE-клиент;
  • потоковое видео — позволяет кодировать области экрана, которые часто обновляются, в видеопоток.
Включение дополнительных функций SPICE:
  • в веб-интерфейсе: выбрать пункт Улучшения SPICE в разделе Параметры ВМ:
    PVE. Дополнительные функции SPICE
  • в командной строке:
    # qm set VMID -spice_enhancements foldersharing=1,videostreaming=all
    

Примечание

Для использования дополнительных функций SPICE в параметре Экран должно быть выбрано значение VirtIO или SPICE (qxl) (см. Настройки дисплея).

⁠30.6.3.1. Общий доступ к папкам

Для доступа к общей папке внутри ВМ должен быть установлен пакет spice-webdavd. Он обеспечивает доступ к перенаправленной папке через локальный сервер WebDAV по адресу http://localhost:9843.

Примечание

Чтобы открыть общий доступ к папке, в меню remote-viewer необходимо выбрать пункт Настройки (Preferences), включить параметр Общая папка, которую необходимо сделать доступной в ВМ:
virt-viewer. Настройка общего доступа к папке
Если общая папка недоступна в ВМ, проверьте, запущена ли служба WebDAV (spice-webdavd). Также может потребоваться перезапуск SPICE-сеанса.

Примечание

Для доступа к общей папке через файловый менеджер, а не через браузер, в гостевой ОС должен быть установлен пакет davfs2.
Доступ к общей папке через файловые менеджеры:
  • Dolphin — выбрать пункт Сеть → Сетевые службы → Сетевой каталог WebDav → Spice client folder;
  • Thunar, Файловый менеджер GNOME — в адресной строке ввести адрес с указанием протокола dav или davs (dav://localhost:9843/).

⁠30.6.3.2. Потоковое видео

Для параметра videostreaming доступны следующие значения:
  • all — области экрана, которые часто обновляются, кодируются в видеопоток;
  • filter — применение потокового видео определяется фильтрами SPICE-клиента.

⁠30.6.4. Проброс USB

В PVE доступны два способа проброса USB-устройств в ВМ:
  • динамический проброс через SPICE (SPICE USB Passthrough) — USB-устройство подключается к ВМ во время работы, если ВМ запущена и используется совместимый SPICE-клиент;
  • прямой проброс USB с хоста (Host USB Passthrough) — USB-устройство хоста передаётся в управление ВМ и становится недоступным для обычного использования на хосте.
В PVE также можно сопоставлять USB-устройства на уровне кластера. Сопоставление позволяет корректно выполнять миграцию ВМ в HA-кластере, автоматически обнаруживать изменения оборудования и предоставлять пользователям без прав root возможность управления устройствами. Подробнее см. Сопоставление устройств.
Чтобы добавить USB-устройство в конфигурацию ВМ, выполните следующие действия:
  1. Перейдите на вкладку Оборудование;
  2. Нажмите кнопку Добавить → USB-устройство:
    Кнопка «Добавить» → «USB-устройство»
  3. Выберите режим проброса:
    • Порт Spice — динамический проброс через SPICE-клиент (устройство выбирается в клиенте во время сеанса):
      Порт Spice
    • Использовать сопоставленное устройство — проброс устройства, зарегистрированного в кластере:
      Проброс сопоставленного устройства
    • Использовать идентификатор производителя/устройства USB — проброс устройства по идентификаторам производителя и устройства (VID:PID):
      Проброс конкретного USB-устройства
      Устройство можно выбрать в списке Выберите устройство или указать его идентификаторы вручную в формате <ID-производителя>:<ID-устройства> (идентификаторы можно получить из вывода команды lsusb).
    • Использовать USB-порт — проброс физического USB-порта (устройство, подключённое к этому порту, будет передаваться ВМ):
      Использовать USB-порт
      Порт можно выбрать в списке Выберите порт или указать вручную в формате <Номер_шины>:<Путь_к_порту> (информацию о шине и пути к порту можно получить с помощью команды lsusb -t).
  4. Нажать кнопку Добавить.
  5. Остановить и запустить ВМ, чтобы применить изменение конфигурации (обычная перезагрузка не применяет изменения конфигурации).
Примеры добавления USB-устройств в консоли:
  • добавление порта Spice:
    # qm set 100 --usb3 spice
    update VM 100: -usb3 spice
    
  • проброс конкретного USB-устройства:
    # qm set 100 --usb4 host=346d:5678
    update VM 100: -usb4 host=346d:5678
    

Примечание

При использовании SPICE Passthrough устройство можно подключать и отключать динамически через меню SPICE-клиента:
Выбор USB-устройства в SPICE-клиенте

Примечание

Сведения об USB-устройствах можно получить на вкладке Монитор с помощью следующих команд:
  • info usb — информация об USB-устройствах, подключённых к гостевой системе;
  • info usbhost — информация об USB-устройствах, обнаруженных на хосте.
Список USB-устройств гостевой системы и хоста
Если в конфигурации ВМ указан конкретный VID:PID или bus:port, а устройство отсутствует на хосте, ВМ может запуститься без этого устройства. Когда соответствующее устройство или порт станет доступен, PVE сможет передать его ВМ.

Предупреждение

Прямой проброс USB-устройства с использованием host=VID:PID или host=bus:port привязывает устройство к текущему хосту и не позволяет выполнять онлайн-миграцию ВМ на другой узел с этим устройством. Для миграции необходимо учитывать доступность подходящего устройства на целевом узле и ограничения PVE.
Сопоставление USB-устройств позволяют выполнять оффлайн-миграцию ВМ на узлы, где зарегистрировано то же устройство.

⁠30.6.5. BIOS и UEFI

По умолчанию в качестве прошивки ВМ используется SeaBIOS, эмулирующий классический BIOS для архитектуры x86. В качестве альтернативы можно выбрать OVMF — реализацию прошивки UEFI.
При использовании OVMF необходимо учитывать следующие особенности:
  • Для сохранения настроек прошивки, в том числе порядка загрузки, требуется EFI-диск. Этот диск:
    • включается в резервные копии и снимки ВМ;
    • может быть только один;
    • после создания параметры диска изменить нельзя — его можно только удалить и создать заново.
  • При использовании виртуального дисплея (без сквозной передачи GPU) необходимо:
    • либо установить требуемое разрешение в меню OVMF (вызывается нажатием Esc во время загрузки);
    • либо выбрать тип дисплея SPICE.
  • Для PXE-загрузки необходимо добавить в ВМ устройство генератора случайных чисел (RNG). В противном случае прошивка OVMF блокирует PXE-загрузку из соображений безопасности.
Пример настройки UEFI для ВМ:
  1. Измените тип прошивки на UEFI:
    PVE. Настройка BIOS
  2. Добавьте в конфигурацию ВМ EFI-диск:
    PVE. Добавление диска EFI
  3. Укажите параметры EFI-диска:
    PVE. Параметры диска EFI
Для создания EFI-диска из командной строки используется команда:
# qm set <vm_id> -efidisk0 <storage>:1,format=<format>,efitype=4m,pre-enrolled-keys=1
где:
  • <storage> — идентификатор хранилища, в котором будет размещён EFI-диск;
  • <format> — формат диска, поддерживаемый выбранным хранилищем;
  • efitype — тип (размер) EFI-диска. Для новых ВМ рекомендуется использовать значение 4m (значение по умолчанию в графическом интерфейсе);
  • pre-enrolled-keys — определяет, добавляются ли в EFI-диск предварительно зарегистрированные ключи Secure Boot. При значении 1 используются предварительно зарегистрированные ключи, включая стандартные ключи Microsoft.

⁠30.6.6. Доверенный платформенный модуль (TPM)

TPM (англ. Trusted Platform Module) — спецификация, определяющая требования к модулю доверенной платформы, предназначенному для выполнения криптографических операций и защиты криптографических ключей. Термин также используют для обозначения аппаратных и программных реализаций TPM.
Виртуальное устройство TPM можно добавить:
  • при создании ВМ (вкладка Система);
  • в конфигурацию уже созданной ВМ.
В PVE состояние виртуального TPM хранится в специальном томе. Формат и возможности хранения зависят от типа хранилища. Использование формата QCOW2 позволяет:
  • создавать снапшоты ВМ с TPM;
  • использовать файловые хранилища (например, NFS или CIFS);
  • применять механизм Snapshots as Volume Chains (технология в статусе preview).
Чтобы добавить TPM в веб-интерфейсе, выберите Добавить → Функция включения доверенного платформенного модуля:
PVE. Добавление TPM в веб-интерфейсе

Примечание

После создания TPM изменить его параметры непосредственно нельзя. Чтобы использовать другие параметры, необходимо удалить устройство и создать его заново.
Для добавления TPM из командной строки используется команда:
# qm set <vm_id> -tpmstate0 [file=]<volume>[,format=<raw|qcow2|vmdk>][,import-from=<source volume>][,size=<размер диска>][,version=<v1.2|v2.0>]
где:
  • <volume> — том для хранения состояния TPM. Для создания нового тома указывают идентификатор хранилища и размер в формате STORAGE_ID:SIZE_IN_GiB (например, nfs-storage:1);
  • format — формат хранения состояния TPM (raw, qcow2, vmdk);
  • import-from — источник для импорта существующего состояния TPM;
  • size — размер тома (фактически игнорируется, используется фиксированный размер 4 МиБ);
  • version — версия TPM (v1.2 или v2.0).
Пример добавления TPM 2.0:
# qm set 104 --tpmstate0 nfs-storage:1,format=qcow2,version=v2.0
Для импорта существующего состояния укажите размер 0 и параметр import-from:
# qm set 104 --tpmstate0 local:0,import-from=local:existing-tpm-state

Примечание

Перед импортом необходимо проверить, что исходный том содержит совместимое состояние TPM и доступен для выбранной операции.

Примечание

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

Примечание

Некоторые гостевые ОС (например, Windows 11) требуют TPM 2.0 для установки или работы отдельных функций.

⁠30.6.7. Проброс PCI(e)

Проброс PCI(e) позволяет виртуальной машине напрямую использовать PCI(e)-устройство хоста.

Примечание

После передачи устройства ВМ хост и другие ВМ не могут использовать его обычным образом.
Для проброса PCI(e) требуется поддержка IOMMU (I/O Memory Management Unit) со стороны оборудования и прошивки хоста.
Для настройки проброса необходимо:
  1. Включить поддержку IOMMU в BIOS/UEFI хоста.
  2. Настроить параметры ядра. Для процессоров Intel — передать ядру параметр intel_iommu=on. Для процессоров AMD поддержка IOMMU обычно включается автоматически.
  3. Убедиться, что загружены следующие модули VFIO (при необходимости добавьте их в файл /etc/modules):
    vfio
    vfio_iommu_type1
    vfio_pci
    vfio_virqfd
    
  4. Перезагрузить хост, чтобы изменения вступили в силу.
  5. Убедиться, что проброс действительно включен:
    # dmesg | grep -e DMAR -e IOMMU -e AMD-Vi
    
Наиболее распространённый вариант проброса PCI(e) — проброс всей PCI(e)-карты (например, GPU или сетевой карты). В этом случае хост не должен использовать данное устройство. Этого можно добиться двумя способами:
  1. Передать идентификаторы устройств модулю vfio-pci. Для этого добавьте, например, в файл /etc/modprobe.d/vfio.conf строку:
    options vfio-pci ids=1234:5678,4321:8765
    где 1234:5678 и 4321:8765 — идентификаторы производителя (vendor ID) и устройства (device ID).
    Получить идентификаторы можно с помощью команды:
    # lspci -nn
    
  2. Запретить загрузку драйвера устройства на хосте. Для этого в файл /etc/modprobe.d/blacklist.conf добавляют строку:
    blacklist DRIVERNAME
После внесения изменений необходимо перезагрузить систему.
Добавить PCI(e)-устройство в ВМ можно следующими способами:
  • в веб-интерфейсе: разделе Оборудование выбрать Добавить → Устройство PCI:
    PVE. Добавление устройства PCI в веб-интерфейсе
    В веб-интерфейсе одной ВМ можно назначить до 16 устройств PCI(e).
  • в командной строке:
    # qm set VMID -hostpci0 00:02.0
    
    Если устройство имеет несколько функций (например, 00:02.0 и 00:02.1), можно использовать сокращённый синтаксис 00:02, чтобы передать все функции устройства. Это соответствует включению параметра Все функции в веб-интерфейсе.
В конфигурации проброса можно переопределить идентификаторы, которые будут предъявляться гостевой системе. Для этого используются параметры vendor-id, device-id, sub-vendor-id и sub-device-id. Эти параметры не изменяют фактические идентификаторы физического устройства на хосте. Например:
# qm set VMID -hostpci0 02:00,device-id=0x10f6,sub-vendor-id=0x0000

⁠30.6.8. Сопоставление устройств

При использовании локальных ресурсов, например PCI(e)-устройств, прямое указание адресов или идентификаторов устройств может создавать проблемы:
  • на разных узлах кластера могут находиться устройства с одинаковыми идентификаторами или разными адресами; при перемещении ВМ между узлами HA может ошибочно назначить неподходящее устройство, что приведёт к нарушению конфигурации;
  • при замене или обновлении оборудования адреса и идентификаторы устройств могут измениться, что потребует проверки конфигурации ВМ.
Для упрощения управления устройствами в кластере можно использовать сопоставления ресурсов. Сопоставление позволяет:
  • назначить устройству логическое имя в конфигурации кластера;
  • связать это имя с соответствующими физическими устройствами на разных узлах.
Для создания сопоставления в веб-интерфейсе:
  1. Перейдите на вкладку Центр обработки данных → Сопоставления ресурсов.
  2. В разделе Устройства PCI или USB-устройства нажмите кнопку Добавить:
    PVE. Сопоставления ресурсов
  3. В открывшемся окне укажите имя сопоставления, узел и устройство.
    Добавление сопоставления PCI:
    PVE. Добавление сопоставления PCI
    Добавление сопоставления USB:
    PVE. Добавление сопоставления USB
  4. Нажмите кнопку Создать.
  5. После создания сопоставления добавьте в него устройства на других узлах кластера с помощью кнопки в строке сопоставления:
    PVE. Добавление устройства в сопоставление на другом узле
    Результат добавления сопоставления:
    PVE. Сопоставление устройств
Для создания сопоставления из командной строки используется команда:
# pvesh create /cluster/mapping/<тип> <опции>
где:
  • <тип> — тип оборудования (pci или usb);
  • <опции> — параметры сопоставления и сведения об устройствах на узлах кластера.
Для каждого узла, на котором устройство должно быть доступно, необходимо указать соответствующее устройство. Сведения в сопоставлении должны позволять идентифицировать устройство на каждом узле.
Пример создания сопоставления PCI-устройства с разными адресами на двух узлах кластера:
# pvesh create /cluster/mapping/pci --id device \
--map node=pve01,path=0000:01:00.0,id=0002:0001 \
--map node=pve02,path=0000:02:00.0,id=0002:0001
Параметр map указывается для каждого узла, на котором должно быть доступно соответствующее устройство.

Примечание

Каждому сопоставлению USB-устройств на узле соответствует одно устройство.
Одно физическое PCI-устройство может предоставлять несколько виртуальных функций (VF) на узле. Если такое устройство назначено гостевой системе, при запуске ВМ автоматически выбирается первое свободное устройство из списка сопоставленных. Порядок проверки устройств соответствует порядку их указания в конфигурации, это позволяет реализовать произвольные политики распределения (например, приоритизацию определенных устройств).
Назначить сопоставленное устройство ВМ можно через веб-интерфейс (см. разделы Проброс USB и Проброс PCI(e)) или в командной строке:
  • для PCI(e)-устройства:
    # qm set <vmid> -hostpci0 <сопоставление>
    
  • для USB-устройства:
    # qm set <vmid> -usb0 <сопоставление>
    
где:
  • <vmid> — идентификатор ВМ;
  • <сопоставление> — имя созданного сопоставления.
Для создания сопоставлений требуется привилегия Mapping.Modify на /mapping/<тип>/<сопоставление> (где <тип> — тип устройства, <сопоставление> — имя сопоставления). Для использования сопоставлений требуется привилегия Mapping.Use на /mapping/<тип>/<сопоставление>, а также необходимые привилегии для изменения конфигурации ВМ.

⁠30.6.9. VirtioFS (проброс каталогов)

VirtioFS — механизм совместного доступа к каталогам хоста из ВМ. Он позволяет обмениваться файлами без использования сетевого протокола для доступа к общему каталогу.
Для работы VirtioFS в гостевой ОС Linux требуется поддержка VirtioFS со стороны ядра и наличие соответствующего драйвера.
Для использования VirtioFS на узлах PVE, на которых могут запускаться соответствующие ВМ, должен быть установлен пакет virtiofsd:
# apt-get install virtiofsd

Примечание

Пакет virtiofsd не входит в состав ISO-образа дистрибутива. Его можно установить из репозитория p11.
Для проброса каталога в ВМ необходимо:
  1. Настроить сопоставление каталогов.
  2. Добавить устройство VirtioFS в ВМ.

⁠30.6.9.1. Настройка сопоставления каталогов

Создание сопоставления (веб-интерфейс):
  1. Перейдите на вкладку Центр обработки данных → Сопоставление каталогов.
  2. Нажмите кнопку Добавить:
    PVE. Сопоставление каталогов
  3. Укажите название сопоставления, узел, абсолютный путь к каталогу:
    PVE. Добавление сопоставления на узле pve01

    Примечание

    Указанный каталог должен существовать на соответствующем узле.
  4. Нажмите кнопку Создать.
После создания сопоставления добавьте пути для других узлов кластера, с помощью кнопки в строке соответствующего сопоставления:
PVE. Добавление каталога в сопоставление на другом узле
Пример добавления сопоставления каталогов в командной строке:
# pvesh create /cluster/mapping/dir --id sharedir \
--map node=pve01,path=/mnt/share \
--map node=pve02,path=/backup/share \
--map node=pve03,path=/mnt/share

⁠30.6.9.2. Добавление VirtioFS в ВМ

Для добавления VirtioFS к ВМ:
  1. Перейдите на вкладку Оборудование.
  2. Нажмите кнопку Добавить → Virtiofs (паравиртуальная файловая система):
    Кнопка «Добавить» → «Virtiofs (паравиртуальная файловая система)»
  3. В открывшемся окне укажите параметры:
    • ID каталога — идентификатор сопоставления (каталог должен быть предварительно настроен);
    • Кэш — режим кеширования (always, never, metadata или auto);
    • Поддержка xattr — разрешение на передачу расширенных атрибутов файлов;
    • POSIX ACL — разрешение на передачу списков контроля доступа POSIX (автоматически включает xattr);
    • Разрешить прямой ввод/вывод — использование флага O_DIRECT при выполнении операций ввода-вывода.
    Проброс VirtioFS
  4. Нажмите кнопку Добавить.
Примеры добавления VirtioFS к ВМ в командной строке:
# qm set 100 --virtiofs1 dirid=sharedir,cache=auto,expose-acl=1
# qm set 101 --virtiofs0 dirid=media,cache=always
Чтобы временно смонтировать VirtioFS в ВМ с драйвером ядра Linux virtiofs, необходимо выполнить следующую команду внутри ВМ:
# mount -t virtiofs <dirid> <точка монтирования>
Например:
# mount -t virtiofs sharedir /mnt/pve_share
Для постоянного монтирования VirtioFS можно создать запись в /etc/fstab:
<dirid> <точка монтирования> virtiofs rw,relatime 0 0

⁠30.6.10. Гостевой агент QEMU

Гостевой агент QEMU (QEMU Guest Agent) — служба, работающая внутри ВМ и обеспечивающая взаимодействие между узлом PVE и гостевой ОС. Агент позволяет выполнять команды в гостевой системе и передавать передавать узлу PVE служебную информацию. Например, IP-адреса ВМ отображаются на панели Сводка с использованием данных, полученных от гостевого агента.
Для корректной работы гостевого агента необходимо:
  • установить агент в гостевой системе и убедиться, что он запущен;
  • включить взаимодействие между агентом и PVE.
Установка гостевого агента в ВМ с ОС «Альт»:
  1. Установите пакет qemu-guest-agent:
    # apt-get install qemu-guest-agent
    
  2. Добавьте службу в автозапуск и запустите её:
    # systemctl enable --now qemu-guest-agent
    
Установка гостевого агента в ВМ с ОС «Windows»:
  1. Скачайте и установите драйверы Virtio.
  2. Скачайте и установите программное обеспечение QEMU Guest Agent.
  3. Убедитесь, что служба QEMU Guest Agent присутствует в списке запущенных служб.
Связь PVE с гостевым агентом можно включить:
  • в веб-интерфейсе: на вкладке Параметры соответствующей ВМ:
    PVE. Включить связь с гостевым агентом QEMU
  • в командной строке:
    # qm set <vmid> --agent 1
Для вступления изменений в силу необходим перезапуск ВМ.
Если включена опция Выполнять команду «trim» для гостя после перемещения диска или миграции ВМ, PVE отправляет гостевой ОС команду TRIM после следующих операций:
  • перемещения диска в другое хранилище;
  • живой миграция ВМ на другой узел, если используется локальное хранилище.
В хранилищах с тонким выделением ресурсов (thin provisioning) это позволяет освободить неиспользуемое пространство при условии поддержки необходимого механизма всеми компонентами системы.
Связь с гостевым агентом осуществляется через UNIX-сокет, расположенный в /var/run/qemu-server/<my_vmid>.qga. Проверить доступность агента можно командой:
# qm agent <vmid> ping
Если агент корректно установлен и запущен в ВМ, вывод команды будет пустой.

⁠30.7. Файлы конфигурации ВМ

Файлы конфигурации ВМ хранятся в кластерной файловой системе PVE в каталоге /etc/pve/qemu-server/. Имя файла соответствует идентификатору ВМ: <VMID>.conf. Файлы доступны на всех узлах кластера благодаря механизму репликации конфигурации в кластерной файловой системе.

Примечание

Идентификаторы ВМ меньше 100 зарезервированы для внутренних целей. Идентификаторы ВМ должны быть уникальными в пределах кластера.
Пример файла конфигурации:
boot: order=scsi0;net0
cores: 1
cpu: x86-64-v2-AES
efidisk0: local-lvm:vm-100-disk-2,efitype=4m,pre-enrolled-keys=1,size=4M
memory: 2048
meta: creation-qemu=9.1.2,ctime=1746532273
name: NewVM
net0: virtio=BC:24:11:40:5F:C3,bridge=vmbr0,firewall=1
numa: 0
ostype: l26
scsi0: local-lvm:vm-100-disk-0,size=52G
scsihw: virtio-scsi-single
smbios1: uuid=cafd8016-03d3-4514-8d6f-5f4e353e5936
sockets: 1
spice_enhancements: foldersharing=1
unused0: local-lvm:vm-100-disk-1
unused1: newCIFS:100/vm-100-disk-0.qcow2
usb0: host=090c:1000
usb1: spice
usb2: spice
usb3: host=346d:5678
vga: qxl
vmgenid: 31f7faef-4014-453b-ba8d-801e5634cc08
Файлы конфигурации используют простой формат пар «ключ–значение», разделённых двоеточием. Пустые строки игнорируются, а строки, начинающиеся с символа #, считаются комментариями. Пример:
OPTION: value
Для изменения конфигурации ВМ рекомендуется использовать команду qm или веб-интерфейс PVE. При ручном редактировании файла конфигурации для применения изменений требуется перезапуск ВМ.
При создании снимка PVE сохраняет конфигурацию ВМ на момент создания снимка в отдельной секции того же файла конфигурации. Например, после создания снимка snapshot файл будет содержать секцию [snapshot] с параметрами ВМ на момент создания снимка. Свойство parent используется для хранения связей между снимками, а snaptime содержит время создания снимка в формате Unix time (количество секунд с начала эпохи Unix):
boot: order=scsi0;net0
…
parent: snapshot
…
vmgenid: 31f7faef-4014-453b-ba8d-801e5634cc08

[snapshot]
boot: order=scsi0;net0
cores: 1
cpu: x86-64-v2-AES
efidisk0: local-lvm:vm-100-disk-2,efitype=4m,pre-enrolled-keys=1,size=4M
memory: 2048
meta: creation-qemu=9.1.2,ctime=1746532273
name: NewVM
net0: virtio=BC:24:11:40:5F:C3,bridge=vmbr0,firewall=1
numa: 0
ostype: l26
parent: first
runningcpu: qemu64,+aes,enforce,+kvm_pv_eoi,+kvm_pv_unhalt,+pni,+popcnt,+sse4.1,+sse4.2,+ssse3
runningmachine: pc-i440fx-9.1+pve0
scsi0: local-lvm:vm-100-disk-0,size=52G
scsihw: virtio-scsi-single
smbios1: uuid=cafd8016-03d3-4514-8d6f-5f4e353e5936
snaptime: 1746609190
sockets: 1
spice_enhancements: foldersharing=1
usb0: host=090c:1000
usb1: spice
usb2: spice
usb3: host=346d:5678
vga: qxl
vmgenid: 31f7faef-4014-453b-ba8d-801e5634cc08
vmstate: local-lvm:vm-100-state-snapshot

⁠Глава 31. Создание и настройка контейнера LXC

⁠31.1. Создание контейнера в графическом интерфейсе

Перед созданием контейнера можно загрузить шаблоны LXC в хранилище. Это можно сделать через веб-интерфейс (см. раздел Управление ISO-образами и шаблонами LXC).

Примечание

PVE позволяет создавать системные контейнеры на основе совместимых OCI-образов. Загрузить OCI-образ в хранилище можно через веб-интерфейс (см. раздел Загрузка OCI-образа).
OCI (Open Container Initiative) — организация, разрабатывающая открытые стандарты контейнерных технологий. OCI определяет, в частности, спецификации форматов образов и сред выполнения контейнеров. Эти стандарты используются различными контейнерными платформами, включая Docker и Podman.
Для создания контейнера необходимо нажать кнопку Создать контейнер, расположенную в правом верхнем углу веб-интерфейса PVE:
Кнопка Создать контейнер
Создание контейнера выполняется с помощью мастера настройки.
На вкладке Общее необходимо указать следующие параметры:
  • Узел — узел кластера, на котором будет размещён контейнер;
  • CT ID — уникальный числовой идентификатор контейнера в кластере;
  • Имя хоста — имя контейнера;
  • Непривилегированный контейнер — определяет, будет ли контейнер привилегированным или непривилегированным. По умолчанию создаётся непривилегированный контейнер, который обеспечивает более высокий уровень изоляции и рекомендуется, если приложениям не требуются особые привилегии;

    Примечание

    Непривилегированный контейнер
    Процессы внутри такого контейнера не имеют прямых прав root на хост-системе. Пользователь root внутри контейнера сопоставляется с непривилегированным UID на хосте. Это повышает безопасность и рекомендуется, если приложениям не требуются полномочия администратора.
    Привилегированный контейнер
    Пользователь root внутри контейнера обладает теми же правами, что и root на хосте. Такой режим обеспечивает полную совместимость, но создаёт серьёзные риски при компрометации контейнера. Привилегированные контейнеры следует использовать только в доверенных средах.
  • Вложенность — разрешает использование вложенных контейнеров и связанных с ними возможностей;
  • Добавить в HA — добавление контейнера в качестве ресурса высокой доступности (подробнее см. раздел Кластер высокой доступности);

    Примечание

    Для добавления контейнера в качестве ресурса высокой доступности при его создании пользователь должен иметь право доступа Sys.Console.
  • Пул ресурсов — пул, в который необходимо включить контейнер. Чтобы выбрать пул, его необходимо предварительно создать;
  • Пароль — пароль пользователя root внутри контейнера;
  • Открытый ключ(и) SSH — открытый ключ или ключи, используемые аутентификации по SSH.
Вкладка Общее диалога создания контейнера

Примечание

Диапазон идентификаторов, из которого PVE выбирает свободный ID при создании виртуальных машин и контейнеров, можно настроить на вкладке Центр обработки данных → Параметры, выбрав пункт Следующий свободный диапазон ID виртуальных машин:
Настройка диапазона VM ID
Если значение параметра Нижний предел установить равным значению Верхний предел, автоподстановка VM ID будет полностью отключена.
На вкладке Шаблон необходимо выбрать следующие параметры:
  • Хранилище — хранилище, в котором находится шаблон LXC;
  • Шаблон — шаблон, на основе которого будет создан контейнер.
Вкладка Шаблон диалога создания контейнера
На вкладке Диски указывается хранилище для корневой файловой системы контейнера и её размер. При выборе размера следует учитывать требования ОС, приложений и размещаемых данных (не следует выбирать размер диска менее 4 ГБ):
Вкладка Диски диалога создания контейнера
На вкладке Процессор указывается количество ядер процессора, доступных контейнеру:
Вкладка Процессор диалога создания контейнера
На вкладке Память настраиваются следующие параметры:
  • Память (MiB) — ограничение объёма оперативной памяти контейнера в мебибайтах;
  • Подкачка (MiB) — объём подкачки, доступный контейнеру, в мебибайтах.
Вкладка Память диалога создания контейнера
На вкладке Сеть настраиваются следующие параметры:
  • Имя — имя виртуального сетевого интерфейса внутри контейнера (по умолчанию eth0);
  • MAC-адрес — MAC-адрес виртуального сетевого интерфейса. Если адрес не задан вручную, PVE назначает его автоматически;
  • Сетевой мост — виртуальный мост, к которому подключается сетевой интерфейс (по умолчанию vmbr0);
  • Тег VLAN — идентификатор VLAN, используемый для передачи трафика интерфейса через VLAN;
  • Сетевой экран — включает обработку трафика интерфейса правилами межсетевого экрана PVE;
  • IPv4/IPv6 — параметры адресации IPv4 и IPv6. Адреса можно задать вручную или настроить автоматическое получение по DHCP, если это поддерживается соответствующим протоколом и сетью. IPv4-адрес указывается в нотации CIDR (например, 192.168.0.30/24).
Вкладка Сеть диалога создания контейнера
На вкладке DNS настраиваются следующие параметры:
  • Домен DNS — домен поиска DNS. По умолчанию используется значение, унаследованное от хоста;
  • Серверы DNS — IP-адреса серверов DNS. По умолчанию используются значения, унаследованные от хоста.
Вкладка DNS диалога создания контейнера
На вкладке Подтверждение отображаются заданные параметры контейнера:
Вкладка Подтверждение диалога создания контейнера
Для создания контейнера следует нажать кнопку Завершить. Если требуется изменить параметры, можно вернуться на соответствующие вкладки.
Если отметить пункт Запуск после создания, контейнер будет автоматически запущен сразу после создания.
После нажатия кнопки Завершить диалог настройки закроется и откроется окно с журналом задачи создания контейнера LXC на основе выбранного шаблона:
Создание контейнера

⁠31.2. Создание контейнера из шаблона в командной строке

Контейнер можно создать из шаблона с помощью команды pct, выполняемой на узле PVE.
Следующий сценарий Bash демонстрирует создание контейнера с использованием переменных:
#!/bin/bash
hostname="altLXC"
vmid="108"
template_path="/var/lib/vz/template/cache"
storage="local-lvm"
description="alt-p11"
template="alt-p11-rootfs-systemd-x86_64.tar.xz"
ip="192.168.0.94/24"
nameserver="8.8.8.8"
ram="1024"
rootpw="password"
rootfs="4"
gateway="192.168.0.1"
bridge="vmbr0"
iface="eth0"

# Создание контейнера
pct create $vmid \
  $template_path/$template \
  -description $description \
  -rootfs $rootfs \
  -hostname $hostname \
  -memory $ram \
  -nameserver $nameserver \
  -storage $storage \
  -password $rootpw \
  -net0 name=$iface,bridge=$bridge,gw=$gateway,ip=$ip
Сценарий предполагает, что в хранилище local-lvm разрешено размещение корневых файловых систем контейнеров, а указанный файл шаблона существует. Идентификатор 108 должен быть свободен.

⁠31.3. Изменение настроек контейнера

Настройки контейнера можно изменять и после его создания. Большинство изменений параметров, поддерживающих динамическое применение, вступает в силу без перезапуска контейнера. Остальные изменения применяются после перезапуска.
Настройки контейнера можно изменять тремя способами:
  • через веб-интерфейс PVE;
  • с помощью командной строки;
  • путём непосредственного редактирования файла конфигурации.

⁠31.3.1. Изменение настроек в веб-интерфейсе

Большинство настроек контейнера и параметров его виртуальных устройств можно изменять через веб-интерфейс PVE.
Для изменения настроек контейнера используются следующие вкладки:
  • Ресурсы — оперативная память, подкачка, количество ядер процессора и параметры дисков;
  • Сеть — параметры сетевых интерфейсов;
  • DNS — параметры DNS;
  • Параметры — дополнительные настройки контейнера.
Изменение настроек контейнера в веб-интерфейсе PVE
Для изменения ресурсов контейнера необходимо выполнить следующие действия:
  1. В режиме просмотра по серверам выбрать контейнер;
  2. Перейти на вкладку Ресурсы;
  3. Выбрать параметр Память, Подкачка или Ядра и нажать кнопку Редактировать;
  4. В открывшемся диалоговом окне указать новое значение и нажать кнопку OK.
Для увеличения размера корневой файловой системы контейнера необходимо:
  1. Перейти на вкладку Ресурсы.
  2. Выбрать элемент Корневой диск.
  3. Нажать кнопку Действие над томом → Изменить размер.
  4. В поле Увеличение размера (ГиБ) укажите, на сколько гибибайт необходимо увеличить размер (например, чтобы увеличить размер с 8 до 18 ГиБ, следует ввести число 10):
    Изменение размера диска
  5. Нажать кнопку Изменить размер диска.
Для перемещения тома контейнера в другое хранилище необходимо:
  1. Перейти на вкладку Оборудование.
  2. Выбрать элемент Корневой диск.
  3. Нажать кнопку Действие над томом → Переместить хранилище.
  4. В списке Целевое хранилище выбрать хранилище, в которое необходимо переместить том:
    Диалоговое окно перемещения тома
  5. При необходимости отметить пункт Удалить источник, чтобы удалить том из исходного хранилища после перемещения.
  6. Нажать кнопку Переместить том.
Для изменения сетевых настроек контейнера необходимо:
  1. В режиме просмотра по серверам выбрать контейнер.
  2. Перейти на вкладку Сеть. На экране отобразится список настроенных виртуальных сетевых интерфейсов контейнера:
    Виртуальные сетевые интерфейсы контейнера
  3. Выбрать нужный интерфейс и нажать кнопку Редактировать;
  4. Изменить необходимые параметры и нажать кнопку OK:
    Изменение сетевых настроек контейнера
На вкладке Параметры можно изменять различные настройки контейнера, в том числе режим консоли:
  • tty — подключение к одному из доступных устройств tty (режим по умолчанию);
  • shell — запуск оболочки внутри контейнера без прохождения обычной процедуры входа в систему;
  • /dev/console — подключение к /dev/console.
Параметры контейнера

Примечание

Если изменение параметра нельзя применить без перезапуска контейнера, оно будет отмечено как ожидающее применения (выделяется цветом). Такие изменения вступят в силу после перезапуска контейнера.
Изменения, которые будут применены после перезапуска контейнера

⁠31.3.2. Настройка ресурсов в командной строке

Если веб-интерфейс PVE недоступен, управлять контейнерами можно из командной строки узла PVE, подключившись к нему по SSH или используя его локальную консоль.
pct — утилита командной строки для управления контейнерами LXC в PVE. Список доступных команд можно просмотреть, выполнив команду:
# pct help
Формат команды для создания контейнера:
# pct create <ct_id> <template> [options]
Например:
# pct create 110 /var/lib/vz/template/cache/alt-p11-rootfs-systemd-x86_64.tar.xz
Формат команды для изменения параметров контейнера:
# pct set <ct_id> [options]
Например, чтобы изменить сетевые параметры интерфейса net0 контейнера с идентификатором 105, можно выполнить:
# pct set 105 -net0 name=eth0,bridge=vmbr0,ip=192.168.0.17/24,gw=192.168.0.1
Команда задаёт параметры интерфейса net0 целиком. Если у интерфейса были настроены дополнительные параметры, например firewall, hwaddr или tag, их необходимо указать повторно, если они должны сохраниться.
Команда изменения ограничения на объём оперативной памяти контейнера:
# pct set <ct_id> -memory <value>
где <value> — объём памяти в мегабайтах.
Для увеличения размера корневой файловой системы использется команда pct resize:
# pct resize <ct_id> rootfs <size>
Например, чтобы увеличить размер корневой файловой системы контейнера 105 до 10 ГиБ:
# pct resize 105 rootfs 10G
Размер указывается как новое абсолютное значение. Чтобы увеличить существующий размер на заданную величину, перед значением ставят знак +. Уменьшение размера тома этой командой не поддерживается. Возможность изменения размера зависит от типа хранилища и тома.
Просмотр конфигурации контейнера:
# pct config <ct_id>
Снятие блокировки контейнера:
# pct unlock <ct_id>
Просмотр списка контейнеров на текущем узле:
# pct list
VMID       Status     Lock         Name
105        running                 newLXC
106        stopped                 altLXC
Для запуска и остановки контейнера используйте команды:
# pct start <ct_id>
# pct stop <ct_id>
Команда удаления контейнера:
# pct destroy <ct_id>

Предупреждение

Удаление контейнера может привести к удалению связанных с ним данных. Перед выполнением команды убедитесь, что нужные данные сохранены.
Если необходимо также удалить контейнер из заданий репликации, заданий резервного копирования и конфигураций ресурсов высокой доступности (HA), следует использовать параметр --purge:
# pct destroy <ct_id> --purge

⁠31.3.3. Настройка ресурсов прямым изменением

Файлы конфигурации контейнеров PVE находятся в каталоге /etc/pve/lxc. Как и другие файлы в каталоге /etc/pve/, они автоматически реплицируются на остальные узлы кластера.
Некоторые параметры контейнеров нельзя изменить через веб-интерфейс или стандартными параметрами утилиты pct. В таких случаях можно отредактировать файл конфигурации непосредственно. Изменения низкоуровневых параметров обычно требуют перезапуска контейнера для применения. Перед редактированием рекомендуется сохранить резервную копию файла конфигурации.
Пример файла конфигурации контейнера /etc/pve/lxc/105.conf:
arch: amd64
cores: 1
features: nesting=1
hostname: newLXC
memory: 512
net0: name=eth0,bridge=vmbr0,firewall=1,gw=192.168.0.1,hwaddr=BC:24:11:A7:B5:AE,ip=192.168.0.230/24,type=veth
ostype: altlinux
rootfs: nfs-storage:105/vm-105-disk-0.raw,size=8G
swap: 512
tty: 3
unprivileged: 1

⁠31.4. Запуск и остановка контейнеров

Запустить контейнер можно одним из следующих способов:
  • выбрать пункт Запуск в контекстном меню контейнера:
    Контекстное меню контейнера
  • нажать кнопку Запуск:
    Кнопки управления состоянием контейнера
Запущенный контейнер обозначается зеленой стрелкой на его значке.
Для управления запущенным контейнером доступны следующие действия:
  • Отключить — корректное завершение работы контейнера;
  • Остановка — принудительная остановка контейнера;
  • Перезагрузить — перезапуск контейнера.
Управлять состоянием контейнера можно также из командной строки узла PVE.
Для запуска контейнера с идентификатором 105 необходимо выполнить команду:
# pct start 105
Остановить контейнер можно при помощи команды:
# pct stop 105

⁠31.5. Доступ к LXC-контейнеру

Для доступа к LXC-контейнеру можно использовать следующие способы:
  • консоль в веб-интерфейсе PVE (noVNC или xterm.js);
  • SSH, если в контейнере настроен и запущен соответствующий сервер;
  • командную строку узла PVE.
Для доступа к запущенному контейнеру через веб-интерфейс необходимо выбрать нужный контейнер, нажать кнопку Консоль и в раскрывающемся списке выбрать доступный вариант консоли:
Кнопка Консоль
Консоль также можно открыть на вкладке Консоль выбранного контейнера:
Консоль
LXC-контейнером можно управлять непосредственно из командной строки узла PVE. Для входа в контейнер используется команда:
# pct enter <ct_id>
Команда открывает оболочку внутри указанного контейнера.
Пример:
[root@pve03 ~]# pct enter 105
[root@newLXC ~]#
В данном примере выполнен вход в контейнер newLXC на узле pve03. При использовании pct enter пароль пользователя внутри контейнера не запрашивается: оболочка открывается от имени root. Доступ к узлу PVE с соответствующими полномочиями позволяет выполнять команды внутри контейнера без обычной процедуры аутентификации. Фактические возможности зависят от конфигурации контейнера и действующих ограничений безопасности.
Чтобы завершить работу в оболочке контейнера и вернуться к командной строке узла PVE, необходимо выполнить команду exit.

Предупреждение

Если при выполнении команды возникает ошибка вида:
Insecure $ENV{ENV} while running with...
необходимо в файле /root/.bashrc закомментировать строку:
ENV=$HOME/.bashrc
и выполнить команду:
# unset ENV
Команды внутри контейнера можно выполнять и без интерактивного входа в него, используя pct exec:
# pct exec <ct_id> -- <command>
Например, создать каталог внутри контейнера и проверить его наличие:
# pct exec 105 mkdir /home/demouser
# pct exec 105 ls /home
demouser
Для выполнения команды с параметрами после идентификатора контейнера необходимо добавить --, чтобы отделить параметры pct от выполняемой внутри контейнера команды:
# pct exec 105 -- df -H /
Файловая система Размер Использовано  Дост Использовано% Cмонтировано в
/dev/loop0         8,4G         516M  7,4G            7% /

⁠Глава 32. Программно-определяемые сети (SDN)

Программно-определяемые сети (Software Defined Networking, SDN) в PVE — это модульная система управления сетями, которая позволяет создавать и настраивать виртуальные сети, изолированные виртуальные среды (VLAN, VXLAN, EVPN) и централизованно управлять связностью между гостевыми системами.
Ключевые компоненты SDN:
  • зона — виртуально разделенная сетевая область;
  • виртуальная сеть (VNet) — виртуальная сеть в рамках зоны;
  • подсеть — диапазон IP-адресов внутри VNet.
Тип зоны определяет поведение сети, её функциональность, преимущества и ограничения.
Варианты использования SDN варьируются от изолированных частных сетей на отдельных узлах до распределенных оверлейных сетей в мультикластерных средах PVE (включая географически разнесенные локации).
После настройки VNet она становится доступной как общий мост Linux на каждом узле кластера и может назначаться ВМ и контейнерам.

⁠32.1. Технология и конфигурация

Настройка SDN выполняется в веб-интерфейсе на уровне центра обработки данных и разделена на следующие разделы:
  • SDN — отображает текущее состояние SDN. Здесь также можно применить ожидающие изменения ко всему кластеру;
  • Зоны — создание и управление виртуально разделенными сетевыми зонами;
  • VNets — создание виртуальных сетевых мостов и управление подсетями.
SDN. Раздел Параметры
В разделе Параметры можно управлять дополнительными службами, которые будут использоваться в настройке SDN:
  • Контроллеры — управление маршрутизацией уровня 3 в сложных настройках (BGP-контроллер, связывающий узлы);
  • IPAM — система управления IP-адресами гостевых систем (встроенная или внешняя);
  • DNS — интеграция с DNS.
Реализация SDN в PVE максимально использует стандартные сетевые возможности Linux.
Конфигурация PVE SDN хранится в каталоге /etc/pve/sdn, который совместно используется всеми узлами кластера через файловую систему PVE.
Внесённые изменения не применяются немедленно, а сначала сохраняются в виде ожидающей конфигурации. Применить набор ожидающих изменений можно, нажав кнопку Применить в разделе Центр обработки данных → SDN или выполнив команду:
# pvesh set /cluster/sdn
Такой механизм позволяет применять набор изменений как единое атомарное действие.
SDN отслеживает текущее применённое состояние конфигурации с помощью файлов .running-config и .version, расположенных в каталоге /etc/pve/sdn.

Примечание

Перед применением изменений конфигурации SDN можно выполнить предварительную проверку (Dry-Run). Для этого в разделе Центр обработки данных → SDN необходимо нажать кнопку Dry-Run. В данном режиме выполняется проверка новой конфигурации и отображается перечень предполагаемых изменений, включая конфигурацию FRR (FRR Config) и сетевых интерфейсов (Interface Config), без внесения изменений в рабочую конфигурацию узлов.
SDN. Ожидаемые изменения

⁠32.2. Зоны

Зона — это логически изолированная сетевая область, которая определяется набором узлов кластера и настройками сетевого взаимодействия. Доступ пользователей к ресурсам зоны регулируется назначенными правами.
Поддерживаемые технологии:
  • Simple — изолированный мост; простой маршрутируемый мост уровня 3 (NAT);
  • VLAN — виртуальные локальные сети (классический метод сегментации локальной сети);
  • QinQ — многоуровневая стекированная VLAN (IEEE 802.1ad);
  • VXLAN — виртуальная сеть уровня 2 через UDP-туннель;
  • EVPN (BGP EVPN) — VXLAN с поддержкой BGP для маршрутизации уровня 3.
Для каждой зоны можно определить правила межсетевого экрана для входящего и/или исходящего трафика.
⁠

Таблица 32.1. Общие параметры зон

Свойство
Описание
nodes
Список узлов кластера, на которых должны быть развернуты зона и связанные с ней виртуальные сети
ipam
Инструмент управления IP-адресами (IPAM) для управления IP-адресами в зоне (по умолчанию — pve)
dns
Адрес API сервера DNS
ReverseDNS
Адрес API сервера обратного DNS
DNSZone
Имя DNS-домена. Используется для регистрации имен узлов, например <hostname>.<domain>. Зона DNS должна уже существовать на DNS-сервере

⁠32.2.1. Простые (Simple) зоны

Simple зона (type simple) предназначена для создания простых виртуальных сетей без использования VLAN и оверлейных технологий. Она обеспечивает локальное соединение ВМ и контейнеров на одном узле. При дополнительной настройке подсетей такая сеть может использоваться в маршрутизируемых схемах и конфигурациях с NAT.
Плагин создает изолированный мост VNet, не связанный с физическим интерфейсом, обеспечивающий только локальный трафик между ВМ на одном узле. Этот мост может использоваться в NAT-конфигурациях или маршрутизируемых схемах.

⁠32.2.2. Зоны VLAN

VLAN-зона (type vlan) — зона, в которой каждый виртуальный сегмент (VNet) соответствует определённому VLAN ID. Внутри зоны создаются VNet, указывающие, какие VLAN ID используются и через какие интерфейсы осуществляется маршрутизация. Плагин VLAN использует существующий локальный мост (Linux или OVS) для подключения к физическому интерфейсу узла.

Примечание

При использовании VLAN-зоны физический коммутатор должен быть настроен соответствующим образом, чтобы корректно обрабатывать VLAN-трафик. Коммутатор должен поддерживать 802.1Q (VLAN tagging).
Дополнительный параметр конфигурации зоны VLAN:
  • bridge — локальный мост с поддержкой VLAN, который уже настроен на каждом локальном узле.

⁠32.2.3. Зоны QinQ

Зона QinQ (type qinq) — расширение обычной VLAN-зоны, позволяющее использовать двойную VLAN-тегировку (802.1ad), то есть VLAN внутри VLAN. Зона QinQ определяет внешний VLAN-тег (сервисную VLAN, S-tag), тогда как внутренний тег (C-tag) определяется VNet.

Примечание

Сетевые коммутаторы должны поддерживать стекированные VLAN.
Дополнительные параметры конфигурации зоны QinQ:
  • bridge — локальный мост с поддержкой VLAN, который уже настроен на каждом локальном узле;
  • tag — основной VLAN-тег этой зоны;
  • vlan-protocol — протокол сервисной VLAN: 802.1Q (по умолчанию) или 802.1ad;
  • mtu — из-за двойного стекирования тегов QinQ общий размер заголовка увеличивается на 4 байта. Например, если MTU физического интерфейса равен 1500, необходимо уменьшить MTU виртуальной сети до 1496.

⁠32.2.4. Зоны VXLAN

Зоны VXLAN (type vxlan) — используются для создания оверлей-сетей, которые позволяют соединять ВМ на разных физических узлах через виртуальные сети (VNet), изолированные друг от друга. Это обеспечивает масштабируемость, гибкость и независимость от физической топологии. Плагин VXLAN инкапсулирует Ethernet-кадры уровня 2 в UDP-датаграммы уровня 4, используя порт назначения по умолчанию 4789.
VXLAN позволяет создавать значительно больше изолированных виртуальных сегментов, чем VLAN, благодаря использованию 24-битного идентификатора VNI (в отличие от VLAN, ограниченного 4094 идентификаторами).
VXLAN используется в SDN для связи ВМ между узлами кластера PVE без настройки физической инфраструктуры.

Предупреждение

VXLAN сам по себе не обеспечивает шифрование. Для соединения удалённых площадок обязательно использование VPN (например, «сайт-сайт»).
Дополнительные параметры конфигурации зоны VXLAN:
  • peers — список IP-адресов всех узлов кластера, участвующих в VXLAN-зоне. Может включать внешние узлы, доступные по указанным IP-адресам. Должен содержать все узлы кластера;
  • fabric — fabric для автоматического создания списка пиров;
  • mtu — поскольку инкапсуляция VXLAN использует 50 байт, MTU виртуальной сети должен быть на 50 байт меньше, чем MTU физического интерфейса (50 байт — типичный дополнительный размер инкапсуляции VXLAN поверх IPv4; при использовании IPv6 накладные расходы больше).

⁠32.2.5. Зоны EVPN

Настройка EVPN зоны (type evpn) в PVE SDN позволяет реализовать распределённую L2-сеть поверх L3-инфраструктуры с использованием BGP EVPN как протокола маршрутизации. Данная зона подходит для крупных сетей и дата-центров с мультиузловой маршрутизацией.
VNet EVPN может иметь IP-адрес anycast и/или MAC-адрес. IP-адрес моста одинаков на всех узлах, что позволяет использовать его как шлюз в гостевых ОС.
Маршрутизация может работать между VNet из разных зон через интерфейс VRF (Virtual Routing and Forwarding).
Дополнительные параметры конфигурации зоны EVPN:
  • vrf-vxlan — VXLAN-ID, используемый для выделенного маршрутного соединения между VNet (должен отличаться от VXLAN-ID VNet);
  • controller — контроллер EVPN;
  • mac — anycast MAC-адрес, который назначается всем VNet в этой зоне (если не определен, будет сгенерирован автоматически);
  • exitnodes — узлы, выступающие в роли шлюзов в реальную сеть. Настроенные узлы объявят маршрут по умолчанию в сети EVPN;
  • exitnodes-primary — если используется несколько выходных узлов, принудительно пропускать трафик через этот основной выходной узел вместо балансировки нагрузки между всеми узлами. Необязательно, но необходимо, если будет использоваться SNAT или если маршрутизатор не поддерживает ECMP;
  • exitnodes-local-routing — специальный параметр, если нужен доступ к ВМ/контейнеру из выходного узла (по умолчанию выходные узлы разрешают пересылку трафика только между реальной сетью и сетью EVPN);
  • advertise-subnets — объявлять полную подсеть в EVPN. Если в кластере есть «молчащие» ВМ/контейнеры (назначены IP-адреса, которые не проявляют активность) и anycast-шлюз не видит от них трафика, то такие IP могут быть недоступны из EVPN-сети. Данный параметр заставляет SDN явно объявить всю подсеть, независимо от активности;
  • disable-arp-nd-suppression — не подавлять пакеты ARP (Address Resolution Protocol) или ND (Neighbor Discovery). Необходимо, если в ВМ используются плавающие IP-адреса (IP и MAC-адреса перемещаются между системами);
  • rt-import — позволяет импортировать список внешних целей маршрута EVPN. Используется для межсетевых соединений DC или различных сетей EVPN;
  • mtu — поскольку инкапсуляция VXLAN использует 50 байт, MTU виртуальной сети должен быть на 50 байт меньше физического (по умолчанию 1450).

⁠32.3. Виртуальные сети

После создания виртуальной сети (VNet) на каждом узле будет доступен локальный сетевой интерфейс с тем же именем. Чтобы подключить гостевую систему к VNet, следует соответствующим образом назначить интерфейс ВМ/контейнеру и задать IP-адрес.
Параметры конфигурации VNet:
  • id — идентификатор виртуальной сети (до 8 символов);
  • alias — более описательный идентификатор (опционально). Назначается как псевдоним на интерфейсе;
  • zone — зона, связанная с этой сетью;
  • tag — уникальный идентификатор VLAN или VXLAN;
  • vlanaware — включает параметр VLAN-aware на интерфейсе, позволяя настройку в гостевой системе;
  • isolate-ports — включает изоляцию гостевых портов на уровне узла. Изолированные порты не могут напрямую обмениваться трафиком друг с другом; взаимодействие с неизолированными портами, в том числе с самим мостом, регулируется правилами изоляции. Чтобы эта настройка вступила в силу, необходимо перезапустить затронутую гостевую систему.

Примечание

Изоляция действует на уровне узла. Для межузловой изоляции следует использовать межсетевой экран VNet. Например, можно запретить всё (установить DROP по умолчанию) и разрешить трафик между подсетью и шлюзом.

⁠32.4. Подсети

Подсеть определяет диапазон IP-адресов в формате CIDR. Одна виртуальная сеть может содержать несколько подсетей.
Подсеть может использоваться для:
  • ограничения IP-адресов, которые можно определить в конкретной виртуальной сети;
  • назначения маршрутов/шлюзов в виртуальной сети в зонах уровня 3;
  • включения SNAT в виртуальной сети в зонах уровня 3;
  • автоматического назначения IP-адресов виртуальным системам через плагины IPAM;
  • регистрации DNS через плагины DNS.
Если сервер IPAM связан с зоной подсети, префикс подсети будет автоматически зарегистрирован в IPAM.
Параметры конфигурации подсети:
  • id — адрес сети в нотации CIDR (например, 10.0.0.0/8);
  • gateway — IP-адрес шлюза по умолчанию сети. В зонах уровня 3 (плагины Simple/EVPN) он будет развернут в виртуальной сети;
  • snat — включить Source NAT, который позволяет гостевым системам из VNet подключаться к внешней сети, пересылая пакеты на исходящий интерфейс узлов. В зонах EVPN пересылка выполняется на шлюзовых узлах EVPN;
  • dnszoneprefix — префикс к DNS-домену, например: <hostname>.prefix.<domain>

⁠32.5. SDN фабрики

SDN фабрики — технология, позволяющая строить маршрутизируемые overlay-сети между узлами кластера без использования внешних коммутаторов. В PVE поддерживаются четыре типа fabric-сетей: OpenFabric, OSPF, WireGuard и BGP.
OSPF (Open Shortest Path First) — протокол динамической маршрутизации для IP-сетей, предназначенный для обмена маршрутной информацией внутри одной автономной системы.
OpenFabric — протокол маршрутизации, разработанный специально для сетей центров обработки данных (ЦОД) и основанный на IS-IS. Он оптимизирован под архитектуру spine-leaf.
WireGuard — протокол и технология построения защищённых VPN-туннелей на основе криптографических примитивов. В SDN PVE используется для создания L3-связности между узлами через зашифрованные peer-to-peer соединения.
BGP (Border Gateway Protocol) — протокол междоменной маршрутизации, используемый для обмена маршрутами между автономными системами и внутри крупных сетей. В SDN PVE применяется для построения гибких политик маршрутизации между узлами кластера и внешними сетями, поддерживает фильтрацию и изменение маршрутов с помощью route-map и prefix-list.
Fabric-сети в PVE SDN обеспечивают автоматическую маршрутизацию между узлами кластера. Они упрощают настройку underlay-сетей и служат основой для SDN-развёртываний.
При создании fabric автоматически настраиваются протоколы маршрутизации на физических сетевых интерфейсах, обеспечивая отказоустойчивую и самонастраивающуюся сетевую ткань, способную адаптироваться к изменениям топологии. Такие fabric-сети могут использоваться:
  • как полносвязная (full mesh) сеть для Ceph;
  • в качестве underlay для EVPN-контроллера;
  • в качестве underlay для VXLAN-зон.
PVE использует реализации OpenFabric и OSPF из состава FRRouting (FRR), поэтому следует убедиться, что установлены необходимые пакеты:
# apt-get install frr frr-pythontools
И на всех узлах кластера включена служба:
# systemctl enable frr.service
Права доступа:
  • для просмотра конфигурации SDN-fabric требуются права SDN.Audit или SDN.Allocate;
  • для создания или изменения конфигурации fabric необходимы права SDN.Allocate;
  • для просмотра конфигурации узла требуются права Sys.Audit или Sys.Modify;
  • при добавлении или обновлении узлов в составе fabric дополнительно требуются права Sys.Modify на конкретный узел, так как операция изменяет файл /etc/network/interfaces.d/sdn на этом узле.
Каждому узлу в фабрике требуется уникальный router-ID:
  • IPv4-адрес (например: 192.0.2.1);
  • Для OpenFabric также поддерживаются IPv6-адреса (например: 2001:db8::1428:57ab).
При создании фабрики автоматически создаётся dummy-интерфейс с адресом router-ID, который функционирует как loopback-интерфейс fabric (по умолчанию — пассивный).
Для каждого fabric автоматически генерируются:
  • access-list;
  • route-map.
Эти правила настраивают маршрутизатор так, чтобы исходный адрес исходящих пакетов переписывался на адрес dummy-интерфейса. Например, при выполнении ping другого узла источником трафика будет IP-адрес dummy-интерфейса, а не физического интерфейса. Это обеспечивает единообразие выбора исходного адреса и корректную работу маршрутизации.

⁠32.5.1. Поддержка IPv6

IPv6 в настоящее время поддерживается в OpenFabric и BGP-сетях. Для корректной работы таких fabric-сетей (особенно в не-full-mesh топологиях) необходимо включить глобальную пересылку IPv6 на всех узлах. Без этого транзитные узлы не смогут пересылать пакеты.
Включение IPv6 forwarding выполняется добавлением в файл /etc/network/interfaces строки:
post-up sysctl -w net.ipv6.conf.all.forwarding=1
Эта команда активирует глобальную пересылку IPv6 при поднятии интерфейса.

Важно

Это влияет на работу механизмов IPv6, таких как SLAAC, Neighbor Advertisements, Router Solicitations и Router Advertisements.

⁠32.5.2. Примеры настройки Fabric

⁠32.5.2.1. Настройка OpenFabric

Пример создания OpenFabric в веб-интерфейсе:
  1. Перейти в раздел Центр обработки данных → SDN → Фабрики, нажать кнопку Добавить фабрику и в раскрывающемся списке выбрать пункт OpenFabric:
    Создание фабрики
  2. Указать параметры фабрики:
    • Имя — имя фабрики (до 8 символов);
    • Префикс IPv4 (ip_prefix) — IPv4-сеть в формате CIDR (например, 192.0.2.0/24) для проверки корректности router-ID;
    • Префикс IPv6 (ip6_prefix) — IPv6-сеть в формате CIDR (например, 2001:db8::/64) для проверки router-ID;

      Примечание

      Для IPv6-фабрик необходимо включить глобальный IPv6 forwarding на всех узлах кластера.
    • Интервал hello-пакетов (hello_interval) — частота отправки hello-пакетов (в секундах). Низкие значения ускоряют обнаружение отказов, но увеличивают трафик. Параметр действует глобально на всю фабрику. По умолчанию: 3 сек;
    • Интервал CSNP (csnp_interval) — частота синхронизации базы маршрутов (в секундах). Параметр является глобальным для фабрики. По умолчанию: 10 сек;
    • Route Filter (route_filter) — ссылка на список префиксов. При наличии фильтра в ядро устанавливаются только маршруты, совпадающие с ним.
    Создание OpenFabric
  3. Добавить узлы в фабрику:
    • нажать кнопку + в строке фабрики или выбрать фабрику и нажать кнопку Добавить узел на верхней панели:
      Кнопка Добавить узел
    • в открывшемся окне выбрать узел, указать IP-адрес узла в поле IPv4, выбрать интерфейсы узла, которые должны входить в состав fabric-сети, и нажать кнопку Создать или Create another (если нужно настроить несколько узлов):
      Добавление узла в Fabric
      Параметры узла:
      • Узел — узел, который нужно добавить в фабрику (список включает только узлы кластера);
      • IPv4 (ip_prefix) — уникальный IPv4-адрес, используемый для генерации OpenFabric NET. Каждый узел в одной и той же fabric-сети должен иметь уникальный Router-ID, а один и тот же узел обязан использовать один и тот же NET-адрес во всех fabric-сетях (если это условие не выполнено, PVE автоматически выберет подходящий NET-адрес и обеспечит корректность конфигурации);
      • IPv6 (ip6_prefix) — уникальный IPv6-адрес для генерации NET. Если указаны оба адреса (IPv4 и IPv6), приоритет имеет IPv4;

        Примечание

        При использовании IPv6 последние 3 сегмента адреса используются для генерации NET. Следует убедиться, что они различаются между узлами.
      • Interfaces (interfaces) — физические интерфейсы, используемые для установления соединений с другими узлами OpenFabric. Рекомендуется использовать интерфейсы без назначенных IP-адресов. Dummy-интерфейс создаётся автоматически.

      Примечание

      Если для интерфейса не настроен IP-адрес, он будет работать в режиме без номера (интерфейс использует IP-адрес от узла). При желании можно определить выделенные IP-адреса для интерфейсов, которые будут использоваться вместо IP-адреса маршрутизатора для создания смежности между узлами.

      Примечание

      Необходимо повторить это для каждого узла, который должен быть частью сети.
      Узлы в Fabric
  4. Активировать конфигурацию. Для этого перейти в раздел Центр обработки данных → SDN и нажать кнопку Применить:
    Активировать конфигурацию OpenFabric
В результате на каждом узле создаётся dummy-интерфейс (например, dummy_of1) с адресом router-ID:
$ ip -br a
enp0s10          UP             fd47:d11e:43c1:0:a00:27ff:fe80:2977/64 fe80::a00:27ff:fe80:2977/64
dummy0           DOWN
dummy_of1        UNKNOWN        10.255.0.2/32 fe80::54b9:eeff:fe6b:b2b8/64
В файле /etc/network/interfaces.d/sdn появляются записи вида:
auto dummy_of1
iface dummy_of1 inet static
    address 10.255.0.3/32
    link-type dummy
    ip-forward 1

auto enp0s10
iface enp0s10
    ip-forward 1

Примечание

Чтобы проверить, сходится ли сеть OpenFabric, можно использовать оболочку vtysh. Соседей и маршруты OpenFabric можно увидеть с помощью следующих команд:
  • проверка соседей:
    # vtysh -c "show openfabric neighbor"
    
  • проверка маршрутов:
    # vtysh -c "show openfabric route"
    
Пример создания OpenFabric в консоли:
  1. Создание фабрики:
    # pvesh create /cluster/sdn/fabrics/fabric  \
      --id of2 --protocol openfabric --ip_prefix 10.250.0.0/24
    
    # pvesh get /cluster/sdn/fabrics/fabric/of2 --output-format yaml
    ---
    digest: 0d9872991acab57cf6afeca9dbf93d0a333fe2d2ef650b21aaedbd30d5b73ecd
    id: of2
    ip_prefix: 10.250.0.0/24
    protocol: openfabric
    
  2. Добавление узлов:
    # pvesh create /cluster/sdn/fabrics/node/of2  \
      --node_id pve01 --protocol openfabric --interfaces name=enp0s10 --ip 10.250.0.1
    # pvesh create /cluster/sdn/fabrics/node/of2  \
      --node_id pve02 --protocol openfabric --interfaces name=enp0s10 --ip 10.250.0.2
    # pvesh create /cluster/sdn/fabrics/node/of2  \
      --node_id pve03 --protocol openfabric --interfaces name=enp0s10 --ip 10.250.0.3
    
    # pvesh get /cluster/sdn/fabrics/node/of2 --output-format yaml
    ---
    - digest: a75048ab2d62fe6e7f3c0e2ff26c2b78565b827b87376e63130c5fe5ed4d7312
      fabric_id: of2
      interfaces:
      - name=enp0s10
      ip: 10.250.0.1
      node_id: pve01
      protocol: openfabric
    - digest: a75048ab2d62fe6e7f3c0e2ff26c2b78565b827b87376e63130c5fe5ed4d7312
      fabric_id: of2
      interfaces:
      - name=enp0s10
      ip: 10.250.0.2
      node_id: pve02
      protocol: openfabric
    ---
    - digest: ba89eae03508e4728939e243bcfdb4452515dfb39eda21692996efaf10b23e54
      fabric_id: of2
      interfaces:
      - name=enp0s10
      ip: 10.250.0.3
      node_id: pve03
      protocol: openfabric
    
  3. Применение конфигурации:
    # pvesh set /cluster/sdn
    

⁠32.5.2.2. Настройка OSPF-фабрики

OSPF (Open Shortest Path First) — широко используемый протокол динамической маршрутизации, вычисляющий кратчайший путь на основе алгоритма Дейкстры.
Пример создания OSPF-фабрики в веб-интерфейсе:
  1. Перейти в раздел Центр обработки данных → SDN → Фабрики, нажать кнопку Добавить фабрику и в раскрывающемся списке выбрать пункт OSPF:
    Создание фабрики
  2. Указать параметры OSPF:
    • Имя — имя фабрики (до 8 символов);
    • Префикс IPv4 (ip_prefix) — IPv4-сеть в формате CIDR (например, 192.0.2.0/24) для проверки корректности router-ID;
    • Область (area) — идентификатор OSPF-области. Может быть 32-битным числом или IP-адресом. Область 0 (0.0.0.0) — магистральная область (backbone area);
    • Route Filter (route_filter) — ссылка на список префиксов. При наличии фильтра в ядро устанавливаются только маршруты, совпадающие с ним.
    Создание OSPF Fabric
  3. Добавить узлы в фабрику:
    • нажать кнопку + в строке фабрики или выбрать фабрику и нажать кнопку Добавить узел на верхней панели:
      Кнопка Добавить узел
    • в открывшемся окне выбрать узел, указать IP-адрес в поле IPv4, выбрать интерфейсы, которые должны входить в состав fabric-сети, и нажать кнопку Создать или Create another (если нужно настроить несколько узлов):
      Добавление узла в фабрику

      Примечание

      Необходимо добавить все узлы, которые должны обмениваться трафиком через эту фабрику.
      Узлы в Fabric
  4. Активировать конфигурацию. Для этого перейти в раздел Центр обработки данных → SDN и нажать кнопку Применить:
    Применить изменения
В результате на каждом узле создаётся dummy-интерфейс (например, dummy_ospf) с адресом router-ID:
$ ip -br a
enp0s9           UP             10.16.0.2/32 fe80::a00:27ff:fe9e:5ea4/64
dummy0           DOWN
dummy_ospf       UNKNOWN        10.16.0.2/32 fe80::cc9f:9bff:fe0c:16bd/64
В файле /etc/network/interfaces.d/sdn появляются записи вида:
auto dummy_ospf
iface dummy_ospf inet static
        address 10.16.0.2/32
        link-type dummy
        ip-forward 1

auto enp0s9
iface enp0s9 inet static
        address 10.16.0.2/32
        ip-forward 1

Примечание

Проверка работы OSPF Fabric:
  • проверка соседей:
    # vtysh -c "show ip ospf neighbor"
    
    Neighbor ID     Pri State           Up Time         Dead Time Address         Interface                        RXmtL RqstL DBsmL
    10.16.0.1         1 Loading/-       0.661s            31.334s 10.16.0.1       enp0s9:10.16.0.2                     0     1     0
    10.16.0.3         1 Exchange/-      0.663s            34.242s 10.16.0.3       enp0s9:10.16.0.2                     1     0     0
    
  • проверка маршрутов:
    # vtysh -c "show ip route ospf"
    
    O   10.16.0.2/32 [110/10] via 0.0.0.0, dummy_ospf onlink, rmapsrc 10.16.0.2, weight 1, 00:08:02
    
Пример создания OSPF-фабрики в консоли:
  1. Создание фабрики:
    # pvesh create /cluster/sdn/fabrics/fabric  \
      --id ospf --protocol ospf --ip_prefix 10.16.0.0/24 --area 0
    
    # pvesh get /cluster/sdn/fabrics/fabric/ospf --output-format yaml
    ---
    area: '0'
    digest: b42b0d474b59609522255008351b21dd2badf03e43f7289a80e2feba97815aa5
    id: ospf
    ip_prefix: 10.16.0.0/24
    protocol: ospf
    
  2. Добавление узлов:
    # pvesh create /cluster/sdn/fabrics/node/ospf  \
      --node_id pve01 --protocol ospf --interfaces name=enp0s9  --ip 10.16.0.1
    # pvesh create /cluster/sdn/fabrics/node/ospf  \
      --node_id pve02 --protocol ospf --interfaces name=enp0s9  --ip 10.16.0.2
    # pvesh create /cluster/sdn/fabrics/node/ospf  \
      --node_id pve03 --protocol ospf --interfaces name=enp0s9  --ip 10.16.0.3
    
    # pvesh get /cluster/sdn/fabrics/node/ospf --output-format yaml
    ---
    - digest: a75048ab2d62fe6e7f3c0e2ff26c2b78565b827b87376e63130c5fe5ed4d7312
      fabric_id: ospf
      interfaces:
      - name=enp0s9
      ip: 10.16.0.1
      node_id: pve01
      protocol: ospf
    - digest: a75048ab2d62fe6e7f3c0e2ff26c2b78565b827b87376e63130c5fe5ed4d7312
      fabric_id: ospf
      interfaces:
      - name=enp0s9
      ip: 10.16.0.2
      node_id: pve02
      protocol: ospf
    - digest: a75048ab2d62fe6e7f3c0e2ff26c2b78565b827b87376e63130c5fe5ed4d7312
      fabric_id: ospf
      interfaces:
      - name=enp0s9
      ip: 10.16.0.3
      node_id: pve03
      protocol: ospf
    
  3. Применение конфигурации:
    # pvesh set /cluster/sdn
    
Содержимое файла /etc/pve/sdn/fabrics.cfg:
ospf_fabric: ospf
        area 0
        ip_prefix 10.16.0.0/24

ospf_node: ospf_pve01
        interfaces name=enp0s9
        ip 10.16.0.1

ospf_node: ospf_pve02
        interfaces name=enp0s9
        ip 10.16.0.2

ospf_node: ospf_pve03
        interfaces name=enp0s9
        ip 10.16.0.3

⁠32.5.2.3. Настройка фабрики WireGuard

WireGuard может использоваться для создания VPN-соединений между узлами PVE и/или внешними узлами. Сам по себе он не обеспечивает динамическую маршрутизацию, однако может применяться совместно с протоколами уровня 3 (например, OSPF или BGP) для построения зашифрованной транспортной сети.
Такая схема может использоваться, например, для передачи трафика EVPN или VXLAN поверх защищённого канала.

Примечание

Для использования WireGuard необходимо установить пакет wireguard-tools (из репозитория p11) на всех узлах:
# apt-get install wireguard-tools
В WireGuard-фабрике используются два типа узлов:
  • Internal (внутренние) — узлы PVE;
  • External (внешние) — сторонние системы или устройства.
Пример создания фабрики WireGuard в веб-интерфейсе:
  1. Перейти в раздел Центр обработки данных → SDN → Фабрики, нажать кнопку Добавить фабрику и в раскрывающемся списке выбрать пункт WireGuard:
    Создание фабрики
  2. Указать параметры фабрики:
    • Имя — имя фабрики (до 8 символов);
    • Persistent Keepalive (persistent_keepalive) — интервал отправки keepalive-пакетов (в секундах). Если параметр задан, WireGuard периодически отправляет пустые аутентифицированные пакеты каждому пиру. Это позволяет поддерживать соединения через NAT и stateful firewall.
    Создание WireGuard Fabric
  3. Добавить узлы в фабрику, нажав кнопку + в строке фабрики или выбрав фабрику и нажав кнопку Добавить узел на верхней панели.
  4. Указать параметры узла:
    • Роль (role) — выбрать значение Internal (cluster member);
    • Узел — имя узла PVE в кластере;
    • Адрес доступа (endpoint) — IP-адрес или имя хоста, по которому другие узлы будут подключаться к данному узлу (например, 192.168.0.186 или 2001:db8::1). Этот адрес используется вместе с портом прослушивания (Listen Port), настроенным в интерфейсе WireGuard, для формирования конечной точки подключения вида IP:PORT;
    • Разрешенные IP-адреса (allowed_ips) — список CIDR, определяющий маршрутизируемые сети через данный узел. Используется как AllowedIPs в конфигурации WireGuard и одновременно как фильтр и маршрут назначения;
    Добавление узла в фабрику WireGuard
  5. Нажать кнопку Создать или Create another.
  6. Добавить остальные узлы.

    Примечание

    Необходимо добавить все узлы, которые должны обмениваться трафиком через эту фабрику.
  7. Отредактировать узлы и указать список peers (пиров), которые будут использоваться для данного интерфейса. Пиры могут быть выбраны из всех узлов фабрики — они генерируются автоматически на основе конфигурации. При необходимости можно включить опцию Skip Route Generation, которая отключает автоматическое добавление маршрутов для AllowedIPs.
    Добавление пиров
  8. Активировать конфигурацию. Для этого перейти в раздел Центр обработки данных → SDN и нажать кнопку Применить:
    Применить изменения
В результате на каждом узле создаётся WireGuard-интерфейс (например, wg0) с назначенными IP-адресами туннеля:
$ ip -br a
enp0s9           UP             10.16.0.2/32 fe80::a00:27ff:fe9e:5ea4/64
wg0              UNKNOWN        198.51.100.1/24
В таблице маршрутизации появляются маршруты для удалённых пиров:
$ ip route
198.51.100.0/24 dev wg0 proto kernel scope link src 198.51.100.1
198.51.100.2 dev wg0 scope link
198.51.100.3 dev wg0 scope link
Конфигурация WireGuard-интерфейса доступна через wg show:
# wg show wg0
interface: wg0
  public key: 54GHc/L8zfRM0XJnR7syhVv1Abl4A4l3JoWa9joIlWM=
  private key: (hidden)
  listening port: 51820

peer: +Vv7sh/mBXcGIVj30P/09guL3G4Ky566AwywL0kXDzU=
  endpoint: 192.168.0.70:51820
  allowed ips: 198.51.100.3/32
  latest handshake: 16 seconds ago
  transfer: 180 B received, 420 B sent
  persistent keepalive: every 25 seconds

peer: VxcuW+7KMQN4knBfC8TA9fC3coPoUNvivU22Tk35bgo=
  endpoint: 192.168.0.90:51820
  allowed ips: 198.51.100.2/32
  latest handshake: 20 seconds ago
  transfer: 180 B received, 272 B sent
  persistent keepalive: every 25 seconds
При определении интерфейса PVE автоматически генерирует для него приватный ключ и сохраняет его в /etc/pve/priv/wg-keys.cfg при сохранении интерфейса. Соответствующий публичный ключ сохраняется вместе с конфигурацией интерфейса в фабрике WireGuard и используется для отображения в веб-интерфейс при редактировании узла. При удалении интерфейса соответствующий приватный ключ также удаляется из wg-keys.cfg в рамках того же API-вызова.
Фабрика автоматически формирует маршруты через интерфейс WireGuard на основе списка Allowed IPs каждого пира. Например, если интерфейс wg0 содержит два пира с разрешёнными сетями 198.51.100.0/24 и 203.0.113.0/24, в таблице маршрутизации создаются маршруты для обеих подсетей.
Если пир связан с интерфейсом узла PVE, IP-адрес этого интерфейса дополнительно добавляется как маршрут хоста в список разрешённых IP-адресов. Например, для узла с адресом 192.0.2.10/24 дополнительно создаётся маршрут 192.0.2.10/32.
Пример создания WireGuard-фабрики в консоли:
  1. Создание фабрики:
    # pvesh create /cluster/sdn/fabrics/fabric  \
      --id wg \
      --protocol wireguard \
      --persistent_keepalive 25
    
    # pvesh get /cluster/sdn/fabrics/fabric/wg --output-format yaml
    ---
    digest: 2c28ab53ac729ad29189e4f2a52a548d942e25415488ab4c30d1d676dc707005
    id: wg
    persistent_keepalive: 25
    protocol: wireguard
    id: wg
    
  2. Добавление узлов:
    # pvesh create /cluster/sdn/fabrics/node/wg  \
      --node_id pve01 --protocol wireguard --role internal \
      --interfaces name=wg2,ip=150.50.0.1/32,listen_port=51821 \
      --endpoint 192.168.0.186
    
    # pvesh create /cluster/sdn/fabrics/node/wg  \
      --node_id pve02 --protocol wireguard --role internal \
      --interfaces name=wg2,ip=150.50.0.2/32,listen_port=51821 \
      --endpoint 192.168.0.90
    
    # pvesh create /cluster/sdn/fabrics/node/wg  \
      --node_id pve03 --protocol wireguard --role internal \
      --interfaces name=wg2,ip=150.50.0.3/32,listen_port=51821 \
      --endpoint 192.168.0.70
    
  3. Настройка peers:
    # pvesh set /cluster/sdn/fabrics/node/wg/pve01 --protocol wireguard \
      --peers iface=wg2,node=pve02,type=internal,node_iface=wg2 \
      --peers iface=wg2,node=pve03,type=internal,node_iface=wg2 \
      --interfaces name=wg2,ip=150.50.0.1/32,listen_port=51821
    
    # pvesh set /cluster/sdn/fabrics/node/wg/pve02 --protocol wireguard \
      --peers iface=wg2,node=pve03,type=internal,node_iface=wg2 \
      --peers iface=wg2,node=pve01,type=internal,node_iface=wg2 \
      --interfaces name=wg2,ip=150.50.0.2/32,listen_port=51821
    
    # pvesh set /cluster/sdn/fabrics/node/wg/pve03 --protocol wireguard \
      --peers iface=wg2,node=pve01,type=internal,node_iface=wg2 \
      --peers iface=wg2,node=pve02,type=internal,node_iface=wg2 \
      --interfaces name=wg2,ip=150.50.0.3/32,listen_port=51821
    
  4. Проверка:
    # pvesh get /cluster/sdn/fabrics/node/wg --output-format yaml
    ---
    - digest: a38ab69cd7a07ed73f23a070b446eaa1dc663516734169280432234b5d212b6f
      endpoint: 192.168.0.186
      fabric_id: wg
      interfaces:
      - name=wg2,listen_port=51821,public_key=lz/I7U9p8//g+JH4jk5E2TQZO9lJfOUOX5MgMCGBaUc=,ip=150.50.0.1/32
      node_id: pve01
      peers:
      - type=internal,node=pve02,node_iface=wg2,iface=wg2
      - type=internal,node=pve03,node_iface=wg2,iface=wg2
      protocol: wireguard
      role: internal
    - digest: a38ab69cd7a07ed73f23a070b446eaa1dc663516734169280432234b5d212b6f
      endpoint: 192.168.0.90
      fabric_id: wg
      interfaces:
      - name=wg2,listen_port=51821,public_key=/kMeSUnr76FE+iPu39NMZcvYqMM8ovjClNJ+BJ76cRA=,ip=150.50.0.2/32
      node_id: pve02
      peers:
      - type=internal,node=pve03,node_iface=wg2,iface=wg2
      - type=internal,node=pve01,node_iface=wg2,iface=wg2
      protocol: wireguard
      role: internal
    - digest: a38ab69cd7a07ed73f23a070b446eaa1dc663516734169280432234b5d212b6f
      endpoint: 192.168.0.70
      fabric_id: wg
      interfaces:
      - name=wg2,listen_port=51821,public_key=zH6M9GsD1i41cjW7luP3z1i8dXl9L1q9pT4ZYpPQmCE=,ip=150.50.0.3/32
      node_id: pve03
      peers:
      - type=internal,node=pve01,node_iface=wg2,iface=wg2
      - type=internal,node=pve02,node_iface=wg2,iface=wg2
      protocol: wireguard
      role: internal
    
  5. Применение конфигурации:
    # pvesh set /cluster/sdn
    
Содержимое файла /etc/pve/sdn/fabrics.cfg:
wireguard_fabric: wg

wireguard_node: wg_pve01
	endpoint 192.168.0.186
	interfaces name=wg2,listen_port=51821,public_key=lz/I7U9p8//g+JH4jk5E2TQZO9lJfOUOX5MgMCGBaUc=,ip=150.50.0.1/32
	peers type=internal,node=pve02,node_iface=wg2,iface=wg2
	peers type=internal,node=pve03,node_iface=wg2,iface=wg2
	role internal

wireguard_node: wg_pve02
	endpoint 192.168.0.90
	interfaces name=wg2,listen_port=51821,public_key=/kMeSUnr76FE+iPu39NMZcvYqMM8ovjClNJ+BJ76cRA=,ip=150.50.0.2/32
	peers type=internal,node=pve03,node_iface=wg2,iface=wg2
	peers type=internal,node=pve01,node_iface=wg2,iface=wg2
	role internal

wireguard_node: wg_pve03
	endpoint 192.168.0.70
	interfaces name=wg2,listen_port=51821,public_key=zH6M9GsD1i41cjW7luP3z1i8dXl9L1q9pT4ZYpPQmCE=,ip=150.50.0.3/32
	peers type=internal,node=pve01,node_iface=wg2,iface=wg2
	peers type=internal,node=pve02,node_iface=wg2,iface=wg2
	role internal

⁠32.5.2.4. Настройка BGP

BGP (Border Gateway Protocol) может использоваться в качестве неадресной (unnumbered) eBGP-фабрики. Каждый узел имеет собственный номер автономной системы (ASN) и устанавливает пиринговые отношения с соседями через физические интерфейсы без необходимости назначения IP-адресов на линках фабрики.
Пример создания BGP в веб-интерфейсе:
  1. Перейти в раздел Центр обработки данных → SDN → Фабрики, нажать кнопку Добавить фабрику и в раскрывающемся списке выбрать пункт BGP:
    Создание фабрики
  2. Указать параметры фабрики:
    • Имя — имя фабрики (до 8 символов);
    • Префикс IPv4 (ip_prefix) — IPv4-сеть в формате CIDR (например, 192.0.2.0/24), используемая для проверки того, что все IPv4-адреса узлов (BGP router-ID) находятся в пределах этого префикса;
    • Префикс IPv6 (ip6_prefix) — IPv6-сеть в формате CIDR (например, 2001:db8::/64), используемая для проверки того, что все IPv6-адреса узлов в фабрике находятся в пределах этого префикса;
    • BFD — включает Bidirectional Forwarding Detection (BFD) для всех пиринговых сессий в данной фабрике. BFD обеспечивает быстрое обнаружение сбоев на линках между узлами;
    • Route Filter (route_filter) — ссылка на список префиксов. Список префиксов, применяемый к входящему направлению (inbound) пир-группы фабрики. Если задан, этот список префиксов заменяет неявный фильтр «должен находиться в пределах префикса фабрики». Используется для расширения принимаемого диапазона (например, для приема дополнительных нефабричных префиксов, реэкспортируемых через фабрику), либо применения более сложных условий сопоставления;
    • Incoming Route Map (Входящая карта маршрутов) — карта маршрутов, вызываемая из неявного входящего фильтра пир-группы фабрики через действие call в FRR. Только префиксы, прошедшие проверку (или переопределённую проверку через Route Filter), попадают в эту карту. Используется для преобразования или дополнительного ограничения принимаемых маршрутов (например, установки community или local-preference), но не может расширять набор принимаемых маршрутов;
    • Outgoing Route Map (Исходящая карта маршрутов) — карта маршрутов, применяемая к исходящему направлению (outbound) пир-группы фабрики. Используется для фильтрации или преобразования анонсируемых маршрутов;
    • Route Redistribution (Реэкспорт маршрутов) — маршруты каких протоколов BGP-маршрутизатор на каждом узле должен реэкспортировать в фабрику. Поддерживаются источники: connected, kernel, static и ospf. Для каждого источника можно назначить карту маршрутов для управления экспортируемыми маршрутами.
    Создание BGP

    Примечание

    Должен быть настроен хотя бы один из префиксов: IPv4 или IPv6.
  3. Добавить узлы в фабрику:
    • нажать кнопку + в строке фабрики или выбрать фабрику и нажать кнопку Добавить узел на верхней панели;
    • в открывшемся окне выбрать узел, указать IP-адрес узла в поле IPv4, выбрать интерфейсы узла, которые должны входить в состав fabric-сети, и нажать кнопку Создать или Create another (если нужно настроить несколько узлов):
      Добавление узла в Fabric
      Параметры узла:
      • Узел — узел, который добавляется в фабрику (список включает только узлы кластера);
      • IPv4 (ip_prefix) — уникальный IPv4-адрес, используемый в качестве BGP router-id. Обязателен, если для фабрики настроен префикс IPv4-префикс; каждый узел в одной фабрике должен иметь уникальный адрес;
      • IPv6 (ip6_prefix) — уникальный IPv6-адрес для данного узла. Если используется только IPv6, BGP router-id может быть вычислен на его основе с помощью хеш-функции FNV-1a;
      • ASN — номер автономной системы BGP для данного узла. Рекомендуется использовать приватные диапазоны ASN: 64512–65534 (16-bit) и 4200000000–4294967294 (32-bit);
      • Interfaces (interfaces) — физические интерфейсы, используемые для установления пиринговых соединений с другими узлами BGP. Эти интерфейсы работают в режиме BGP unnumbered (IP-адреса не требуются). При настройке IPv4/IPv6 адреса узла автоматически создаётся loopback-интерфейс с этим адресом.

      Примечание

      В отличие от OSPF и OpenFabric, неадресным интерфейсам BGP не требуются IP-адреса. Пиринг устанавливается через IPv6 link-local адреса.

      Примечание

      В неадресной eBGP-фабрике непосредственно пирингующиеся узлы должны иметь разные ASN.
  4. Активировать конфигурацию. Для этого перейти в раздел Центр обработки данных → SDN и нажать кнопку Применить:
    Активировать конфигурацию BGP
В результате на каждом узле создаётся dummy-интерфейс с адресом router-ID:
$ ip -br a | grep dummy_
dummy_bgp-mesh   UNKNOWN        10.10.0.1/32 fe80::44cd:10ff:fe70:6081/64

Примечание

Чтобы проверить, сходится ли сеть BGP, можно использовать оболочку vtysh. Соседей и маршруты BGP можно увидеть с помощью следующих команд:
  • проверка соседей:
    # vtysh -c "show openfabric neighbor"
    
  • проверка маршрутов:
    # vtysh -c "show openfabric route"
    
⁠32.5.2.4.1. Использование BGP-фабрик с EVPN
При настройке EVPN-контроллера в качестве транспортной сети (underlay) можно использовать BGP-фабрику вместо ручного указания адресов пиров. По умолчанию сессии EVPN (VTEP) запускаются в режиме iBGP с использованием ASN контроллера EVPN.
ASN фабрики для каждого узла автоматически применяется через механизм local-as в группе соседей транспортной сети.
Это означает, что ASN контроллера EVPN и ASN фабрики должны различаться. Например, если узлы используют ASN 65001, 65002 и 65003 для underlay-сети, контроллер EVPN может использовать ASN 65000 для overlay.
В альтернативной конфигурации при установке режима BGP «external» на контроллере EVPN VTEP-сессии работают в режиме eBGP. В этом случае ASN фабрики используется как локальный ASN для пир-группы VTEP, и узлы устанавливают пиринг друг с другом под разными ASN без необходимости отдельного ASN для overlay. ASN контроллера EVPN при этом используется для автоматического формирования route-target, обеспечивая их согласованность во всей фабрике.

Примечание

Использование BGP-фабрики для транспортной сети EVPN требует наличия IPv4-адреса на каждом узле, так как он используется как VTEP-адрес.

⁠32.6. Списки префиксов и карты маршрутов

Списки префиксов и карты маршрутов используются для управления политиками маршрутизации в SDN PVE. Они позволяют:
  • ограничивать распространение маршрутов между узлами и пирами BGP, EVPN, OSPF и OpenFabric;
  • фильтровать маршруты по префиксам;
  • изменять атрибуты маршрутов при импорте и экспорте.
Оба механизма работают совместно:
  • список префиксов выполняет классификацию маршрутов по CIDR и диапазонам префиксов;
  • карта маршрутов определяет политику обработки маршрутов (match → action → set) в виде упорядоченных правил.
Конфигурация SDN хранится в кластере PVE в каталоге /etc/pve/sdn/ и транслируется в конфигурацию FRR:
  • prefix-list → FRR prefix-lists
  • route-map → FRR route-maps
Итоговая конфигурация FRR формируется на каждом узле в /etc/frr/frr.conf. Локальные дополнения могут быть заданы в /etc/frr/frr.conf.local.
Изменения SDN сначала попадают в состояние ожидания (pending) и применяются только после подтверждения в веб-интерфейсе SDN.

⁠32.6.1. Списки префиксов (prefix-list)

Список префиксов — это упорядоченный именованный набор записей, каждая из которых сопоставляется с одним целевым CIDR (или диапазоном длин префиксов внутри него) и либо разрешает (permit), либо запрещает (deny) его. FRR обрабатывает записи последовательно и применяет первое совпавшее правило. Если совпадений нет, маршрут неявно отклоняется.
Управление списками префиксов осуществляется в разделе Центр обработки данных → SDN → Prefix Lists.
Раздел «Prefix Lists»
Каждый список содержит одну или несколько записей со следующими свойствами:
  • Sequence Nr. (seq) — порядок, в котором запись оценивается внутри списка. Должен быть уникальным в пределах списка и не менее 1. Если поле не задано при создании, PVE автоматически назначает следующий свободный порядковый номер по принципу «максимальное значение + 5», оставляя место для последующих вставок;
  • Действие (action) — permit (разрешить) или deny (запретить). В конце списка действует неявный запрет;
  • Prefix (prefix) — целевая сеть в нотации CIDR, например 192.0.2.0/24 или 2001:db8::/32. Префиксы 0.0.0.0/0 и ::/0 допустимы и соответствуют маршруту по умолчанию;

    Примечание

    В веб-интерфейсе PVE нельзя задать префиксы 0.0.0.0/0 и ::/0 при создании или редактировании списков префиксов. Такие значения не проходят валидацию формы.
    Эти префиксы можно задать следующими способами:
    • вручную в конфигурационном файле /etc/pve/sdn/prefix-lists.cfg;
    • через интерфейс командной строки (CLI) PVE SDN.
  • Prefix <= (le) — необязательная максимальная длина префикса. Если задано, запись сопоставляется с подсетями, длина которых не больше указанного значения;
  • Prefix >= (ge) — необязательная минимальная длина префикса. Если задано, запись сопоставляется с подсетями, длина которых не меньше указанного значения.
Создание записи Prefix Lists
Если ge и le не указаны, выполняется точное совпадение. При указании обоих параметров запись применяется ко всем подсетям в заданном диапазоне длин. Например:
10.0.0.0/8 ge 16 le 24
означает все подсети от /16 до /24 внутри 10.0.0.0/8.
Ограничения PVE:
  • ge не должен превышать le;
  • значения не могут быть меньше длины базового префикса;
  • значения ограничены семейством адресов (/32 IPv4, /128 IPv6).

Примечание

Имена only_default, only_default_v6 и loopbacks_ips зарезервированы. Контроллеры BGP и EVPN генерируют их автоматически, и они не могут использоваться как пользовательские списки префиксов.

⁠32.6.2. Карты маршрутов (Route Maps)

Карта маршрутов — это упорядоченный список записей, которые сопоставляют входящие или исходящие маршруты с заданными критериями, при необходимости изменяют их атрибуты (например, метрику или local preference) и либо разрешают (передают маршрут, возможно с изменениями), либо запрещают (отбрасывают маршрут). FRR оценивает записи по порядку; первое совпадение определяет действие. Каждая карта маршрутов неявно содержит финальное правило deny, отклоняющее все маршруты, не совпавшие ни с одной записью.
Управление картами маршрутов осуществляется в разделе Центр обработки данных → SDN → Route Maps.
Раздел «Route Maps»
Каждая запись имеет следующие свойства:
  • Route Map ID — имя карты маршрутов (логический идентификатор route-map), которое используется для группировки записей;
  • Порядок — порядок обработки записи (0 – 65535). Обязательный параметр, должен быть уникальным внутри одной карты маршрутов. Использование промежутков (например, 10, 20, 30) позволяет добавлять новые записи без перенумерации;
  • Действие (action) — permit или deny. permit пропускает маршрут (после выполнения действий set); deny — отбрасывает его;
  • Совпадение (match) — одно или несколько условий сопоставления. Поддерживаемые ключи:
    • route-type
    • vni
    • ip-address-prefix-list
    • ip6-address-prefix-list
    • ip-next-hop-prefix-list
    • ip6-next-hop-prefix-list
    • ip-next-hop-address
    • ip6-next-hop-address
    • metric
    • local-preference
    • peer
    • tag
    Четыре ключа *-prefix-list ссылаются на список префиксов по имени. tag сопоставляется с 32-битным атрибутом тега маршрута, тем же значением, которое присваивается действием set tag; это позволяет одной записи помечать маршруты тегом, а последующей записи (в той же или другой карте) выполнять над ними действия. Все условия должны выполняться одновременно;
  • Набор (set) — атрибуты, устанавливаемые при совпадении. Поддерживаются:
    • ip-next-hop
    • local-preference
    • metric
    • tag
    • weight
    • src
    Значение metric поддерживает операции N, +N, -N (корректировка), rtt, +rtt, -rtt, igp и aigp. Значение tag принимает целое число или буквальное значение untagged;
  • Call (call) — вызов другой карты маршрутов после обработки текущей записи;
  • Exit Policy (exit-action) — управление переходом после совпадения:
    • exit — завершить обработку (поведение по умолчанию);
    • on-match-next — перейти к следующей записи;
    • on-match-goto <порядок> — перейти к записи с указанным или следующим порядком;
    • continue <порядок> — продолжить с записи с конкретным порядковым номером.
Создание записи карты маршрутов
В веб-интерфейсе каждая запись Route Map отображается как отдельная строка. В конфигурационном файле /etc/pve/sdn/route-maps.cfg имя секции формируется автоматически как:
<Route Map ID>_<Порядок>
где:
  • bgp-out — имя карты маршрутов;
  • 10 — порядок выполнения записи.

Примечание

Имена MAP_VTEP_IN, MAP_VTEP_OUT, correct_src и все имена, начинающиеся с pve_, зарезервированы системой.
Карту маршрутов нельзя удалить, если она используется. Сначала необходимо удалить ссылки на неё.

⁠32.6.3. Использование списков префиксов и карт маршрутов

BGP- и EVPN-контроллеры применяют входящие и исходящие карты маршрутов. Входящие карты применяются к маршрутам, полученным от пиров, перед установкой в таблицу маршрутизации; исходящие — перед анонсированием маршрутов. Оба параметра являются опциональными и выбираются из карт маршрутов SDN.
Для фабрик OSPF и OpenFabric предусмотрен фильтр маршрутов (Route Filter), который ссылается на список префиксов. Если фильтр задан, в таблицу маршрутизации ядра устанавливаются только маршруты, соответствующие списку. Если фильтр не задан, используется автоматический фильтр на основе IPv4 Prefix и IPv6 Prefix (access-list FRR), разрешающий соответствующие сети.
Примеры:
  • разрешить только маршрут по умолчанию IPv4:
    # /etc/pve/sdn/prefix-lists.cfg
    
    prefix-list: default-only
     entries action=permit,prefix=0.0.0.0/0,seq=10
    
  • разрешить подсети /16 — /24 внутри 10.0.0.0/8 и запретить всё остальное в пределах блока 10.0.0.0/8:
    # /etc/pve/sdn/prefix-lists.cfg
    
    prefix-list: internal-subnets
     entries action=permit,prefix=10.0.0.0/8,ge=16,le=24,seq=10
     entries action=deny,prefix=10.0.0.0/8,le=32,seq=20
    
Route-map пример (BGP outbound policy):
# /etc/pve/sdn/route-maps.cfg

route-map-entry: bgp-out_10
 action permit
 match key=ip-address-prefix-list,value=internal-subnets
 set key=local-preference,value=50

route-map-entry: bgp-out_20
 action permit
Последняя запись permit без условий сопоставления используется как стандартный шаблон FRR («разрешить всё остальное»). Без неё неявный deny в конце карты маршрутов отбрасывал бы все несовпавшие маршруты.

⁠32.7. IPAM

Системы управления IP-адресами (IP Address Management, IPAM) предназначены для учёта адресного пространства, управления подсетями и назначения IP-адресов ВМ и контейнерам.
Один экземпляр IPAM может быть связан с одной или несколькими зонами.

⁠32.7.1. Плагин PVE IPAM

PVE IPAM — встроенный механизм управления IP-адресами в PVE.
Текущее состояние плагина PVE IPAM можно просмотреть в разделе Центр обработки данных → SDN → IPAM. Здесь можно создавать, редактировать и удалять сопоставления IP-адресов:
Панель IPAM
Если используется DHCP, панель IPAM можно использовать для создания или редактирования IP-адресов, выделенных определенным ВМ. После изменения IP-адреса следует перезапустить сетевой стек гостевой системы или перезагрузить ВМ.
Текущее состояние плагина PVE IPAM можно посмотреть с помощью команды:
# pvesh get /cluster/sdn/ipams/pve/status --output-format yaml

⁠32.7.2. Плагин NetBox IPAM

NetBox — это инструмент управления IP-адресами (IPAM) и инфраструктурой центра обработки данных (DCIM) с открытым исходным кодом.

Примечание

Перед подключением в NetBox необходимо сгенерировать API-токен.
Добавить плагин NetBox можно в разделе Центр обработки данных → SDN → Параметры → IPAM, нажав кнопку Добавить → NetBox:
Добавление плагина IPAM
Параметры конфигурации NetBox:
  • URL-адрес (url) — конечная точка NetBox REST API: http://<netboxURL>/api;
  • Токен (token) — API-токен доступа;
  • Отпечаток (fingerprint) — отпечаток SHA-256 сертификата сервера NetBox (требуется при использовании самоподписанного сертификата). Получить отпечаток можно, выполнив на сервере NetBox команду:
    # openssl x509 -in /var/lib/ssl/certs/nginx-netbox.cert -noout -fingerprint -sha256
    sha256 Fingerprint=17:71:60:6A:C7:65:10:7E:FA:00:91:42:…:3A:CB:7B:F3:D0:0C:DC:DE
    
    
Добавление плагина NetBox

⁠32.7.3. Плагин phpIPAM

phpIPAM — система управления IP-адресами с открытым исходным кодом. Позволяет централизованно отслеживать подсети, резервировать IP-адреса, управлять VLAN и интегрироваться с внешними системами через REST API.

Примечание

Перед подключением в phpIPAM необходимо создать «приложение» и сгенерировать API-токен с правами администратора.
Добавить плагин phpIPAM можно в разделе Центр обработки данных → SDN → Параметры → IPAM, нажав кнопку Добавить → phpIPAM:
Добавление плагина IPAM
Параметры конфигурации phpIPAM:
  • URL-адрес (url) — конечная точка REST API: http://<phpipam>/api/<appname>/;
  • Токен (token) — API-токен доступа;
  • Секция (section) — идентификатор раздела (целое число). Раздел — это группа подсетей в phpIPAM. По умолчанию для клиентов используется sectionid=1.
  • Отпечаток (fingerprint) — отпечаток SHA-256 сертификата сервера phpIPAM (требуется при использовании самоподписанного сертификата). Получить отпечаток можно, выполнив на сервере phpIPAM команду:
    # openssl x509 -in /etc/openssl/phpipam/phpipam.crt -noout -fingerprint -sha256
    sha256 Fingerprint=52:EA:33:D0:D4:0D:7E:EE:D5:58:1A:C5:88:…:6B:7B:5A:F4:64:95:4D:E1:41:C4
    
Добавление плагина phpIPAM

⁠32.8. DNS

Плагин DNS в PVE SDN используется для автоматического управления DNS-записями (например, A/AAAA и PTR) при назначении IP-адресов через IPAM. Конфигурация DNS может быть связана с одной или несколькими зонами для регистрации DNS-записей всех IP-адресов в подсетях этих зон.
Добавить плагин DNS можно в разделе Центр обработки данных → SDN → Параметры в секции DNS, нажав кнопку Добавить → powerdns.
Добавление плагина DNS

⁠32.8.1. Плагин PowerDNS

Примечание

PowerDNS должен быть установлен на внешнем сервере и подключен через API.
В конфигурации PowerDNS должны быть включены веб-сервер и REST API:
api=yes
api-key=WcSieGekANq5KCcEkSk8k7Mv88Wbm7 # случайно сгенерированная строка
webserver=yes
webserver-port=8081
Добавление плагина PowerDNS
Параметры конфигурации PowerDNS:
  • URL (url) — конечная точка REST API: http://<powerdnserver>:8081/api/v1/servers/localhost;
  • Ключ API (token) — ключ доступа API;
  • TTL (ttl) — время жизни DNS-записей по умолчанию.

⁠32.9. DHCP

Плагин DHCP в PVE SDN используется для автоматического развертывания DHCP-сервера в зоне. Он предоставляет DHCP для всех подсетей в зоне, в которых настроен диапазон адресов. В настоящее время единственным доступным бэкенд-плагином для DHCP является плагин dnsmasq.
Плагин DHCP выделяет IP-адреса через IPAM-плагин зоны при добавлении нового сетевого интерфейса в ВМ или контейнер.
При запуске ВМ в плагине DHCP зоны создается сопоставление для MAC и IP-адреса. При удалении сетевых интерфейсов или уничтожении ВМ/контейнера записи в IPAM и DHCP также удаляются.

Примечание

Некоторые функции (добавление, редактирование, удаление сопоставлений IP) в настоящее время доступны только при использовании плагина PVE IPAM.
Включить DHCP для зоны можно в дополнительных параметрах зоны — поле Автоматически (DHCP).

Примечание

В настоящее время только простые зоны (Simple Zone) поддерживают DHCP.
Если для зоны включен DHCP, для подсетей в зоне необходимо настроить диапазоны DHCP. Сделать это можно в разделе Vnets, выбрав подсеть, для которой нужно настроить диапазоны DHCP. Диапазоны DHCP для подсети также можно задать с помощью команды:
# pvesh set /cluster/sdn/vnets/<vnet>/subnets/<subnet> \
  --dhcp-range start-address=10.10.1.100,end-address=10.10.1.200 \
  --dhcp-range start-address=10.10.2.100,end-address=10.10.2.200
Для подсети также необходимо настроить шлюз — в противном случае DHCP работать не будет.
Плагин DHCP будет выделять IP-адреса в IPAM только в настроенных диапазонах.

⁠32.9.1. Плагин Dnsmasq

В настоящее время Dnsmasq — единственный плагин DHCP и, следовательно, плагин, который используется при включении DHCP для зоны.
Плагин создаёт новую службу systemd для каждой зоны, в которой развертывается dnsmasq. Имя службы — dnsmasq@<zone>. Жизненный цикл этой службы управляется плагином DHCP.
Плагин автоматически генерирует следующие конфигурационные файлы в каталоге /etc/dnsmasq.d/<zone>:
  • 00-default.conf — содержит глобальную конфигурацию по умолчанию для экземпляра dnsmasq;
  • 10-<Vnet>.conf — содержит DHCP-диапазоны для экземпляра dnsmasq;
  • ethers — содержит сопоставления MAC и IP-адресов из плагина IPAM. Чтобы переопределить эти сопоставления, следует использовать соответствующий плагин IPAM, а не редактировать этот файл, так как он будет перезаписан плагином dnsmasq.
Вышеуказанные файлы нельзя редактировать, так как они управляются плагином DHCP. Для настройки конфигурации можно создать дополнительные файлы (например, 90-custom.conf) — они не будут изменены плагином DHCP dnsmasq.
Аренда DHCP хранится в файле /var/lib/misc/dnsmasq.<zone>.leases.
При использовании плагина PVE IPAM можно управлять DHCP-арендой (см. Плагин PVE IPAM)

⁠32.10. Интеграция с межсетевым экраном

SDN интегрируется с межсетевым экраном PVE, автоматически генерируя наборы IP-адресов (IPSet), на которые затем можно ссылаться в полях источника/назначения правил межсетевого экрана. Наборы IP-адресов генерируются автоматически для записей VNets и IPAM.

⁠32.10.1. Виртуальные сети и подсети

Межсетевой экран автоматически генерирует следующие наборы IP-адресов в области SDN для каждой виртуальной сети:
  • vnet-all — содержит CIDR всех подсетей в виртуальной сети;
  • vnet-gateway — содержит IP-адреса шлюзов всех подсетей в виртуальной сети;
  • vnet-no-gateway — содержит CIDR всех подсетей в виртуальной сети, но исключает шлюзы;
  • vnet-dhcp — содержит все диапазоны DHCP, настроенные в подсетях в виртуальной сети.
При изменении конфигурации наборы IP-адресов обновляются автоматически.
Например, для конфигурации: простая зона (simple) с виртуальной сетью vnet0, для которой настроены две подсети:
  • подсеть IPv4 10.20.30.0/24 с шлюзом 10.20.30.1 и диапазоном DHCP 10.20.30.100 - 10.20.30.150;
  • подсеть IPv6 2001:db8::/64 с шлюзом 2001:db8::1 и диапазоном DHCP 2001:db8::100 - 2001:db8::199.
# /etc/pve/sdn/vnets.cfg
vnet: vnet0
	zone simple

# /etc/pve/sdn/subnets.cfg
subnet: simple-10.20.30.0-24
	vnet vnet0
	dhcp-range start-address=10.20.30.100,end-address=10.20.30.150
	gateway 10.20.30.1
	snat 1
subnet: simple-2001:db8::-64
	vnet vnet0
	dhcp-range start-address=2001:db8::100,end-address=2001:db8::199
	gateway 2001:db8::1
	snat 1
Автоматически сгенерированные IP-наборы для vnet0 будут содержать следующие элементы:
vnet0-all
10.20.30.0/24
2001:db8::/64

vnet0-gateway
10.20.30.1
2001:db8::1

vnet0-no-gateway
10.20.30.0/24
2001:db8::/64

!10.20.30.1
!2001:db8::1

vnet0-dhcp
10.20.30.100 – 10.20.30.150
2001:db8::1000 – 2001:db8::1999

⁠32.10.2. IPAM

Если используется встроенный PVE IPAM, то межсетевой экран автоматически генерирует IPset для каждой гостевой системы, у которой есть записи в IPAM. Например, ВМ с ID 100 будет соответствовать IPset guest-ipam-100. Он будет содержать все IP-адреса из всех записей IPAM. Таким образом, если ВМ 100 является членом нескольких виртуальных сетей, то IPset будет содержать IP-адреса из всех VNet.
При добавлении/обновлении/удалении записей IPSet будут обновлены соответствующим образом.

Примечание

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

⁠32.11. Примеры настройки SDN

Примечание

Для возможности создания зон на каждом узле кластера в файле /etc/network/interfaces должна присутствовать строка:
source /etc/network/interfaces.d/*

⁠32.11.1. Настройка Simple Zone

Пример создания Simple Zone в веб-интерфейсе:
  1. Создать зону:
    • перейти в раздел Центр обработки данных → SDN → Зоны, нажать кнопку Добавить и в раскрывающемся списке выбрать пункт Simple:
      Создание зоны
    • указать название и другие параметры зоны:
      Создание Simple Zone
      Для возможности автоматического назначения IP-адресов гостевым системам, можно установить отметку в поле Автоматически (DHCP) (доступно если отмечен пункт Дополнительно).
  2. Создать виртуальную сеть:
    • перейти в раздел Центр обработки данных → SDN → VNets и в секции VNets нажать кнопку Создать:
      Кнопка Создать виртуальную сеть
    • в открывшемся окне указать название сети и выбрать созданную на предыдущем шаге зону:
      Создание виртуальной сети
  3. Cоздать подсеть (определить параметры для виртуальной сети):
    • выделить созданную сеть и в секции Подсети нажать кнопку Создать:
      Кнопка Создать подсеть
    • на вкладке Общее указать:
      • Подсеть — адрес сети в нотации CIDR;
      • Шлюз — IP-адрес шлюза по умолчанию сети. В зонах уровня 3 (плагины Simple/EVPN) он будет развернут в виртуальной сети;
      • SNAT — включить Source NAT, который позволяет гостевым системам из VNet подключаться к внешней сети, пересылая пакеты на исходящий интерфейс узлов. В зонах EVPN пересылка выполняется на шлюзовых узлах EVPN (если доступ к внешней сети не нужен, можно не устанавливать эту отметку);
      • Префикс зоны DNS — позволяет добавить префикс к регистрации домена, например <hostname>.prefix.<domain>;
      Создание подсети. Вкладка Общее
    • на вкладке Диапазоны адресов DHCP, если для зоны был отмечен пункт Автоматически (DHCP), можно настроить диапазоны адресов, которые будут выдаваться сервером DHCP:
      Создание подсети. Вкладка Диапазоны адресов DHCP
  4. Применить изменения. Для этого перейти в раздел Центр обработки данных → SDN и нажать кнопку Применить:
    Применить изменения
    В результате на узлах кластера, которые были выбраны при создании зоны, появятся созданные виртуальные зоны и сетевые мосты:
    Созданные виртуальные зоны
  5. Назначить виртуальный мост гостевым системам (сделать это можно при создании или редактировании параметров ВМ/контейнера), например:
    Назначение виртуального моста ВМ
    Гостевой системе также необходимо назначить статический IP-адрес из диапазона IP-адресов подсети или выбрать получение IP-адреса по DHCP, если для зоны был отмечен Автоматический DHCP.

Примечание

Если при настройке сети был отмечен пункт SNAT, узел автоматически получит IP-адрес шлюза (10.25.16.1) и будет функционировать в качестве NAT-шлюза для гостевых систем в указанной подсети.
Пример создания Simple Zone в консоли:
  1. Создать зону simple:
    # pvesh create /cluster/sdn/zones --type simple --zone simple --dhcp dnsmasq --ipam pve
    
    # pvesh get /cluster/sdn/zones/simple --output-format yaml
    ---
    dhcp: dnsmasq
    digest: 9ad0df155d3dab9967a90671dc6123d771f65d29
    type: simple
    zone: simple
    
  2. Создать сеть vnet0:
    # pvesh create /cluster/sdn/vnets --vnet vnet0 --zone simple
    
    # pvesh get /cluster/sdn/vnets/vnet0 --output-format yaml
    ---
    digest: f137eddad03996ecf6c48aa8b6bd96ef2c8aab3d
    type: vnet
    vnet: vnet0
    zone: simple
    
  3. Создать подсеть 10.20.30.0/24:
    # pvesh create /cluster/sdn/vnets/vnet0/subnets \
      --subnet 10.20.30.0/24 --type subnet \
      --dhcp-range "start-address=10.20.30.10,end-address=10.20.30.20" \
      --gateway 10.20.30.1 --snat 1
    
    # pvesh get /cluster/sdn/vnets/vnet0/subnets --output-format yaml
    ---
    - cidr: 10.20.30.0/24
      dhcp-range:
      - end-address: 10.20.30.20
        start-address: 10.20.30.10
      digest: ca799c5ffdc2ffc30f60ed303bd79f4c13cc6519
      gateway: 10.20.30.1
      id: simple-10.20.30.0-24
      mask: '24'
      network: 10.20.30.0
      snat: 1
      subnet: simple-10.20.30.0-24
      type: subnet
      vnet: vnet0
      zone: simple
    
  4. Изменить диапазон выдаваемых DHCP-сервером IP-адресов:
    # pvesh set /cluster/sdn/vnets/vnet0/subnets/simple-10.20.30.0-24 \
      --dhcp-range start-address=10.20.30.100,end-address=10.20.30.150
    
    Если нужно не изменить, а добавить новый диапазон, команда будет выглядеть так:
    # pvesh set /cluster/sdn/vnets/vnet0/subnets/simple-10.20.30.0-24 \
      --dhcp-range start-address=10.20.30.10,end-address=10.20.30.20 \
      --dhcp-range start-address=10.20.30.100,end-address=10.20.30.150
    
  5. Применить ожидающую конфигурацию SDN:
    # pvesh set /cluster/sdn
    pve03: reloading network config
    pve01: reloading network config
    pve02: reloading network config
    UPID:pve01:00021C9F:0029311C:681F9B30:reloadnetworkall::root@pam:
    
  6. Назначить виртуальный мост vnet0 контейнеру 101:
    # pvesh set /nodes/pve01/lxc/101/config --net0 name=eth0,bridge=vnet0,ip=dhcp
    
    # pvesh get /nodes/pve01/lxc/101/config --output-format yaml
    ---
    arch: amd64
    cores: 1
    digest: a954d7b078b605d6d477dcd4303419080963ac7f
    features: nesting=1
    hostname: ALTp11
    memory: 512
    net0: name=eth0,bridge=vnet0,hwaddr=BC:24:11:02:A2:1A,ip=dhcp,type=veth
    ostype: altlinux
    rootfs: local-lvm:vm-101-disk-0,size=8G
    swap: 512
    unprivileged: 1
    
На вкладке Центр обработки данных → SDN → IPAM будут отображаться виртуальные сети и все задействованные IP-адреса:
Виртуальные сети и задействованные IP-дреса
Соединение между гостевыми системами будет возможно, если все они находятся на одном узле.

⁠32.11.2. Настройка зоны VLAN

Пример создания зоны VLAN в веб-интерфейсе:
  1. Создать зону myvlan:
    • перейти в раздел Центр обработки данных → SDN → Зоны, нажать кнопку Добавить и в раскрывающемся списке выбрать пункт VLAN:
      Создание зоны
    • указать название зоны и в поле Bridge указать интерфейс моста. При необходимости в поле MTU можно задать собственное значение MTU (по умолчанию 1450):
      Создание зоны VLAN
  2. Создать виртуальную сеть:
    • перейти в раздел Центр обработки данных → SDN → VNets и в секции VNets нажать кнопку Создать:
      Кнопка Создать виртуальную сеть
    • в открывшемся окне указать название сети, выбрать созданную на предыдущем шаге зону и в поле Метка указать VLAN ID:
      Создание виртуальной сети для зоны VLAN
  3. Применить изменения. Для этого перейти в раздел Центр обработки данных → SDN и нажать кнопку Применить:
    Применить изменения
    В результате на узлах кластера, которые были выбраны при создании зоны, появятся созданные виртуальные зоны и сетевые мосты.
  4. Назначить виртуальный мост гостевым системам, например:
    Пример настройки сетевого устройства контейнера 101

Примечание

Если при настройке сети был отмечен пункт SNAT, узел автоматически получит IP-адрес шлюза (10.25.16.1) и будет функционировать в качестве NAT-шлюза для гостевых систем в указанной подсети.
Пример создания зоны VLAN в консоли:
  1. Создать зону myvlan2:
    # pvesh create /cluster/sdn/zones --type vlan --zone myvlan2 --bridge vmbr0 --ipam pve
    
    # pvesh get /cluster/sdn/zones/myvlan2 --output-format yaml
    ---
    bridge: vmbr0
    digest: 58543afd2dd2b1edf46b9d11647b0cdf42293509
    ipam: pve
    type: vlan
    zone: myvlan2
    
  2. Создать сеть vlannet2:
    # pvesh create /cluster/sdn/vnets --vnet vlannet2 --zone myvlan2 --tag 100
    
    # pvesh get /cluster/sdn/vnets/vlannet2 --output-format yaml
    ---
    digest: 41e1f7bff1c16506882b4ee1290d6dd066bc8333
    tag: 100
    type: vnet
    vnet: vlannet2
    zone: myvlan2
    
  3. Применить ожидающую конфигурацию SDN:
    # pvesh set /cluster/sdn
    
  4. Назначить виртуальный мост контейнеру 106 на узле pve03:
    # pvesh set /nodes/pve03/lxc/106/config \
      --net0 name=eth0,bridge=vlannet2,gw=192.168.100.1,ip=192.168.100.94/24
    
Соединение между гостевыми системами будет возможно, даже если они находятся на разных узлах, при условии, что физическая сеть настроена для передачи трафика соответствующего VLAN между узлами.

⁠32.11.3. Настройка зоны QinQ

В этом примере настраиваются две зоны QinQ и добавляются две ВМ в каждую зону для демонстрации дополнительного уровня тегов VLAN, что позволяет настраивать более изолированные VLAN.
Пример создания зоны QinQ в веб-интерфейсе:
  1. Создать зону qinq20 со служебной VLAN 20:
    • перейти в раздел Центр обработки данных → SDN → Зоны, нажать кнопку Добавить и в раскрывающемся списке выбрать пункт QinQ:
      Создание зоны
    • указать название зоны, в поле Bridge мост, через который будет передаваться трафик, в поле Сервисная VLAN указать VLAN ID (внешний VLAN ID, который будет использоваться на физическом уровне). При необходимости в поле MTU можно задать собственное значение MTU (по умолчанию 1450):
      Создание зоны QinQ
  2. Повторить п.1 и создать зону qinq30 с VLAN ID 30.
  3. Создать виртуальную сеть qvnet1 с VLAN ID 100 в зоне qinq20:
    • перейти в раздел Центр обработки данных → SDN → VNets и в секции VNets нажать кнопку Создать:
      Кнопка Создать виртуальную сеть
    • в открывшемся окне указать название сети, выбрать созданную на предыдущем шаге зону и в поле Метка указать VLAN ID (внутренний VLAN ID):
      Создание виртуальной сети для зоны QinQ
  4. Повторить п.3 и создать виртуальную сеть qvnet2 с VLAN ID 100 в зоне qinq30.
  5. Применить изменения. Для этого перейти в раздел Центр обработки данных → SDN и нажать кнопку Применить:
    Применить изменения
  6. Cоздать четыре ВМ, в качестве моста для первой пары ВМ необходимо указать qvnet1, для второй — qvnet2. Внутри ВМ настроить IP-адреса интерфейсов, например, назначив IP-адреса из диапазона 10.0.3.101–10.0.3.104.
В результате данной настройки возможность пинговать друг друга будет у ВМ1 и ВМ2, а также у ВМ3 и ВМ4. Однако ни одна из машин ВМ1 или ВМ2 не сможет пинговать ВМ3 или ВМ4, так как они находятся в зоне с другим сервисным VLAN.
Пример создания зоны QinQ в консоли:
  1. Создать зону myqinq:
    # pvesh create /cluster/sdn/zones --type qinq --zone myqinq --bridge vmbr0 --ipam pve --tag 40
    
    # pvesh get /cluster/sdn/zones/myqinq --output-format yaml
    ---
    bridge: vmbr0
    digest: 6e9910da8a2ff11579e69c1302c0b5296932e0cc
    ipam: pve
    tag: 40
    type: qinq
    zone: myqinq
    
  2. Создать сеть myqnet:
    # pvesh create /cluster/sdn/vnets --vnet myqnet --zone myqinq --tag 100
    
    # pvesh get /cluster/sdn/vnets/myqnet --output-format yaml
    ---
    digest: 7153cea08ff37c355366ff3edd70d8a54f157046
    tag: 100
    type: vnet
    vnet: myqnet
    zone: myqinq
    
  3. Применить ожидающую конфигурацию SDN:
    # pvesh set /cluster/sdn
    
  4. Назначить виртуальный мост контейнеру 106 на узле pve03:
    # pvesh set /nodes/pve03/lxc/106/config \
      --net0 name=eth0,bridge=myqnet,gw=192.168.100.1,ip=192.168.100.94/24
    

⁠32.11.4. Настройка зоны VXLAN

В примере рассматривается кластер с тремя узлами (pve01, pve02, pve03). IP-адреса узлов: 192.168.0.186, 192.168.0.90 и 192.168.0.70.
Пример создания зоны VXLAN в веб-интерфейсе:
  1. Создать зону:
    • перейти в раздел Центр обработки данных → SDN → Зоны, нажать кнопку Добавить и в раскрывающемся списке выбрать пункт VXLAN:
      Создание зоны
    • указать название зоны и в поле Список адресов одноранговых узлов добавить IP-адреса всех узлов кластера:
      Создание зоны VXLAN
      или в поле SDN Fabric указать ранее созданную fabric-сеть:
      Underlay для VXLAN
      При необходимости в поле MTU можно задать собственное значение MTU (по умолчанию 1450):
  2. Создать виртуальную сеть:
    • перейти в раздел Центр обработки данных → SDN → VNets и в секции VNets нажать кнопку Создать:
      Кнопка Создать виртуальную сеть
    • в открывшемся окне указать название сети, выбрать созданную на предыдущем шаге зону и в поле Метка указать VLAN ID:
      Создание виртуальной сети для зоны VXLAN
  3. Применить изменения. Для этого перейти в раздел Центр обработки данных → SDN и нажать кнопку Применить:
    Применить изменения
  4. Назначить виртуальный мост гостевым системам, например:
    Пример настройки сетевого устройства контейнера 101
Пример создания зоны VXLAN в консоли:
  1. Создать зону myvxlan:
    # pvesh create /cluster/sdn/zones --type vxlan --zone myvxlan \
      --peers 192.168.0.186,192.168.0.90,192.168.0.70 --ipam pve
    
    # pvesh get /cluster/sdn/zones/myvxlan --output-format yaml
    ---
    digest: 2b49f2691553ab2bc10b7a3486926995a02af885
    ipam: pve
    peers: 192.168.0.186,192.168.0.90,192.168.0.70
    type: vxlan
    zone: myvxlan
    
  2. Создать сеть myvxnet:
    # pvesh create /cluster/sdn/vnets --vnet myvxnet --zone myvxlan --tag 200000
    
    # pvesh get /cluster/sdn/vnets/myvxnet --output-format yaml
    ---
    digest: ee2782a86911fd35fc37d478b4d3aadce2380ce6
    tag: 200000
    type: vnet
    vnet: myvxnet
    zone: myvxlan
    
  3. Применить ожидающую конфигурацию SDN:
    # pvesh set /cluster/sdn
    
  4. Назначить виртуальный мост контейнеру 106 на узле pve03:
    # pvesh set /nodes/pve03/lxc/106/config \
      --net0 name=eth0,bridge=myvxnet,gw=192.168.100.1,ip=192.168.100.94/24
    
Соединение между гостевыми системами будет возможно, даже если они находятся на разных узлах.

⁠Глава 33. Миграция ВМ и контейнеров

В случае, если PVE управляет не одним физическим узлом, а кластером узлов, должна обеспечиваться возможность миграции ВМ с одного узла на другой.
Миграция — это процесс сохранения состояния ВМ на одном узле, переноса её данных и конфигурации на другой узел и восстановления состояния на новом месте.
Возможные сценарии, при которых может потребоваться миграция:
  • отказ физического узла;
  • необходимость перезагрузки узла после применения обновлений или проведения технического обслуживания;
  • перенос ВМ с менее производительного узла на более производительный.
Существуют два механизма миграции:
  • онлайн-миграция (Live Migration);
  • офлайн-миграция.

Примечание

Миграция контейнеров без перезапуска в настоящее время не поддерживается.
При миграции запущенного контейнера он будет остановлен, перемещён и затем снова запущен на целевом узле. Поскольку контейнеры являются легковесными, простой обычно составляет несколько сотен миллисекунд.
Для выполнения онлайн-миграции ВМ должны соблюдаться следующие условия:
  • у ВМ отсутствуют локальные ресурсы, которые невозможно перенести. Например, напрямую проброшенные устройства PCI или USB блокируют Live Migration. Локальные диски могут быть перенесены при указании целевого хранилища;
  • хосты входят в один кластер PVE;
  • между хостами имеется надежное сетевое соединение;
  • на целевом хосте установлены те же или более новые версии пакетов PVE.
Миграция в реальном времени обеспечивает минимальный простой ВМ, однако занимает больше времени. В процессе Live Migration (без выключения ВМ) копируется всё содержимое оперативной памяти на целевой узел. Чем больше объём выделенной памяти, тем дольше будет выполняться перенос.
Если ВМ использует локальные ресурсы, её можно перенести в офлайн-режиме при условии, что все диски находятся в хранилище, доступном на обоих хостах. В этом случае при миграции диски будут скопированы на целевой узел по сети — аналогично процессу онлайн-миграции.
Запустить процесс миграции можно как в графическом интерфейсе PVE, так и в интерфейсе командной строки.

⁠33.1. Настройка сети миграции

PVE позволяет изолировать трафик миграции ВМ от управляющего трафика (веб-интерфейс, API, SSH). Это повышает безопасность и снижает нагрузку на основную сеть.
Изоляция достигается за счёт:
  • выделенной подсети;
  • отдельного сетевого интерфейса или моста на каждом узле кластера.
Указать сеть миграции можно двумя способами:
  1. Через веб-интерфейс (Центр обработки данных → Параметры → Параметры миграции → Редактировать):
    Настройка сети миграции
  2. Напрямую в файле /etc/pve/datacenter.cfg:
    migration: network=10.10.10.150/24,type=secure
В параметре network указывается подсеть в формате CIDR. Параметр type=secure означает использование SSH-туннеля для передачи данных миграции.

Важно

На каждом узле кластера должен быть настроен сетевой интерфейс с IP-адресом из указанной подсети. Сеть миграции должна обеспечивать низкую задержку и высокую пропускную способность.
При запуске миграции PVE выполняет следующие действия:
  1. Определяет сеть миграции, указанную в /etc/pve/datacenter.cfg.
  2. Находит на исходном и целевом узлах интерфейсы с IP-адресами из этой подсети.
  3. Передаёт данные памяти ВМ через выбранный интерфейс.

⁠33.2. Миграция состояний сonntrack

Примечание

Миграция состояний сonntrack выполняется по принципу best-effort и может не сработать, так как сильно зависит от сетевой конфигурации. Например, схемы с использованием маскарадинга (MASQUERADE) или SNAT на уровне хоста, при которых соединения привязаны к IP-адресу исходного узла, обычно не поддерживаются.
Conntrack — это механизм ядра Linux, обеспечивающий работу stateful firewall за счёт отслеживания состояния сетевых соединений.
При онлайн-миграции ВМ активные входящие и исходящие соединения могут быть прерваны в момент запуска ВМ на целевом узле. Это связано с тем, что на целевом узле отсутствуют соответствующие записи сonntrack, и межсетевой экран может начать отбрасывать пакеты.
Механизм миграции состояний сonntrack позволяет скопировать записи, относящиеся к мигрируемой ВМ, с исходного узла на целевой. После успешной миграции эти записи удаляются из таблицы сonntrack на исходном узле. Это позволяет сохранить активные сетевые соединения (например, SSH или TCP-сессии) при миграции ВМ без их разрыва.

⁠33.3. Миграция с применением графического интерфейса

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

    Примечание

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

⁠33.4. Миграция в командной строке

Чтобы выполнить миграцию ВМ, необходимо использовать следующую команду:
# qm migrate <vmid> <target> [OPTIONS]
Для выполнения миграции ВМ в реальном времени следует добавить параметр --online.
Пример онлайн миграции с миграцией состояния conntrack:
# qm migrate 104 pve02 --online --with-conntrack-state
Чтобы выполнить миграцию контейнера необходимо использовать команду:
# pct migrate <ctid> <target> [OPTIONS]
Поскольку миграция контейнеров в реальном времени не поддерживается, для переноса работающего контейнера с его автоматическим перезапуском необходимо добавить параметр --restart. Например:
# pct migrate 101 pve02 --restart

⁠33.5. Миграция ВМ из внешнего гипервизора

Импорт ВМ из внешнего гипервизора обычно заключается в переносе одного или нескольких образов дисков и файла конфигурации, описывающего параметры ВМ (ОЗУ, количество ядер и т. д.). Образы дисков могут быть в формате vmdk (VMware или VirtualBox) или qcow2 (KVM). Наиболее распространённым форматом конфигурационного файла для экспорта ВМ является стандарт OVF.

Примечание

Для ВМ Windows необходимо дополнительно установить паравиртуализированные драйверы Windows.
Для импорта ВМ из внешних гипервизоров (VMware ESXi, Hyper-V) или для переноса между кластерами PVE доступны следующие методы:
  1. Мастер импорта (прямое подключение к ESXi-хранилищу или импорт файлов в форматах OVA/OVF). Мастер автоматически определяет конфигурацию ВМ и позволяет изменить параметры перед развёртыванием;
  2. Импорт с помощью команды qm importovf (для файлов OVF/OVA, экспортированных из VMware или VirtualBox).
  3. Создание резервной копии ВМ на исходном узле и последующее восстановление на целевом узле (для миграции между кластерами PVE). При этом сохраняются все параметры ВМ, включая сетевые интерфейсы и диски.

⁠33.5.1. Импорт из ESXi-хранилища

PVE предоставляет встроенный инструмент для импорта ВМ напрямую из хранилищ VMware ESXi.
Для возможности использования мастера импорта из ESXi-хранилища должно быть настроено хранилище ESXi.
Процедура импорта ВМ:
  1. В дереве ресурсов выбрать ранее настроенное хранилище ESXi. На вкладке Виртуальные гостевые машины отобразятся все доступные для импорта гостевые системы:
    Доступные для импорта гостевые системы
  2. Выбрать нужную ВМ из списка и запустить мастер импорта, нажав кнопку Импорт.
  3. В открывшемся окне настроить параметры ВМ:
    • на вкладке Общее указать базовые параметры ВМ: имя ВМ, ID, ресурсы;
      Импорт ВМ. Вкладка Общее
    • на вкладке Дополнительно можно выбрать целевые хранилища для дисков ВМ и изменить сетевые настройки:
      Импорт ВМ. Вкладка Дополнительно
    • на вкладке Итоговая конфигурация можно проверить сводку настроек перед началом импорта:
      Импорт ВМ. Вкладка Итоговая конфигурация
  4. Нажать кнопку Импорт для запуска процесса.

Примечание

Сложные правки можно внести после завершения импорта.

Примечание

Следует обратить внимание, что гостевые системы, использующие хранилище vSAN, не могут быть импортированы напрямую; их диски сначала необходимо переместить в другое хранилище.

⁠33.5.2. Импорт OVA/OVF

Для возможности импорта ВМ из файлов OVA/OVF в веб-интерфейсе необходимо файловое хранилище с типом содержимого import. Для хранилища с таким типом содержимого будет создан каталог import, в который можно загрузить файлы OVA (архивный формат) или набор файлов OVF + VMDK/RAW (в плоской структуре, без подкаталогов).
OVA-файлы можно также загрузить в хранилище напрямую через веб-интерфейс:
  1. В дереве ресурсов выбрать хранилище, с настроенным типом содержимого import.
  2. Перейти на вкладку Импорт.
  3. Нажать кнопку Отправить, если нужно загрузить файл с локального диска, или кнопку Скачать по URL-адресу, если нужно скачать файл с сервера.
  4. Для локальной загрузки: выбрать файл и нажать кнопку Отправить:
    Загрузка файла OVA в каталог import с локального диска
    Для загрузки с сервера: указать URL-адрес и нажать кнопку Скачивание:
    Загрузка файла OVA в каталог import с сервера
Процедура импорта ВМ:
  1. В дереве ресурсов выбрать хранилище и перейти на вкладку Импорт.
  2. Выбрать файл OVA и запустить мастер импорта, нажав кнопку Импорт:
    Запуск мастера импорта
  3. В открывшемся окне настроить параметры ВМ:
    • на вкладке Общее указать базовые параметры ВМ: имя ВМ, ID, ресурсы;
      Импорт ВМ. Вкладка Общее
    • на вкладке Дополнительно можно выбрать целевые хранилища для дисков ВМ и изменить сетевые настройки:
      Импорт ВМ. Вкладка Дополнительно
    • на вкладке Итоговая конфигурация можно проверить сводку настроек перед началом импорта.
  4. Нажать кнопку Импорт.

Примечание

Для OVA-файлов требуется дополнительное место для временного извлечения образов. По умолчанию используется исходное хранилище, но можно указать отдельное рабочее хранилище для распаковки.

Примечание

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

⁠33.5.3. Импорт OVA/OVF в консоли

Команда импорта ВМ из файлов OVF и VMDK:
# qm importovf <VMID> /path/to/vm.ovf <целевое хранилище>
Процедура импорта ВМ:
  1. Скопировать файлы ovf и vmdk на хост PVE (в примере haos_ova-15.2.ovf и haos_ova-15.2.vmdk).
  2. Создать новую ВМ, используя имя ВМ, информацию о ЦП и памяти из файла конфигурации OVF, и импортировать диски в хранилище local-lvm:
    # qm importovf 999 haos_ova-15.2.ovf local-lvm
    

Примечание

Если вместо файлов ovf и vmdk есть файл ova, его необходимо предварительно распаковать, например:
$ tar -xvf haos_ova-15.2.ova

Примечание

Сеть необходимо настроить вручную.

⁠33.5.4. Резервное копирование и восстановление

Для миграции ВМ или контейнеров между разными кластерами PVE, или просто между двумя несвязанными узлами PVE, не объединёнными в один кластер, можно использовать резервное копирование и восстановление файла резервной копии.
Процедура миграции с одного узла PVE на другой:
  1. На исходном узле PVE создать резервную копию ВМ:
    # vzdump <VMID> --storage <хранилище резервных копий> --mode snapshot --compress zstd
    
  2. Перенести файл резервной копии (vzdump-qemu-<VMID>-<date>.vma.zst) на целевой PVE.
  3. Восстановить ВМ:
    # qmrestore /path/to/vzdump-qemu-<VMID><date>.vma.zst <new_VMID> --storage <целевое хранилище>
    

⁠33.5.5. Миграция KVM ВМ в PVE

В данном разделе рассмотрен процесс миграции ВМ из OpenNebula в PVE в ручном режиме.
Выключить ВМ на хосте источнике. Найти путь до образа жесткого диска, который используется в ВМ (в данной команде 14 — id образа диска ВМ):
$ oneimage show 14
IMAGE 14 INFORMATION
ID             : 14
NAME           : ALT Linux p9
USER           : oneadmin
GROUP          : oneadmin
LOCK           : None
DATASTORE      : default
TYPE           : OS
REGISTER TIME  : 04/30 11:00:42
PERSISTENT     : Yes
SOURCE         : /var/lib/one//datastores/1/f811a893808a9d8f5bf1c029b3c7e905
FSTYPE         : save_as
SIZE           : 12G
STATE          : used
RUNNING_VMS    : 1

PERMISSIONS
OWNER          : um-
GROUP          : ---
OTHER          : ---

IMAGE TEMPLATE
DEV_PREFIX="vd"
DRIVER="qcow2"
SAVED_DISK_ID="0"
SAVED_IMAGE_ID="7"
SAVED_VM_ID="46"
SAVE_AS_HOT="YES"
где /var/lib/one//datastores/1/f811a893808a9d8f5bf1c029b3c7e905 — адрес образа жёсткого диска ВМ.
Скопировать данный образ с PVE на хост назначения.

Примечание

В OpenNebula любой диск ВМ можно экспортировать в новый образ (если ВМ находится в состояниях RUNNING, POWEROFF или SUSPENDED):
$ onevm disk-saveas <vmid> <diskid> <img_name>  [--type type --snapshot snapshot]
где --type <type> — тип нового образа (по умолчанию raw); --snapshot <snapshot_id> — снимок диска, который будет использован в качестве источника нового образа (по умолчанию текущее состояние диска).
Экспорт диска ВМ:
$ onevm disk-saveas 125 0 test.qcow2
Image ID: 44
Информация об образе диска ВМ:
$ oneimage show 44
MAGE 44 INFORMATION
ID             : 44
NAME           : test.qcow2
USER           : oneadmin
GROUP          : oneadmin
LOCK           : None
DATASTORE      : default
TYPE           : OS
REGISTER TIME  : 07/12 21:34:42
PERSISTENT     : No
SOURCE         : /var/lib/one//datastores/1/9d6336a88d6ab62ea1dce65d81e55881
FSTYPE         : save_as
SIZE           : 12G
STATE          : rdy
RUNNING_VMS    : 0

PERMISSIONS
OWNER          : um-
GROUP          : ---
OTHER          : ---

IMAGE TEMPLATE
DEV_PREFIX="vd"
DRIVER="qcow2"
SAVED_DISK_ID="0"
SAVED_IMAGE_ID="14"
SAVED_VM_ID="125"
SAVE_AS_HOT="YES"

VIRTUAL MACHINES
Информация о диске:
$ qemu-img info /var/lib/one//datastores/1/9d6336a88d6ab62ea1dce65d81e55881
image: /var/lib/one//datastores/1/9d6336a88d6ab62ea1dce65d81e55881
file format: qcow2
virtual size: 12 GiB (12884901888 bytes)
disk size: 3.52 GiB
cluster_size: 65536
Format specific information:
    compat: 1.1
    compression type: zlib
    lazy refcounts: false
    refcount bits: 16
    corrupt: false
    extended l2: false
На хосте назначения подключить образ диска к ВМ (рассмотрено подключение на основе Directory Storage), выполнив следующие действия:
  1. Создать новую ВМ в веб-интерфейсе PVE или командой:
    # qm create 120 --bootdisk scsi0 --net0 virtio,bridge=vmbr0 --scsihw virtio-scsi-pci
    
  2. Чтобы использовать в PVE образ диска в формате qcow2 (полученный из другой системы KVM, либо преобразованный из другого формата), его необходимо импортировать. Команда импорта:
    # qm importdisk <vmid> <source> <storage> [OPTIONS]
    
    Импорт диска f811a893808a9d8f5bf1c029b3c7e905 в хранилище local, для ВМ с ID 120 (подразумевается, что образ импортируемого диска находится в каталоге, из которого происходит выполнение команды):
    # qm importdisk 120 f811a893808a9d8f5bf1c029b3c7e905 local --format qcow2
    importing disk 'f811a893808a9d8f5bf1c029b3c7e905' to VM 120 ...
    …
    Successfully imported disk as 'unused0:local:120/vm-120-disk-0.qcow2'
    
  3. Привязать диск к ВМ.
    В веб-интерфейсе PVE: перейти на вкладку Оборудование созданной ВМ. В списке устройств будет показан неиспользуемый жесткий диск, выбрать его, выбрать режим SCSI и нажать кнопку Добавить:
    Добавление диска к ВМ
    В командной строке:
    # qm set 120 --scsi0 local:120/vm-120-disk-0.qcow2
    update VM 120: -scsi0 local:120/vm-120-disk-0.qcow2
    
Донастроить параметры процессора, памяти, сетевых интерфейсов, порядок загрузки. Включить ВМ.

⁠33.5.6. Миграция ВМ из VMware в PVE

В данном разделе рассмотрена миграция ВМ в ручном режиме из VMware в PVE на примере ВМ с Windows 7.
Подготовить ОС Windows. ОС Windows должна загружаться с дисков в режиме IDE.
Подготовить образ диска. Необходимо преобразовать образ диска в тип single growable virtual disk. Сделать это можно с помощью утилиты vmware-vdiskmanager (поставляется в комплекте с VMWare Workstation). Для преобразования образа перейти в папку с образами дисков и выполнить команду:
"C:\Program Files\VMware\VMware Server\vmware-vdiskmanager" -r win7.vmdk -t 0 win7-pve.vmdk
где win7.vmdk — файл с образом диска.
На хосте назначения подключить образ диска к ВМ одним из трёх указанных способов:
  1. Подключение образа диска к ВМ на основе Directory Storage:
    • в веб-интерфейсе PVE создать ВМ KVM;
    • скопировать преобразованный образ win7-pve.vmdk в каталог с образами ВМ /var/lib/vz/images/VMID, где VMID — VMID, созданной виртуальной машины (можно воспользоваться WinSCP);
    • преобразовать файл win7-pve.vmdk в qemu формат:
      # qemu-img convert -f vmdk win7-pve.vmdk -O qcow2 win7-pve.qcow2
      
    • добавить в конфигурационный файл ВМ (/etc/pve/nodes/pve02/qemu-server/VMID.conf) строку:
      unused0: local:100/win7-pve.qcow2
      
      где 100 — VMID, а local — хранилище в PVE.
    • перейти в веб-интерфейсе PVE на вкладку Оборудование созданной ВМ. В списке устройств будет показан неиспользуемый жесткий диск, выбрать его, выбрать режим IDE и нажать кнопку Добавить:
      Добавление диска к ВМ
  2. Подключение образа диска к ВМ на основе LVM Storage:
    • в веб-интерфейсе PVE создать ВМ с диском большего размера, чем диск в образе vmdk. Посмотреть размер диска в образе можно командой:
      # qemu-img info win7-pve.vmdk
      image: win7-pve.vmdk
      file format: vmdk
      virtual size: 127G (136365211648 bytes)
      disk size: 20.7 GiB
      cluster_size: 65536
      Format specific information:
          cid: 3274246794
          parent cid: 4294967295
          create type: streamOptimized
          extents:
              [0]:
                  compressed: true
                  virtual size: 136365211648
                  filename: win7-pve.vmdk
                  cluster size: 65536
                  format:
      
      В данном случае необходимо создать диск в режиме IDE размером не меньше 127GB.
    • скопировать преобразованный образ win7-pve.vmdk в каталог с образами ВМ /var/lib/vz/images/VMID, где VMID — VMID, созданной виртуальной машины (можно воспользоваться WinSCP);
    • перейти в консоль ноды кластера и посмотреть, как называется LVM диск созданной ВМ (диск должен быть в статусе ACTIVE):
      # lvscan
        ACTIVE            '/dev/sharedsv/vm-101-disk-1' [130,00 GiB] inherit
      
    • сконвертировать образ vdmk в raw-формат непосредственно на LVM-устройство:
      # qemu-img convert -f vmdk win7-pve.vmdk -O raw /dev/sharedsv/vm-101-disk-1
      
  3. Подключение образа диска к ВМ на основе CEPH Storage:
    • в веб-интерфейсе PVE создать ВМ с диском большего размера, чем диск в образе vmdk. Посмотреть размер диска в образе можно командой:
      # qemu-img info win7-pve.vmdk
      
    • скопировать преобразованный образ win7-pve.vmdk в каталог с образами ВМ /var/lib/vz/images/VMID, где VMID — VMID созданной ВМ;
    • перейти в консоль ноды кластера. Отобразить образ из пула CEPH в локальное блочное устройство:
      # rbd map rbd01/vm-100-disk-1
      /dev/rbd0
      

      Примечание

      Имя нужного пула можно посмотреть на вкладке Центр обработки данных → Хранилище → rbd-storage.
    • сконвертировать образ vdmk в raw-формат непосредственно на отображенное устройство:
      # qemu-img convert -f vmdk win7-pve.vmdk -O raw /dev/rbd0
      
Адаптация новой ВМ:
  1. Проверить режим работы жесткого диска: для Windows — IDE, для Linux — SCSI.
  2. Установить режим VIRTIO для жесткого диска (режим VIRTIO также доступен для Windows, но сразу загрузиться в этом режиме система не может):
    • загрузиться сначала в режиме IDE и выключить машину, добавить еще один диск в режиме VIRTIO и включить машину. Windows установит нужные драйвера;
    • выключить машину;
    • изменить режим основного диска с IDE на VIRTIO;
    • загрузить систему, которая должна применить VIRTIO драйвер и выдать сообщение, что драйвер от RedHat.
  3. Включить ВМ. Первое включение займет какое-то время (будут загружены необходимые драйвера).

⁠Глава 34. Клонирование ВМ

Простой способ развернуть несколько ВМ одного типа — создать клон существующей ВМ.
Существует два вида клонов:
  • Полный клон — независимая копия ВМ, дисковые образы которой не зависят от исходной ВМ. При создании полного клона можно выбрать целевое хранилище, что позволяет разместить копию в другом хранилище. Если драйвер целевого хранилища поддерживает несколько форматов, можно также изменить формат образов виртуальных дисков.
  • Связанный клон — копия ВМ, которая использует исходный образ диска в качестве базового. Создание связанного клона происходит практически мгновенно и на начальном этапе не требует дополнительного места для копирования данных диска. Новый образ диска ссылается на исходный: неизменённые блоки данных считываются из базового образа, а изменения записываются в отдельный образ. Для работы связанного клона исходный образ должен оставаться доступным и использоваться в режиме только для чтения.
    В PVE можно преобразовать ВМ в шаблон, который впоследствии используется для создания связанных клонов. При создании связанного клона нельзя выбрать другое целевое хранилище, поскольку размещение связанных образов определяется возможностями и ограничениями хранилища.

Примечание

При создании полного клона необходимо прочитать и скопировать все данные образов ВМ. Поэтому полное клонирование обычно занимает значительно больше времени, чем создание связанного клона.
Для клонирования ВМ необходимо выполнить следующие действия:
  1. Создать ВМ с необходимыми настройками (все создаваемые из такой ВМ клоны будут иметь идентичные настройки) или воспользоваться существующей ВМ;
  2. В контекстном меню ВМ выбрать пункт Клонировать:
    Контекстное меню ВМ
  3. В открывшемся диалоговом окне укажите следующие параметры:
    • Целевой узел — узел, на котором будет создан клон. Для создания клона на другом узле исходная ВМ должна находиться в общем хранилище, доступном на целевом узле;
    • VM ID — идентификатор новой ВМ;
    • Имя — название новой ВМ;
    • Пул ресурсов — пул, к которому будет относиться новая ВМ;
    • Режим — способ клонирования (если клонирование происходит из шаблона ВМ). Доступны значения: Полное клонирование и Связанная копия;
    • Снимок — снимок, данные которого будут использоваться при создании клона (если у данной ВМ есть снимк);
    • Целевое хранилище — хранилище для виртуальных дисков клона;
    • Формат — формат образов виртуальных дисков; возможность выбора зависит от типа хранилища.
    Настройки клонирования
  4. Нажать кнопку Клонировать, чтобы запустить процесс клонирования.
Некоторые типы хранилищ позволяют создать клон на основе определённого снимка ВМ. Если снимок не выбран, используются текущие данные ВМ. Клон не содержит остальные снимки исходной ВМ.
Выбор снимка для клонирования
Чтобы избежать конфликтов ресурсов, при клонировании MAC-адреса сетевых интерфейсов генерируются заново. Для параметра SMBIOS smbios1 также генерируется новый UUID.

⁠Глава 35. Шаблоны ВМ

ВМ можно преобразовать в шаблон. Шаблоны доступны только для чтения и используются как основа для создания клонов.

Примечание

Если ВМ содержит снимки (snapshot), преобразовать её в шаблон невозможно. Перед созданием шаблона необходимо удалить все снимки этой ВМ.
Чтобы преобразовать ВМ в шаблон, необходимо в её контекстном меню выбрать пункт Сохранить как шаблон и подтвердить действие, нажав кнопку Да.
Создание шаблона ВМ

Примечание

Запустить шаблон невозможно, поскольку это могло бы привести к изменению образов его дисков. Если требуется изменить содержимое шаблона, следует создать связанный клон и внести изменения в него.
Для создания связанного клона необходимо выполнить следующие действия:
  1. В контекстном меню шаблона ВМ выбрать пункт Клонировать:
    Контекстное меню шаблона ВМ
  2. Указать параметры клонирования. В поле Режим выбрать значение Связанная копия:
    Создание связанного клона
  3. Нажать кнопку Клонировать.

⁠Глава 36. Теги (метки) ВМ

Для упорядочивания ресурсов ВМ и контейнерам можно назначать теги (метки).
Теги отображаются в дереве ресурсов и в строке состояния выбранной ВМ или контейнера:
Теги ВМ 103
Теги позволяют выполнять фильтрацию ВМ:
Фильтрация ВМ по тегам (меткам)
В дереве ресурсов можно выбрать режим просмотра В виде меток. В этом режиме гостевые системы группируются по тегам:
Режим просмотра «В виде меток»
Для выполнения массового действия с ВМ можно выбрать соответствующий пункт в контекстном меню тега. Например, чтобы запустить все ВМ с определённым тегом, откройте контекстное меню этого тега и выберите пункт Массовый запуск:
Контекстное меню тега

⁠36.1. Работа с тегами

Чтобы добавить, изменить или удалить теги, нажмите значок карандаша в строке статуса ВМ:
Строка статуса ВМ
Можно добавить несколько тегов, нажав кнопку Кнопка добавления тега , и удалить их, нажав кнопку Кнопка удаления тега . Для сохранения или отмены изменений используются кнопки Кнопка сохранения и Кнопка отмены :
Теги ВМ 102
Теги также можно задавать в командной строке (несколько тегов разделяются точкой с запятой):
  • для ВМ:
    # qm set ID --tags 'linux;openuds'
    
  • для контейнера:
    # pct set 101 --tags 'linux;openuds'
    

⁠36.2. Настройка тегов

В разделе Центр обработки данных → Параметры доступны настройки тегов, позволяющие управлять их отображением, доступностью и регистрацией:
Настройки тегов

⁠36.2.1. Стиль тегов

Переопределение стилей меток
В параметре Переопределение стилей меток можно настроить цвет, форму отображения тегов в дереве ресурсов, чувствительность к регистру и способ сортировки. Доступны следующие параметры:
  • Форма дерева (Shape):
    • Полное — отображение тегов в виде текстовых меток;
    • Круговое — отображение тегов в виде цветных кругов;
    • Плотное — компактное отображение тегов в виде небольших прямоугольников (удобно, если ВМ назначено много тегов);
    • Нет — отключение отображения тегов в дереве ресурсов;
  • Порядок —  определение порядка сортировки тегов;
  • С учётом регистра — определение того, различаются ли теги, отличающиеся только регистром символов;
  • Переопределение цветов — позволяет задать цвета для тегов (по умолчанию цвета выбираются автоматически).
Настроить стиль тегов также можно в командной строке, используя команду:
# pvesh set /cluster/options --tag-style [case-sensitive=<1|0>]\
[,color-map=<tag>:<hex-color> [:<hex-color-for-text>][;<tag>=...]]\
[,ordering=<config|alphabetical>][,shape=<circle|dense|full|none>]
Например, следующая команда задаёт для тега «FreeIPA» чёрный цвет фона (#000000) и белый цвет текста (#FFFFFF), а для отображения тегов в дереве ресурсов устанавливает компактную форму:
# pvesh set /cluster/options --tag-style color-map=FreeIPA:000000:FFFFFF,shape=dense

Примечание

При изменении параметра --tag-style необходимо учитывать, что передача новой конфигурации заменит ранее заданные переопределения стилей тегов.

⁠36.2.2. Права

По умолчанию пользователи, имеющие привилегию VM.Config.Options на ресурсе /vms/ID (см. раздел Управление доступом), могут назначать ему любые теги. При необходимости это поведение можно ограничить в разделе Доступ к пользовательским меткам:
Доступ к пользовательским меткам
Доступны следующие режимы (поле Режим):
  • free — пользователи могут назначать произвольные теги (по умолчанию);
  • list — пользователи назначать только теги из предварительно заданного списка;
  • existing — пользователи могут назначать теги из предварительно заданного списка и теги, уже существующие в конфигурации;
  • none — пользователи не могут назначать теги.
В этом же разделе можно определить, какие теги разрешено использовать (поле Предустановленные метки) при использовании режимов list или existing.
Назначить права можно также в командной строке:
# pvesh set /cluster/options --user-tag-access \
[user-allow=<existing|free|list|none>][,user-allow-list=<tag>[;<tag>...]]
Например, чтобы запретить пользователям использовать теги:
# pvesh set /cluster/options --user-tag-access user-allow=none
Следует учитывать, что пользователь с привилегией Sys.Modify на / всегда может добавлять и удалять любые теги независимо от настроек раздела Доступ к пользовательским меткам. Кроме того, можно задать список зарегистрированных тегов. Управлять такими тегами — добавлять их в конфигурацию и удалять из неё — могут только пользователи с привилегией Sys.Modify на корневом ресурсе /. Этот список можно редактировать в разделе Зарегистрированные метки или через интерфейс командной строки:
# pvesh set /cluster/options --registered-tags <tag>[;<tag>...]
Зарегистрированные метки

⁠Глава 37. Резервное копирование (Backup)

PVE предоставляет встроенные средства резервного копирования ВМ и контейнеров. Резервные копии включают конфигурацию гостевой системы и данные, предусмотренные для резервного копирования.
Резервное копирование можно запустить через веб-интерфейс или с помощью утилиты командной строки vzdump.
Задания резервного копирования можно планировать: настроить автоматическое выполнение в заданные дни и часы для выбранных узлов и гостевых систем.

⁠37.1. Режимы резервного копирования

Способ обеспечения согласованности данных (параметр mode) зависит от типа гостевой системы.
Режимы резервного копирования ВМ:
  • Режим остановки (Stop) — высокую согласованность данных за счёт временного простоя ВМ. Если ВМ запущена, PVE выполняет её штатное выключение, после чего запускает фоновый процесс QEMU для чтения данных дисков. После начала резервного копирования ВМ возвращается к работе, если до его начала она была запущена.
  • Режим приостановки (Suspend) — предназначен для совместимости с прежним поведением PVE. Перед резервным копированием в режиме Snapshot ВМ приостанавливается, что увеличивает время простоя, но не обязательно повышает согласованность данных. Поэтому рекомендуется использовать режим Snapshot.
  • Режим снимка (Snapshot) — обеспечивает минимальное время простоя: данные дисков копируются, пока ВМ продолжает работать. При этом существует небольшой риск несогласованности данных. Если гостевой агент установлен, настроен и работает, PVE может использовать его для замораживания и последующего размораживания файловых систем гостевой ОС, что повышает согласованность резервной копии.

Примечание

Механизм live-резервного копирования PVE позволяет создавать резервные копии работающих ВМ независимо от поддержки снимков на уровне хранилища. Во время копирования QEMU читает диски в фоновом режиме. Поэтому остановленная ВМ может кратковременно отображаться как запущенная, хотя сама гостевая ОС не загружается: считываются только данные её дисков.
Режимы резервного копирования контейнеров:
  • Режим остановки (Stop) — контейнер останавливается на время резервного копирования. Это может привести к длительному простою
  • Режим приостановки (Suspend) — сначала rsync копирует данные контейнера во временный каталог, указанный параметром --tmpdir. Затем контейнер приостанавливается, а rsync копирует изменившиеся файлы. После этого контейнер возобновляет работу. Такой подход сокращает время простоя, но требует дополнительного места для временной копии данных контейнера.
    Если контейнер размещён в локальной файловой системе, а резервная копия сохраняется на сервере NFS или CIFS, рекомендуется указывать локальную файловую систему для --tmpdir: это может существенно повысить производительность. Локальный временный каталог также необходим для резервного копирования локального контейнера с использованием списков контроля доступа (ACL) в режиме Suspend, если резервные копии сохраняются на NFS-сервере.
  • Режим снимка (Snapshot) — использует механизм снимков хранилища, в котором размещены тома контейнера. Сначала контейнер приостанавливается для обеспечения согласованности данных, затем создаётся временный снимок томов. Данные снимка архивируются в файл tar, после чего временный снимок удаляется. Для этого режима все включённые в резервную копию тома должны находиться в хранилищах, поддерживающих снимки. Отдельные точки монтирования можно исключить из резервной копии.

Примечание

Точку монтирования контейнера (mount point) можно исключить из резервной копии, указав backup=0 в конфигурации контейнера:
mp0: local:210/vm-210-disk-1.raw,mp=/mnt/data,backup=0,size=8G
В этом случае содержимое /mnt/data не будет включено в резервную копию.

Примечание

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

⁠37.2. Хранилище резервных копий

Перед настройкой резервного копирования необходимо выбрать хранилище:
  • Proxmox Backup Server (PBS) — поддерживает дедупликацию, шифрование, инкрементальные резервные копии, мгновенное восстановление. Для производственной среды рекомендуется использовать PBS на выделенном узле;
  • файловое хранилище (NFS, CIFS, локальный диск) — резервные копии сохраняются в виде файлов.
Если хранилище используется только для резервных копий, в его настройках следует отключить другие типы содержимого:
Настройка хранилища NFS
На вкладке Политика хранения резервной копии можно задать правила автоматического удаления старых копий:
Политика хранения резервных копий в хранилище NFS
Доступны следующие параметры хранения резервных копий (в скобках указаны параметры опции prune-backups команды vzdump):
  • Хранить все резервные копии (keep-all=<1|0>) —  если параметр включён, сохраняются все резервные копии, а остальные правила хранения не применяются;
  • Хранить последние (keep-last=<N>) — сохранять последние <N> резервных копий;
  • Хранить почасовые (keep-hourly=<N>) — сохранять резервные копии за последние <N> часов (если за один час создано несколько копий, сохраняется только последняя);
  • Хранить ежедневные (keep-daily=<N>) — сохранять резервные копии за последние <N> дней (если за один день создано несколько копий, сохраняется только последняя);
  • Хранить еженедельные (keep-weekly=<N>) —  сохранять резервные копии за последние <N> недель (если за одну неделю создано несколько копий, сохраняется только последняя);
  • Хранить ежемесячные (keep-monthly=<N>) — сохранять резервные копии за последние <N> месяцев (если за один месяц создано несколько копий, сохраняется только последняя);
  • Хранить ежегодные (keep-yearly=<N>) — сохранять резервные копии за последние <N> лет (если за один год создано несколько копий, сохраняется только последняя);
Макс. кол-во защищённых (параметр хранилища: max-protected-backups) — максимальное количество защищённых резервных копий для одной гостевой системы, разрешённое в хранилище. Значение -1 означает отсутствие ограничения. По умолчанию ограничение отсутствует для пользователей с привилегией Datastore.Allocate и равно 5 для остальных пользователей.
Правила хранения обрабатываются последовательно, начиная с кратчайших интервалов; первым обрабатывается keep-last. Каждое правило учитывает только те резервные копии, которые ещё не были учтены предыдущими правилами. Поэтому копии, сохранённые одним правилом, не учитываются повторно при обработке последующих правил.
Пример задания политики хранения при создании резервной копии:
# vzdump 777 --prune-backups keep-last=3,keep-daily=13,keep-yearly=9
Рекомендуется настраивать политику хранения на уровне хранилища, если для заданий резервного копирования не требуются отдельные правила.

⁠37.3. Сжатие файлов резервных копий

PVE поддерживает следующие алгоритмы сжатия:
  • LZO (lzo) — алгоритм сжатия данных без потерь. Для сжатия используется утилита lzop. LZO обеспечивает высокую скорость обработки данных, но степень сжатия зависит от содержимого резервной копии.
  • GZIP (gzip) — алгоритм сжатия без потерь на основе Deflate. Позволяет уменьшить размер резервной копии; скорость сжатия и степень сжатия зависят от данных и настроек.
  • Zstandard (zstd) — алгоритм сжатия без потерь, обеспечивающий баланс между скоростью обработки и степенью сжатия. Поддерживает многопоточную обработку.
Выбор алгоритма влияет на скорость создания резервной копии, её размер и нагрузку на процессор.

⁠37.4. Файлы резервных копий

При использовании файлового хранилища резервные копии обычно сохраняются в подкаталоге dump. Имя файла зависит от типа гостевой системы и алгоритма сжатия:
  • vzdump-qemu-номер_ВМ-дата-время.vma.zst или vzdump-lxc-номер_контейнера-дата-время.tar.zst — при использовании Zstandard (zstd);
  • vzdump-qemu-номер_ВМ-дата-время.vma.gz или vzdump-lxc-номер_контейнера-дата-время.tar.gz — при использовании GZIP (gzip);
  • vzdump-qemu-номер_ВМ-дата-время.vma.lzo или vzdump-lxc-номер_контейнера-дата-время.tar.lzo — при использовании LZO (lzo).
Если имя файла резервной копии не заканчивается одним из соответствующих расширений (.zst, .gz, .lzo), это означает, что vzdump не сжимал файл.

⁠37.5. Шифрование резервных копий

Для хранилищ Proxmox Backup Server можно включить шифрование резервных копий на стороне клиента (см. раздел Шифрование).

⁠37.6. Выполнение резервного копирования в веб-интерфейсе

Чтобы создать резервную копию отдельной ВМ, необходимо выбрать ВМ, перейти в раздел Резервная копия и нажать кнопку Создать резервную копию сейчас:
Вкладка Резервная копия ВМ
Далее следует указать параметры резервного копирования:
Выбор режима создания резервной копии
После создания резервной копии рекомендуется проверить возможность восстановления:
  1. Открыть хранилище с резервной копией, выбрать резервную копию и нажать кнопку Восстановить:
    Резервная копия в хранилище nfs-backup
  2. При восстановлении можно задать новый идентификатор и имя ВМ а также изменить доступные параметры:
    Восстановить ВМ из резервной копии
Если запускать восстановление из раздела самой ВМ, а не из содержимого хранилища, интерфейс предлагает восстановить резервную копию с заменой существующей ВМ.
Восстановление из резервной копии в интерфейсе ВМ
Резервную копию можно пометить как защищённую, чтобы запретить её удаление средствами PVE:
Пометить резервную копию как защищённую

Предупреждение

Защищённую резервную копию нельзя удалить через веб-интерфейс, CLI или API PVE. Однако файл резервной копии в файловом хранилище можно удалить вручную, если у пользователя есть права на запись в соответствующее хранилище. Защита реализована средствами PVE и не заменяет механизмы защиты файловой системы. Защищённые копии также не удаляются при автоматической очистке по политике хранения.

⁠37.7. Задания резервного копирования

Помимо запуска резервного копирования вручную, настроить периодические задания, которые автоматически создают резервные копии выбранных ВМ/контейнеров.
Управление заданиями доступно:
  • в веб-интерфейсе (раздел Центр обработки данных → Резервное копирование);
  • через API (/cluster/backup).
Оба метода сохраняют задания в файле /etc/pve/jobs.cfg, которые анализируются и выполняются демоном pvescheduler.
Задание можно настроить для всех узлов кластера или для отдельного узла.

⁠37.7.1. Формат расписания

Расписание задаётся в формате календарных событий, совместимом с systemd.time (см. man 7 systemd.time):
[ДЕНЬ_НЕДЕЛИ] [[ГОД-]МЕСЯЦ-ДЕНЬ] [ЧАСЫ:МИНУТЫ[:СЕКУНДЫ]]
День недели указывается английским трёхбуквенным обозначением: mon, tue, wed, thu, fri, sat и sun. Поддерживаются списки (mon,wed,fri), диапазоны (mon..fri) и их комбинации. Если день недели не указан, ограничение по дню недели не применяется.
Время задаётся в 24-часовом формате. Можно указывать отдельные значения, списки и диапазоны. Для повторения с заданным интервалом используется /. Если время не указано, расписание соответствует полуночи.
⁠

Таблица 37.1. Специальные значения

Расписание
Значение
Синтаксис
minutely
Каждую минуту
*-*-* *:*:00
hourly
Каждый час
*-*-* *:00:00
daily
Раз в день
*-*-* 00:00:00
weekly
Раз в неделю
mon *-*-* 00:00:00
monthly
Раз в месяц
*-*-01 00:00:00
yearly или annually
Раз в год
*-01-01 00:00:00
quarterly
Раз в квартал
*-01,04,07,10-01 00:00:00
semiannually или semi-annually
Раз в полгода
*-01,07-01 00:00:00
⁠

Таблица 37.2. Примеры

Расписание
Эквивалент
Значение
mon,tue,wed,thu,fri
mon..fri
Каждый будний день в 00:00
sat,sun
sat..sun
Каждую субботу и воскресенье в 00:00
mon,wed,fri
-
Каждый понедельник, среду и пятницу в 00:00
12:05
12:05
Каждый день в 12:05
*/5
0/5
Каждые пять минут
mon..wed 30/10
mon,tue,wed 30/10
По понедельникам, вторникам и средам в 30, 40 и 50 минут каждого часа
mon..fri 8..17,22:0/15
-
В будние дни каждые 15 минут с 08:00 до 17:45 и с 22:00 до 22:45
fri 12..13:5/20
fri 12,13:5/20
По пятницам в 12:05, 12:25, 12:45, 13:05, 13:25 и 13:45
12,14,16,18,20,22:5
12/2:5
Каждые два часа каждый день с 12:05 до 22:05
*
*/1
Ежеминутно (минимальный интервал)
*-05
-
Пятого числа каждого месяца
Sat *-1..7 15:00
-
В первую субботу каждого месяца в 15:00
2026-10-22
-
22 октября 2026 года в 00:00
Проверить расписание можно в окне Имитатор расписания заданий (Центр обработки данных → Резервная копия кнопка Имитатор расписания): ввести выражение в поле Расписание, указать число итераций (поле Итерации) и нажать кнопку Имитировать:
Имитатор расписания заданий

⁠37.7.2. Настройка заданий в графическом интерфейсе

Чтобы создать задание резервного копирования, необходимо перейти во вкладку Центр обработки данных → Резервная копия и нажать кнопку Добавить:
Вкладка Резервная копия
Откроется окно, в котором можно задать параметры резервного копирования:
Создание задания резервного копирования. Вкладка Общее
На вкладке Общее необходимо указать:
  • Узел (node) — узел, для которого создаётся задание (можно выбрать все узлы кластера);
  • Хранилище (storage) — целевое хранилище резервных копий;
  • Расписание (schedule) — расписание выполнения задания. Можно выбрать готовый вариант или задать расписание вручную:
    Выбор расписания резервного копирования
  • Режим выбора — определяет, какие ВМ и контейнеры включаются в задание: выбранные, все, все кроме выбранных или системы из указанного пула;
  • Сжатие (compress) — алгоритм сжатия: ZSTD (быстро и хорошо) (zstd) (по умолчанию), LZO (быстро) (lzo), GZIP (хорошо) (gzip) и нет (0);
  • Режим (mode) — режим резервного копирования: Снимок (snapshot), Приостановить (suspend), Остановка (stop):
    Выбор режима создания резервной копии
Далее в списке необходимо выбрать ВМ/контейнеры, для которых создаётся задание резервного копирования. Для сокращения списка выбора можно использовать поле Поиск (по имени или VMID) или фильтры (фильтры доступны для полей ID, Статус, Имя, Тип):
Настройка фильтра
На вкладке Уведомления настраивается способ отправки уведомлений о выполнении задания:
  • Использовать глобальные параметры уведомлений (notification-system) — использовать систему уведомлений PVE и настроенные в ней правила маршрутизации;
  • Использовать sendmail для отправки письма (устар.) (legacy-sendmail) — отправлять электронные письма с помощью системной команды sendmail, используя параметры mailto и mailnotification;
  • Получатели (mailto) — адреса электронной почты и/или пользователи, которым отправляются уведомления;
  • Когда (mailnotification) — определяет когда отправлять уведомление:
    • Всегда (always) — при любом результате выполнения задания;
    • Только в случае ошибки (failure) — только при неудачном выполнении задания.

    Примечание

    Для отправки почты необходимо, чтобы команда sendmail работала и была настроена доставка сообщений. Например, при использовании Postfix его можно включить и запустить командой:
    # systemctl enable --now postfix
Создание задания резервного копирования. Вкладка Уведомления
На вкладке Хранение настраивается политика хранения резервных копий, определяющая, какие копии следует сохранять, а какие можно удалять:
Создание задания для резервного копирования. Вкладка Хранение
Политика может включать ограничения по количеству последних копий, а также по периодам хранения: почасовому, ежедневному, еженедельному, ежемесячному и годовому.
На вкладке Шаблон примечания можно задать шаблон текста, который будет добавляться к резервной копии. В шаблоне поддерживаются следующие переменные:
  • {{cluster}} — имя кластера;
  • {{guestname}} — имя ВМ или контейнера;
  • {{node}} — имя узла, на котором выполняется резервное копирование;
  • {{vmid}} — идентификатор ВМ или контейнера.
Создание задания для резервного копирования. Вкладка Шаблон примечания
На вкладке Дополнительно собраны настройки производительности резервного копирования и некоторые другие настройки:
  • ID задания — идентификатор задания резервного копирования;
  • Ограничение пропускной способности (bwlimit) — ограничение скорости передачи данных при резервном копировании (МиБ/с);
  • Потоки ZSTD (zstd) — настройка количества потоков, используемых для сжатия Zstandard:
    • N=0 — используется половина доступных ядер CPU;
    • N>0 —используется указанное количество потоков;
  • Рабочие процессы ввода/вывода (max-workers) — максимальное количество параллельных операций ввода-вывода, используемых при резервном копировании ВМ;
  • Буферизация (fleecing enabled) — включает механизм fleecing для резервного копирования ВМ. Блоки, которые изменяются во время резервного копирования, временно сохраняются в отдельном хранилище. Это может уменьшить влияние резервного копирования на операции ввода-вывода гостевой системы, но требует дополнительного дискового пространства;
  • Хранилище для буферизации (fleecing storage) — хранилище для временных данных fleecing. Для эффективного использования пространства рекомендуется локальное хранилище с поддержкой освобождения неиспользуемых блоков (discard) и тонкого выделения ресурсов (thin provisioning) либо разреженных файлов (sparse files);
  • Повторять пропущенные (repeat-missed) — позволяет запустить пропущенное задание при первой возможности после восстановления работы узла или планировщика;
  • Режим обнаружения изменения PBS (pbs-change-detection-mode) — определяет метод обнаружения изменений при резервном копировании контейнеров в PBS. Метод влияет на чтение файлов и формирование архива pxar. Возможные значения:
    • Default — используется формат pxar версии 1: данные и метаданные не разделяются на отдельные потоки;
    • Data — используется формат pxar версии 2 с разделением данных и метаданных на отдельные потоки. Файлы читаются и кодируются при резервном копировании;
    • Metadata — используется формат pxar версии 2. Метаданные предыдущего снимка, если они доступны, позволяют определять неизменившиеся файлы и повторно использовать их данные без чтения содержимого с диска.
Создание задания для резервного копирования. Вкладка Дополнительно
После нажатия кнопки Создать задание появится в списке (и будет записано в файл /etc/pve/jobs.cfg):
Задание резервного копирования
Задание будет выполняться в назначенное время. Столбец Следующий запуск показывает ближайшее время выполнения. Существует также возможность запустить задание по требованию — кнопка Запустить сейчас.

⁠37.8. Восстановление

Восстановить данные из резервной копии можно через веб-интерфейс PVE или с помощью утилит командной строки:
  • pct restore — восстановление контейнера;
  • qmrestore — восстановление ВМ.

⁠37.9. Ограничение пропускной способности

При восстановлении крупных резервных копий может потребоваться значительная пропускная способность хранилища. Высокая нагрузка на дисковую подсистему может отрицательно сказаться на работе других ВМ.
В PVE предусмотрены два типа ограничений:
  • ограничение для отдельного восстановления (per-restore limit) — максимальная скорость чтения данных из резервной копии при выполнении операции восстановления;
  • ограничение записи для хранилища (per-storage write limit) — максимальная скорость записи данных в целевое хранилище.
Ограничение скорости чтения может снижать общую скорость восстановления, поскольку перед записью данные необходимо прочитать из резервной копии.

Важно

Ограничение на чтение косвенно влияет на запись.
Если для задания задано меньшее ограничение, чем для хранилища — оно переопределяет лимит хранилища. Увеличение лимита в задании повлияет на лимит хранилища только при наличии привилегии Data.Allocate.
Для задания ограничения скорости восстановления используется параметр bwlimit (в КиБ/с). Например, значение 10240 соответствует 10 МиБ/с. оставив ресурсы хранилища для работающих ВМ.

Примечание

Значение 0 отключает ограничение, заданное этим параметром.
Глобальное ограничение для хранилища задаётся командой:
# pvesm set <ID хранилища> --bwlimit restore=<KIBs>

⁠37.10. Восстановление в реальном времени (Live-Restore)

Для резервных копий, хранящихся в PBS, доступен режим Live-Restore. Он позволяет запустить ВМ до завершения восстановления: необходимые данные считываются из PBS по мере обращения к ним, а оставшиеся данные восстанавливаются в фоновом режиме.
Включить Live-Restore можно:
  • через веб-интерфейс (отметка Восстановление в реальном времени):
    Восстановление в реальном времени
  • через параметр --live-restore в команде qmrestore.
Особенности режима:
  • во время восстановления чтение ещё не восстановленных данных может выполняться медленнее, поскольку они считываются из PBS. После первого чтения данные сохраняются в целевом хранилище;
  • скорость записи обычно не ограничивается самим механизмом Live-Restore, но зависит от производительности целевого хранилища и нагрузки;
  • если восстановление завершается ошибкой, состояние ВМ может оказаться неконсистентным. Изменения, сделанные после запуска ВМ, могут не сохраниться при повторном восстановлении.
Live-Restore особенно полезен для больших ВМ, которым для начала работы требуется лишь часть данных. Например, веб-сервер может начать обслуживать запросы после загрузки ОС и запуска необходимых служб, пока восстановление остальных данных продолжается в фоновом режиме.

⁠37.11. Восстановление отдельных файлов

Кнопка Восстановление файла на вкладке Резервные копии хранилища PBS позволяет просматривать содержимое резервной копии и восстанавливать отдельные файлы. Эта функция доступна только для резервных копий, хранящихся в PBS.
Восстановление отдельных файлов
Для контейнеров в корне файлового дерева отображаются архивы pxar, содержащие данные контейнера. Каждый архив можно открыть и просмотреть его содержимое.
Для ВМ в корне отображаются образы дисков. Если образ содержит таблицу разделов, в дереве отображается запись part, соответствующая разделам диска. Можно открыть раздел и просмотреть доступную файловую систему. Некоторые данные могут быть недоступны из-за неподдерживаемых файловых систем или технологий хранения.
Для загрузки отдельного файла необходимо нажать кнопку Скачивание. Для загрузки каталога следует нажать кнопку Скачать как и выбрать формат архива (zip или tar.zst).
Для изоляции хост-системы от потенциально опасных данных, например вредоносных файлов из гостевой ОС, при просмотре данных дисков ВМ запускается временная ВМ. Она не отображается в обычном списке гостевых систем и автоматически останавливается по истечении заданного времени. Пользователь взаимодействует с ней через интерфейс восстановления файлов.

Примечание

Для каждой временной ВМ создаётся файл журнала в каталоге /var/log/proxmox-backup/file-restore/. Журнал может содержать дополнительную информацию, если не удалось восстановить отдельные файлы или получить доступ к файловым системам внутри резервной копии.

⁠37.12. Файл конфигурации vzdump.conf

Глобальные настройки резервного копирования задаются в файле /etc/vzdump.conf. Каждая строка файла содержит имя параметра и его значение в следующем формате:
OPTION: value
Пустые строки и строки, начинающиеся с символа #, игнорируются.
⁠

Таблица 37.3. Параметры файла конфигурации

Опция
Описание
bwlimit: <целое число> (0 — N) (по умолчанию 0)
Ограничение скорости передачи данных при резервном копировании (КиБ/с)
compress: (0|1|gzip|lzo|zstd) (по умолчанию 0)
Метод сжатия. 0 означает отсутствие сжатия, а 1 — использование алгоритма по умолчанию (zstd)
dumpdir: <строка>
Каталог для сохранения файлов резервных копий
exclude-path: <массив>
Список файлов и каталогов, исключаемых из резервной копии контейнера. Абсолютные пути, начинающиеся с /, отсчитываются от корня файловой системы контейнера. Относительные пути сопоставляются с каталогами внутри дерева файлов контейнера
fleecing: [[enabled=]<1|0>] [,storage=<ID хранилища>]
Отложенное копирование (только для ВМ):
  • enabled (по умолчанию 0) — включение отложенного резервного копирования. Данные резервных копий из блоков, в которые гостевая система записывает данные во время резервного копирования, временно сохраняются в указанном хранилище, а не копируются напрямую в целевое хранилище резервных копий. Это может повысить производительность ввода-вывода гостевой системы и даже предотвратить её зависание, но требует дополнительного дискового пространства;
  • storage — хранилище для временного размещения образов отложенного копирования. Для эффективного использования пространства рекомендуется использовать локальное хранилище, которое поддерживает очистку неиспользуемых блоков (discard) и, либо тонкое выделение ресурсов (thin provisioning), либо разреженные файлы (sparse files).
ionice: <целое число> (0 — 8) (по умолчанию 7)
Настройка приоритета ввода-вывода при использовании планировщика BFQ. Для резервных копий ВМ в режимах снимка (snapshot) и приостановки (suspend) этот параметр влияет только на работу компрессора (а не на основное копирование данных). Значение 8 означает, что используется приоритет простоя (idle), в противном случае используется стандартный приоритет (best-effort) с указанным уровнем
lockwait: <целое число> (0 — N) (по умолчанию 180)
Максимальное время ожидания получения глобальной блокировки (в минутах)
mailnotification: (always|failure) (по умолчанию always)
Устаревший параметр: следует использовать цели и сопоставители уведомлений. Указание, когда следует отправить отчет по электронной почте (используется при notification-mode: legacy-sendmail)
mailto: <строка>
Устаревший параметр: следует использовать цели и сопоставители уведомлений. Разделенный запятыми список адресов электронной почты или пользователей, которым будут приходить уведомления (используется при notification-mode: legacy-sendmail)
maxfiles: <целое число> (1 — N) (по умолчанию 1)
Устаревший параметр: для управления сроком хранения следует использовать prune-backups. Максимальное количество файлов резервных копий для каждой ВМ или контейнера
mode: (snapshot|stop|suspend) (по умолчанию snapshot)
Режим резервного копирования
notes-template: <строка>
Шаблон примечания с переменными: {{cluster}}, {{guestname}}, {{node}} и {{vmid}}. Шаблон должен быть записан в одну строку, новая строка и обратная косая черта должны быть экранированы как \n и \\ соответственно
notification-mode: <notification-system | legacy-sendmail>
Способ отправки уведомлений. Если установлено значение legacy-sendmail, vzdump будет учитывать параметры mailto/mailnotification и отправлять электронные письма на указанные адреса с помощью команды sendmail. Если установлено значение notification-system, уведомление будет отправлено через систему уведомлений PVE, а параметры mailto/mailnotification игнорируются
pbs-change-detection-mode: <data | legacy | metadata>
Определяет режим обнаружения изменений при резервном копировании контейнера в PBS:
  • legacy — использует формат pxar версии 1, в котором данные и метаданные не разделяются на отдельные потоки;
  • data — использует формат pxar версии 2 с разделением данных и метаданных на отдельные потоки. Для обнаружения изменений читаются и кодируются файлы;
  • metadata — использует формат pxar версии 2 и метаданные предыдущего снимка, если они доступны, чтобы определять неизменённые файлы и повторно использовать соответствующие данные без чтения их содержимого с диска
performance: [max-workers=<целое число>][,pbs-entries-max=<целое число>]
Другие настройки, связанные с производительностью:
  • max-workers=<целое число> (1 — 256) (по умолчанию 16) — максимальное количество параллельных операций ввода-вывода (IO), выполняемых во время резервного копирования (применяется к ВМ);
  • pbs-entries-max=<целое число> (1 — N) (по умолчанию 1048576) — применяется к резервным копиям контейнеров, отправляемым в PBS. Ограничивает количество файловых записей, хранящихся в памяти во время резервного копирования, чтобы предотвратить нехватку памяти (OOM). Следует увеличить значение этого параметра для ускорения обработки резервных копий контейнеров с большим количеством файлов (слишком высокое значение может привести к риску исчерпания памяти)
pigz: <целое число> (по умолчанию 0)
Если N=0 при сжатии резервных копий используется gzip. Если N>0 — используется pigz.
При N=1 pigz использует половину ядер CPU, при N>1 pigz работает в многопоточном режиме с указанным количеством потоков (N)
pool: <строка>
Пул, из которого выбираются ВМ для резервного копирования
protected: <логическое значение>
Пометить резервную копию как защищённую от удаления средствами PVE
prune-backups: [keep-all=<1|0>] [,keep-daily=<N>] [,keep-hourly=<N>] [,keep-last=<N>] [,keep-monthly=<N>] [,keep-weekly=<N>] [,keep-yearly=<N>] (по умолчанию keep-all=1)
Политика хранения резервных копий (переопределяет настройки хранения, заданные для хранилища)
remove: <логическое значение> (по умолчанию 1)
Включает удаление старых резервных копий в соответствии с политикой prune-backups. При значении 0 очистка старых копий не выполняется
script: <строка>
Скрипт, вызываемый на определённых этапах резервного копирования
stdexcludes: <логическое значение> (по умолчанию 1)
Включает исключение стандартных временных файлов и файлов PID при резервном копировании контейнера
stopwait: <целое число> (0 — N) (по умолчанию 10)
Максимальное время ожидания остановки гостевой системы (в минутах)
storage: <строка>
Идентификатор целевого хранилища резервных копий
tmpdir: <строка>
Каталог для временных файлов, создаваемых при резервном копировании (рекомендуется — быстрый локальный диск)
zstd: <целое число> (по умолчанию 1)
Количество потоков, используемых для сжатия алгоритмом Zstandard:
  • N=0 — используется половина доступных ядер CPU;
  • N>0 —используется указанное количество потоков
Пример файла vzdump.conf:
tmpdir: /mnt/fast_local_disk
storage: my_backup_storage
mode: snapshot
bwlimit: 10000

⁠37.13. Сценарии перехвата (hookscripts)

Сценарий перехвата можно указать с помощью параметра --script. ОН вызывается на различных этапах процесса резервного копирования и получает параметры, соответствующие текущему этапу (см. пример скрипта /usr/share/doc/pve-manager/examples/vzdump-hook-script.pl).

⁠37.14. Файлы, не включаемые в резервную копию

Примечание

Параметры исключения путей доступны только при резервном копировании контейнеров.
По умолчанию vzdump исключает из резервной копии следующие пути:
/tmp/?*
/var/tmp/?*
/var/run/?*pid
Исключение стандартных путей можно отключить с помощью параметра --stdexcludes 0.
Дополнительные пути можно исключить вручную. Например:
# vzdump 777 --exclude-path /tmp/ --exclude-path '/var/foo*'
Если путь не начинается с символа «/», он не привязывается к корню контейнера и сопоставляется с компонентами пути в его файловом дереве. Например:
# vzdump 777 --exclude-path bar
Такой параметр исключает совпадающие пути, например /bar, /var/bar, /var/foo/bar и т.д.
Конфигурация ВМ или контейнера также включается в архив резервной копии. При восстановлении PVE использует сохранённую конфигурацию, если она не переопределена параметрами восстановления.

⁠37.15. Примеры создания резервных копий в командной строке

Создать резервную копию ВМ 103, сохранив её в каталоге резервных копий по умолчанию (обычно /var/lib/vz/dump/):
# vzdump 103
Создать резервную копию ВМ 103 в режиме приостановки:
# vzdump 103 --mode suspend
Создать резервную копию ВМ 103 в режиме snapshot в каталоге /mnt/backup:
# vzdump 103 --dumpdir /mnt/backup --mode snapshot
Резервное копирование нескольких ВМ:
# vzdump 101 102 103
Резервное копирование всех ВМ, исключая 101 и 102:
# vzdump --mode suspend --exclude 101,102
Выполнить резервное копирование контейнера с использованием режима обнаружения изменений metadata:
# vzdump 105 --storage pbs-backup --pbs-change-detection-mode metadata
Восстановить контейнер в новый контейнер 600:
# pct restore 600 /mnt/backup/vzdump-lxc-104.tar
Восстановить QEMU-ВМ в ВМ 601:
# qmrestore /mnt/backup/vzdump-qemu-105.vma 601
Создание резервной копии контейнера 101 в стандартный поток с последующим восстановлением контейнера с новым идентификатором:
# vzdump 101 --stdout | pct restore --rootfs 4 300 - 

⁠37.16. Снимки (snapshot)

Снимок ВМ — это сохранённое состояние ВМ на определённый момент времени, включающее конфигурацию ВМ и состояние её дисков. В зависимости от настроек при создании снимка также может сохраняться состояние оперативной памяти. Можно создать несколько снимков ВМ, в том числе во время её работы, если это поддерживается используемой конфигурацией хранилища и параметрами снимка. При необходимости ВМ можно вернуть к состоянию, сохранённому в выбранном снимке.
Чтобы создать снимок ВМ, необходимо в меню ВМ выбрать пункт Снимки и нажать кнопку Сделать снимок:
Окно управления снимками ВМ
В открывшемся окне следует ввести название снимка и нажать кнопку Сделать снимок:
Создание снимка ВМ
Для восстановления ВМ из снимка необходимо в меню ВМ выбрать пункт Снимки, выбрать нужный снимок и нажать кнопку Откатить:
Восстановление ОС из снимка
При создании снимка конфигурация ВМ сохраняется в её конфигурационном файле в отдельном разделе. Например, после создания снимка с именем first файл конфигурации может выглядеть следующим образом:
boot: order=scsi0;net0
cores: 1
cpu: x86-64-v2-AES
memory: 2048
meta: creation-qemu=9.1.2,ctime=1746532273
name: NewVM
net0: virtio=BC:24:11:40:5F:C3,bridge=vmbr0,firewall=1
numa: 0
ostype: l26
parent: first
scsi0: local-lvm:vm-100-disk-0,size=52G
scsihw: virtio-scsi-single
smbios1: uuid=cafd8016-03d3-4514-8d6f-5f4e353e5936
sockets: 1
spice_enhancements: foldersharing=1
tags: admc;linux;openuds
usb1: host=090c:1000
usb2: spice
vga: qxl
vmgenid: 31f7faef-4014-453b-ba8d-801e5634cc08

[first]
boot: order=scsi0;net0
cores: 1
cpu: x86-64-v2-AES
memory: 2048
meta: creation-qemu=9.1.2,ctime=1746532273
name: NewVM
net0: virtio=BC:24:11:40:5F:C3,bridge=vmbr0,firewall=1
numa: 0
ostype: l26
scsi0: local-lvm:vm-100-disk-0,size=52G
scsihw: virtio-scsi-single
smbios1: uuid=cafd8016-03d3-4514-8d6f-5f4e353e5936
snaptime: 1746637751
sockets: 1
spice_enhancements: foldersharing=1
tags: admc;linux;openuds
usb1: host=090c:1000
usb2: spice
vga: qxl
vmgenid: 31f7faef-4014-453b-ba8d-801e5634cc08

Параметр parent указывает на родительский снимок, относительно которого находится текущее состояние ВМ. Параметр snaptime содержит время создания снимка в формате Unix time — количество секунд, прошедших с 1 января 1970 года по UTC.

⁠Глава 38. Уведомления

Система уведомлений (нотификаций) PVE предназначена для информирования администраторов о значимых событиях, происходящих в системе, например об ошибках репликации данных, сбоях ограждения узлов, успешном завершении или ошибках выполнения заданий резервного копирования.
При возникновении значимого события PVE формирует событие уведомления, которое обрабатывается системой уведомлений. Каждое событие содержит метаданные: временную метку, уровень серьёзности, тип события и дополнительные поля, зависящие от типа события.
Сопоставители уведомлений определяют, каким целям следует передать уведомление. Для выбора целевых объектов сопоставители могут использовать правила фильтрации по метаданным события.
Цель уведомления — конечный пункт назначения, в который направляется уведомление. PVE поддерживает следующие типы целей:
  • Sendmail — отправка уведомлений через локальный почтовый сервер;
  • SMTP — отправка уведомлений через внешний SMTP-сервер;
  • Gotify — отправка уведомлений в сервис Gotify (легковесный сервер для push-уведомлений);
  • Webhook — отправка HTTP-запросов на настраиваемый URL-адресу.
Для заданий резервного копирования можно настроить режим уведомлений: использовать систему уведомлений PVE или классический механизм отправки сообщений электронной почты.
Систему уведомлений можно настроить следующими способами:
  • через веб-интерфейс (раздел Центр обработки данных → Уведомления);
  • с помощью конфигурационных файлов.
Конфигурация системы уведомлений хранится в файлах:
  • /etc/pve/notifications.cfg — основные настройки;
  • /etc/pve/priv/notifications.cfg — конфиденциальные параметры (пароли, токены аутентификации). Файл доступен для чтения только пользователю root.

⁠38.1. Цели уведомлений (Notification Targets)

⁠38.1.1. Sendmail

Цель уведомлений Sendmail использует команду sendmail для отправки электронных писем указанным получателям. Если в качестве получателя указан пользователь PVE, система использует адрес электронной почты из его профиля (адрес электронной почты пользователя можно настроить в разделе Центр обработки данных → Разрешения → Пользователи). Если адрес электронной почты не указан, отправить уведомление этому пользователю не удастся.

Примечание

Команда sendmail предоставляется почтовым агентом (MTA), например Postfix. Для корректной доставки писем может потребоваться настройка Postfix, в том числе указание внешнего ретранслятора. При ошибках доставки следует проверить системный журнал на наличие сообщений службы Postfix:
# journalctl -u postfix

Примечание

Для работы цели Sendmail необходимо, чтобы команда sendmail была доступна и почтовая система была настроена для отправки сообщений. В стандартной установке PVE команда обычно предоставляется Postfix. Если используется Postfix, необходимо добавить его в автозагрузку и запустить:
# systemctl enable --now postfix
Для настройки цели Sendmail необходимо выполнить следующие действия:
  1. Перейти в раздел Центр обработки данных → Уведомления → Получатели уведомлений.
  2. Нажать кнопку Добавить → Sendmail:
    Создание цели уведомлений Sendmail
  3. В открывшемся окне указать параметры (в скобках приведены соответствующие имена параметров в файле notifications.cfg):
    • Имя конечной точки — идентификатор цели уведомлений;
    • Включить (disable) —  состояние цели: включена или отключена;
    • Получатель (получатели) (mailto-user) — пользователи PVE, которым будут отправляться уведомления. Адреса электронной почты пользователей берутся из файла users.cfg;
    • Дополнительный получатель (получатели) (mailto) — адреса электронной почты дополнительных получателей;
    • Комментарий (comment) —  описание цели;
    • Автор (author) — имя отправителя (по умолчанию: Proxmox VE);
    • Адрес отправителя (from-address) —  адрес отправителя. Если параметр не задан, используется настройка Центр обработки данных → Параметры → Адрес для отправки сообщений (значение email_from из файла datacenter.cfg). Если оно также не задано, используется адрес root@$hostname, где $hostname — имя узла.
    Настройка цели уведомлений Sendmail
Пример конфигурации (/etc/pve/notifications.cfg):
sendmail: sendmails-admin
    comment Отправка уведомлений администраторам
    mailto user@example.test
    mailto-user kim@test.alt
    mailto-user orlov@test.alt
    mailto-user root@pam

⁠38.1.2. SMTP

Цель уведомлений SMTP отправляет электронные письма непосредственно через SMTP-сервер, не используя системный MTA для доставки сообщений.

Примечание

В отличие от Sendmail, SMTP-цель не поддерживает очередь сообщений и повторные попытки отправки в случае сбоя доставки.
Для настройки цели SMTP необходимо выполнить следующие действия:
  1. Перейти в раздел Центр обработки данных → Уведомления → Получатели уведомлений.
  2. Нажать кнопку Добавить → SMTP:
    Создание цели уведомлений SMTP
  3. В открывшемся окне указать параметры (в скобках приведены соответствующие имена параметров в файле notifications.cfg):
    • Имя конечной точки —  идентификатор цели уведомлений;
    • Включить (disable) — состояние цели: включена или отключена;
    • Сервер (server) — адрес SMTP-сервера;
    • Шифрование (mode) — режим соединения: без шифрования (insecure), STARTTLS (starttls) или TLS (tls). По умолчанию используется TLS;
    • Порт (port) — порт SMTP-сервера. Если порт не указан, он выбирается в зависимости от режима соединения: 465 (TLS), 587 (STARTTLS), 25 (без шифрования);
    • Выполнять аутентификацию — настройка аутентификации на SMTP-сервере;
    • Имя пользователя (username) — имя пользователя для аутентификации SMTP. Если параметр не задан, аутентификация не выполняется. Поддерживаются методы аутентификации PLAIN и LOGIN;
    • Пароль (password) — пароль для аутентификации SMTP;
    • Адрес отправителя (from-address) — адрес отправителя. SMTP-сервер может требовать, чтобы этот адрес принадлежал аутентифицированному пользователю. В заголовке From указываются имя автора и адрес отправителя в формате $author <$from-address>;
    • Получатель (получатели) (mailto-user) — пользователи PVE, которым будут отправляться уведомления. Адреса электронной почты пользователей берутся из файла users.cfg;
    • Дополнительный получатель (получатели) (mailto) — адреса электронной почты дополнительных получателей;
    • Комментарий (comment) — описание цели;
    • Автор (author) — имя отправителя (по умолчанию: Proxmox VE).
    Настройка цели уведомлений SMTP
Пример конфигурации:
  • файл /etc/pve/notifications.cfg:
    smtp: smtp
        from-address pve-mail@test.alt
        mailto-user root@pam
        mailto-user orlov@test.alt
        mode tls
        server mail.test.alt
        username pve-mail
    
  • файл /etc/pve/priv/notifications.cfg:
    smtp: smtp
    	password somepassword
    

⁠38.1.3. Webhook

Цель уведомлений Webhook выполняет HTTP-запросы к указанному URL-адресу. Для формирования URL, заголовков и тела запроса поддерживается шаблонизация с использованием Handlebars.
Для настройки цели Webhook необходимо выполнить следующие действия:
  1. Перейти в раздел Центр обработки данных → Уведомления → Получатели уведомлений.
  2. Нажать кнопку Добавить → Webhook:
    Создание цели уведомлений Webhook
  3. В открывшемся окне указать параметры (в скобках приведены соответствующие имена параметров в файле notifications.cfg):
    • Имя конечной точки — идентификатор цели уведомлений;
    • Включить (disable) —  состояние цели: включена или отключена;
    • Метод/URL-адрес (method/url) — HTTP-метод (POST, PUT или GET) и URL-адрес, на который отправляется запрос. URL-адрес поддерживает шаблонизацию, позволяющую подставлять содержимое уведомления, метаданные и секреты;
    • Заголовки (header) — HTTP-заголовки запроса. Их значения могут содержать шаблоны;
    • Тело письма (body) — содержимое HTTP-запроса (в формате base64). Поддерживается шаблонизация;
    • Секреты (secret) — набор секретов, представленных парами «имя — значение». Секреты хранятся в защищенном файле конфигурации (/etc/pve/priv/notifications.cfg), доступном для чтения только пользователю root. При получении конфигурации через API возвращается имя секрета, но не его значение. В шаблонах URL, заголовков и тела запроса к секретам можно обращаться через пространство имён secrets.
    • Комментарий (comment) — описание цели;
    Настройка цели уведомлений Webhook (ntfy.sh)
Пример конфигурации:
  • файл /etc/pve/notifications.cfg:
    webhook: ntfy
    	body e3sgbWVzc2FnZSB9fQ== # Закодированный {{ message }}
    	comment Отправка PUSH уведомлений
    	method post
    	url https://ntfy.sh/pve_backup_job_186
    
  • файл /etc/pve/priv/notifications.cfg:
    webhook: ntfy
    	secret name=channel,value=MTIzNDU2NDg3OA==
    

Примечание

В конфигурационном файле значение параметра body и значения value в записях header и secret хранятся в формате Base64.
Закодировать строку в Base64 можно следующей командой:
$ echo -n 'pve_backup_job_186' | base64 -w 0
cHZlX2JhY2t1cF9qb2JfMTg2
Доступны следующие переменные шаблонов:
  • {{ title }} — заголовок уведомления;
  • {{ message }} — тело уведомления;
  • {{ severity }} — уровень серьёзности (info, notice, warning, error, unknown);
  • {{ timestamp }} — временная метка в формате времени Unix (количество секунд с начала эпохи Unix);
  • {{ fields.<name> }} — метаданные события (например, fields.type содержит тип уведомления);
  • {{ secrets.<name> }} — секреты (например, секрет с именем token доступен через secrets.token).
Для обработки значений доступны следующие помощники:
  • {{ url-encode <value/property> }} —  URL-кодирование значения или свойства;
  • {{ escape <value/property> }} — экранирование управляющих символов, которые нельзя безопасно представить в строке JSON;
  • {{ json <value/property> }} — преобразование значения в JSON. Например, {{ json fields }} позволяет представить всё пространство имён fields в формате JSON.

Примечание

Цели Webhook учитывают настройки HTTP-прокси, заданные в разделе Центр обработки данных → Параметры → Прокси HTTP.

⁠38.2. Сопоставители уведомлений (Notification Matchers)

Сопоставители уведомлений направляют события в цели уведомлений на основе правил сопоставления. Правила могут учитывать различные свойства события, например временную метку (match-calendar), уровень серьёзности (match-severity) и поля метаданных (match-field). Если событие соответствует правилам сопоставителя, уведомление передаётся всем указанным в нём целям.
Можно создать произвольное количество сопоставителей, каждый со своими правилами и списком целей. При этом каждая цель получает уведомление не более одного раза для каждого события, даже если она указана в нескольких сопоставителях.
Сопоставитель без правил соответствует любому уведомлению, поэтому указанные в нём цели будут получать все уведомления:
matcher: always-matches
    comment Это сопоставление всегда срабатывает
    mode all
    target mail-to-root

⁠38.2.1. Правила сопоставления по календарю (match-calendar)

Правило match-calendar сопоставляет временную метку уведомления с заданным расписанием.
Для задания временных интервалов используется специальный синтаксис.
Примеры:
  • match-calendar 8-12 — ежедневно с 8:00 до 12:00;
  • match-calendar 8:00-15:30 — ежедневно с 8:00 до 15:30;
  • match-calendar mon..fri 9:00-17:00 — в будние дни с 9:00 до 17:00;
  • match-calendar sun,tue..wed,fri 9-17 — в воскресенье, вторник, среду и пятницу с 9:00 до 17:00.

⁠38.2.2. Правила сопоставления полей (match-field)

Правило match-field фильтрует уведомления по значениям полей метаданных.
В режиме exact можно перечислить несколько значений через запятую. Правило срабатывает, если значение поля совпадает хотя бы с одним из указанных значений.
В режиме regex используется регулярное выражение.
Примеры:
  • match-field exact:type=vzdump — только уведомления о резервном копировании;
  • match-field exact:type=replication,fencing — уведомления о репликации и ограждении узлов;
  • match-field regex:hostname=^pve-.*$ — уведомления для узлов, имена которых начинаются с pve-.
Если у события отсутствует указанное поле, правило не срабатывает. Например, правило match-field regex:hostname=.* соответствует только уведомлениям, содержащим поле hostname.

⁠38.2.3. Правила сопоставления по уровню серьёзности (match-severity)

Правило match-severity фильтрует уведомления по уровню серьёзности (severity) события. Поддерживаются следующие уровни: info, notice, warning, error, unknown.
Примеры:
  • match-severity error — только ошибки;
  • match-severity warning,error — предупреждения и ошибки.

⁠38.2.4. События уведомлений

В таблице События уведомлений приведены типы событий уведомлений PVE, их уровни серьёзности и доступные поля метаданных. Эти данные можно использовать в правилах сопоставления.
⁠

Таблица 38.1. События уведомлений

Событие
Тип (type)
Серьезность
Поля метаданных (кроме type)
Доступны обновления пакетов
package-updates
info
hostname
Узел кластера изолирован механизмом ограждения
fencing
error
hostname
Задание репликации хранилища завершилось с ошибкой
replication
error
hostname, job-id
Резервное копирование выполнено успешно
vzdump
info
hostname, job-id (только для заданий резервного копирования)
Резервное копирование завершилось с ошибкой
vzdump
error
hostname, job-id (только для заданий резервного копирования)
Почта для пользователя root
system-mail
unknown
hostname
В таблице Описание полей метаданных описаны поля метаданных, доступные для использования в правилах match-field.
⁠

Таблица 38.2. Описание полей метаданных

Поле
Описание
type
Тип события уведомления
hostname
Имя узла PVE без домена (например, pve01)
job-id
Идентификатор задания

Примечание

Уведомления о заданиях резервного копирования содержат идентификатор задания (поле job-id) только в том случае, если задание резервного копирования было выполнено автоматически по расписанию. Если задание запущено вручную с помощью кнопки Запустить сейчас, поле job-id отсутствует.
Примеры конфигурации (/etc/pve/notifications.cfg):
  • уведомлять администраторов в рабочее время:
    matcher: workday
            match-calendar mon..fri 9-17
            target admin
            comment Notify admins during working hours
    
  • уведомлять дежурных в нерабочее время:
    matcher: night-and-weekend
            match-calendar mon..fri 9-17
            invert-match true
            target on-call-admins
            comment Separate target for non-working hours
    
  • при ошибках резервного копирования отправлять уведомления в рабочее время через SMTP:
    matcher: zfs-error
            match-calendar mon..fri 8-17
            match-field exact:type=vzdump
            match-severity error
            mode all
            target smtp
    

⁠38.2.5. Создание сопоставителя уведомлений

Для создания сопоставителя необходимо выполнить следующие действия:
  1. Перейти в раздел Центр обработки данных → Уведомления → Средства сопоставления уведомлений.
  2. Нажать кнопку Добавить.
  3. В открывшемся окне на вкладке Общее в поле Имя средства сопоставления уведомлений указать название сопоставителя:
    Создание сопоставителя уведомлений
  4. На вкладке Правила совпадения настроить условия сопоставления:
    Настройка правил сопоставления
  5. На вкладке Получатели уведомлений выбрать цели, которым необходимо передавать уведомления:
    Выбор целей уведомлений

⁠38.3. Пересылка системной почты

Некоторые локальные системные службы, например smartd, отправляют уведомления локальному пользователю root. PVE перехватывает такие письма, передаёт их в систему уведомлений как события типа system-mail с уровнем серьёзности unknown и обрабатывает их в соответствии с глобальными настройками системы уведомлений.
При пересылке на цель Sendmail содержимое и заголовки письма передаются без изменений. Для целей других типов система пытается извлечь тему и основной текст письма. Если письмо содержит только HTML, его содержимое преобразуется в обычный текст.

⁠38.4. Разрешения

Для просмотра и изменения конфигурации целей уведомлений требуются разрешения Mapping.Modify и Mapping.Audit соответственно на узле ACL /mapping/notifications.
Для тестирования цели требуется одно из следующих разрешений на узле /mapping/notifications: Mapping.Use, Mapping.Audit или Mapping.Modify.

⁠38.5. Режим уведомления

В конфигурации задания резервного копирования предусмотрен параметр notification-mode (Режим отправки уведомлений), который определяет способ отправки уведомлений. Поддерживаются следующие режимы:
  • Система отправки уведомлений (notification-system) — отправлять уведомления в соответствии с глобальными настройками системы уведомлений PVE. Для маршрутизации используются настроенные цели и сопоставители уведомлений;
  • Эл. почта (устаревшее) (legacy-sendmail) — отправлять уведомления по электронной почте с помощью системной команды sendmail на адрес, указанный в конфигурации задания резервного копирования. В этом режиме можно выбрать, отправлять ли письмо после каждого выполнения задания или только при ошибке резервного копирования. Глобальные цели и сопоставители уведомлений не используются.

⁠38.6. Переопределение шаблонов уведомлений

PVE использует шаблоны Handlebars для формирования уведомлений. Исходные шаблоны, поставляемые вместе с PVE, хранятся в каталоге /usr/share/pve-manager/templates/default/.
Чтобы изменить шаблон, необходимо создать собственный файл в каталоге /etc/pve/notification-templates/default/. При формировании уведомления PVE сначала пытается загрузить шаблон из каталога пользовательских шаблонов. Если файл отсутствует или его обработка завершается ошибкой, используется исходный шаблон.

Примечание

Каталог /etc/pve/notification-templates/default/ необходимо предварительно создать:
# mkdir -p /etc/pve/notification-templates/default/
Имена файлов шаблонов соответствуют формату <тип>-<часть>.<формат>.hbs, где:
  • <тип> — тип уведомления, например vzdump или package-updates;
  • <часть> — body для тела уведомления или subject для темы письма;
  • <формат> — html или txt.
Например, файл vzdump-body.html.hbs содержит шаблон HTML-версии тела уведомления о резервном копировании, а package-updates-subject.txt.hbs — шаблон темы уведомления о доступных обновлениях пакетов.
Цели уведомлений sendmail и smtp отправляют электронные письма, содержащие HTML- и текстовую версии сообщения. Поэтому при формировании письма используются оба шаблона тела уведомления: <тип>-body.html.hbs и <тип>-body.txt.hbs.
Для остальных типов целей уведомлений используется только текстовый шаблон <тип>-body.txt.hbs.

⁠Глава 39. Встроенный мониторинг PVE

Данные о потреблении ресурсов и производительности можно просматривать на вкладках Сводка узла PVE и ВМ. Статистику можно отображать за час, день, неделю, месяц или год — в зависимости от доступных вариантов выбора периода.
Сводка узла pve01 со списком для выбора периода отображения данных:
Выбор периода отображения статистики
Просмотреть список узлов, ВМ и контейнеров кластера можно, выбрав Центр обработки данных → Поиск. В этом списке отображаются текущие значения потребления ресурсов.
Потребление ресурсов
К полям, отображаемым по умолчанию, можно добавить дополнительные поля, а также изменить порядок сортировки дерева ресурсов:
Выбор отображаемых полей
Для проверки состояния локальных дисков используется пакет smartmontools. Он инструменты для получения информации о состоянии дисков и управления функциями S.M.A.R.T.
Получить информацию о состоянии диска можно с помощью команды:
# smartctl -a /dev/sdX
где /dev/sdX — путь к устройству, соответствующему локальному диску.
Если поддержка S.M.A.R.T. отключена, её можно включить командой:
# smartctl -s on /dev/sdX
Просмотреть данные S.M.A.R.T. диска в веб-интерфейсе можно, выбрав нужный диск в разделе Диски и нажав кнопку Показать данные S.M.A.R.T.:
Кнопка Показать данные S.M.A.R.T.
По умолчанию служба smartd, входящая в состав пакета smartmontools, запускается и включается при загрузке системы. Она периодически проверяет обнаруженные диски на наличие ошибок и предупреждений. При обнаружении проблемы служба может отправить уведомление по электронной почте. Для получения уведомлений необходимо настроить отправку почты и указать действительный адрес электронной почты для пользователя root в PVE.
Электронное уведомление будет содержать имя узла, на котором обнаружена проблема, и сведения об устройстве, например серийный номер и идентификатор дискового устройства. При повторном обнаружении той же проблемы, узел будет отсылать электронное сообщение каждые 24 часа. Полученную информацию можно использовать для определения неисправного устройства и принятия решения о его замене.

⁠Глава 40. Высокая доступность в PVE

Механизм высокой доступности (High Availability, HA) в PVE позволяет автоматически восстанавливать работу ВМ и контейнеров на других узлах кластера при отказе узла или службы.
Ресурс HA может работать только на узлах, на которых доступны необходимые ему ресурсы и зависимости. По умолчанию HA Manager рассматривает все узлы кластера как потенциально подходящие для размещения ресурса. Чтобы ресурс можно было запустить на любом из этих узлов, необходимо обеспечить следующие условия:
  • конфигурация ВМ или контейнера должна быть совместима со всеми узлами, на которых разрешено размещение ресурса;
  • диски и данные ресурса должны быть доступны на целевых узлах, например через общее хранилище;
  • необходимые сетевые интерфейсы и сетевые настройки должны быть доступны на всех узлах, на которых может работать ресурс;
  • устройства, подключённые к ВМ с использованием проброса (passthrough), должны быть доступны на целевых узлах и соответствовать конфигурации ВМ.
Если необходимые ресурсы доступны только на части узлов кластера, следует ограничить размещение ресурса HA этим подмножеством узлов с помощью правила строгой привязки к узлам (см. Правила привязки к узлам (Node Affinity)). В этом случае HA Manager учитывает заданное ограничение при выборе узла для размещения или восстановления ресурса.

Примечание

HA в PVE управляет узлами и виртуальными машинами внутри кластера PVE. Этот механизм не заменяет обеспечение избыточности на уровне хранилища. Общие хранилища сторонних производителей могут иметь собственные механизмы высокой доступности. Для построения отказоустойчивой инфраструктуры необходимо обеспечить как восстановление ресурсов средствами HA в PVE, так и отказоустойчивость используемых хранилищ.
Вычислительные узлы PVE могут иметь собственные механизмы аппаратной избыточности, например RAID-массивы, резервные блоки питания и объединённые сетевые интерфейсы. HA дополняет эти механизмы на уровне управления ВМ и контейнерами, обеспечивая восстановление их работы при отказе узла.

⁠40.1. Как работает высокая доступность в PVE

PVE предоставляет программный стек ha-manager, который отслеживает состояние ресурсов и управляет их запуском, остановкой, перемещением и восстановлением в соответствии с конфигурацией HA.
Основной объект, управляемый ha-manager, называется ресурсом (service). Ресурс однозначно идентифицируется идентификатором службы (Service ID, SID), состоящим из типа ресурса и идентификатора, специфичного для данного типа:
  • vm: 100 (ресурс типа ВМ с идентификатором 100);
  • ct: 109 (ресурс типа контейнера с идентификатором 109).
Для обеспечения высокой доступности на каждом узле работают два демона:
  • pve-ha-lrm — локальный менеджер ресурсов (Local Resource Manager, LRM). Управляет ресурсами HA на локальном узле, получает сведения об их требуемом состоянии и выполняет соответствующие действия;
  • pve-ha-crm — кластерный менеджер ресурсов (Cluster Resource Manager, CRM). Координирует работу HA на уровне кластера, принимает решения о размещении и восстановлении ресурсов, передаёт команды LRM и обрабатывает результаты их выполнения. CRM также участвует в обеспечении безопасного переключения ресурсов при отказе узла.
При отказе узла HA должен обеспечить безопасную изоляцию отказавшего узла и восстановление ресурсов на других подходящих узлах. Перед запуском ресурса на другом узле необходимо исключить возможность его одновременной работы на исходном узле.
При недоступности узла (например, сетевой разрыв или зависание) HA-менеджер:
  1. Ожидает 60 секунд, чтобы исключить временные сбои.
  2. Выполняет ограждение (fencing) отказавшего узла — блокирует узел, чтобы предотвратить одновременную работу ВМ на нескольких узлах («split-brain»).
  3. Перемещает ВМ и контейнеры на другой доступный узел в группе HA.

Примечание

Даже если узел продолжает работать, но потерял связь с кластером, HA считает его отказавшим и мигрирует ресурсы.
После восстановления узла HA не возвращает ВМ на исходный узел автоматически. Если требуется разместить ВМ на исходном узле, следует выполнить управляемое перемещение ресурса:
  1. Отключить HA для нужной ВМ.
  2. Переместить ВМ на исходный узел.
  3. Включить HA для этой ВМ.

Примечание

ВМ может быть перемещена вручную только если HA отключён для данной ВМ.

⁠40.2. Требования для настройки HA

Для корректной работы HA необходимо учитывать следующие условия:
  • наличие кворума кластера; для повышения отказоустойчивости рекомендуется использовать не менее трёх узлов;
  • доступность данных ВМ и контейнеров на узлах, на которых они могут быть запущены после отказа (например, общее хранилище);
  • согласованность сетевых настроек и конфигурации оборудования на узлах кластера;
  • наличие и корректную настройку механизма сторожевого таймера (hardware watchdog); при его отсутствии используется программный таймер ядра Linux;
  • использование совместимого серверного оборудования;
  • наличие необходимых механизмов обеспечения безопасного переключения ресурсов при отказе узла (например, IPMI, управление питанием через PDU).

Примечание

Для повышения общей отказоустойчивости инфраструктуры рекомендуется использовать аппаратную избыточность, например RAID-массивы, резервные блоки питания и объединённые сетевые интерфейсы.

Примечание

На некоторых серверах HP модуль ядра hpwdt может конфликтовать с механизмом watchdog, используемым PVE. В этом случае необходимо запретить загрузку модуля ядра hpwdt. Для отключения модуля можно создать файл /etc/modprobe.d/nohpwdt.conf со следующим содержимым:
# Do not load the 'hpwdt' module on boot.
blacklist hpwdt
Для применения изменений следует перезагрузить систему.

⁠40.3. Настройка высокой доступности

Стек HA интегрирован в API PVE и доступен следующими способами:
  • через веб-интерфейс PVE (раздел Центр обработки данных → HA);
  • через командную строку (ha-manager);
  • через API PVE, в том числе из автоматизированных скриптов.
Меню HA. Статус настройки HA
В разделе Статус отображается текущее состояние HA, в том числе:
  • состояние кворума;
  • главный узел кластера и время последнего обновления его состояния;
  • состояние узлов и их локальных менеджеров ресурсов (LRM);
  • состояние механизма ограждения (fencing) и сторожевых таймеров (watchdog).
В строке fencing отображается состояние механизма ограждения узлов, связанное с работой watchdog кластерного менеджера ресурсов (CRM). Каждая строка lrm дополнительно содержит сведения о состоянии локального менеджера ресурсов и его watchdog.
Возможные состояния watchdog:
  • armed (активен) — watchdog активирован. CRM поддерживает свой сторожевой таймер, пока выполняются необходимые условия работы HA. LRM также использует собственный watchdog в соответствии с состоянием локального менеджера и удерживаемой им блокировкой. При нарушении условий безопасной работы HA механизм watchdog может инициировать перезагрузку узла;
  • standby (ожидание) — watchdog CRM находится в режиме ожидания. Такое состояние может наблюдаться, например, при отсутствии ресурсов HA или до выбора главного узла после запуска кластера. После активации CRM состояние может измениться на armed;
  • disarming (отключение) — выполняется отключение HA с помощью команды disarm-ha. CRM прекращает обычное управление ресурсами в соответствии с выбранным режимом и ожидает освобождения watchdog всеми LRM. На этом этапе watchdog CRM ещё может оставаться активным;
  • disarmed (отключен) — сторожевые таймеры HA освобождены. Автоматическая изоляция узлов и восстановление ресурсов средствами HA в этом состоянии не выполняются.
Примеры команд ha-manager:
  • Просмотр статуса HA:
    # ha-manager status
    quorum OK
    master pve01 (active, Mon Jul  6 15:14:51 2026)
    fencing armed (CRM watchdog active)
    lrm pve01 (active, watchdog active, Mon Jul  6 15:14:54 2026)
    lrm pve02 (idle, watchdog standby, Mon Jul  6 15:14:53 2026)
    lrm pve03 (active, watchdog active, Mon Jul  6 15:14:53 2026)
    service ct:102 (pve01, started)
    service ct:103 (pve03, stopped)
    service vm:104 (pve01, started)
    
  • Просмотр конфигурации ресурсов HA:
    # ha-manager config
    ct:102
        state started
    
    ct:103
        max_relocate 2
        state stopped
    
    vm:104
    	state started
    
  • Онлайн-миграция ВМ на другой узел:
    # ha-manager migrate vm:104 pve02
    

    Примечание

    При онлайн-миграции содержимое памяти ВМ передаётся по сети, поэтому иногда быстрее остановить ВМ и перезапустить её на новом узле.
  • Перемещение ВМ с остановкой и последующим запуском:
    # ha-manager relocate vm:104 pve02
    
  • Удаление ресурса из конфигурации HA:
    # ha-manager remove ct:103
    

    Примечание

    Эта команда не запускает и не останавливает ресурс.
Ресурсы HA могут находиться в следующих состояниях:
  • stopped — служба остановлена (подтверждено LRM). Если LRM обнаружит, что служба фактически работает, он может повторно инициировать её остановку в соответствии с требуемым состоянием;
  • request_stop — CRM запросил остановку службы и ожидает подтверждения от LRM;
  • stopping — выполняется остановка службы; CRM ожидает подтверждения от LRM;
  • started — служба должна быть запущена и поддерживаться в работающем состоянии. Если служба не работает, LRM предпринимает действия для её запуска;
  • starting — выполняется запуск службы; CRM ожидает подтверждения от LRM;
  • fence — ожидается завершение ограждения узла, на котором выполнялась служба. Это необходимо, когда узел находится вне кворумной части кластера и требуется обеспечить безопасное переключение. После успешного ограждения служба переводится в состояние recovery;
  • recovery — выполняется восстановление службы. HA Manager выбирает подходящий узел с учётом доступности узлов, состояния кворума и настроенных правил размещения. После выбора узла служба переносится туда и сначала получает состояние stopped. Если служба должна быть запущена — узел её запускает;
  • freeze — управление службой временно приостановлено. Это состояние может использоваться, например, при перезагрузке узла или перезапуске LRM;
  • ignored — служба временно исключена из обычного управления HA. Это позволяет выполнять отдельные операции вручную без удаления ресурса из конфигурации HA;
  • migrate — выполняется миграция службы на другой узел;
  • error — служба отключена из-за ошибок LRM. Требуется ручное вмешательство;
  • queued — служба ожидает обработки кластерным менеджером ресурсов;
  • disabled — служба отключена от автоматического управления запуском средствами HA. Для возобновления автоматического управления необходимо изменить её состояние в конфигурации HA.
Все конфигурационные файлы HA хранятся в каталоге /etc/pve/ha/ и автоматически синхронизируются между узлами кластера.

⁠40.3.1. Создание ресурса

Для создания ресурса необходимо в подменю Ресурсы нажать кнопку Добавить.
Создание ресурса
Параметры ресурса:
  • VM — идентификатор ВМ или контейнера;
  • Макс. перезапусков (max_restart) — максимальное количество попыток перезапустить ресурс на текущем узле после неудачного запуска. После исчерпания этих попыток HA Manager может попытаться перенести ресурс на другой узел;
  • Макс. перемещений (max_relocate) — максимальное количество попыток перенести ресурс на другой узел после неудачных попыток запуска;
  • Восстановление размещения (failback) — разрешает автоматически возвращать ресурс на узел с наивысшим приоритетом в соответствии с правилами привязки к узлам, когда такой узел становится доступен;
  • Auto-Rebalance (auto-rebalance) — определяет, может ли ресурс участвовать в автоматической перебалансировке нагрузки кластера;
  • Статус запроса:
    • started — ресурс должен быть запущен. HA Manager запускает его, если он не работает, и восстанавливает работу при сбоях;
    • stopped — ресурс должен быть остановлен. HA Manager поддерживает его в остановленном состоянии;
    • ignored — ресурс временно исключается из управления HA, но остаётся в конфигурации;
    • disabled — ресурс останавливается и помечается как отключённый.
Пример создания ресурса в командной строке:
# ha-manager add ct:108 --state started --max_relocate 2
Список ресурсов, управляемых ha-manager, хранится в файле /etc/pve/ha/resources.cfg в формате:
<тип>: <имя>
       <свойство> <значение>
…
⁠

Таблица 40.1. Дополнительные свойства

Свойство
Описание
auto-rebalance: <логическое значение> (по умолчанию 1)
Определяет, может ли ресурс участвовать в автоматической перебалансировке нагрузки кластера
comment: <строка>
Описание ресурса
failback: <логическое значение> (по умолчанию 1)
Разрешает автоматически переносить ресурс на узел с наивысшим приоритетом согласно правилам привязки к узлам, если этот узел становится доступен
group: <строка>
Устаревший механизм. Идентификатор группы высокой доступности
max_relocate: <целое число> (0 — N) (по умолчанию 1)
Максимальное количество попыток перенести ресурс на другой узел после неудачных попыток запуска
max_restart: <целое число> (0 — N) (по умолчанию 1)
Максимальное количество попыток перезапустить ресурс на текущем узле после неудачного запуска. После исчерпания этих попыток HA Manager пытается перенести ресурс на другой узел
state: <disabled | enabled | ignore | started | stopped> (по умолчанию started)
Запрошенное состояние ресурса (enabled — псевдоним для started)
Пример конфигурации (/etc/pve/ha/resources.cfg):
ct: 103
    state stopped

vm: 104
    state started

ct: 102
    max_relocate 2
    state started

Примечание

Если параметры не указаны, используются значения по умолчанию.

⁠40.3.2. Правила

Правила HA (Affinity Rules) позволяют задавать ограничения на размещение ресурсов в кластере: определять узлы, на которых должны или могут работать ресурсы, а также взаимное расположение ресурсов.
Правила HA (Affinity Rules)
Конфигурация правил хранится в файле /etc/pve/ha/rules.cfg. Формат файла:
<тип>: <имя_правила>
       resources <список_ресурсов>
       <свойство> <значение>
⁠

Таблица 40.2. Дополнительные свойства правил HA

Свойство
Описание
comment: <строка>
Описание правила HA
disable: <логическое значение>
Определяет, отключено ли правило
resources: <тип>:<имя>{,<тип>:<имя>}*
Список идентификаторов ресурсов HA, к которым применяется правило
⁠

Таблица 40.3. Типы правил HA

Тип правила
Описание
node-affinity
Задаёт предпочтительные или обязательные узлы для размещения ресурсов HA
resource-affinity
Задаёт взаимное расположение двух или более ресурсов: positive — ресурсы должны размещаться на одном узле, negative — ресурсы должны размещаться на разных узлах

⁠40.3.2.1. Правила привязки к узлам (Node Affinity)

По умолчанию ресурс HA может работать на любом узле кластера. Правила привязки к узлам позволяют задать предпочтительные узлы для размещения ресурса или ограничить размещение определённым набором узлов.
По умолчанию правило привязки к узлам является нестрогим. Если ни один из указанных в правиле узлов недоступен, ресурс может быть размещён на другом узле кластера. Если правило является строгим (strict = 1), ресурс может работать только на указанных узлах. Если все эти узлы недоступны, ресурс не будет запущен на других узлах.
Для добавления правила привязки к узлам необходимо на вкладке Центр обработки данных → HA → Правила размещения в разделе Правила размещения на узлах высокой доступности (HA) нажать кнопку Добавить.
Добавление правила привязки к узлам
Настройки правила:
  • Включить — включает или отключает правило;
  • Ресурсы высокой доступности (HA) — список ресурсов, к которым применяется правило;
  • Строго — определяет, является ли привязка к указанным узлам обязательной;
  • Узел — список узлов, на которых предпочтительно или разрешено размещать ресурсы (нужно выбрать хотя бы один узел);
  • Приоритет — приоритет узла при размещении ресурса. Ресурс размещается на доступных узлах с наивысшим приоритетом. Если несколько узлов имеют одинаковый наивысший приоритет, ресурсы могут распределяться между ними. Приоритеты являются относительными: чем больше число, тем выше приоритет.
Для больших кластеров или особых сценариев использования можно настроить последовательность предпочтительных узлов при отказе. Например, ресурсы vm:200 и ct:300 должны работать на узле pve01. Если узел pve01 становится недоступен, ресурсы могут размещаться на узлах pve02 и pve03. Если эти узлы также недоступны, ресурсы могут быть размещены на pve04.
Для реализации такого поведения узлам назначают приоритеты. Узел pve01 получает наивысший приоритет, узлы pve02 и pve03 — одинаковый приоритет ниже, а pve04 — самый низкий. Если приоритет не указан, используется значение 0.
Пример команд для работы с правилами привязки к узлам:
  • создание правила, задающего предпочтительный узел pve01 для ресурса vm:104:
    # ha-manager rules add node-affinity ha-rule-vm104 --resources vm:104 --nodes pve01
    
  • Оключение строгой привязки:
    # ha-manager rules set node-affinity ha-rule-vm104 --strict 1
    
  • создание правила с несколькими приоритетами:
    # ha-manager rules add node-affinity priority-cascade \
      --resources ct:102,ct:103 --nodes "pve01:2,pve02:1,pve03:1,pve04"
    
    В этом примере узел pve01 имеет наивысший приоритет, узлы pve02 и pve03 — одинаковый приоритет ниже, а pve04 — приоритет 0, который используется по умолчанию.
Пример конфигурации правил привязки к узлам (/etc/pve/ha/rules.cfg):
node-affinity: ha-rule-vm104
        nodes pve01
        resources vm:104
        strict 1

node-affinity: priority-cascade
        nodes pve01:2,pve02:1,pve03:1,pve04
        resources ct:102,ct:103
⁠

Таблица 40.4. Свойства правила привязки к узлам

Свойство
Описание
nodes: <узел>[:<приоритет>]{,<узел>[:<приоритет>]}*
Список узлов кластера, которым могут назначаться приоритеты. Если приоритет не указан, используется значение 0
resources: <тип>: <имя>{,<тип>: <имя>}*
Список идентификаторов ресурсов HA, к которым применяется правило
strict: <логическое значение> (по умолчанию 0)
Определяет строгость привязки. При значении 0 ресурс может размещаться на других узлах, если указанные недоступны. При значении 1 ресурс ограничен указанными узлами

⁠40.3.2.2. Правила привязки ресурсов (Resource Affinity)

Правила привязки ресурсов позволяют задавать, должны ли два или более ресурса высокой доступности (HA) размещаться на одном узле или, наоборот, на разных узлах. Такие ограничения также называют правилами совместного и раздельного размещения (affinity/anti-affinity).
Например, если между ресурсами vm:104 (веб-сервер) и vm:108 (база данных) происходит интенсивный обмен данными, их размещение на разных узлах может увеличить сетевые задержки и нагрузку на сеть. В этом случае правило с положительной привязкой (positive affinity) предписывает размещать оба ресурса на одном узле.
Однако совместное размещение не всегда целесообразно. Например, если vm:120 и ct:130 — ресурсоёмкие экземпляры баз данных, их размещение на одном узле может привести к перегрузке узла и снижению производительности. В этом случае правило с отрицательной привязкой (negative affinity) предписывает размещать ресурсы на разных узлах.

Важно

В отличие от правил привязки к узлам, правила привязки ресурсов являются строгими. Если ограничение невозможно выполнить (например, не хватает узлов для разделения), HA Manager переводит ресурс в состояние восстановления (recovery) при обработке сбоя или в состояние ошибки (error) в других случаях.
Для добавления правила привязки ресурсов необходимо на вкладке Центр обработки данных → HA → Правила размещения в разделе Правила размещения ресурсов высокой доступности (HA) нажать кнопку Добавить.
Добавление правила привязки ресурсов
Настройка правила:
  • Включить — активировать или отключить правило;
  • Ресурсы высокой доступности (HA) — ресурсы, к которым применяется правило;
  • Привязка — тип привязки:
    • Размещать совместно — ресурсы должны находиться на одном узле;
      Размещать раздельно — ресурсы должны находиться на разных узлах.
Примеры создания правила привязки ресурсов в командной строке:
# ha-manager rules add resource-affinity keep-together \
  --affinity positive --resources vm:104,ct:108

# ha-manager rules add resource-affinity keep-separate \
--affinity negative --resources vm:200,ct:300
Первое правило предписывает размещать ресурсы на одном узле, второе — на разных.

Примечание

Если несколько правил с положительной привязкой содержат общие ресурсы, они рассматриваются как одно логическое правило. Например, правила для пар vm:100, vm:101 и vm:101, vm:102 эквивалентны одному правилу для vm:100, vm:101, vm:102.

Примечание

Если ресурсы, включённые в правило с положительной привязкой, уже запущены на разных узлах, HA Manager переместит их на узел, на котором запущено наибольшее количество этих ресурсов. Если количество ресурсов на узлах одинаково, выбирается узел с именем, первым в алфавитном порядке.
Пример конфигурации правил привязки ресурсов (/etc/pve/ha/rules.cfg):
resource-affinity: ha-rule-6827bc89-3620
    affinity negative
    resources ct:101,vm:104
⁠

Таблица 40.5. Свойства правила привязки ресурсов

Свойство
Описание
affinity: <negative | positive>
Определяет, должны ли ресурсы размещаться на одном узле (positive) или на разных узлах (negative)
resources: <тип>: <имя>{,<тип>: <имя>}*
Список идентификаторов ресурсов HA, к которым применяется правило
Логика взаимодействия правил и конфликты
Если ресурсы A, B и C связаны правилом positive affinity, а ресурс A также участвует в правиле negative affinity с ресурсом D, то ресурсы B и C также будут иметь отрицательную привязку к ресурсу D.
Конфликт возникает, если два или более одинаковых ресурса одновременно входят в правила с положительной и отрицательной привязкой. В этом случае конфликтующие правила отключаются, поскольку невозможно одновременно размещать одни и те же ресурсы на одном узле и на разных узлах.
Взаимодействие с правилами привязки к узлам
Если ресурсы vm:100, vm:101, vm:102 входят в одно правило positive affinity, а для vm:102 задано правило привязки к узлу pve03, то все три ресурса будут ограничены узлом pve03.
Однако нельзя включать ресурсы, связанные одним правилом положительной привязки, в разные правила привязки к узлам. Такое сочетание правил не поддерживается: соответствующие правила будут отключены.

⁠40.3.2.3. Конфликты правил и ошибки

Перед применением правила HA проверяются на выполнимость. Правила, не прошедшие проверку, отключаются до устранения конфликтов и ошибок.
Проверяются следующие условия:
  • Ресурс HA может входить только в одно правило привязки к узлам.
  • Правило привязки ресурсов должно содержать не менее двух ресурсов.
  • Правило negative affinity не может включать больше ресурсов, чем узлов в кластере (для размещения каждого ресурса на отдельном узле должно хватать узлов).
  • Один и тот же набор ресурсов не может одновременно входить в правила positive affinity и negative affinity.
  • Ресурс может одновременно участвовать в правилах привязки к узлам и к ресурсам, только если правило к узлам использует один класс приоритетов.
  • Ресурсы, входящие в правило positive affinity, могут участвовать не более чем в одном правиле привязки к узлам.
  • Для ресурсов, входящих в правило negative affinity, должно быть достаточно узлов с учётом ограничений, заданных правилами привязки к узлам.

⁠40.4. Отключение HA для обслуживания кластера

Некоторые задачи по обслуживанию кластера, например перенастройка сети или стека кластерной коммуникации Corosync, могут приводить к временной потере кворума или разделению сети (partition). В обычном режиме HA может интерпретировать такие события как сбой узла и инициировать его самоизоляцию (self-fencing), что приведёт к прерыванию работы сервисов.
Механизм отключения HA (disarm) освобождает сторожевые таймеры (watchdog) CRM и LRM на всех узлах кластера. Это позволяет выполнять обслуживание без автоматического срабатывания механизма изоляции узлов (fencing) со стороны HA.

Примечание

В отключённом состоянии HA не обеспечивает защиту сервисов. Сбои в этот период не обрабатываются автоматически. Продолжительность отключения следует свести к минимуму.
При отключении HA можно выбрать режим обработки ресурсов, который определяет, как будут обрабатываться ресурсы, управляемые HA, в период отключения (текущее состояние ресурсов при этом не изменяется):
  • freeze (заморозка) — новые команды и изменения запрошенного состояния не применяются. Сервисы остаются в текущем состоянии, но стек HA не реагирует на сбои и не обрабатывает новые запросы. Этот режим подходит, если предполагается, что все узлы останутся работоспособными;
  • ignore (игнорирование) — ресурсы исключаются из отслеживания HA и могут управляться так, как если бы они не находились под управлением HA. Это позволяет вручную запускать, останавливать или мигрировать сервисы во время обслуживания. Этот режим следует использовать, если требуется ручное управление сервисами в процессе обслуживания. После повторного включения HA (re-arm) CRM повторно проверяет расположение сервисов на соответствие конфигурации, чтобы учесть возможные изменения, выполненные вручную.

⁠40.4.1. Отключение и повторное включение HA

Чтобы отключить HA в веб-интерфейсе, необходимо в разделе Центр обработки данных → HA выбрать Disarm HA → Freeze или Disarm HA → Ignore и подтвердить действие, нажав кнопку Да в открывшемся окне.
Отключение HA
Состояние HA отображается на панели. В строке состояния изоляции (fencing) указывается состояние сторожевого таймера CRM. Состояние сторожевого таймера каждого LRM отображается отдельно в строке соответствующего узла.
HA в состоянии freeze
Чтобы повторно включить HA, необходимо нажать кнопку Arm HA.
Для отключения HA в командной строке используются команды:
# ha-manager crm-command disarm-ha freeze
или:
# ha-manager crm-command disarm-ha ignore
Для повторного включения HA после завершения обслуживания используется команда:
# ha-manager crm-command arm-ha
Текущее состояние HA можно проверить командой:
# ha-manager status

⁠40.4.2. Процесс отключения

После получения запроса на отключение HA выполняется следующая последовательность действий:
  1. CRM замораживает все сервисы или исключает их из отслеживания (в зависимости от выбранного режима ресурсов).
  2. Каждый LRM завершает выполняющиеся рабочие процессы (workers), после чего освобождает блокировку агента и свой сторожевой таймер.
  3. После того как все работающие узлы (на которых LRM находятся в состоянии online) завершат обработку запроса и перейдут в состояние простоя, CRM также освобождает свой сторожевой таймер.
  4. На протяжении всего процесса CRM удерживает блокировку менеджера, чтобы иметь возможность принять и обработать команду arm-ha, отменяющую отключение.
Если какие-либо сервисы в данный момент находятся в процессе изоляции, восстановления или миграции, отключение откладывается до завершения этих операций. Это позволяет избежать несогласованного состояния сервисов, находящихся в процессе перехода.

⁠40.4.3. Узлы в офлайн-режиме во время отключения

Если узел находится в офлайн-режиме на момент отключения HA, его LRM не может обработать запрос на отключение. CRM переходит в состояние отключения после того, как все работающие узлы завершат обработку запроса. Офлайн-узел не блокирует этот процесс.
Если узел возвращается в онлайн во время отключения HA, его LRM считывает состояние отключения и освобождает сторожевой таймер, не предпринимая попыток восстановления сервисов.
При повторном включении HA сервисы, находившиеся на офлайн-узле, обрабатываются по стандартным правилам HA: если узел остаётся недоступным, HA выполняет его изоляцию и восстанавливает сервисы на других узлах; если узел уже вернулся в онлайн, HA предпринимает попытку восстановить работу сервисов на нём.

⁠40.4.4. Взаимодействие с режимом обслуживания (Maintenance Mode)

Если на момент запроса на отключение HA узел уже находится в режиме обслуживания, миграция сервисов продолжается до тех пор, пока все сервисы не будут перемещены с этого узла. После завершения миграции LRM освобождает блокировку агента и сторожевой таймер в рамках процесса отключения.
При повторном включении HA состояние режима обслуживания сохраняется. Узел остаётся в режиме обслуживания, и сервисы не переносятся обратно до тех пор, пока этот режим не будет явно отключён.

Примечание

Пока стек HA отключён, автоматическое восстановление, переключение при сбое (failover) и изоляция узлов (fencing) не выполняются. Сбой узла в этот период обрабатывается средствами HA. Продолжительность отключения следует свести к минимуму. Перед повторным включением HA необходимо убедиться, что кластер находится в работоспособном состоянии.

⁠40.5. Планировщик ресурсов кластера (CRS)

Планировщик ресурсов кластера (Cluster Resource Scheduler, CRS) отвечает за выбор узлов для размещения ресурсов HA и поддержание их размещения на узлах, допустимых с учётом правил HA.
В каждом цикле работы HA Manager планировщик проверяет, требуется ли изменить размещение ресурсов HA. Необходимость переразмещения может возникнуть, например, при восстановлении ресурсов после отказа узла или изменении правил размещения.
Настройки планировщика ресурсов кластера можно изменить в веб-интерфейсе, выбрав пункт Центр обработки данных → Параметры → Планирование ресурсов кластера или нажав кнопку CRS settings в разделе Центр обработки данных → HA.
Настройки планировщика ресурсов кластера

⁠40.5.1. Режим планирования CRS

Режим планирования CRS (Scheduling Mode) определяет, какие сведения об использовании ресурсов кластера учитываются при выборе узла для размещения ресурса HA:
  • Basic (Resource Count) — режим по умолчанию. При выборе узла учитывается количество активных гостевых систем на каждом узле. Предпочтение отдаётся узлу с наименьшим количеством активных гостевых систем;
  • Static Load (планировщик статической нагрузки) — при выборе узла учитываются статические характеристики нагрузки:
    • выделенные (заданные) лимиты CPU и памяти ВМ;
    • суммарное потребление ресурсов на узле на основе конфигурации;
  • Dynamic Load (планировщик динамической нагрузки) — при выборе узла учитываются статические характеристики и динамические показатели нагрузки:
    • фактическое среднее использование CPU и памяти;
    • конфигурационные лимиты ВМ;
    • текущую нагрузку на узлы кластера.
Изменения вступают в силу со следующего цикла HA Manager (обычно до 10 секунд).

⁠40.5.2. Точки планирования CRS

CRS пересчитывает размещение ресурсов HA при наступлении следующих событий:
  • восстановление ресурса HA (всегда активно) — если узел с активными HA-ресурсами выходит из строя, CRS выбирает узлы для восстановления этих ресурсов на оставшихся узлах кластера;
  • изменение правил HA (всегда активно) — при изменении правил привязки или ограничений размещения CRS учитывает новые условия при выборе допустимых узлов. Основные типы правил, влияющих на размещение ресурсов:
    • Node affinity rules (правила привязки к узлам) — ресурсы ограничиваются набором допустимых узлов или предпочтений размещения;
    • Positive resource affinity rules (правила положительной привязки ресурсов) — связанные ресурсы стремятся размещаться на одном узле;
    • Negative resource affinity rules (правила отрицательной привязки ресурсов) — связанные ресурсы размещаются на разных узлах.
Если включена опция Повторная балансировка при запуске, CRS выбирает подходящий узел при запуске ресурса HA. Если выбранный узел отличается от текущего, ресурс мигрирует на него.
В режиме Basic при выборе узла учитывается количество активных гостевых систем. В режимах Static Load и Dynamic Load CRS моделирует размещение ресурса на каждом допустимом узле и оценивает результирующую нагрузку кластера. При этом:
  • нагрузка CPU и памяти оценивается с разными весами;
  • больший вес придаётся использованию памяти;
  • учитываются максимальная нагрузка среди узлов и средняя нагрузка по кластеру.

Примечание

Для режимов статической и динамической нагрузки функция находится в состоянии технологического preview. При большом количестве ресурсов HA расчёт может занимать значительное время.

⁠40.5.3. Автоматический балансировщик нагрузки CRS

Примечание

Эта функция находится в состоянии технологического preview.
Автоматическая балансировка нагрузки CRS (Automatic Rebalance) позволяет уменьшать дисбаланс нагрузки между узлами кластера за счёт автоматического запуска миграций ресурсов HA.
Использование ресурсов отдельных узлов может существенно различаться в зависимости от размещения гостевых систем и создаваемой ими нагрузки. Со временем это может приводить к дисбалансу: на одном узле ресурсы HA испытывают конкуренцию за вычислительные ресурсы, тогда как другой узел используется слабо.
Настройка автоматической балансировки нагрузки
В каждом цикле HA Manager, который обычно занимает около 10 секунд, балансировщик выполняет следующие действия:
  1. Проверяется дисбаланс кластера.
  2. Если дисбаланс превышает пороговое значение (Imbalance Threshold) в течение заданного количества последовательных циклов HA Manager (Hold Duration):
    • выбирает миграцию ресурса HA, которая, согласно расчёту, сильнее всего уменьшит дисбаланс. Метод выбора задаётся параметром Rebalancing Method.
  3. Проверяется ожидаемое улучшение дисбаланса:
    • если улучшение превышает заданный порог (параметр Minimum Imbalance Improvement), запускается миграция.
Отключение автоматической балансировки для ресурса HA предотвращает его участие в миграциях, инициируемых балансировщиком.

Примечание

Если для ресурса HA отключена автоматическая балансировка, ресурсы, связанные с ним правилом положительной привязки (positive affinity), также не участвуют в таких миграциях.
Для работы автоматической балансировки требуется режим планирования Static Load или Dynamic Load.
Дисбаланс кластера рассчитывается на основе стандартного отклонения и среднего значения загрузки узлов и нормализуется к диапазону 0–100%. Порог дисбаланса (Imbalance Threshold) и минимальное улучшение дисбаланса (Minimum Imbalance Improvement) задаются в процентах. Порог дисбаланса по умолчанию составляет 30% и определяет чувствительность балансировщика; при значении 0 он будет пытаться выбирать миграции каждый раз после превышения Hold Duration. Минимальное улучшение по умолчанию составляет 10% и фильтрует допустимые миграции; при значении 0 миграция выполняется даже при нулевом улучшении дисбаланса. Значение не может быть отрицательным, поэтому миграции с ухудшением дисбаланса никогда не выполняются.

⁠Глава 41. Межсетевой экран PVE (firewall)

Межсетевой экран PVE позволяет защищать ИТ-инфраструктуру с помощью правил фильтрации сетевого трафика. Можно настроить правила межсетевого экрана для всех узлов кластера, а также задать отдельные правила для ВМ и контейнеров.
Конфигурация хранится в файловой системе кластера, а служба pve-firewall, использующая iptables, работает на каждом узле. Это позволяет фильтровать трафик непосредственно на узлах, где работают ВМ и контейнеры.
Межсетевой экран поддерживает протоколы IPv4 и IPv6. По умолчанию трафик обоих протоколов фильтруется, поэтому обычно не требуется создавать отдельные наборы правил для IPv6.

⁠41.1. Зоны

Межсетевой экран PVE группирует сетевой трафик в логические зоны:
  • Узел — трафик, поступающий на узел кластера или отправляемый с него;
  • ВМ — трафик, поступающий в ВМ или контейнер либо отправляемый ими;
  • Виртуальная сеть — транзитный трафик, проходящий через виртуальную сеть SDN.

Предупреждение

Создание правил на уровне виртуальной сети поддерживается только новым межсетевым экраном proxmox-firewall, основанным на nftables. Стандартный межсетевой экран pve-firewall игнорирует такие правила, поэтому они не влияют на обработку трафика.

Примечание

Чтобы включить межсетевой экран на основе nftables, используйте веб-интерфейс (Узел → Сетевой экран → Параметры → nftables) или задайте параметр nftables в конфигурационном файле узла (/etc/pve/nodes/<node_name>/host.fw):
[OPTIONS]

nftables: 1
Перед включением этого параметра убедитесь, что установлен пакет proxmox-firewall. Если включить nftables без этого пакета, правила межсетевого экрана не будут созданы, поэтому узел и гостевые системы останутся без защиты.
После включения или отключения proxmox-firewall необходимо перезапустить все работающие ВМ и контейнеры, чтобы обеспечить корректную работу выбранной реализации межсетевого экрана.
Для каждой зоны можно задавать правила входящего и исходящего трафика. В зоне VNet правила применяются к транзитному трафику.

⁠41.2. Файлы конфигурации

Конфигурация межсетевого экрана хранится в файловой системе кластера и автоматически распространяется на узлы. При изменении конфигурации служба pve-firewall обновляет соответствующие правила iptables.
Настраивать межсетевой экран можно через веб-интерфейс PVE (например, в разделах Центр обработки данных → Сетевой экран или Узел → Сетевой экран) или через конфигурационные файлы (/etc/pve/firewall/).
Файлы конфигурации содержат разделы, названия которых заключены в квадратные скобки. В зависимости от типа раздела в нём могут задаваться параметры, правила, наборы IP-адресов, группы правил или псевдонимы. Строки, начинающиеся с символа #, и пустые строки считаются комментариями.

⁠41.2.1. Настройка кластера

Файл /etc/pve/firewall/cluster.fw содержит конфигурацию межсетевого экрана на уровне кластера. В нём задаются общие параметры, правила и другие объекты, используемые при настройке межсетевого экрана.
Файл автоматически синхронизируется между узлами с помощью файловой системы кластера PVE (PVE Cluster File System, pmxcfs).
Файл /etc/pve/firewall/cluster.fw может содержать следующие разделы:
  • [OPTIONS] — параметры межсетевого экрана кластера;
  • [RULES] — правила межсетевого экрана, применяемые на уровне кластера;
  • [IPSET <имя_набора>] — определения наборов IP-адресов;
  • [GROUP <имя_группы>] — определения групп правил;
  • [ALIASES] — определения псевдонимов IP-адресов и сетей.
⁠

Таблица 41.1. Опции секции [OPTIONS] файла cluster.fw

Опция
Описание
ebtables: <1|0> (по умолчанию 1)
Включить правила ebtables на уровне кластера
enable: <1|0>
Включить или отключить межсетевой экран на уровне кластера
log_ratelimit: [enable=]<1|0> [,burst=<integer>] [,rate=<rate>]
Настройки ограничения частоты записи сообщений в журнал (rate limiting).
  • burst=<integer> (0 — N) (по умолчанию 5) —  количество сообщений, которые могут быть записаны до применения ограничения частоты;
  • enable=<1|0> (по умолчанию 1) — включить или отключить ограничение частоты записи сообщений;
  • rate=<rate> (по умолчанию 1/second) — частота записи сообщений. Формат: <число>/<интервал> (например, 1/second, 5/minute)
policy_forward: <ACCEPT | DROP >
Политика по умолчанию для переадресованного трафика:
  • ACCEPT — разрешить;
  • DROP — отбросить без ответа
policy_in: <ACCEPT | DROP | REJECT>
Политика по умолчанию для входящего трафика:
  • ACCEPT — разрешить;
  • DROP — отбросить без ответа;
  • REJECT — отклонить с отправкой ответа
policy_out: <ACCEPT | DROP | REJECT>
Политика по умолчанию для исходящего трафика. Значения аналогичны policy_in
Параметры межсетевого экрана кластера можно настроить в веб-интерфейсе (Центр обработки данных → Сетевой экран → Параметры):
Параметры сетевого экрана кластера
По умолчанию межсетевой экран на уровне кластера отключён. Его можно включить в веб-интерфейсе (отредактировав параметр Сетевой экран в веб-интерфейсе) или задать параметр enable в файле /etc/pve/firewall/cluster.fw:
[OPTIONS]
# enable firewall (настройка для всего кластера, по умолчанию отключено)
enable: 1

Важно

После включения межсетевого экрана часть сетевого трафика к узлам блокируется в соответствии с политиками и правилами по умолчанию. Для доступа к WebGUI (8006) и SSH (22) и другим необходимым службам предусмотрены исключения для трафика из управляющей сети. Перед включением следует проверить, какие адреса входят в управляющую сеть и какие соединения разрешены.
Для удалённого администрирования необходимо разрешить доступ с соответствующих IP-адресов к веб-интерфейсу PVE (TCP-порт 8006). При необходимости также следует разрешить SSH (TCP-порт 22), SPICE (TCP-порт 3128) и другие используемые службы.

Примечание

Перед включением межсетевого экрана рекомендуется установить SSH-соединение с одним из узлов PVE. Это может помочь восстановить доступ к узлу, если после изменения правил возникнут проблемы.
Чтобы упростить настройку удалённого администрирования, можно использовать стандартный набор IP-адресов «management». Его необходимо создать и добавить в него адреса, с которых разрешено управление узлами. Этот набор используется правилами доступа к интерфейсу управления и другим службам администрирования.

⁠41.2.2. Конфигурация узла

Конфигурация межсетевого экрана отдельного узла считывается из файла /etc/pve/nodes/<nodename>/host.fw.
В этом файле можно задавать правила, специфичные для узла, переопределять некоторые настройки кластера, изменять уровень журналирования и задавать параметры netfilter.
Файл host.fw содержит следующие разделы:
  • [OPTIONS] — параметры межсетевого экрана узла;
  • [RULES] — правила межсетевого экрана, применяемые на узле.
⁠

Таблица 41.2. Опции секции [OPTIONS] конфигурации узла

Опция
Описание
enable: <1|0>
Включить или отключить межсетевой экран узла
log_level_forward: <alert | crit | debug | emerg | err | info | nolog | notice | warning>
Уровень журнала для переадресованного трафика. Используются следующие уровни:
  • emerg — аварийные события;
  • alert — события, требующие немедленного внимания;
  • crit — критические события;
  • err — ошибки;
  • warning — предупреждения;
  • notice — важные уведомления;
  • info — информационные сообщения;
  • debug — отладочные сообщения;
  • nolog — не записывать сообщения в журнал.
log_level_in: <alert | crit | debug | emerg | err | info | nolog | notice | warning>
Уровень журналирования входящего трафика. Значения аналогичны log_level_forward
log_level_out: <alert | crit | debug | emerg | err | info | nolog | notice | warning>
Уровень журналирования исходящего трафика. Значения аналогичны log_level_forward
log_nf_conntrack: <1|0> (по умолчанию 0)
Включить журналирование информации об отслеживании соединений (conntrack)
ndp: <1|0> (по умолчанию 1)
Разрешить обработку пакетов протокола обнаружения соседей IPv6 (Neighbor Discovery Protocol, NDP)
nf_conntrack_allow_invalid: <1|0> (по умолчанию 0)
Разрешить недействительные пакеты при отслеживании соединений
nf_conntrack_helpers: <string> (по умолчанию ``)
Включить помощники отслеживания соединений для указанных протоколов. Поддерживаются amanda, ftp, irc, netbios-ns, pptp, sane, sip, snmp, tftp
nf_conntrack_max: <integer> (32768 — N) (по умолчанию 262144)
Максимальное количество отслеживаемых соединений
nf_conntrack_tcp_timeout_established: <integer> (7875 — N) (по умолчанию 432000)
Тайм-аут для TCP-соединений в состоянии ESTABLISHED
nf_conntrack_tcp_timeout_syn_recv: <integer> (30 — 60) (по умолчанию 60)
Тайм-аут для TCP-соединений в состоянии SYN_RECV
nftables: <1|0> (по умолчанию 0)
Включение межсетевого экрана на основе nftables (предварительная версия)
nosmurfs: <1|0>
Включить или отключить фильтрацию атак типа SMURF
protection_synflood: <1|0> (по умолчанию 0)
Включить защиту от SYN flood
protection_synflood_burst: <integer> (по умолчанию 1000)
Порог пакетной нагрузки для защиты от SYN flood на один IP-адрес источника
protection_synflood_rate: <integer> (по умолчанию 200)
Допустимая скорость SYN-пакетов в секунду для одного IP-адреса источника
smurf_log_level: <alert | crit | debug | emerg | err | info | nolog | notification | warning>
Уровень журналирования для фильтра SMURFS
tcp_flags_log_level: <alert | crit | debug | emerg | err | info | nolog | notification | warning>
Уровень журнала для фильтра недопустимых комбинаций флагов TCP
tcpflags: <1|0> (по умолчанию 0)
Включить фильтрацию недопустимых комбинаций флагов TCP
Параметры межсетевого экрана узла можно настроить в веб-интерфейсе (Узел → Сетевой экран → Параметры):
Параметры межсетевого экрана узла

⁠41.2.3. Конфигурация ВМ и контейнера

Конфигурация межсетевого экрана ВМ или контейнера считывается из файла /etc/pve/firewall/<VMID>.fw, где <VMID> — идентификатор гостевой системы.
Файл может содержать следующие разделы:
  • [OPTIONS] — параметры межсетевого экрана ВМ или контейнера;
  • [RULES] — правила межсетевого экрана;
  • [IPSET <имя_набора>] — определения набора IP-адресов;
  • [ALIASES] — определения псевдонимов IP-адресов и сетей.
⁠

Таблица 41.3. Опции секции [OPTIONS] файла конфигурации ВМ/контейнера

Опция
Описание
dhcp: <1|0> (по умолчанию 0)
Разрешить DHCP-трафик
enable: <1|0>
Включить или отключить правила межсетевого экрана для ВМ или контейнера
ipfilter: <1|0>
Включить фильтры IP-адресов по умолчанию. Это эквивалентно добавлению пустого набора ipfilter-net<id> ipset для каждого сетевого интерфейса. Такие наборы неявно включают link-local IPv6-адрес, производный от MAC-адреса интерфейса. Для контейнеров в них также автоматически включаются настроенные IP-адреса
log_level_in: <alert | crit | debug | emerg | err | info | nolog | notice | warning>
Уровень журналирования входящего трафика. Используются следующие уровни:
  • emerg — аварийные события;
  • alert — события, требующие немедленного внимания;
  • crit — критические события;
  • err — ошибки;
  • warning — предупреждения;
  • notice — важные уведомления;
  • info — информационные сообщения;
  • debug — отладочные сообщения;
  • nolog — не записывать сообщения в журнал.
log_level_out: <alert | crit | debug | emerg | err | info | nolog | notice | warning>
Уровень журналирования исходящего трафика. Значения аналогичны log_level_in
macfilter: <1|0> (по умолчанию 1)
Включить или отключить фильтрацию MAC-адресов
ndp: <1|0> (по умолчанию 1)
Разрешить обработку пакетов протокола обнаружения соседей IPv6 (NDP)
policy_in: <ACCEPT | DROP | REJECT>
Политика по умолчанию для входящего трафика. Возможные значения:
  • ACCEPT — разрешить;
  • DROP — отбросить;
  • REJECT — отклонить с отправкой ответа.
policy_out: <ACCEPT | DROP | REJECT>
Политика по умолчанию для исходящего трафика. Значения аналогичны policy_in
radv: <1|0>
Разрешить отправку объявлений маршрутизатора (Router Advertisement)
Параметры межсетевого экрана ВМ или контейнера можно настроить в веб-интерфейсе (ВМ/Контейнер → Сетевой экран → Параметры):
Параметры сетевого экрана ВМ
Каждый виртуальный сетевой интерфейс имеет собственный флаг включения межсетевого экрана. Чтобы фильтрация трафика через интерфейс работала, необходимо включить межсетевой экран как для ВМ или контейнера в целом, так и для соответствующего сетевого интерфейса.
Включение межсетевого экрана для сетевого устройства ВМ

⁠41.2.4. Правила межсетевого экрана

Правило межсетевого экрана состоит из направления (IN или OUT) и действия (ACCEPT, DENY, REJECT). Можно также указать имя макроса. Макросы содержат предопределенные наборы правил и параметров. Правило можно отключить, добавив перед ним символ |.
Синтаксис правил:
[RULES]

DIRECTION ACTION [OPTIONS]
|DIRECTION ACTION [OPTIONS] # отключенное правило

DIRECTION MACRO(ACTION) [OPTIONS] # использование предопределённого макроса
Параметры, уточняющие условия применения правила, приведены в таблице Параметры правила межсетевого экрана.
⁠

Таблица 41.4. Параметры правила межсетевого экрана

Параметр
Описание
--dest <string>
Адрес назначения пакета. Можно указать IP-адрес, набор IP-адресов (+имя_набора), псевдоним IP-адреса, диапазон адресов или список адресов и сетей, разделённых запятыми. Не следует смешивать IPv4- и IPv6-адреса в одном списке
--dport <string>
Порт назначения TCP/UDP. Можно указать имя службы или номер порта в диапазоне 0-65535 (как определено в /etc/services), а также диапазон портов в формате начало:конец, например 80:85. Несколько портов или диапазонов можно перечислить через запятую
--icmp-type <string>
Тип ICMP-сообщения. Применяется только при соответствующем значении параметра протокола
--iface <string>
Сетевой интерфейс, к которому применяется правило. Для ВМ и контейнеров указывают имя ключа сетевой конфигурации, например net0. Для правил узла можно использовать произвольные строки
--log <alert | crit | debug | emerg | err | info | nolog | notice | warning>
Уровень журналирования для правила
--proto <string>
IP-протокол. Можно указать имя протокола, например tcp или udp, либо его номер согласно /etc/protocols
--source <string>
Исходный IP-адрес. Можно указать IP-адрес, набор IP-адресов (+имя_набора), псевдоним, диапазон адресов или список адресов и сетей, разделённых запятыми. Не следует смешивать IPv4- и IPv6-адреса в одном списке
--sport <string>
Исходный порт TCP/UDP. Можно указать имя службы или номер порта в диапазоне 0-65535, а также диапазон портов в формате начало:конец, например 80:85. Несколько портов или диапазонов можно перечислить через запятую
Примеры:
[RULES]
IN SSH(ACCEPT) -i net0
IN SSH(ACCEPT) -i net0 # комментарий
IN SSH(ACCEPT) -i net0 -source 192.168.0.192 # разрешить SSH только из 192.168.0.192
IN SSH(ACCEPT) -i net0 -source 10.0.0.1-10.0.0.10 # разрешить SSH для диапазона IP
IN SSH(ACCEPT) -i net0 -source 10.0.0.1,10.0.0.2,10.0.0.3 # разрешить SSH для списка IP-адресов
IN SSH(ACCEPT) -i net0 -source +mynetgroup # разрешить SSH для набора mynetgroup
IN SSH(ACCEPT) -i net0 -source myserveralias # разрешить SSH для псевдонима myserveralias

|IN SSH(ACCEPT) -i net0 # отключенное правило

IN  DROP # отбросить все входящие пакеты
OUT ACCEPT # принять все исходящие пакеты
Для добавления правила в веб-интерфейсе необходимо перейти в раздел Сетевой экран (например, Центр обработки данных → Сетевой экран), нажать кнопку Добавить, в открывшемся окне задать параметры правила и нажать кнопку Добавить:
Создание правила

⁠41.2.5. Группы безопасности

Группа безопасности — это набор правил, определенных в конфигурации межсетевого экрана кластера и доступных для использования в правилах ВМ и контейнеров.
Например, можно создать группу webserver, содержащую правила для разрешения HTTP- и HTTPS-трафика:
# /etc/pve/firewall/cluster.fw

[group webserver]
IN ACCEPT -p tcp -dport 80
IN ACCEPT -p tcp -dport 443
Затем эту группу можно подключить к конфигурации межсетевого экрана ВМ:
# /etc/pve/firewall/<VMID>.fw

[RULES]
GROUP webserver
Создание и использование группы безопасности в веб-интерфейсе:
  1. Перейти в раздел Центр обработки данных → Сетевой экран → Группа безопасности;
  2. В секции Группа нажать кнопку Создать, в открывшемся окне ввести название группы и нажать кнопку Создать:
    Создание группы безопасности
  3. Выбрать созданную группу безопасности.
  4. В секции Правила нажать кнопку Добавить, в открывшемся окне установить параметры правила и нажать кнопку Добавить:
    Добавление правила к группе безопасности
  5. Повторить п.3 для каждого правила, которое необходимо включить в группу.
    Правила группы безопасности webserver
  6. Перейти в раздел ВМ → Сетевой экран.
  7. Нажать кнопку Вставить: Группа безопасности, в открывшемся окне в поле Группа безопасности выбрать группу, установить отметку в поле Включить и нажать кнопку Добавить:
    Добавление правил группы безопасности к ВМ

⁠41.2.6. IP-псевдонимы

IP-псевдонимы упрощают настройку правил межсетевого экрана, позволяя связывать IP-адреса и сети с именами. Эти имена можно использовать:
  • в определениях наборов IP-адресов;
  • в параметрах source и dest правил межсетевого экрана.
IP-псевдоним local_network определяется автоматически. Чтобы просмотреть его значение и сведения об обнаруженной локальной сети, выполните команду:
# pve-firewall localnet
local hostname: pve01
local IP address: 192.168.0.186
network auto detect: 192.168.0.0/24
using detected local_network: 192.168.0.0/24

accepting corosync traffic from/to:
 - pve02: 192.168.0.90 (link: 0)
 - pve03: 192.168.0.70 (link: 0)
Межсетевой экран использует этот псевдоним при формировании правил, разрешающих трафик, необходимый для работы кластера, включая Corosync, API и SSH.
Значение local_network можно переопределить в секции [ALIASES] файла /etc/pve/firewall/cluster.fw. Если узел работает в публичной сети и не имеет других узлов в локальной сети, рекомендуется явно указать его IP-адрес, чтобы не использовать автоматически определённую сеть:
# /etc/pve/firewall/cluster.fw
[ALIASES]
local_network 192.168.0.186 # указать IP-адрес узла
Пример создания IP-псевдонима (Центр обработки данных → Сетевой экран → Псевдоним кнопка Добавить):
Создание псевдонима

⁠41.2.7. Наборы IP-адресов

Наборы IP-адресов (IPSet) позволяют объединять IP-адреса и сети в группы. В правилах межсетевого экрана на набор можно ссылаться с помощью +имя_набора, указывая его в параметре source или dest.
Следующий пример разрешает HTTP-трафик из набора IP-адресов управления:
IN HTTP(ACCEPT) -source +management
Пример создания набора IP-адресов в веб-интерфейсе:
  1. Перейти в раздел Центр обработки данных → Сетевой экран → IPSet;
  2. В секции IPSet нажать кнопку Создать, в открывшемся окне ввести название набора и нажать кнопку ОК:
    Создание набора IP-адресов
  3. Выбрать созданный набор.
  4. В секции IP/CIDR нажать кнопку Добавить, в открывшемся окне указать IP-адрес или сеть в формате CIDR и нажать кнопку Создать:
    Добавление сети в набор
  5. Повторить п.3 для добавления остальных IP-адресов и сетей.
    IP-адреса в наборе my_ip_set
  6. Перейти в раздел ВМ → Сетевой экран.
  7. Нажать кнопку Добавить, в открывшемся окне в поле Источник выбрать созданный набор, установить остальные параметры правила и нажать кнопку Добавить:
    Указание набора IP-адресов в правиле межсетевого экрана

⁠41.2.7.1. Стандартный набор IP-адресов management

Стандартный набор IP-адресов management применяется только к межсетевым экранам узлов, но не к межсетевым экранам виртуальных машин. Адресам из этого набора разрешается выполнять обычные задачи управления, включая доступ к веб-интерфейсу PVE, VNC, SPICE и SSH.
Локальная сеть кластера автоматически добавляется в набор с использованием псевдонима cluster_network. Это позволяет обеспечить межузловое взаимодействие, необходимое для работы кластера, в том числе обмен трафиком Corosync и SSH.
Пример содержимого файла /etc/pve/firewall/cluster.fw:
[IPSET management]
192.168.0.90
192.168.0.0/24

⁠41.2.7.2. Стандартный набор IP-адресов blacklist

Трафик с IP-адресов, включённых в стандартный набор blacklist, отбрасывается межсетевыми экранами узлов и ВМ.
Пример содержимого файла /etc/pve/firewall/cluster.fw:
[IPSET blacklist]
77.240.159.182
213.87.123.0/24

⁠41.2.7.3. Стандартный набор IP-адресов ipfilter-net*

Наборы ipfilter-net* к сетевым интерфейсам ВМ и используются главным образом для защиты от подмены IP-адресов. Если для интерфейса существует соответствующий набор, исходящий трафик с IP-адресом источника, не входящим в этот набор, отбрасывается.
Для контейнеров с настроенными IP-адресами соответствующие наборы, если они существуют или активированы с помощью общего параметра фильтрации IP-адресов на вкладке параметров межсетевого экрана, неявно включают настроенные IP-адреса контейнера.
Для ВМ и контейнеров эти наборы также неявно включают локальный IPv6-адрес канала, сформированный на основе MAC-адреса сетевого интерфейса. Это необходимо для работы протокола обнаружения соседей (NDP).
Пример содержимого файла /etc/pve/firewall/<VMID>.fw:
[IPSET ipfilter-net0] # разрешить на net0 только указанные IP-адреса
192.168.0.90

⁠41.2.8. Службы и команды

Межсетевой экран PVE использует на каждом узле две службы:
  • pve-firewall — служба, которая формирует и применяет правила межсетевого экрана;
  • pvefw-logger — служба для обработки и регистрации событий, передаваемых межсетевым экраном.
Для запуска и остановки службы pve-firewall можно использовать команду pve-firewall:
# pve-firewall start
# pve-firewall stop
Чтобы проверить состояние межсетевого экрана, выполните команду:
# pve-firewall status
Команда проверяет и компилирует правила межсетевого экрана. Если в конфигурации обнаружены ошибки, они отображаются в выводе команды.
Чтобы просмотреть сгенерированные правила iptables, выполните команду:
# iptables-save

⁠41.3. Правила по умолчанию

⁠41.3.1. Политика DROP/REJECT для входящего и исходящего трафика центра обработки данных

Если политика входящего или исходящего трафика межсетевого экрана установлена в DROP или REJECT, для всех узлов PVE в кластере по-прежнему разрешён следующий трафик:
  • трафик через интерфейс обратной петли (loopback);
  • пакеты, относящиеся к уже установленным соединениям;
  • трафик протокола IGMP;
  • TCP-трафик от узлов управления на порт 8006, необходимый для доступа к веб-интерфейсу;
  • TCP-трафик от узлов управления на порты 5900–5999, необходимый для работы веб-консоли VNC;
  • TCP-трафик от узлов управления на порт 3128 для подключений к прокси-серверу SPICE;
  • TCP-трафик от узлов управления на порт 22 для доступа по SSH;
  • TCP-трафик от узлов управления на порты 60000–60050, используемый для миграции виртуальных машин;
  • UDP-трафик в сети кластера на порты 5405–5412, используемый Corosync;
  • UDP-трафик с многоадресной рассылкой (multicast) в сети кластера;
  • ICMP-сообщения типов 3 (Destination Unreachable), 4 (Source Quench) и 11 (Time Exceeded).
Следующий трафик отбрасывается без регистрации в журнале, даже если ведение журнала включено:
  • TCP-пакеты с недопустимым состоянием соединения;
  • широковещательный (broadcast), многоадресный (multicast) и anycast-трафик, не связанный с Corosync, то есть не проходящий через порты 5405–5412;
  • TCP-трафик на порт 43;
  • UDP-трафик на порты 135 и 445;
  • UDP-трафик на порты 137–139;
  • UDP-трафик с исходного порта 137 на порты 1024–65535;
  • UDP-трафик на порт 1900;
  • TCP-трафик на порты 135, 139 и 445;
  • UDP-трафик с исходного порта 53.
Остальной трафик отбрасывается или отклоняется в соответствии с правилами межсетевого экрана и регистрируется в журнале. Поведение может зависеть от дополнительных параметров, заданных в разделе Сетевой экран → Параметры, например NDP, Фильтр SMURFS и Фильтр флагов TCP.
Параметры сетевого экрана узла
Чтобы просмотреть активные цепочки и правила межсетевого экрана, можно использовать команду:
# iptables-save
Вывод этой команды также включается в системный отчёт, который можно получить с помощью команды:
# pvereport

⁠41.3.2. Политика DROP/REJECT для входящего и исходящего трафика ВМ

Весь трафик к ВМ и контейнерам отбрасывается или отклоняется, за исключением трафика, разрешённого с учётом настроек DHCP, NDP, Router Advertisement, фильтрации по MAC-адресам и фильтрации по IP-адресам.
Правила отбрасывания и отклонения пакетов, заданные на уровне центра обработки данных, также применяются к ВМ и контейнерам. При этом исключения, разрешающие входящий и исходящий трафик узлов, на ВМ и контейнеры не распространяются.

⁠41.4. Ведение журнала

По умолчанию ведение журнала трафика, обрабатываемого правилами межсетевого экрана, отключено.
Чтобы включить ведение журнала, необходимо задать уровень журнала для входящего и/или исходящего трафика в разделе Сетевой экран → Параметры. Настройки можно задать отдельно для узла и для каждой ВМ или контейнера.
При включении журналирования регистрируются события, предусмотренные стандартными правилами межсетевого экрана PVE. Просматривать записи можно в разделе Сетевой экран → Журнал. При этом стандартные правила регистрируют не все отброшенные или отклонённые пакеты (см. Правила по умолчанию).
Параметр loglevel не влияет на количество регистрируемого отфильтрованного трафика. Он определяет значение LOGID, добавляемое в начало записи журнала для упрощения фильтрации и последующей обработки.
⁠

Таблица 41.5. Значения параметра loglevel

loglevel
LOGID
nolog
—
emerg
0
alert
1
crit
2
err
3
warning
4
notice
5
info
6
debug
7
Типичная запись журнала межсетевого экрана имеет следующий формат:
VMID LOGID CHAIN TIMESTAMP POLICY: PACKET_DETAILS
Для межсетевого экрана узла значение VMID равен 0.
Чтобы регистрировать пакеты, обработанные пользовательскими правилами межсетевого экрана, можно задавать уровень журналирования для каждого правила отдельно. Это позволяет управлять журналированием отдельных правил независимо от уровня, заданного для стандартных правил.
Уровень журналирования отдельного правила можно задать или изменить в веб-интерфейсе при создании или редактировании правила, а также с помощью соответствующих вызовов API pvesh.
Уровень журналирования также можно задать в файле конфигурации межсетевого экрана, добавив к правилу параметр -log <loglevel>.
Например, следующие правила эквивалентны:
IN REJECT -p icmp -log nolog
IN REJECT -p icmp
Следующее правило:
IN REJECT -p icmp -log debug
создаёт записи журнала с уровнем debug.

⁠41.5. Особенности IPv6

Межсетевой экран поддерживает несколько параметров, специфичных для IPv6. В отличие от IPv4, IPv6 не использует протокол ARP для обнаружения соседних узлов. Вместо него применяется протокол NDP (Neighbor Discovery Protocol), работающий на уровне IP. Для работы NDP используются локальные адреса канала (link-local), формируемые на основе MAC-адреса сетевого интерфейса.
По умолчанию параметр NDP включён как на уровне узла, так и на уровне виртуальной машины. Это позволяет отправлять и принимать пакеты, необходимые для обнаружения соседних узлов.
NDP используется не только для обнаружения соседних узлов, но и для автоматической настройки сетевых параметров и обнаружения маршрутизаторов.
Router Solicitation (запросы маршрутизатора) и принимать сообщения Router Advertisement (объявления маршрутизатора). Это позволяет использовать автоматическую настройку IPv6 без сохранения состояния (SLAAC).
При этом ВМ не разрешено отправлять объявления маршрутизатора, если не включён параметр Объявление маршрутизатора (radv: 1).
Для локальных адресов канала, необходимых NDP, можно также включить параметр Фильтр IP (ipfilter: 1). Он обеспечивает эффект, аналогичный созданию набора IP-адресов ipfilter-net* ipset для каждого сетевого интерфейса ВМ с включением соответствующего локального IPv6-адреса канала.

⁠41.6. Порты, используемые PVE

⁠

Таблица 41.6. Используемые порты

Порт
Функция
8006/TCP (HTTP/1.1 через TLS)
Веб-интерфейс PVE
5900–5999/TCP (WebSocket)
Доступ к консоли VNC
3128/TCP
Доступ к прокси-серверу SPICE
22/TCP
Доступ по SSH
111/UDP
Служба rpcbind
25/TCP (исходящий трафик)
Отправка почты (sendmail)
5405-5412/UDP
Трафик кластера Corosync
60000-60050/TCP
Живая миграция ВМ: передача памяти ВМ и данных локальных дисков

⁠41.7. Межсетевой экран на основе nftables

В качестве альтернативы pve-firewall предлагается proxmox-firewall — реализация межсетевого экрана PVE на основе более современного механизма nftables вместо iptables.

Важно

В настоящее время proxmox-firewall имеет статус технического предварительного просмотра (tech preview). Возможны ошибки и несовместимости с исходной реализацией межсетевого экрана. Эта реализация пока не предназначена для использования в производственной среде.
В proxmox-firewall используются те же файлы конфигурации и тот же формат конфигурационных данных, что и в pve-firewall. Поэтому при переключении можно использовать существующую конфигурацию. Функциональность обеих реализаций практически одинакова, за исключением следующих особенностей:
  • при использовании мостов Linux дополнительные мосты межсетевого экрана fwbrX не создаются. Для гостевых сетевых интерфейсов, подключённых к мостам OVS, такие мосты по-прежнему создаются;
  • для трафика гостевых систем действие REJECT пока не поддерживается: пакеты вместо отклонения отбрасываются;
  • при использовании параметров NDP, Router Advertisement или DHCP правила межсетевого экрана создаются независимо от политики по умолчанию;
  • правила межсетевого экрана для гостевых систем проверяются даже для соединений, записи о которых уже присутствуют в таблице отслеживания соединений (conntrack).
После установки параметра конфигурации nftables управление межсетевым экраном передаётся новой службе proxmox-firewall. Проверить её состояние можно командой:
# systemctl status proxmox-firewall
Также можно просмотреть сформированный набор правил. Следует проверить и то, что pve-firewall больше не создаёт правила iptables (см. раздел Службы и команды).
Чтобы вернуться к прежней реализации межсетевого экрана, достаточно установить значение параметра конфигурации nftables в 0.

⁠41.7.1. Использование nftables

Служба proxmox-firewall создаёт две таблицы nftables, которыми управляет: proxmox-firewall и proxmox-firewall-guests.
Если необходимо создать собственные правила, не входящие в конфигурацию межсетевого экрана PVE, для них можно создать отдельные таблицы. proxmox-firewall изменяет только таблицы, которые создаёт самостоятельно. Поэтому поведение межсетевого экрана можно расширять и настраивать, добавляя собственные таблицы с правилами.
Вместо команды pve-firewall для управления межсетевым экраном на основе nftables используется proxmox-firewall. Запускать и останавливать её можно с помощью systemctl:
# systemctl start proxmox-firewall
# systemctl stop proxmox-firewall
При остановке службы все созданные ею правила удаляются.
Чтобы проверить состояние межсетевого экрана, выполните команду:
# systemctl status proxmox-firewall

⁠41.7.2. Полезные команды

Просмотреть сформированный набор правил можно с помощью команды:
# nft list ruleset
Для отладки proxmox-firewall можно вывести команды, которые генерирует межсетевой экран, с помощью подкоманды compile. Кроме того, переменная окружения PVE_LOG позволяет выводить сообщения журнала в стандартный поток ошибок (STDERR). Это может быть полезно при диагностике проблем, возникающих во время формирования набора правил nftables.
Например:
# PVE_LOG=trace /usr/libexec/proxmox/proxmox-firewall compile > firewall.json
Набор правил nftables состоит из базового набора правил (skeleton ruleset), встроенного в исполняемый файл proxmox-firewall, и правил, сформированных на основе конфигурации межсетевого экрана. Получить базовый набор можно с помощью подкоманды skeleton:
# /usr/libexec/proxmox/proxmox-firewall skeleton
Вывод обеих команд можно передать непосредственно команде nft. Следующие команды позволяют заново создать весь набор правил nftables:
# /usr/libexec/proxmox/proxmox-firewall skeleton | nft -f -
# /usr/libexec/proxmox/proxmox-firewall compile | nft -j -f -
Для получения подробных сообщений от службы межсетевого экрана во время её работы можно создать переопределение конфигурации службы systemd:
# systemctl edit proxmox-firewall
В открывшемся редакторе добавьте следующие параметры:
[Service]
Environment="PVE_LOG=trace"
Уровень trace приводит к быстрому накоплению большого количества сообщений. Рекомендуется использовать его только для отладки. Менее подробные уровни журналирования — info и debug.
Для диагностики правил межсетевого экрана может быть полезно отслеживать прохождение пакетов через различные цепочки. Для этого пакетам, которые требуется отслеживать, задают значение 1 для параметра nftrace. Не рекомендуется включать отслеживание для всех пакетов. В следующем примере отслеживаются только пакеты ICMP.
Создайте файл со следующим содержимым:
#!/usr/sbin/nft -f
table bridge tracebridge
delete table bridge tracebridge

table bridge tracebridge {
    chain trace {
        meta l4proto icmp meta nftrace set 1
    }

    chain prerouting {
        type filter hook prerouting priority -350; policy accept;
        jump trace
    }

    chain postrouting {
        type filter hook postrouting priority -350; policy accept;
        jump trace
    }
}
Сохраните файл, сделайте его исполняемым и выполните один раз. В результате будут созданы соответствующие цепочки для отслеживания. Просматривать результаты можно в веб-интерфейсе (Сетевой экран → Журнал) или с помощью команды:
# nft monitor trace
В приведённом примере отслеживается трафик через все мосты. Обычно через них проходит трафик гостевых систем. Чтобы отслеживать трафик самого узла, необходимо создать аналогичные цепочки в таблице inet, а не bridge.

Примечание

Отслеживание может приводить к быстрому накоплению большого количества сообщений в журнале и значительно снижать производительность сетевого стека.
Удалить правила отслеживания можно командой:
# nft delete table bridge tracebridge

⁠Глава 42. Пользователи и их права

PVE поддерживает несколько областей аутентификации, в том числе Linux PAM, встроенную область аутентификации PVE, LDAP, Active Directory и OpenID Connect:
Выбор области аутентификации в веб-интерфейсе
Ролевая модель управления доступом позволяет назначать разрешения на объекты PVE (ВМ, хранилища, узлы и т. д.) и настраивать многоуровневый доступ.
PVE хранит данные пользователей в файле /etc/pve/user.cfg:
# cat /etc/pve/user.cfg
user:root@pam:1:0::::::
user:test@pve:1:0::::::
user:testuser@pve:1:0::::Just a test::
user:user@pam:1:0::::::

group:admin:user@pam::
group:testgroup:test@pve::
Запись о пользователе содержит его идентификатор, состояние учётной записи, срок действия и другие атрибуты, в том числе имя, фамилию, адрес электронной почты и комментарий. Членство в группах описывается отдельными записями.
Идентификатор пользователя включает имя пользователя и область аутентификациив и имеет формат <user>@<realm>.
ПВ стандартной конфигурации PVE предусмотрена учётная запись root@pam, соответствующая суперпользователю операционной системы. Удалить эту учётную запись нельзя. По умолчанию системные письма отправляются на адрес электронной почты, назначенный этому пользователю. Суперпользователь обладает неограниченными правами, поэтому для повседневного администрирования рекомендуется создавать дополнительные учётные записи с ограниченными правами.
Пользователь может входить в несколько групп. Для упрощения управления доступом рекомендуется назначать разрешения группам, а не отдельным пользователям, когда это соответствует принятой модели разграничения доступа

⁠42.1. API-токены

API-токены позволяют аутентифицироваться при обращении к REST API из внешних приложений и систем без передачи пароля пользователя. Для каждого пользователя можно создавать отдельные токены. Токенам можно назначать собственные разрешения и задавать срок действия, чтобы ограничить объём и продолжительность доступа. Если токен скомпрометирован, его можно отозвать, не отключая учётную запись пользователя.
API-токены бывают двух типов:
  • токен с разделением привилегий — для него необходимо явно назначить разрешения с помощью списков контроля доступа (ACL). Эффективные разрешения токена определяются пересечением разрешений пользователя и разрешений, назначенных токену;
  • токен с полными привилегиями — обладает теми же разрешениями, что и связанный с ним пользователь.
API-токен состоит из двух частей:
  • идентификатора токена (Token ID), включающего идентификатор пользователя, область аутентификации и имя токена: user@realm!tokenid;
  • секрета — секретного значения, используемого для аутентификации.
Для создания API-токена в веб-интерфейсе необходимо в окне Центр обработки данных → Разрешения → Токены API нажать кнопку Добавить. В открывшемся окне следует выбрать пользователя и указать идентификатор токена:
Генерация API-токена в веб-интерфейсе

Примечание

Если необходимо, чтобы токен наследовал все разрешения пользователя, снимите отметку Разделение привилегий. В противном случае токену необходимо явно назначить разрешения ACL. Подробнее см. Управление доступом.
После нажатия кнопки Добавить будет создан API-токен:
PVE. API-токен
Отображаеммый секрет токена необходимо сохранить.

Примечание

Секрет токена отображается только один раз — при его создании. Впоследствии получить его повторно через API нельзя

Примечание

Можно повторно сгенерировать секрет существующего API-токена, не удаляя сам токен (кнопка Сгенерировать секрет заново). Это позволяет выполнить ротацию секрета, например, в случае компрометации токена, при этом связанные с токеном записи ACL сохраняются.
Если создан токен разделением привилегий, ему необходимо назначить разрешения:
  1. В окне Центр обработки данных → Разрешения нажать кнопку Добавить → Разрешения токена API:
    PVE. Добавление разрешений
  2. В открывшемся окне указать путь, токен и роль и нажать кнопку Добавить:
    Назначение разрешений API-токену
Для создания API-токена в консоли используется команда:
# pveum user token add <userid> <tokenid> [ОПЦИИ]
Доступные параметры:
  • --comment <строка> — комментарий к токену;
  • --expire <целое число> — время истечения срока действия API-токена в секундах с начала эпохи Unix. По умолчанию срок действия API-токена совпадает со сроком действия пользователя. Значение 0 означает отсутствие ограничения срока действия токена;
  • --privsep <логическое значение> —  определяет, используется ли разделение привилегий. Значение 1 включает разделение привилегий (по умолчанию), а значение 0 позволяет токену использовать разрешения связанного с ним пользователя.
Примеры команд для работы с токенами:
  • создать токен t2 для пользователя user@pam без разделения привилегий:
    # pveum user token add user@pam t2 --privsep 0
    ┌──────────────┬──────────────────────────────────────┐
    │ key          │ value                                │
    ╞══════════════╪══════════════════════════════════════╡
    │ full-tokenid │ user@pam!t2                          │
    ├──────────────┼──────────────────────────────────────┤
    │ info         │ {"privsep":"0"}                      │
    ├──────────────┼──────────────────────────────────────┤
    │ value        │ 3c749375-e189-493d-8037-a1179317c406 │
    └──────────────┴──────────────────────────────────────┘
    
  • вывести список токенов пользователя:
    # pveum user token list user@pam
    ┌─────────────┬─────────┬────────┬─────────┐
    │ tokenid     │ comment │ expire │ privsep │
    ╞═════════════╪═════════╪════════╪═════════╡
    │ monitoring  │         │      0 │ 1       │
    ├─────────────┼─────────┼────────┼─────────┤
    │ t2          │         │      0 │ 0       │
    └─────────────┴─────────┴────────┴─────────┘
    
  • вывести эффективные разрешения токена:
    # pveum user token permissions user@pam t2
    
    Можно использовать опцию --path, чтобы вывести разрешения только для определённого пути, а не всё дерево разрешений:
    # pveum user token permissions user@pam t2 --path /storage
    
  • назначить разрешения токену с разделением привилегий:
    # pveum acl modify /vms --tokens 'user@pam!monitoring' --roles PVEAdmin,PVEAuditor
    
  • удалить токен пользователя:
    # pveum user token remove user@pam t2
    

Примечание

Разрешения API-токена не могут превышать разрешения соответствующего пользователя. Поэтому токен нельзя использовать для выполнения действий, на которые у пользователя нет разрешений.
Пример:
  1. Назначить пользователю test@pve роль PVEVMAdmin для всех ВМ:
    # pveum acl modify /vms --users test@pve --roles PVEVMAdmin
    
  2. Создать API-токен с разделением привилегий
    # pveum user token add test@pve monitoring --privsep 1
    
  3. Назначить токену права на просмотр информации о ВМ:
    # pveum acl modify /vms --tokens 'test@pve!monitoring' --roles PVEAuditor
    
  4. Проверить разрешения пользователя и API-токена:
    # pveum user permissions test@pve
    # pveum user token permissions test@pve monitoring
    
Для аутентификации с помощью API-токена в HTTP-запросе необходимо указать заголовок Authorization со значением следующего формата:
PVEAPIToken=USER@REALM!TOKENID=UUID

⁠42.2. Пулы ресурсов

Пул ресурсов — это логическая группа ВМ, контейнеров и хранилищ. Пулы ресурсов позволяют назначать разрешения на группу объектов, а не на каждый объект отдельно. Пулы ресурсов можно использовать совместно с группами пользователей, чтобы предоставлять членам группы доступ к определённому набору ВМ, контейнеров и хранилищ.
Пример создания пула ресурсов в веб-интерфейсе:
  1. В окне Центр обработки данных → Разрешения → Пулы нажать кнопку Создать. В открывшемся окне указать название пула и нажать кнопку ОК:
    Создание пула ресурсов в веб-интерфейсе
  2. Добавить ВМ в пул. Для этого выбрать пул, перейти на вкладку Члены, нажать кнопку Добавить → Виртуальная машина, выбрать ВМ и нажать кнопку Добавить:
    Добавление ВМ в пул ресурсов
  3. Добавить хранилища в пул. Для этого выбрать пул, перейти на вкладку Члены, нажать кнопку Добавить → Хранилище, выбрать хранилище и нажать кнопку Добавить:
    Добавление хранилища в пул ресурсов
Управление пулами ресурсов из командной строки:
  • создать пул:
    # pveum pool add IT --comment 'IT development pool'
    
  • вывести список пулов:
    # pveum pool list
    ┌────────┬─────────────────────┬─────────┐
    │ poolid │ comment             │ members │
    ╞════════╪═════════════════════╪═════════╡
    │ IT     │ IT development pool │         │
    ├────────┼─────────────────────┼─────────┤
    │ mypool │                     │         │
    └────────┴─────────────────────┴─────────┘
    
  • добавить ВМ и хранилища в пул:
    # pveum pool modify IT --vms 201,108,202,104,208 --storage mpath2,nfs-storage
    
  • удалить ВМ из пула:
    # pveum pool modify IT --delete 1 --vms 108,104
    
  • удалить пул:
    # pveum pool delete IT
    

Примечание

Удалить можно только пустой пул, не содержащий ресурсов.

⁠42.3. Области аутентификации

PVE поддерживает следующие области аутентификации:
  • Linux PAM (Стандартная аутентификация Linux PAM) —  аутентификация с использованием системных учётных записей Linux;
  • PVE (Сервер аутентификации PVE) — встроенный сервер аутентификации PVE. Учётные записи и пароли управляются средствами PVE. Пользователи могут изменять свои пароли через графический интерфейс. Этот вариант подходит для небольших и средних установок, в которых пользователям не требуется доступ к внешним системам;
  • Сервер LDAP — аутентификация пользователей с использованием внешнего LDAP-сервера, например OpenLDAP;
  • Сервер Active Directory — аутентификация пользователей домена Active Directory с использованием LDAP;
  • Сервер OpenID Connect — проверка идентичности пользователей на основе аутентификации, выполняемой внешним сервером авторизации. OpenID Connect представляет собой уровень идентификации поверх протокола OAuth 2.0.
Настройки области аутентификации хранятся в файле /etc/pve/domains.cfg.

⁠42.3.1. Стандартная аутентификация Linux PAM

При использовании Linux PAM системная учётная запись пользователя должна существовать на каждом узле PVE, на котором пользователю разрешён вход в систему. Для доступа к PVE необходимо также добавить соответствующую учётную запись в конфигурацию пользователей PVE. При входе пользователь указывает системное имя пользователя и пароль.
Область Linux PAM создается по умолчанию и не может быть удалена. Администратор может включить обязательную двухфакторную аутентификацию для пользователей данной области (Требовать двухфакторную проверку подлинности) и назначить её используемой по умолчанию при входе в систему (По умолчанию):
Настройка аутентификации Linux PAM
Для добавления пользователя необходимо в окне Центр обработки данных → Разрешения → Пользователи нажать кнопку Добавить.
Создание пользователя с использованием Linux PAM
При создании пользователя с использованием Linux PAM необходимо указать имя существующей системной учётной записи. Для аутентификации будет использоваться пароль этой учётной записи.

⁠42.3.2. Сервер аутентификации PVE

Область аутентификации PVE использует хранилище паролей в формате, аналогичном Unix. Хеши паролей хранятся в файле /etc/pve/priv/shadow.cfg и формируются с использованием алгоритма SHA-256. Пользователи управляются средствами PVE и могут изменять свои пароли через графический интерфейс.
Область создается по умолчанию. Администратор может включить обязательную двухфакторную аутентификацию для пользователей данной области (Требовать двухфакторную проверку подлинности) и назначить её используемой по умолчанию при входе в систему (По умолчанию):
Настройка аутентификации PVE
Создание пользователя с использованием аутентификации PVE:
Создание пользователя с использованием аутентификации PVE
Примеры использования командной строки для управления пользователями PVE:
  • создать пользователя:
    # pveum useradd testuser@pve -comment "Just a test"
    
  • задать или изменить пароль:
    # pveum passwd testuser@pve
    
  • отключить пользователя:
    # pveum usermod testuser@pve -enable 0
    
  • создать новую группу:
    # pveum groupadd testgroup
    
  • создать новую роль:
    # pveum roleadd VM_Power-only -privs "VM.PowerMgmt VM.Console"
    

⁠42.3.3. LDAP-аутентификация

В данном разделе приведён пример настройки аутентификации пользователей PVE с использованием LDAP-сервера FreeIPA.
В примере используются следующие исходные данные:
  • ipa.example.test, 192.168.0.113 — сервер FreeIPA;
  • admin@example.test — учётная запись с правами чтения LDAP-каталога;
  • pve — членам которой необходимо предоставить доступ к PVE.
Для настройки аутентификации LDAP необходимо выполнить следующие действия:
  1. Создать область аутентификации LDAP. Для этого в разделе Центр обработки данных → Разрешения → Области нажать кнопку Добавить → Сервер LDAP:
    Создание области аутентификации LDAP
  2. На вкладке Общее указать следующие данные:
    • Область — идентификатор области аутентификации;
    • Имя основного домена (base_dn) — базовое имя каталога, от которого выполняется поиск пользователей (dc=example,dc=test);
    • Атрибут имени пользователя (user_attr) — атрибут LDAP, значение которого используется в качестве имени пользователя при входе (uid);
    • По умолчанию — назначить область используемой по умолчанию при входе в систему;
    • Сервер — IP-адрес или DNS-имя сервера FreeIPA (192.168.0.113 или ipa.example.test);
    • Резервный сервер (опционально) — адрес резервного LDAP-сервера, если он предусмотрен;
    • Порт — порт, на котором сервер принимает LDAP-подключения (обычно 389 для LDAP, 636 для LDAP поверх TLS);
    • Режим — режим подключения к LDAP-серверу;
    • Требовать двухфакторную проверку подлинности — включить обязательную двухфакторную аутентификацию для пользователей данной области.
    Настройка аутентификации FreeIPA (вкладка Общее)
  3. На вкладке Параметры синхронизации заполнить следующие поля (в скобках указаны значения, используемые в данном примере):
    • Пользователь привязки — имя учётной записи, используемой для подключения к LDAP-каталогу (uid=admin,cn=users,cn=accounts,dc=example,dc=test);
    • Пароль привязки — пароль учётной записи, указанной в поле Пользователь привязки. Пароль сохраняется в файле /etc/pve/priv/realm/<realmname>.pw;
    • Атрибут электронной почты (опционально) — атрибут LDAP, содержащий адрес электронной почты пользователя;
    • Атрибут имени группы — атрибут LDAP, содержащий имя группы (cn);
    • Классы пользователей — классы объектов LDAP, соответствующих пользователям (person);
    • Классы групп —  классы объектов LDAP, соответствующих группам (posixGroup);
    • Фильтр пользователей — LDAP-фильтр для выбора пользователей, которых необходимо синхронизировать (memberOf=cn=pve,cn=groups,cn=accounts,dc=example,dc=test);
    • Фильтр групп — LDAP-фильтр для выбора групп, которые необходимо синхронизировать ((|(cn=*pve*)(dc=ipa)(dc=example)(dc=test)));
    Настройка аутентификации FreeIPA (вкладка Параметры синхронизации)
  4. Нажать кнопку Добавить.
  5. Выбрать созданную область аутентификации и нажать кнопку Синхронизировать:
    Кнопка Синхронизировать
  6. При необходимости указать дополнительные параметры синхронизации и нажать кнопку Синхронизировать:
    Параметры синхронизации области аутентификации
    В результате синхронизации выбранные пользователи и группы из каталога FreeIPA добавляются в конфигурацию PVE или обновляются в ней в соответствии с заданными параметрами синхронизации. Сведения о пользователях и группах можно просмотреть на вкладках Пользователи и Группы.
  7. Настроить необходимые разрешения для синхронизированных пользователей и групп на вкладке Разрешения.

Примечание

Для синхронизации пользователей и групп из командной строки можно выполнить команду:
# pveum realm sync example.test --scope both
Значение example.test должно совпадать с идентификатором области аутентификации, заданным в PVE. Параметр --scope both указывает на синхронизацию пользователей и групп.
Для автоматической синхронизации можно создать задание синхронизации области. Для этого необходимо перейти в Центр обработки данных → Разрешения → Области и в разделе Задания синхронизации области нажать кнопку Добавить:
Создание задания синхронизации области аутентификации

⁠42.3.4. Аутентификация AD

В данном разделе приведён пример настройки аутентификации пользователей PVE с использованием AD.
В примере используются следующие исходные данные:
  • dc1.test.alt, 192.168.0.132 — сервер AD;
  • administrator@test.alt — учётная запись администратора домена. В рабочей среде рекомендуется использовать отдельную учётную запись, которой предоставлены только необходимые для чтения каталога права, вместо учётной записи администратора домена;
  • office — группа, членам которой необходимо предоставить доступ к PVE.
Для настройки AD-аутентификации необходимо выполнить следующие действия:
  1. Создать область аутентификации AD (в разделе Центр обработки данных → Разрешения → Области нажать кнопку Добавить → Сервер Active Directory):
    Создание области аутентификации AD
  2. На вкладке Общее указать следующие данные:
    • Область — идентификатор области аутентификации;
    • Домен — DNS-имя домена AD (test.alt);
    • С учётом регистра — учитывать регистр символов в имени пользователя;
    • По умолчанию — назначить область используемой по умолчанию при входе в систему;
    • Сервер — IP-адрес или DNS-имя сервера (192.168.0.132 или dc1.test.alt);
    • Резервный сервер (опционально) — адрес резервного сервера, если он предусмотрен;
    • Порт — порт, на котором сервер AD принимает LDAP-подключения (обычно 389 для LDAP, 636 для LDAP поверх TLS);
    • Режим — режим подключения к LDAP-серверу;
    • Требовать двухфакторную проверку подлинности — включить обязательную двухфакторную аутентификацию для пользователей данной области.
    Настройка аутентификации AD (вкладка Общее)
  3. На вкладке Параметры синхронизации заполнить следующие поля (в скобках указаны значения, используемые в данном примере):
    • Пользователь привязки — имя учётной записи, используемой для подключения к AD (cn=Administrator,cn=Users,dc=test,dc=alt);
    • Пароль привязки — пароль учётной записи, указанной в поле Пользователь привязки. Пароль сохраняется в файле /etc/pve/priv/realm/<realmname>.pw;
    • Атрибут электронной почты (опционально) — атрибут LDAP, содержащий адрес электронной почты пользователя;
    • Атрибут имени группы — атрибут LDAP, содержащий имя группы (cn);
    • Классы пользователей — классы объектов AD, соответствующих пользователям;
    • Классы групп — классы объектов AD, соответствующих группам;
    • Фильтр пользователей — LDAP-фильтр для выбора пользователей, которых необходимо синхронизировать ((&(objectclass=user)(samaccountname=*)(MemberOf=CN=office,ou=OU,dc=TEST,dc=ALT)));
    • Фильтр групп — LDAP-фильтр для выбора групп, которые необходимо синхронизировать ((|(cn=*office*)(dc=dc)(dc=test)(dc=alt)));
    Настройка аутентификации AD (вкладка Параметры синхронизации)
  4. Нажать кнопку Добавить.
  5. Выбрать созданную область аутентификации и нажать кнопку Синхронизировать.
  6. При необходимости указать дополнительные параметры синхронизации и нажать кнопку Синхронизировать:
    Параметры синхронизации области аутентификации
    В результате синхронизации выбранные пользователи и группы из AD добавляются в конфигурацию PVE или обновляются в ней в соответствии с заданными параметрами синхронизации. Сведения о пользователях и группах можно просмотреть на вкладках Пользователи и Группы.
  7. Настроить необходимые разрешения для синхронизированных пользователей и групп на вкладке Разрешения.

Примечание

Для синхронизации пользователей и групп из командной строки можно выполнить команду:
# pveum realm sync test.alt --scope both
Значение test.alt должно совпадать с идентификатором области аутентификации, заданным в PVE. Параметр --scope both указывает на синхронизацию пользователей и групп.
Для автоматической синхронизации можно создать задание синхронизации области. Для этого необходимо перейти в Центр обработки данных → Разрешения → Области и в разделе Задания синхронизации области нажать кнопку Добавить:
Создание задания синхронизации области аутентификации

⁠42.4. Двухфакторная аутентификация

В PVE предусмотрены два сценария настройки двухфакторной аутентификации (ДФА):
  • Обязательная ДФА — включается при настройке области аутентификации. Пользователи этой области должны настроить второй фактор, чтобы иметь возможность входить в систему. Новому пользователю необходимо настроить второй фактор до первого входа, поскольку вход без него невозможен.
    Чтобы включить обязательную двухфакторную аутентификацию, добавьте или отредактируйте область аутентификации и установите соответствующий параметр:
    PVE. Настройка двухфакторной аутентификации при редактировании области
  • Самостоятельная настройка ДФА пользователем — пользователь может настроить второй фактор независимо от того, включено ли требование обязательной ДФА для соответствующей области аутентификации.
    Для настройки ДФА пользователь может выбрать пункт TFA в раскрывающемся списке пользователя:
    PVE. Настройка двухфакторной аутентификации пользователем
    И затем выбрать тип ДФА:
    PVE. Настройка двухфакторной аутентификации пользователем
При добавлении в области аутентификации доступны следующие методы двухфакторной аутентификации:
  • OATH/TOTP — метод аутентификации на основе одноразовых паролей, генерируемых с учётом времени. Для формирования кода используется алгоритм TOTP, основанный на HOTP и обычно применяющий HMAC-SHA-1. Параметры временного шага и длины кода могут настраиваться:
    PVE. Основанная на времени OATH (TOTP)
    У пользователя может быть настроено несколько ключей (разделенных пробелами), и ключи могут быть указаны в Base32 (RFC3548) или в шестнадцатеричном представлении.
    Для генерации ключей PVE предоставляет инструмент oathkeygen, который выводит случайный ключ в кодировке Base32. Ключ можно использовать с совместимыми приложениями и инструментами, например oathtool или FreeOTP.
  • Yubico (YubiKey OTP) — метод аутентификации с использованием аппаратного ключа YubiKey. Для его настройки необходимо указать идентификатор API Yubico, ключ API и URL-адрес сервера проверки. У пользователя должен быть доступен совместимый ключ YubiKey.
    Чтобы получить идентификатор ключа, подключите YubiKey к USB-порту и активируйте его. Скопируйте первые 12 символов сформированного одноразового пароля в поле идентификатора ключа пользователя.
Помимо перечисленных методов, пользователям доступны следующие методы двухфакторной аутентификации:
  • TOTP — одноразовый пароль, генерируемый с учётом времени. Код обычно обновляется каждые 30 секунд;
  • WebAuthn (веб-аутентификация) — веб-аутентификация с использованием совместимых устройств, например аппаратных ключей безопасности или встроенных средств аутентификации платформы. Для работы WebAuthn требуется HTTPS-соединение с действительным сертификатом;
  • Ключи восстановления (Recovery Keys) — набор одноразовых кодов, каждый из которых можно использовать только один раз. Пользователю предоставляется один набор таких кодов. Ключи восстановления позволяют войти в систему, если другие средства двухфакторной аутентификации недоступны.

Примечание

Если для области аутентификации применяется YubiKey OTP, пользователи не могут использовать TOTP или WebAuthn в качестве второго фактора при входе в систему.

Примечание

Чтобы снизить риск потери доступа при утрате устройства или средства аутентификации, рекомендуется настроить несколько доступных вторых факторов для одной учётной записи:
PVE. Несколько настроенных вторых факторов для учётной записи
Настройка TOTP:
  • для настройки TOTP добавьте соответствующий метод двухфакторной аутентификации в настройках пользователя:
    PVE. Настройка аутентификации TOTP
  • при входе в веб-интерфейс после ввода имени пользователя и пароля укажите одноразовый код, сформированный приложением-аутентификатором:
    PVE. Запрос второго фактора (TOTP) при аутентификации пользователя в веб-интерфейсе
Настройка ключей восстановления:
  • создайте набор ключей восстановления в настройках двухфакторной аутентификации пользователя:
    PVE. Настройка аутентификации Recovery Keys
  • при входе в систему введите один из неиспользованных ключей восстановления, если основной метод двухфакторной аутентификации недоступен:
    PVE. Запрос второго фактора (Recovery Key) при аутентификации пользователя в веб-интерфейсе
При восьми неудачных попытках ввода TOTP-кода двухфакторная аутентификация с использованием TOTP блокируется для пользователя. Разблокировать её можно с помощью ключа восстановления. Если TOTP был единственным доступным вторым фактором и ключи восстановления не настроены либо недоступны, потребуется вмешательство администратора.
Администратор может разблокировать двухфакторную аутентификацию пользователя через веб-интерфейс:
PVE. Разблокировка двухфакторной аутентификации
Для разблокировки из командной строки выполните команду:
# pveum user tfa unlock orlov@test.alt

Важно

После разблокировки рекомендуется немедленно сменить пароль пользователя.
Методы Webauthn и ключи восстановления менее уязвимы к атакам методом подбора. Для этих методов допустимо до 100 неудачных попыток. При превышении установленного лимита вторые факторы блокируются на один час.

⁠42.5. Управление доступом

Чтобы пользователь мог выполнять действия в PVE, например просматривать, изменять или удалять ВМ, ему необходимо предоставить соответствующие разрешения.
PVE использует ролевую модель управления доступом, основанную на путях к объектам. Запись в таблице разрешений назначает пользователю, группе или API-токену роль для указанного пути. Таким образом, правило доступа задаётся сочетанием пути, субъекта доступа и роли. Роль определяет набор привилегий, доступных субъекту при обращении к соответствующему объекту.
Роль — это набор привилегий. В PVE предусмотрены встроенные роли, предназначенные для выполнения типовых административных задач:
  • Administrator — полный набор привилегий;
  • NoAccess — роль без привилегий, используемая для ограничения доступа;
  • PVEAdmin — выполнение большинства административных операций, за исключением изменения системных настроек (Sys.PowerMgmt, Sys.Modify, Realm.Allocate) и разрешений (Permissions.Modify);
  • PVEAuditor — доступ только для чтения;
  • PVEDatastoreAdmin — создание и выделение места для резервного копирования и шаблонов;
  • PVEDatastoreUser — просмотр хранилищ и выделение места для резервного копирования;
  • PVEMappingAdmin — управление сопоставлениями ресурсов;
  • PVEMappingUser — просмотр и использование сопоставлений ресурсов;
  • PVEPoolAdmin — управление пулами ресурсов;
  • PVEPoolUser — просмотр пулов ресурсов;
  • PVESDNAdmin — управление конфигурацией SDN;
  • PVESDNUser — доступ к мостам и виртуальным сетям SDN;
  • PVESysAdmin — просмотр системной информации, доступ к системной консоли и журналам;
  • PVETemplateUser — просмотр и клонирование шаблонов;
  • PVEUserAdmin — управление пользователями;
  • PVEVMAdmin — управление ВМ;
  • PVEVMUser — просмотр ВМ, резервное копирование, управление виртуальным CD/DVD-приводом, доступ к консоли и управление питанием ВМ.
Просмотреть список встроенных ролей в веб-интерфейсе можно, выбрав Центр обработки данных → Разрешения → Роли:
Список предопределенных ролей
Создать пользовательскую роль можно:
  • в веб-интерфейсе: Центр обработки данных → Разрешения → Роли нажать кнопку Создать:
    Добавление роли Sys_Power-only
  • в командной строке:
    # pveum role add VM_Power-only --privs "VM.PowerMgmt VM.Console"
    

Примечание

Имена встроенных ролей с префиксом PVE зарезервированы. Пользовательские роли не должны использовать этот префикс.
Привилегия — право на выполнение определенного действия. Для упрощения управления привилегии объединены в роли, которые назначаются пользователям, группам или API-токенам через таблицу разрешений. Отдельные привилегии напрямую субъектам доступа не назначаются: они предоставляются в составе роли.
⁠

Таблица 42.1. Привилегии, используемые в PVE

Привилегия
Описание
Привилегии узла/системы
Group.Allocate
Создание/удаление/изменение групп
Mapping.Audit
Просмотр сопоставлений ресурсов
Mapping.Modify
Управление сопоставлениями ресурсов
Mapping.Use
Использование сопоставлений ресурсов
Permissions.Modify
Изменение прав доступа
Pool.Allocate
Создание/удаление/изменение пулов
Pool.Audit
Просмотр пула
Realm.Allocate
Создание/удаление/изменение областей аутентификации
Realm.AllocateUser
Создание пользователей в области аутентификации
SDN.Allocate
Управление конфигурацией SDN
SDN.Audit
Просмотр конфигурации SDN
Sys.AccessNetwork
Просмотр информации о сетевых интерфейсах, использование сетевых ресурсов
Sys.Audit
Просмотр состояния и конфигурации узла, конфигурации Corosync и HA
Sys.Console
Консольный доступ к узлу
Sys.Incoming
Разрешение приёма потоков данных из других кластеров (экспериментальная привилегия)
Sys.Modify
Изменение конфигурации узла
Sys.PowerMgmt
Управление питанием узла (запуск, остановка, сброс, выключение)
Sys.Syslog
Просмотр Syslog
User.Modify
Создание/удаление/изменение пользователя
Права, связанные с ВМ
SDN.Use
Доступ к виртуальным сетям SDN и локальным сетевым мостам
VM.Allocate
Создание/удаление ВМ
VM.Audit
Просмотр конфигурации ВМ
VM.Backup
Резервное копирование/восстановление ВМ
VM.Clone
Клонирование/копирование ВМ
VM.Config.CDROM
Извлечение и изменение настроек виртуального CD/DVD-привода
VM.Config.CPU
Изменение настроек процессора
VM.Config.Cloudinit
Изменение параметров Cloud-init
VM.Config.Disk
Добавление/изменение/удаление дисков ВМ
VM.Config.HWType
Изменение типа виртуального оборудования
VM.Config.Memory
Изменение настроек памяти
VM.Config.Network
Добавление/изменение/удаление сетевых устройств
VM.Config.Options
Изменение любой другой конфигурации ВМ
VM.Console
Консольный доступ к ВМ
VM.GuestAgent.Audit
Выполнение информационных команд QEMU Guest Agent
VM.GuestAgent.FileRead
Чтение файлов в гостевой системе через QEMU Guest Agent
VM.GuestAgent.FileSystemMgmt
Замораживание, размораживание и выполнение TRIM для файловых систем гостевой ОС через QEMU Guest Agent
VM.GuestAgent.FileWrite
Запись файлов в гостевой системе через QEMU Guest Agent
VM.GuestAgent.Unrestricted
Выполнение произвольных команд QEMU Guest Agent без ограничений
VM.Migrate
Миграция ВМ на другой узел кластера
VM.PowerMgmt
Управление питанием (запуск, остановка, сброс, выключение)
VM.Replicate
Настройка и выполнение репликации гостевой ВМ
VM.Snapshot.Rollback
Откат ВМ к одному из её снимков
VM.Snapshot
Создание/удаление снимков ВМ
Права, связанные с хранилищем
Datastore.Allocate
Создание/удаление/изменение хранилища данных
Datastore.AllocateSpace
Выделение места в хранилище
Datastore.AllocateTemplate
Размещение шаблонов контейнеров и ISO-образов в хранилище
Datastore.Audit
Просмотр хранилища данных

Примечание

Следует внимательно обращаться с правами Permissions.Modify и Sys.Modify, так как они позволяют изменять важные и конфиденциальные аспекты системы и ее конфигурации.
Права доступа назначаются объектам, таким как ВМ, хранилища или пулы ресурсов. PVE использует файловую систему как путь к этим объектам. Эти пути образуют естественное дерево, и права доступа более высоких уровней (более короткий путь) могут распространяться вниз по этой иерархии.
Путь может представлять шаблон. Когда API-вызов требует разрешений на шаблонный путь, путь может содержать ссылки на параметры вызова API. Эти ссылки указываются в фигурных скобках. Некоторые параметры неявно берутся из URI вызова API. Например, путь /nodes/{node} при вызове /nodes/pve01/status требует разрешений на /nodes/pve01, в то время как путь {path} в запросе PUT к /access/acl ссылается на параметр метода path.
Примеры:
  • /nodes/{node} — доступ к узлам PVE;
  • /vms — распространяется на все ВМ;
  • /vms/{vmid} — доступ к определенным ВМ;
  • /storage/{storeid} — доступ к определенным хранилищам;
  • /pool/{poolid} — доступ к ресурсам из определенного пула ресурсов;
  • /access/groups — администрирование групп;
  • /access/realms/{realmid} — административный доступ к области аутентификации.
Используются следующие правила наследования:
  • разрешения для отдельных пользователей всегда заменяют разрешения для групп;
  • разрешения для групп применяются, если пользователь является членом этой группы;
  • разрешения на более глубоких уровнях перекрывают разрешения, унаследованные от верхнего уровня;
  • NoAccess отменяет все другие роли на данном пути.
Кроме того, токены с разделением привилегий (см. API-токены) не могут обладать разрешениями на пути, которых нет у связанного с ними пользователя.
Для назначения разрешений необходимо в окне Центр обработки данных → Разрешения нажать кнопку Добавить, в раскрывающемся списке выбрать Разрешения группы, если разрешения назначаются группе пользователей, или Разрешения пользователя, если разрешения назначаются пользователю:
Добавление разрешений
Далее в открывшемся окне выбрать путь, группу и роль и нажать кнопку Добавить:
Добавление разрешений группе
Примеры работы с разрешениями в командной строке:
  • предоставить группе admin полные права администратора:
    # pveum acl modify / --groups admin --roles Administrator
    
  • предоставить пользователю test@pve доступ к ВМ только для чтения:
    # pveum acl modify /vms --users test@pve --roles PVEAuditor
    
  • делегировать управление пользователями пользователю test@pve:
    # pveum acl modify /access --users test@pve --roles PVEUserAdmin
    
  • разрешить пользователю orlov@test.alt изменять пользователей в области test.alt, если они являются членами группы office-test.alt:
    # pveum acl modify /access/realm/test.alt --users orlov@test.alt --roles PVEUserAdmin
    # pveum acl modify /access/groups/office-test.alt --users orlov@test.alt --roles PVEUserAdmin
    
  • разрешить пользователям группы developers администрировать ресурсы, назначенные пулу IT:
    # pveum acl modify /pool/IT/ --groups developers --roles PVEAdmin
    
  • удалить у пользователя test@pve право на просмотр ВМ:
    # pveum acl delete /vms --users test@pve --roles PVEAuditor
    

Примечание

Назначение привилегий на токены см. в разделе API-токены.

⁠Глава 43. Просмотр задач и журналов PVE

При устранении неполадок сервера, например при сбоях резервного копирования, полезно просматривать журналы выполнения задач.
В PVE многие операции, например создание ВМ, выполняются в фоновом режиме. Такие операции представлены в виде задач. Для задач формируется журнал выполнения, который содержит информацию о ходе выполнения операции и её результате.
Просматривать список задач и их журналы можно с помощью команд pvenode task, а также через веб-интерфейс PVE.

⁠43.1. Просмотр задач с помощью pvenode task

Основные подкоманды pvenode task и их параметры приведены в таблице Команды pvenode task.
⁠

Таблица 43.1. Команды pvenode task

Команда
Описание
pvenode task list [Параметры]
Вывести список задач узла.
Параметры:
  • --errors <логическое значение> — показывать только задачи, завершившиеся с ошибкой (по умолчанию 0);
  • --limit <целое число> — максимальное количество выводимых задач (по умолчанию 50);
  • --since <целое число> — показывать задачи, начавшиеся не ранее указанной отметки времени в формате Unix time;
  • --source <active | all | archive> — выбрать источник задач: активные, все или архивные (по умолчанию archive);
  • --start <целое число> — смещение в списке задач, с которого начинается вывод (по умолчанию 0);
  • --statusfilter <строка> — фильтр по статусу задачи;
  • --typefilter <строка> — фильтр по типу задачи (например, vzstart или vzdump);
  • --until <целое число> — показывать задачи, начавшиеся не позднее указанной отметки времени в формате Unix time;
  • --userfilter <строка> — фильтр по имени пользователя, запустившего задачу;
  • --vmid <целое число> — фильтр по идентификатору ВМ
pvenode task log <upid> [Параметры]
Вывести журнал указанной задачи.
Параметры:
  • --start <целое число> — начать вывод журнала с указанной строки (по умолчанию 0)
pvenode task status <upid>
Вывести сведения о состоянии указанной задачи.

Примечание

UPID (Unique Process Identifier) — уникальный идентификатор задачи. Он имеет следующий формат:
UPID:$node:$pid:$pstart:$starttime:$dtype:$id:$user
Поля pid, pstart и starttime представлены в шестнадцатеричном формате. Поле starttime содержит время начала задачи в формате Unix time.
Примеры использования команд pvenode task:
  • вывести список задач ВМ с идентификатором 104, завершившихся с ошибкой:
    # pvenode task list --errors --vmid 104
    
    Список задач будет представлен в виде таблицы:
    Список задач, связанных с ВМ 104
  • вывести список задач пользователя user:
    # pvenode task list --userfilter user
    
  • вывести журнал задачи, указав её UPID:
    # pvenode task log UPID:pve01:0002277F:0033E9A0:681B87A1:qmsnapshot:102:root@pam:
    
    Пример вывода:
    snapshotting 'drive-scsi0' (local-lvm:vm-102-disk-0)
      Logical volume "snap_vm-102-disk-0_first" created.
    TASK OK
    
  • вывести сведения о состоянии задачи:
    # pvenode task status UPID:pve01:0002277F:0033E9A0:681B87A1:qmsnapshot:102:root@pam:
    
    Пример вывода:
    ┌────────────┬────────────────────────────────────────────────────────────────┐
    │ key        │ value                                                          │
    ╞════════════╪════════════════════════════════════════════════════════════════╡
    │ exitstatus │ OK                                                             │
    ├────────────┼────────────────────────────────────────────────────────────────┤
    │ id         │ 102                                                            │
    ├────────────┼────────────────────────────────────────────────────────────────┤
    │ node       │ pve01                                                          │
    ├────────────┼────────────────────────────────────────────────────────────────┤
    │ pid        │ 141183                                                         │
    ├────────────┼────────────────────────────────────────────────────────────────┤
    │ pstart     │ 3402144                                                        │
    ├────────────┼────────────────────────────────────────────────────────────────┤
    │ starttime  │ 1746634657                                                     │
    ├────────────┼────────────────────────────────────────────────────────────────┤
    │ status     │ stopped                                                        │
    ├────────────┼────────────────────────────────────────────────────────────────┤
    │ type       │ qmsnapshot                                                     │
    ├────────────┼────────────────────────────────────────────────────────────────┤
    │ upid       │ UPID:pve01:0002277F:0033E9A0:681B87A1:qmsnapshot:102:root@pam: │
    ├────────────┼────────────────────────────────────────────────────────────────┤
    │ user       │ root@pam                                                       │
    └────────────┴────────────────────────────────────────────────────────────────┘
    

⁠43.2. Просмотр событий в веб-интерфейсе PVE

⁠43.2.1. Панель журнала

Основная цель панели журнала — показать, что в данный момент происходит в кластере. Панель журнала расположена в нижней части веб-интерфейса PVE.
Панель журнала
На вкладке Задачи отображаются недавние задачи со всех узлов кластера. Это позволяет отслеживать выполняемые операции на разных узлах.
Чтобы просмотреть подробную информацию о задаче, следует дважды щелкнуть мышью по записи журнала. Откроется окно с журналом выполнения задачи (вкладка Выход) и сведениями о её состоянии (вкладка Статус).
Информация о задаче
Если задача ещё выполняется, её можно остановить с помощью кнопки Остановка. Кнопка Скачивание позволяет сохранить журнал задачи в файл.

Примечание

Кнопка Остановка доступна только для выполняющихся задач.
На вкладке Журнал кластера отображаются сообщения, относящиеся к событиям кластера.

Примечание

Панель журнала можно скрыть, чтобы освободить место для отображения других элементов интерфейса.
На вкладке Задачи отображаются только недавние задачи. Для просмотра истории задач конкретного узла используйте раздел Узел → Журнал задач.

⁠43.2.2. Журнал задач узла PVE

Просмотреть список всех задач узла PVE можно, выбрав Узел → Журнал задач.
Журнал задач узла pve01
Записи можно отфильтровать. Для этого следует нажать кнопку Фильтр и задать необходимые параметры:
Отфильтрованные задачи узла pve01
Просмотреть журнал задачи можно, дважды щелкнув по записи или нажав кнопку Просмотреть задачу.

⁠43.2.3. Журнал задач ВМ

Просмотреть список всех задач ВМ можно, выбрав Узел → ВМ → Журнал задач.
Журнал задач ВМ 100
Записи можно отфильтровать. Для этого следует нажать кнопку Фильтр и задать необходимые параметры:
Задачи ВМ 100 типа qmsnapshot
Просмотреть журнал задачи можно, дважды щелкнув по записи или нажав кнопку Просмотреть задачу.

⁠Глава 44. PVE API

PVE предоставляет REST API, использующий протокол HTTP поверх TLS (HTTPS). Основным форматом обмена данными является JSON. Структура параметров и ответов API описывается с помощью JSON Schema.
Утилита pvesh (см. ниже) предоставляет интерфейс командной строки для выполнения операций через API PVE.
HTTP-запрос включает следующие компоненты:
  • URL — адрес конечной точки API, к которой направляется запрос;
  • метод HTTP (GET, POST, PUT, PATCH или DELETE), определяющий тип операции;
  • заголовки HTTP, содержащие сведения об аутентификации, формате данных и другие служебные параметры;
  • тело запроса — данные, передаваемые серверу, если они необходимы для выполнения операции.

Примечание

При передаче параметров, содержащих специальные символы, может потребоваться URL-кодирование. Для этого можно использовать опцию --data-urlencode.
Методы HTTP определяют тип операции, выполняемой над ресурсом API:
  • GET — получение данных;
  • POST — выполнение операции, в том числе создание ресурса;
  • PUT — изменение ресурса или выполнение операции в соответствии с контрактом конечной точки;
  • DELETE — удаление ресурса;
  • PATCH — частичное изменение ресурса, если оно поддерживается конечной точкой.
Для передачи команд через REST API можно использовать утилиту curl.

Примечание

По мере роста числа пользователей и ВМ, API PVE может начать реагировать на изменения с задержкой.
Для решения этой проблемы нужно очистить /var/lib/rrdcached/, например, выполнив команду:
# find /var/lib/rrdcached -type f -mtime +5 -delete
Или, добавив соответствующее задание в crontab.

⁠44.1. URL API

API PVE использует протокол HTTPS. По умолчанию сервер API прослушивает порт 8006. Базовый URL API имеет следующий вид:
https://server:8006/api2/json/
Параметры запроса можно передавать следующими способами:
  • в URL — для конечных точек, поддерживающих параметры в пути или строке запроса;
  • в теле запроса с типом содержимого application/x-www-form-urlencoded — для методов POST и PUT.
В URL можно указать формат возвращаемых данных:
  • json — JSON;
  • extjs — JSON в структуре, совместимой с ExtJS;
  • html — HTML (иногда полезно для отладки);
  • text — обычный текст (иногда полезно для отладки);

⁠44.2. Аутентификация

Есть два способа доступа к API PVE:
  • использование временно сгенерированного токена (билета);
  • использование API-токена.
Все API-запросы должны включать в себя билет в заголовке Cookie или отправлять API-токен через заголовок Authorization.

⁠44.2.1. Аутентификация с использованием билета

Билет аутентификации (ticket) — это подписанное значение, связанное с учётной записью пользователя и временем выдачи. Билет подписывается общекластерным ключом аутентификации, который обновляется один раз в день.
Для аутентификации с использованием билета его передают в cookie PVEAuthCookie. Для запросов, изменяющих состояние системы (POST, PUT, DELETE), дополнительно требуется заголовок CSRFPreventionToken. Это предотвращает выполнение нежелательных запросов в рамках CSRF-атак (межсайтовой подделки запросов).
Пример получения нового билета и CSRF-токена:
$ curl -k -d 'username=root@pam' --data-urlencode 'password=xxxxxxxxx' \
https://192.168.0.186:8006/api2/json/access/ticket

Примечание

Пароль, передаваемый в командной строке, может быть доступен другим пользователям системы через средства просмотра процессов. Поэтому не следует передавать пароль таким способом на недоверенных узлах
Пример получения нового билета и CSRF-токена с паролем, сохранённым в файле, доступном для чтения только владельцу:
$ curl -k -d 'username=root@pam' --data-urlencode "password@$HOME/.pve-pass-file" \
https://192.168.0.186:8006/api2/json/access/ticket

Примечание

Файл .pve-pass-file должен содержать пароль без завершающего символа перевода строки. Доступ к файлу необходимо ограничить, например, разрешив чтение только его владельцу:
$ echo -n "пароль" > ./.pve-pass-file
$ chmod 600 "$HOME/.pve-pass-file"

Примечание

Для форматирования JSON-ответа можно использовать команду jq (должен быть установлен пакет jq):
$ curl -k -d 'username=root@pam' --data-urlencode "password@$HOME/.pve-pass-file" \
https://192.168.0.186:8006/api2/json/access/ticket | jq
Пример ответа:
{
  "data": {
    "ticket":"PVE:root@pam:66AA52D6::d85E+IIFAuG731…",
    "CSRFPreventionToken":"66AA52D6:Y2zvIXjRVpxx4ZG74F14Ab0EHn8NRoso/WmVqZEnAuM",
    "username":"root@pam"
  }
}

Примечание

Билет действителен в течение двух часов. По истечении срока действия билета необходимо получить новый билет. До истечения этого срока можно получить новый билет, передав старый билет в качестве пароля методу /access/ticket до истечения срока его действия.
Полученный билет необходимо передавать с Cookie при любом запросе, например:
$ curl -k -b "PVEAuthCookie=PVE:root@pam:66AA52D6::d85E+IIFAuG731…" \
https://192.168.0.186:8006/api2/json/
Ответ:
{
  "data": [
    { "subdir": "version" },
    { "subdir": "cluster" },
    { "subdir": "nodes" },
    { "subdir": "storage" },
    { "subdir": "access" },
    { "subdir": "pools" }
  ]
}

Примечание

Для передачи данных в заголовке Cookie используется параметр --cookie (-b).
Любой запрос на запись (POST, PUT, DELETE), кроме билета, должен включать заголовок CSRFPreventionToken, например:
$ curl -k -X 'DELETE' \
'https://pve01:8006/api2/json/access/users/testuser@pve' \
-b "PVEAuthCookie=PVE:root@pam:66AA52D6::d85E+IIFAuG731…" \
-H "CSRFPreventionToken: 66AA52D6:Y2zvIXjRVpxx4ZG74F14Ab0EHn8NRoso/WmVqZEnAuM"

⁠44.2.2. API-токены

API-токены позволяют внешним системам и программам аутентифицироваться при обращении к API PVE без использования билета веб-сеанса. Токены создаются для отдельных пользователей. Для каждого токена можно задать собственные разрешения и срок действия, ограничив объём и продолжительность доступа (подробнее см. раздел API-токены). Если токен скомпрометирован, его можно отозвать без блокировки учётной записи пользователя.
Примеры запросов с использованием API-токена:
  • получить список пользователей:
    $ curl -H 'Authorization: PVEAPIToken=root@pam!test=373007e1-4ecb-4e56-b843-d0fbed543375' \
    https://192.168.0.186:8006/api2/json/access/users
    
  • добавить пользователя testuser@pve:
    $ curl -k -X 'POST' \
    'https://pve01:8006/api2/json/access/users' \
    --data-urlencode 'userid=testuser@pve' \
    -H 'Authorization: PVEAPIToken=root@pam!test=373007e1-4ecb-4e56-b843-d0fbed543375'
    
  • удалить пользователя testuser@pve:
    $ curl -k -X 'DELETE' \
    'https://pve01:8006/api2/json/access/users/testuser@pve' \
    -H 'Authorization: PVEAPIToken=root@pam!test=373007e1-4ecb-4e56-b843-d0fbed543375'
    

Примечание

Если запрос завершается ошибкой вида:
curl: (60) SSL certificate problem: unable to get local issuer certificate
можно дополнить запрос опцией --insecure (-k), чтобы отключить проверку сертификата сервера:
$ curl -k -H 'Authorization: PVEAPIToken=root@pam!test=373007e1-4ecb-4e56-b843-d0fbed543375' \
https://192.168.0.186:8006/api2/json/

Примечание

При использовании API-токена заголовок CSRFPreventionToken для запросов POST, PUT и DELETE не требуется. Это связано с тем, что аутентификация выполняется посредством заголовка Authorization, а не с использованием cookie веб-сеанса.

⁠44.3. Пример создания контейнера с использованием API

Используемые обозначения:
  • APINODE — узел PVE, API которого используется для аутентификации;
  • TARGETNODE — узел PVE, на котором создаётся контейнер;
  • cookie — файл, содержащий cookie аутентификации;
  • csrftoken — файл, содержащий CSRF-токен.
Пример создания контейнера с использованием API:
  1. Для удобства задайте переменные окружения:
    $ export APINODE=pve01
    $ export TARGETNODE=pve03
    
  2. Получите билет аутентификации и CSRF-токен:
    $ response=$(curl --silent --show-error --fail --insecure \
      --data-urlencode 'username=root@pam' \
      --data-urlencode "password@$HOME/.pve-pass-file" \
      "https://$APINODE:8006/api2/json/access/ticket")
    
    В примере предполагается, что пароль сохранён в файле $HOME/.pve-pass-file.
  3. Сохраните cookie и CSRF-токен в отдельные файлы:
    $ printf 'PVEAuthCookie=%s' \
      "$(printf '%s' "$response" | jq -er '.data.ticket')" > cookie
    
    $ printf 'CSRFPreventionToken: %s' \
      "$(printf '%s' "$response" | jq -er '.data.CSRFPreventionToken')" > csrftoken
    
    $ chmod 600 cookie csrftoken
    
  4. Получите сведения о состоянии целевого узла:
    $ curl --silent --show-error --fail --insecure \
      --cookie "$(<cookie)" \
      "https://$APINODE:8006/api2/json/nodes/$TARGETNODE/status" | jq .
    
  5. Создайте LXC-контейнер:
    $ curl --silent --show-error --fail --insecure \
      --cookie "$(<cookie)" \
      --header "$(<csrftoken)" \
      --request POST \
      --data-urlencode 'net0=name=eth0,bridge=vmbr0' \
      --data-urlencode 'ostemplate=nfs-storage:vztmpl/alt-p11-rootfs-systemd-x86_64.tar.xz' \
      --data-urlencode storage="local" \
      --data-urlencode 'vmid=601' \
      "https://$APINODE:8006/api2/json/nodes/$TARGETNODE/lxc" | jq .
    
    Пример ответа:
    {
      "data": "UPID:pve03:00005470:00083F6D:66A76C80:vzcreate:601:root@pam:"
    }
    
    Ответ содержит идентификатор задачи (UPID), запущенной для создания контейнера.

    Примечание

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

⁠44.4. Утилита pvesh

Утилита управления PVE (pvesh) позволяет вызывать методы API непосредственно из командной строки, без обращения к серверу REST/HTTPS:
# pvesh ls /
Dr---        access
Dr---        cluster
Dr---        nodes
Drwcd        pools
Dr-c-        storage
-r---        version

Примечание

Для выполнения команд pvesh необходимы права пользователя root.
При обращении к API другого узла кластера утилита автоматически перенаправляет запрос к соответствующему узлу.
Примеры использования:
  • вывести текущую версию PVE:
    # pvesh get /version
    
  • получить список узлов кластера:
    # pvesh get /nodes
    
  • получить список параметров конфигурации центра обработки данных:
    # pvesh usage cluster/options -v
    
  • создать пользователя:
    # pvesh create /access/users --userid testuser@pve
    
  • удалить пользователя:
    # pvesh delete /access/users/testuser@pve
    
  • установить HTML5-консоль NoVNC в качестве консоли по умолчанию:
    # pvesh set cluster/options -console html5
    
  • создать контейнер на узле pve03:
    # pvesh create nodes/pve03/lxc -vmid 210 -hostname test --storage local \
      --password "supersecret" \
      --ostemplate nfs-storage:vztmpl/alt-p11-rootfs-systemd-x86_64.tar.xz \
      --memory 512 --swap 512
    
    Команда возвращает идентификатор задачи, выполняющей создание контейнера:
    UPID:pve03:0000286E:0003553C:66A75FE7:vzcreate:210:root@pam:
    
  • запустить контейнер с идентификатором 210 на узле pve03:
    # pvesh create /nodes/pve03/lxc/210/status/start
    
    Пример ответа:
    UPID:pve03:0000294B:00036B33:66A7601F:vzstart:210:root@pam
    

⁠Глава 45. Основные службы PVE

Список и состояние служб PVE отображаются на вкладке Узел → Система:
Состояние служб PVE
Здесь же можно просмотреть системный журнал службы (кнопка Системный журнал) и изменить её состояние (кнопки Запуск/Остановка/Перезапустить).
Команды служб PVE на примере pvedaemon:
  • вывести справку:
    # pvedaemon help
  • перезапустить службу или запустить её, если она остановлена:
    # pvedaemon restart
  • запустить службу:
    # pvedaemon start
  • запустить службу в режиме отладки:
    # pvedaemon start --debug 1
  • вывести состояние службы:
    # pvedaemon status
  • остановить службу:
    # pvedaemon stop

⁠45.1. pvedaemon — служба PVE API

Служба pvedaemon предоставляет весь API PVE на 127.0.0.1:85. Она работает от имени пользователя root и имеет разрешение на выполнение всех привилегированных операций.

Примечание

Служба принимает соединения только на локальном адресе, поэтому к ней нельзя получить доступ извне. Доступ к API извне предоставляет служба pveproxy.

⁠45.1.1. Количество рабочих процессов

pvedaemon передаёт обработку входящих запросов рабочим процессам. По умолчанию запускаются три рабочих процесса, чего достаточно для большинства нагрузок.
Если при интенсивной автоматизации, сопровождающейся большим количеством запросов к API, наблюдаются замедление обработки запросов или превышение времени ожидания, количество рабочих процессов можно увеличить с помощью параметра MAX_WORKERS в файле /etc/default/pvedaemon. Например:
MAX_WORKERS=5
Увеличение количества рабочих процессов может привести к повышению нагрузки на процессор. Значение параметра должно быть больше 0 и меньше 128.
Аналогичный параметр предусмотрен для службы pveproxy.

⁠45.2. pveproxy — служба PVE API Proxy

Служба pveproxy предоставляет весь PVE API на TCP-порту 8006 с использованием HTTPS. Она работает от имени пользователя www-data и имеет минимальные разрешения. Операции, требующие дополнительных разрешений, перенаправляются локальному pvedaemon.
Запросы, предназначенные для других узлов, автоматически перенаправляются на них. Таким образом, управлять всем кластером можно, подключившись к одному узлу PVE.

⁠45.2.1. Управление доступом на основе IP-адреса клиента

В pveproxy можно настроить списки контроля доступа, аналогичные спискам, используемым в Apache HTTP Server. Параметры задаются в файле /etc/default/pveproxy. Например:
ALLOW_FROM="10.0.0.1-10.0.0.5,192.168.0.0/22"
DENY_FROM="all"
POLICY="allow"
IP-адреса можно указывать в форматах, поддерживаемых модулем Perl Net::IP. Значение all обозначает все адреса IPv4 и IPv6 (0/0 и ::/0).
По умолчанию параметр POLICY имеет значение allow.
⁠

Таблица 45.1. Правила обработки запросов

Соответствие
POLICY=deny
POLICY=allow
Соответствует только Allow
Запрос разрешён
Запрос разрешён
Соответствует только Deny
Запрос отклонён
Запрос отклонён
Нет соответствий
Запрос отклонён
Запрос разрешён
Соответствует и Allow, и Deny
Запрос отклонён
Запрос разрешён

⁠45.2.2. Прослушиваемый IP-адрес

По умолчанию службы pveproxy и spiceproxy прослушивают подстановочный адрес, принимая соединения по IPv4 и IPv6.
Параметр LISTEN_IP в файле /etc/default/pveproxy позволяет указать IP-адрес, на котором будут принимать соединения службы pveproxy и spiceproxy. IP-адрес должен быть настроен в системе.
Если установить параметр ядра sysctl net.ipv6.bindv6only в значение 1 (sysctl net.ipv6.bindv6only=1), службы будут принимать соединения только по IPv6. Это может нарушить доступ к службам по IPv4. В таком случае следует восстановить значение параметра, обеспечивающее требуемое поведение, либо явно задать адрес прослушивания в LISTEN_IP.
Например, чтобы принимать соединения по IPv4 на всех локальных адресах, можно указать:
LISTEN_IP="0.0.0.0"
Чтобы ограничить прослушивание конкретным адресом IPv4:
LISTEN_IP="192.168.0.186"
Для IPv6 можно указать:
LISTEN_IP="2001:db8:85a3::1"
Если используется локальный IPv6-адрес, необходимо указать имя интерфейса:
LISTEN_IP="fe80::c463:8cff:feb9:6a4e%vmbr0"

Примечание

Не рекомендуется задавать LISTEN_IP в кластерной конфигурации без необходимости: ограничение адреса прослушивания может нарушить взаимодействие между узлами.
Для применения изменений нужно перезагрузить узел или перезапустить pveproxy и spiceproxy:
# systemctl restart pveproxy.service spiceproxy.service

Примечание

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

⁠45.2.3. Настройка наборов шифров TLS

Наборы шифров, используемые при установлении TLS-соединения, можно задать в файле /etc/default/pveproxy:
  • CIPHERS — наборы шифров для TLS 1.2 и более ранних версий, поддерживаемых службой;
  • CIPHERSUITES — наборы шифров для TLS 1.3.
Например:
CIPHERS="ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256"
CIPHERSUITES="TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256"
Параметр HONOR_CIPHER_ORDER определяет, учитывается ли порядок наборов шифров, заданный на стороне сервера, при согласовании соединения. Например:
HONOR_CIPHER_ORDER=0

⁠45.2.4. Поддерживаемые версии TLS

Чтобы отключить поддержку TLS 1.2 или TLS 1.3, установите соответствующий параметр в файле /etc/default/pveproxy:
DISABLE_TLS_1_2=1
или:
DISABLE_TLS_1_3=1

Примечание

Не следует ограничивать поддерживаемые версии TLS без необходимости: это может нарушить совместимость с клиентами.

⁠45.2.5. Параметры Диффи — Хеллмана

Параметры Диффи — Хеллмана можно задать в файле /etc/default/pveproxy, указав в DHPARAMS путь к файлу, содержащему параметры DH в формате PEM, например:
DHPARAMS="/path/to/dhparams.pem"
Если этот параметр не задан, используются встроенные параметры skip2048.

Примечание

Эти параметры используются только при согласовании набора шифров, предусматривающего обмен ключами по алгоритму Диффи — Хеллмана.

⁠45.2.6. Альтернативный сертификат HTTPS

Можно заменить используемый сертификат внешним сертификатом или сертификатом, полученным с помощью ACME.
Если файлы /etc/pve/local/pveproxy-ssl.pem и /etc/pve/local/pveproxy-ssl.key существуют, pveproxy использует их. В противном случае используются файлы /etc/pve/local/pve-ssl.pem и /etc/pve/local/pve-ssl.key.
Закрытый ключ не должен быть зашифрован парольной фразой.
Путь к закрытому ключу можно переопределить с помощью параметра TLS_KEY_FILE в /etc/default/pveproxy. Например:
TLS_KEY_FILE="/secrets/pveproxy.key"

⁠45.2.7. Сжатие ответа

По умолчанию pveproxy использует сжатие HTTP-ответов методом gzip, если клиент поддерживает его. Чтобы отключить сжатие, задайте в файле /etc/default/pveproxy:
COMPRESSION=0

Примечание

Отключение сжатия увеличивает объём передаваемых данных, но может снизить риск атак по побочным каналам, связанных со сжатием.

⁠45.2.8. Регистрация реального IP-адреса клиента

По умолчанию pveproxy записывает в журнал IP-адрес клиента, отправившего запрос. Если перед pveproxy установлен прокси-сервер, может потребоваться регистрировать IP-адрес исходного клиента, а не прокси-сервера.
Чтобы использовать HTTP-заголовок, устанавливаемый прокси-сервером и содержащий IP-адрес клиента, задайте имя этого заголовка в параметре PROXY_REAL_IP_HEADER. Например:
PROXY_REAL_IP_HEADER="X-Forwarded-For"
Недопустимые значения, переданные в этом заголовке, игнорируются.
По умолчанию значение указанного заголовка регистрируется для всех входящих запросов. Чтобы определить список прокси-серверов, которым разрешено задавать этот HTTP-заголовок, используйте параметр PROXY_REAL_IP_ALLOW_FROM. Например:
PROXY_REAL_IP_ALLOW_FROM="192.168.0.2"
Параметр PROXY_REAL_IP_ALLOW_FROM поддерживает форматы адресов, аналогичные используемым в параметрах ALLOW_FROM и DENY_FROM.

⁠45.2.9. Количество рабочих процессов

pveproxy передаёт обработку входящих запросов рабочим процессам. По умолчанию запускаются три рабочих процесса, чего достаточно для большинства нагрузок.
Если при интенсивной автоматизации, сопровождающейся большим количеством запросов к API, наблюдаются замедление обработки запросов или превышение времени ожидания, количество рабочих процессов можно увеличить с помощью параметра MAX_WORKERS в файле /etc/default/pveproxy. Например:
MAX_WORKERS=5
Увеличение количества рабочих процессов может привести к повышению нагрузки на процессор. Значение параметра должно быть больше 0 и меньше 128.
Аналогичный параметр предусмотрен для службы pvedaemon.

⁠45.3. pvestatd — служба PVE Status

Служба pvestatd периодически собирает сведения о состоянии ВМ, контейнеров и хранилищ и обновляет данные о состоянии системы.

⁠45.4. spiceproxy — служба SPICE Proxy

Служба spiceproxy прослушивает TCP-порт 3128 и работает как HTTP-прокси, перенаправляя запросы CONNECT от SPICE-клиентов к ВМ. Служба работает от имени пользователя www-data и имеет ограниченные привилегии.

⁠45.4.1. Управление доступом на основе IP-адреса клиента

Для spiceproxy можно настроить списки контроля доступа по аналогии с pveproxy. Параметры задаются в файле /etc/default/pveproxy. Подробнее см. раздел pveproxy — служба PVE API Proxy.

⁠45.5. pvescheduler — служба планировщика PVE

Служба pvescheduler отвечает за выполнение запланированных задач, в том числе задач резервного копирования и репликации.
Конфигурация запланированных задач резервного копирования vzdump хранится в файле /etc/pve/jobs.cfg.

⁠Глава 46. Обновление системы

ОС Альт Виртуализация редакция PVE использует APT в качестве инструмента управления пакетами.

⁠46.1. Управление репозиториями в PVE

Состояние настроенных репозиториев можно проверить на вкладке Узел → Обновления → Репозитории.
Вкладка Репозитории
В разделе Статус отображается общее состояние настроенных репозиториев, а в разделе Репозитории APT  — список репозиториев и сведения об их состоянии. В веб-интерфейсе доступны основные операции управления репозиториями: добавление, включение и отключение.
Для добавления репозитория необходимо нажать кнопку Добавить, в открывшемся окне выбрать нужный репозиторий в списке Репозиторий и нажать кнопку Добавить:
Добавление репозитория
Чтобы включить отключенный репозиторий, необходимо выделить его в списке и нажать кнопку Включить. Для отключения репозитория необходимо выделить его и нажать кнопку Отключить:
Список репозиториев

⁠46.2. Обновление системного ПО

Обновления можно устанавливать с помощью apt-get или через веб-интерфейс (Узел → Обновления).
Чтобы получить актуальный список пакетов и просмотреть доступные обновления, необходимо:
  • перейти в раздел Узел → Обновления и нажать кнопку Обновить;
    Обновление индексов пакетов
  • выполнить команду:
    # apt-get update
После обновления индексов пакетов в веб-интерфейсе отобразится список доступных обновлений:
Список пакетов для обновления
Чтобы начать обновление, следует нажать кнопку Обновить. Откроется окно со списком изменений, который необходимо подтвердить:
Список изменений

Примечание

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

⁠46.3. Обновление с PVE 8.x до PVE 9.x

В версии PVE 9.x представлено несколько новых функций. Обновление до этой версии требует тщательного планирования: необходимо создать и проверить резервные копии, а также провести тестирование в контролируемой среде. В зависимости от текущей конфигурации могут потребоваться ручные действия и временное прекращение работы (простой).

Примечание

Перед началом обновления следует убедиться в наличии корректной и протестированной резервной копии. Резервные копии рекомендуется предварительно протестировать в изолированной тестовой лаборатории.
Существует два основных способа миграции с PVE 8.x на PVE 9.x:
  1. Новая установка на новом или переформатированном оборудовании с последующим восстановлением ВМ и контейнеров из резервных копий.
  2. Обновление на месте (in-place upgrade) — пошаговое обновление существующей системы.

Важно

Если кластер PVE использует встроенный или внешний Ceph-кластер, процедура обновления (особенно с переустановкой ОС) требует дополнительных действий. В отличие от узлов без Ceph, здесь необходимо учитывать состояние OSD-дисков и сервисов Ceph, а также доступное свободное пространство в кластере.

⁠46.3.1. Обновление с переустановкой

⁠46.3.1.1. Одиночный узел

Процедура обновления:
  1. Создать резервные копии всех ВМ и контейнеров на внешнем хранилище (см. раздел Резервное копирование и восстановление).
  2. Выполнить резервное копирование всех файлов в каталоге /etc.
  3. Установить систему с PVE 9.x из ISO-образа alt-virtualization-pve-11.1-x86_64.iso.

    Предупреждение

    Установка из ISO-образа полностью очистит диск узла и удалит все существующие данные.
  4. Действия после установки:
    • очистить кеш браузера (во избежание ошибок при работе с веб-интерфейсом);
    • воспроизвести сетевую конфигурацию на основе сохранённого файла /etc/network/interfaces;
    • восстановить файл /etc/pve/storage.cfg для подключения внешнего хранилища, используемого для резервного копирования;
    • восстановить конфигурации брандмауэра:
      • /etc/pve/firewall/;
      • /etc/pve/nodes/<node>/host.fw (если применимо);
    • при необходимости добавить в sysctl.conf параметр:
      net.ipv4.ip_forward = 1
    • восстановить все ВМ и контейнеры из резервных копий (см. раздел Резервное копирование и восстановление).

⁠46.3.1.2. Узел в составе кластера

Для кластерной инсталляции обновление выполняется поочерёдно для каждого узла.
Процедура обновления:
  1. Убедиться, что кластер находится в корректном состоянии (pvecm status).
  2. Перенести (мигрировать) все ВМ и контейнеры с обновляемого узла на другие узлы кластера (см. раздел Миграция ВМ и контейнеров).
  3. Отключить узел и вывести его из кластера (см. раздел Удаление узла из кластера).
  4. Установить систему с PVE 9.x из ISO-образа alt-virtualization-pve-11.1-x86_64.iso.

    Предупреждение

    Установка из ISO-образа полностью очистит диск узла и удалит все существующие данные.
  5. Ввести узел в кластер. Убедиться, что каталог /etc/pve синхронизирован и узел появился в кластере.
  6. При необходимости вернуть ВМ и контейнеры на обновлённый узел.

⁠46.3.1.3. Обновление узла Ceph

При переустановке ОС на узле, входящем в Ceph-кластер, OSD-диски необходимо предварительно корректно вывести из кластера. В противном случае после установки новой системы Ceph не сможет корректно «подхватить» существующие OSD, и повторное подключение дисков станет затруднительным или невозможным.
Перед началом работ необходимо убедиться, что:
  • Ceph-кластер находится в состоянии HEALTH_OK;
  • в кластере имеется достаточный запас свободного места, позволяющий:
    • временно вывести один или несколько OSD;
    • выполнить служебные операции Ceph (backfill, recovery, rebalancing);
  • коэффициент репликации позволяет безопасно удалить OSD без потери данных;
  • для служб MON / MGR / MDS в кластере имеются резервные экземпляры на других узлах.

Примечание

Для безопасного вывода одного OSD в Ceph требуется репликация не ниже size=3, свободное место в кластере — не менее объёма данных одного OSD (желательно с запасом 30 %), а заполненность OSD не должна превышать 70–75 %. В кластере из трёх OSD любые операции по их выводу допустимы, но считаются пограничными и требуют повышенного контроля.
Процедура обновления:
  1. Проверка состояния кластера
    • убедиться, что PVE-кластер находится в корректном состоянии:
      # pvecm status
      …
      Quorum information
      ------------------
      Date:             Wed Feb  4 16:34:33 2026
      Quorum provider:  corosync_votequorum
      Nodes:            3
      Node ID:          0x00000001
      Ring ID:          1.27
      Quorate:          Yes
      
    • проверить состояние Ceph:
      # ceph -s
      cluster:
      id:     e2a86754-35d1-4e63-a41b-35aafa5e0542
      health: HEALTH_OK
      
      services:
      mon: 3 daemons, quorum pve01,pve02,pve03 (age 38s)
      mgr: pve03(active, since 2m), standbys: pve01
      mds: 1/1 daemons up, 1 standby
      osd: 3 osds: 3 up (since 24m), 3 in (since 58m)
      
      data:
      volumes: 1/1 healthy
      pools:   3 pools, 65 pgs
      objects: 24 objects, 595 KiB
      usage:   222 MiB used, 315 GiB / 315 GiB avail
      pgs:     65 active+clean
      
  2. Миграция нагрузок
    Перенести (мигрировать) все ВМ и контейнеры с обновляемого узла на другие узлы кластера (см. раздел Миграция ВМ и контейнеров).
  3. Удаление Ceph-служб с узла (если присутствуют)
    Если на узле размещены службы Ceph, их необходимо корректно удалить из кластера, а не просто остановить (подробнее об удалении служб см. в разделах Удаление монитора и Удаление менеджера):
    # pveceph mon destroy <mon_id>
    # pveceph mgr destroy <mgr_id>
    # pveceph mds destroy <mds_id>
    

    Примечание

    Убедитесь, что на других узлах кластера существуют рабочие резервные экземпляры MON / MGR / MDS.
  4. Вывод OSD из Ceph-кластера
    Для каждого OSD, размещённого на обновляемом узле:
    1. Пометить OSD как out:
      # ceph osd out <osd.id>
      
    2. Отслеживать состояние кластера:
      # ceph -s
      # ceph pg stat
      
      Дождаться, пока все затронутые PG перейдут в состояние active+clean (завершение backfill и rebalancing).
    3. Пометить OSD как down:
      # ceph osd down <osd.id>
      
    4. Остановить службу OSD на узле:
      # systemctl stop ceph-osd@<osd.id>.service
      
    5. Удалить OSD из CRUSH-карты и базы Ceph:
      # ceph osd rm <osd.id>
      # ceph osd crush remove <osd.id>
      # ceph auth del osd.<osd.id>
      
    6. Проверить состояние дерева OSD:
      # ceph osd tree
      # ceph osd crush tree
      

    Примечание

    Подробнее см. в разделе Удаление OSD
  5. Очистка дисков OSD на узле
    После удаления OSD необходимо очистить диски:
    • при использовании LVM:
      # ceph-volume lvm zap /dev/X --destroy
      
    • вручную:
      # lvremove
      # vgremove
      # wipefs -a /dev/X
      

    Примечание

    Если использовались отдельные устройства под DB/WAL, их также необходимо очистить.
  6. Вывод узла из PVE-кластера и переустановка
    1. Выключить узел.
    2. Установить систему с PVE 9.x из ISO-образа alt-virtualization-pve-11.1-x86_64.iso.
  7. Возврат узла в кластер
    После установки системы:
    1. Подключить его к Ceph-кластеру.
    2. Заново добавить OSD-диски (диски должны быть пустыми).
    3. При необходимости повторно развернуть MON / MGR / MDS (подробнее см. в разделах Создание монитора, Создание менеджера и Создание сервера метаданных).
  8. Проверка состояния Ceph
    1. Проверить состояние Ceph:
      # ceph -s
    2. Дождаться завершения всех операций восстановления и ребалансировки.
  9. Возврат нагрузок
    При необходимости вернуть ВМ и контейнеры на обновлённый узел.

⁠46.3.2. Обновление на месте

Обновление на месте выполняется с помощью системы управления пакетами.
Предварительные требования:
  • На всех узлах должен быть установлен PVE версии 8.x.
  • Репозитории пакетов должны быть корректно настроены (через веб-интерфейс: Узел → Обновления → Репозитории или с помощью команды apt-repo).
  • Должен быть обеспечен надёжный доступ к узлу. Рекомендуется использовать независимый от ОС канал управления, например:
    • iKVM / IPMI;
    • физический доступ к консоли.
  • Если доступ возможен только по SSH:
    • следует протестировать процедуру обновления на идентичной, но непроизводственной системе;
    • рекомендуется использовать терминальный мультиплексор (например, tmux или screen), чтобы избежать прерывания обновления при потере SSH-соединения.
  • Кластер должен находиться в стабильном и работоспособном состоянии.
  • Должна существовать действующая и протестированная резервная копия всех ВМ и контейнеров.
  • На корневом разделе должно быть не менее 5 ГБ свободного места, рекомендуется — 10 ГБ и более.

Важно

Не используйте виртуальную консоль веб-интерфейса PVE: во время обновления она может быть недоступна.

Примечание

Рекомендуется протестировать обновление на отдельном сервере или ВМ:
  1. Установить тестовую систему с помощью ISO-образа alt-virtualization-pve-11.0-x86_64.iso.
  2. Воспроизвести производственную конфигурацию (сетевые настройки, хранилища, брандмауэр и т.д.).
  3. Выполнить обновление и оценить стабильность системы.
Также существует возможность миграции ВМ между кластерами (qm remote-migrate). При наличии технической возможности можно развернуть новый кластер параллельно и выполнить миграцию всех ВМ.
Обновление следует выполнять на каждом узле кластера по отдельности, соблюдая установленную последовательность.
Рекомендуемый порядок обновления узлов кластера:
  1. Включить на узле режим технического обслуживания (если используется кластерная конфигурация):
    # ha-manager crm-command node-maintenance enable <Узел>
    

    Примечание

    При активации режима maintenance ha-manager переместит все ресурсы, за которыми он следит (HA-ресурсы), на другие узлы кластера. Также данный режим помечает узел как недоступный для размещения новых ресурсов, предотвращая автоматическую миграцию ВМ с других узлов.
    ВМ и контейнеры, не управляемые HA, необходимо мигрировать вручную.
  2. Перенести все ВМ и контейнеры с обновляемого узла на другие узлы кластера или сохранить их в хранилище (см. раздел Миграция ВМ и контейнеров).
  3. Выполнить обновление на узле:
    # apt-get update && apt-get dist-upgrade
    # update-kernel
    # apt-get clean
    # reboot
    
  4. Отключить режим технического обслуживания:
    # ha-manager crm-command node-maintenance disable <Узел>
    
  5. Проверить корректность работы узла и при необходимости вернуть (мигрировать) ВМ и контейнеры обратно.
  6. При отсутствии проблем аналогичным образом обновить остальные узлы кластера.

Примечание

При обновлении с версии 8.x на 9.x в работающем кластере возможны временные ошибки в pmxcfs. После обновления всех узлов эти ошибки, как правило, исчезают.
Возможны проблемы в работе сетевой подсистемы, требующие ручной корректировки конфигурации.
Из-за значительных изменений между версиями 8.x и 9.x при частичном обновлении кластера возможны некорректные состояния. В случае возникновения неустранимых проблем рекомендуется рассмотреть альтернативный вариант — полную переустановку PVE 9.x на всех узлах с последующей пересборкой кластера и восстановлением виртуальных машин и конфигураций из резервных копий.

⁠Часть V.  Установка пакетов для опытных пользователей

⁠Введение

После установки ОС Альт Виртуализация редакция PVE в системе доступен определённый набор программного обеспечения (ПО). Его состав зависит от выбранных при установке компонентов. Если необходимые программы не установлены, их можно установить дополнительно из доступных источников.
Дополнительное ПО может находиться на установочном носителе, а также в репозиториях, доступных через Интернет или локальную сеть. Программы из этих источников распространяются в виде пакетов, подготовленных для установки.

Примечание

В установочный комплект Альт Виртуализация редакция PVE включено наиболее употребительное программное обеспечение. Для установки дополнительных программных пакетов можно использовать репозиторий продукта (p11).
Для установки, удаления и обновления программ, а также управления зависимостями между пакетами в ОС семейства Linux используются системы управления пакетами. В дистрибутивах Альт, использующих формат RPM, применяется система управления пакетами APT (от англ. Advanced Packaging Tool).
APT использует репозитории, содержащие пакеты и метаданные о них. Репозитории могут содержать пакеты официального дистрибутива, обновляемые разработчиками, а также дополнительные пакеты, например разработанные внутри организации.
На основании сведений об установленных пакетах и метаданных подключённых репозиториев APT определяет доступные версии пакетов, учитывает зависимости и выбирает необходимые действия при установке или обновлении программ.
Для управления пакетами в APT предусмотрено несколько утилит. Одна из основных — apt-get, которая позволяет устанавливать, удалять и обновлять пакеты с учётом зависимостей между ними.

⁠Глава 47. Источники программ (репозитории)

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

Важно

Подключая одновременно несколько репозиториев, нужно следить за тем, чтобы они были совместимы друг с другом по пакетной базе — отражали один определенный этап разработки. Совместное использование репозиториев, относящихся к разным дистрибутивам, или смешение стабильного репозитория с нестабильной веткой разработки (Sisyphus) может привести к конфликтам зависимостей и другим проблемам при обновлении пакетов.
APT позволяет взаимодействовать с репозиторием с помощью различных протоколов доступа. Наиболее распространены протоколы HTTP и FTP, однако существуют и некоторые дополнительные методы.
Для того чтобы APT мог использовать тот или иной репозиторий, информацию о нём необходимо поместить в файл /etc/apt/sources.list либо в любой файл с расширением .list (например, mysources.list) в каталоге /etc/apt/sources.list.d/.
Описания репозиториев заносятся в эти файлы в следующем виде:
rpm [подпись] метод:путь база название
rpm-src [подпись] метод:путь база название
где:
  • rpm — тип записи для репозитория с бинарными пакетами;
  • rpm-src — тип записи для репозитория с исходными пакетами;
  • [подпись] — идентификатор электронной подписи, которой должны быть подписаны пакеты репозитория. Сведения о допустимых подписях хранятся в файле /etc/apt/vendor.list и в файлах с расширением .list каталога /etc/apt/vendors.list.d;
  • метод — способ доступа к репозиторию: ftp, http, file, rsh, ssh, cdrom, rsync или copy;
  • путь — путь к репозиторию, определяемый выбранным способом доступа;
  • база — относительный путь к базе данных репозитория;
  • название — название репозитория.
Если строка начинается с символа комментария, она считается комментарием и не используется как описание источника. Для активной записи символ комментария в начале строки отсутствует.
При описании репозитория указывают тип содержащихся в нём пакетов и их архитектуру. Например, x86_64-i586 обозначает репозиторий с пакетами для архитектур x86_64 и i586, а noarch — с пакетами, не зависящими от архитектуры процессора. Источники с пакетами noarch могут дополнять источники с архитектурно-зависимыми пакетами, если соответствующие пакеты разделены между репозиториями.
При выборе пакетов для установки APT руководствуется всеми доступными репозиториями вне зависимости от способа доступа к ним. Если в сетевом репозитории доступна более новая версия пакета, чем на компакт-диске или DVD, APT загрузит пакет из сетевого репозитория.

⁠47.1. Редактирование репозиториев

Непосредственно после установки дистрибутива Альт Виртуализация редакция PVE в файлах /etc/apt/sources.list.d/*.list обычно указывается интернет-репозиторий, совместимый с установленным дистрибутивом.

⁠47.1.1. Утилита apt-repo для работы с репозиториями

Для управления репозиториями можно воспользоваться утилитой apt-repo.

Примечание

Для выполнения большинства команд требуются права администратора.
Некоторые команды:
  • просмотреть список активных репозиториев:
    $ apt-repo
    
  • добавить репозиторий в список активных репозиториев:
    # apt-repo add репозиторий
    
  • удалить репозиторий из списка активных источников:
     # apt-repo rm репозиторий
    
  • обновить информацию о репозиториях:
    # apt-repo update
    
  • справка о команде apt-repo:
    $ man apt-repo
    
    или
    $ apt-repo --help
    
Пример: удалить все источники и добавить стандартный репозиторий P11 (архитектура выбирается автоматически):
# apt-repo rm all
# apt-repo add p11
Эту же операцию можно выполнить одной командой:
# apt-repo set p11

⁠47.1.2. Добавление репозитория на сменном носителе

Для добавления в sources.list репозитория на сменном диске в APT предусмотрена специальная утилита — apt-cdrom.
Чтобы добавить запись о репозитории на сменном диске, необходимо выполнить следующие действия:
  1. Создать каталог для монтирования носителя. Точка монтирования задается параметром Acquire::CDROM::mount в конфигурации APT (/etc/apt/apt.conf). По умолчанию используется каталог /media/ALTLinux:
    # mkdir /media/ALTLinux
    
  2. Смонтировать носитель в указанную точку:
    # mount /dev/носитель /media/ALTLinux
    
    здесь /dev/носитель — имя соответствующего блочного устройства (например, /dev/dvd для CD/DVD-диска).
  3. Добавить носитель в список источников, выполнив команду:
    # apt-cdrom -m add
    
После выполнения команды в списке источников появится запись о подключённом диске, например:
rpm cdrom:[ALT Virtualization 11.2 x86_64 build 2026-10-13]/ ALTLinux main

Примечание

Команду mount /dev/носитель /media/ALTLinux необходимо выполнять перед каждой командой apt-get install имя_пакета.

⁠47.1.3. Добавление репозиториев вручную

Для ручного управления списком репозиториев отредактируйте с правами доверенного администратора файлы каталога /etc/apt/sources.list.d/ в любом текстовом редакторе.

Примечание

Для изменения этих файлов необходимы права администратора.
Например, в файле alt.list могут содержаться следующие записи:
# ftp.altlinux.org (ALT Linux, Moscow)

# ALT Platform 11
#rpm [p11] ftp://ftp.altlinux.org/pub/distributions/ALTLinux p11/branch/x86_64 classic
#rpm [p11] ftp://ftp.altlinux.org/pub/distributions/ALTLinux p11/branch/x86_64-i586 classic
#rpm [p11] ftp://ftp.altlinux.org/pub/distributions/ALTLinux p11/branch/noarch classic

rpm [p11] http://ftp.altlinux.org/pub/distributions/ALTLinux p11/branch/x86_64 classic
rpm [p11] http://ftp.altlinux.org/pub/distributions/ALTLinux p11/branch/x86_64-i586 classic
rpm [p11] http://ftp.altlinux.org/pub/distributions/ALTLinux p11/branch/noarch classic
Каждая запись описывает отдельный источник пакетов.
Для отключения репозитория достаточно закомментировать соответствующую запись, добавив символ # в начало строки. Чтобы добавить новый репозиторий, необходимо внести соответствующую запись в этот или другой файл каталога /etc/apt/sources.list.d/.
После изменения списка репозиториев обновите локальные индексы пакетов командой apt-get update или apt-repo update.

⁠Глава 48. Обновление информации о репозиториях

Перед выполнением операций с пакетами рекомендуется обновить индексы активных репозиториев. Это следует делать перед поиском новых версий пакетов, установкой программ и обновлением установленных пакетов.
Обновление данных осуществляется командой:
$ apt-get update
При выполнении этой команды APT загружает индексы пакетов из активных репозиториев и сохраняет их в локальном кеше.

⁠Глава 49. Поиск пакетов

Утилита apt-cache предназначена для поиска программных пакетов в репозиториях. Она позволяет искать пакеты не только по имени, но и по описанию.
Команда apt-cache search подстрока позволяет найти все пакеты, в именах или описаниях которых встречается указанная подстрока. Пример поиска может выглядеть следующим образом:
$ apt-cache search ^telegraf
ceph-mgr-telegraf - Telegraf module for Ceph Manager Daemon
telegraf - The plugin-driven server agent for collecting and reporting metrics
Символ «^» в поисковом выражении указывает на то, что совпадение должно находиться в начале строки (в данном случае — в начале имени пакета).
Чтобы получить дополнительные сведения о найденном пакете, можно воспользоваться командой apt-cache show:
$ apt-cache show telegraf
Package: telegraf
Section: Development/Other
Installed Size: 276056584
Maintainer: Alexey Shabalin (ALT Team) <shaba@altlinux.org>
Version: 1.33.0-alt1:p11+365214.100.2.1@1734429624
Pre-Depends: /bin/sh, /usr/sbin/groupadd, /usr/sbin/useradd, /usr/sbin/usermod, /usr/sbin/post_service, /usr/sbin/preun_service, rpmlib(PayloadIsXz)
Depends: /bin/kill, /bin/sh, /etc/logrotate.d, /etc/rc.d/init.d, /etc/rc.d/init.d(SourceIfNotEmpty), /etc/rc.d/init.d(msg_reloading), /etc/rc.d/init.d(msg_usage), /etc/rc.d/init.d(start_daemon), /etc/rc.d/init.d(status), /etc/rc.d/init.d(stop_daemon), /etc/rc.d/init.d/functions
Provides: telegraf (= 1.33.0-alt1:p11+365214.100.2.1)
Architecture: x86_64
Size: 46969532
MD5Sum: 92c284ee01d9657bebe670bb72468f5c
Filename: telegraf-1.33.0-alt1.x86_64.rpm
Description: The plugin-driven server agent for collecting and reporting metrics
 Telegraf is an agent written in Go for collecting, processing, aggregating, and writing metrics.

 Design goals are to have a minimal memory footprint with a plugin system so that developers
 in the community can easily add support for collecting metrics from well known services
 (like Hadoop, Postgres, or Redis) and third party APIs (like Mailchimp, AWS CloudWatch,
 or Google Analytics).
Поиск может выполняться и по русскоязычным описаниям пакетов, если они содержат искомую подстроку.

⁠Глава 50. Установка или обновление пакета

Важно

Для установки пакетов требуются привилегии администратора.
Установка пакета с помощью APT выполняется командой:
# apt-get install имя_пакета

Важно

Перед установкой и обновлением пакетов рекомендуется обновить индексы репозиториев командой:
# apt-get update
Если пакет уже установлен и в подключённых репозиториях нет более новой версии, APT сообщит, что установлена последняя версия пакета. Если в репозитории доступна более новая версия пакета, APT предложит установить её.
Утилита apt-get позволяет устанавливать в систему пакеты, даже если для их работы требуются дополнительные, ещё не установленные зависимости. В этом случае она автоматически разрешает зависимости и устанавливает все необходимые пакеты, используя настроенные репозитории.
Установка пакета telegraf командой apt-get install telegraf приведёт к следующему диалогу с APT (если пакет еще не установлен):
# apt-get install telegraf
Чтение списков пакетов... Завершено
Построение дерева зависимостей... Завершено
Следующие НОВЫЕ пакеты будут установлены:
  telegraf
0 будет обновлено, 1 новых установлено, 0 пакетов будет удалено и 31 не будет обновлено.
Необходимо получить 47,0MB архивов.
После распаковки потребуется дополнительно 276MB дискового пространства.
Получено: 1 http://ftp.altlinux.org p11/branch/x86_64/classic telegraf 1.33.0-alt1:p11+365214.100.2.1@1734429624 [47,0MB]
Получено 47,0MB за 15s (2942kB/s).
Совершаем изменения...
Подготовка...                     ################################### [100%]
Обновление / установка...
1: telegraf-1.33.0-alt1           ################################### [100%]
Завершено.
Команду apt-get install имя_пакета можно использовать также для обновления уже установленного пакета до версии, доступной в подключённых репозиториях. В этом случае apt-get дополнительно проверяет, не обновилась ли версия пакета в репозитории по сравнению с установленным в системе.
Например, если пакет telegraf установлен и в репозитории нет обновлённой версии этого пакета, то вывод команды apt-get install telegraf будет таким:
# apt-get install telegraf

Чтение списков пакетов... Завершено
Построение дерева зависимостей... Завершено
Последняя версия telegraf уже установлена.
0 будет обновлено, 0 новых установлено, 0 пакетов будет удалено и 2262 не будет обновлено.
С помощью APT можно установить RPM-пакет, который отсутствует в подключённых репозиториях. Для этого достаточно выполнить команду:
# apt-get install /путь/к/файлу.rpm
При этом APT проведёт стандартную процедуру проверки зависимостей и конфликтов с уже установленными пакетами.
Операции с пакетами в обход APT могут привести к нарушению целостности системы. В этом случае apt-get может отказаться устанавливать, удалять или обновлять пакеты.
Для попытки исправить нарушенные зависимости можно повторить команду с опцией -f (--fix-broken). В зависимости от ситуации APT может установить недостающие пакеты или удалить пакеты, препятствующие разрешению зависимостей. Любые действия в этом режиме обязательно требуют подтверждения со стороны пользователя.
При установке пакетов происходит запись в системный журнал вида:
apt-get: имя-пакета installed

⁠Глава 51. Удаление установленного пакета

Важно

Для удаления пакетов требуются привилегии администратора.
Для удаления пакета используется команда:
# apt-get remove имя_пакета
При удалении пакета APT проверяет зависимости и предложит удалить также пакеты, которые зависят от него.
По умолчанию apt-get remove удаляет пакет, но сохраняет его конфигурационные файлы.
Для удаления пакета вместе с конфигурационными файлами используется команда:
# apt-get remove --purge имя_пакета
При попытке с помощью apt-get удалить базовый компонент системы появится запрос на подтверждение операции:
# apt-get remove filesystem
Чтение списков пакетов... Завершено
Построение дерева зависимостей... Завершено
Следующие пакеты будут УДАЛЕНЫ:
  ...
ВНИМАНИЕ: Будут удалены важные для работы системы пакеты
Обычно этого делать не следует. Вы должны точно понимать возможные последствия!
  ...
0 будет обновлено, 0 новых установлено, 2648 пакетов будет удалено и 0 не будет обновлено.
Необходимо получить 0B архивов.
После распаковки будет освобождено 8994MB дискового пространства.
Вы делаете нечто потенциально опасное!
Введите фразу 'Yes, do as I say!' чтобы продолжить.

Предупреждение

Каждый такой запрос APT необходимо рассматривать отдельно. Подтверждение такой операции может привести к неработоспособности системы. Перед продолжением необходимо внимательно проверить список удаляемых пакетов.
При удалении пакетов происходит запись в системный журнал вида:
apt-get: имя-пакета removed

⁠Глава 52. Обновление системы

⁠52.1. Обновление всех установленных пакетов

Для обновления системы выполните команды:
# apt-get update && apt-get dist-upgrade
Первая команда (apt-get update) обновляет индексы пакетов. Вторая (apt-get dist-upgrade) обновляет установленные пакеты до доступных версий с учётом изменений зависимостей. При необходимости APT может установить дополнительные пакеты или удалить пакеты, мешающие обновлению.
При обновлении системы APT сравнивает установленные версии пакетов с версиями, доступными в репозиториях. При этом могут устанавливаться новые версии пакетов, удаляться устаревшие пакеты, а также учитываться изменения зависимостей и переименования пакетов. Перед началом обновления APT выводит список предполагаемых изменений, включая пакеты, которые будут установлены, обновлены или удалены.

Примечание

Команда apt-get dist-upgrade обновит систему, но ядро ОС не будет обновлено.

⁠52.2. Обновление ядра

Для обновления ядра ОС необходимо выполнить команду:
# update-kernel

Примечание

Перед выполнением команды update-kernel необходимо выполнить команду apt-get update.
При обновлении ядра команда update-kernel также устанавливает или обновляет соответствующие модули ядра, если необходимые пакеты доступны в репозиториях.
Новое ядро будет использоваться после перезагрузки системы.
Если при загрузке или работе с новым ядром возникнут проблемы, можно выбрать предыдущую версию ядра в меню загрузчика.
После успешной загрузки системы с новым ядром при необходимости можно удалить старые ядра командой:
# remove-old-kernels

⁠Часть VI. Основы администрирования Linux

⁠Глава 53. Общие принципы работы ОС

⁠53.1. Процессы и файлы

ОС Альт Виртуализация редакция PVE является многопользовательской интегрированной системой. Это значит, что она разработана в расчете на одновременную работу нескольких пользователей.
Пользователь может либо сам работать в системе, выполняя некоторую последовательность команд, либо от его имени могут выполняться прикладные процессы.
Пользователь взаимодействует с системой через командный интерпретатор. Командный интерпретатор представляет собой прикладную программу, которая принимает от пользователя команды или набор команд и транслирует их в системные вызовы к ядру системы. Интерпретатор позволяет пользователю просматривать файлы, передвигаться по дереву файловой системы, запускать прикладные процессы. Все командные интерпретаторы UNIX имеют развитый командный язык и позволяют писать достаточно сложные программы, упрощающие процесс администрирования системы и работы с ней.

⁠53.1.1. Процессы функционирования ОС

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

⁠53.1.2. Файловая система ОС

В Linux файловая система имеет структуру единого дерева каталогов с корневым каталогом /, в отличие от DOS и Windows, где используются отдельные обозначения дисков (например, C:).
Части дерева файловой системы могут физически располагаться в разных разделах разных дисков или вообще на других компьютерах — для пользователя это прозрачно. Процесс присоединения файловой системы раздела к дереву называется монтированием, удаление — размонтированием. Например, файловая система CD-ROM в дистрибутиве монтируется по умолчанию в каталог /media/cdrom (путь в дистрибутиве обозначается с использованием /, а не \, как в DOS/Windows).
Текущий каталог обозначается ./.

⁠53.1.3. Структура каталогов

Корневой каталог /:
  • /bin — командные оболочки (shell), основные утилиты;
  • /boot — содержит ядро системы;
  • /dev — псевдофайлы устройств, позволяющие работать с устройствами напрямую. Файлы в /dev создаются сервисом udev
  • /etc — общесистемные конфигурационные файлы для большинства программ в системе;
  • /etc/rc?.d, /etc/init.d, /etc/rc.boot, /etc/rc.d — каталоги, где расположены командные файлы, выполняемые при запуске системы или при смене её режима работы;
  • /etc/passwd — база данных пользователей, в которой содержится информация об имени пользователя, его настоящем имени, личном каталоге, его зашифрованный пароль и другие данные;
  • /etc/shadow — теневая база данных пользователей. При этом информация из файла /etc/passwd перемещается в /etc/shadow, который недоступен для чтения всем, кроме пользователя root. В случае использования альтернативной схемы управления теневыми паролями (TCB), все теневые пароли для каждого пользователя располагаются в каталоге /etc/tcb/имя пользователя/shadow;
  • /home — домашние каталоги пользователей;
  • /lib — содержит файлы динамических библиотек, необходимых для работы большей части приложений, и подгружаемые модули ядра;
  • /lost+found — восстановленные файлы;
  • /media — подключаемые носители (каталоги для монтирования файловых систем сменных устройств);
  • /mnt — точки временного монтирования;
  • /opt — вспомогательные пакеты;
  • /proc — виртуальная файловая система, хранящаяся в памяти компьютера при загруженной ОС. В данном каталоге расположены самые свежие сведения обо всех процессах, запущенных на компьютере;
  • /root — домашний каталог администратора системы;
  • /run — файлы состояния приложений;
  • /sbin — набор программ для административной работы с системой (системные утилиты);
  • /selinux — виртуальная файловая система SELinux;
  • /srv — виртуальные данные сервисных служб;
  • /sys — файловая система, содержащая информацию о текущем состоянии системы;
  • /tmp — временные файлы;
  • /usr — пользовательские двоичные файлы и данные, используемые только для чтения (программы и библиотеки);
  • /var — файлы для хранения изменяющихся данных (рабочие файлы программ, очереди, журналы).
Каталог /usr:
  • /usr/bin — дополнительные программы для всех учетных записей;
  • /usr/sbin — команды, используемые при администрировании системы и не предназначенные для размещения в файловой системе root;
  • /usr/local — место, где рекомендуется размещать файлы, установленные без использования пакетных менеджеров, внутренняя организация каталогов практически такая же, как и корневого каталога;
  • /usr/share — каталог для размещения общедоступных файлов большей части приложений, например, /usr/share/man — каталог, где хранятся файлы справочного руководства man.
Каталог /var:
  • /var/log — каталог для регистрации сообщений, системный журнал;
  • /var/spool — каталог для хранения файлов, находящихся в очереди на обработку для того или иного процесса (очереди печати, непрочитанные или не отправленные письма, задачи cron и т.д.).

⁠53.1.4. Организация файловой структуры

Система домашних каталогов пользователей помогает организовывать безопасную работу пользователей в многопользовательской системе. Вне своего домашнего каталога пользователь обладает минимальными правами (обычно чтение и выполнение файлов) и не может нанести ущерб системе, например, удалив или изменив файл.
Кроме файлов, созданных пользователем, в его домашнем каталоге обычно содержатся персональные конфигурационные файлы некоторых программ.
Маршрут (путь) — это последовательность имён каталогов, представляющая собой путь в файловой системе к данному файлу, где каждое следующее имя отделяется от предыдущего наклонной чертой (слешем). Если название маршрута начинается со слеша, то путь в искомый файл начинается от корневого каталога всего дерева системы. В обратном случае, если название маршрута начинается непосредственно с имени файла, то путь к искомому файлу должен начаться от текущего каталога (рабочего каталога).
Имя файла может содержать любые символы за исключением косой черты (/). Однако следует избегать применения в именах файлов большинства знаков препинания и непечатаемых символов. При выборе имен файлов рекомендуется ограничиться следующими символами:
  • строчные и ПРОПИСНЫЕ буквы. Следует обратить внимание на то, что регистр всегда имеет значение;
  • цифры;
  • символ подчеркивания (_);
  • точка (.).
Для удобства работы точку можно использовать для отделения имени файла от расширения файла. Эта возможность может быть необходима пользователям или некоторым программам, но не имеет значение для shell.

⁠53.1.5. Имена дисков и разделов

Все физические устройства компьютера отображаются в каталог /dev файловой системы дистрибутива. Диски (в том числе IDE/SATA/SCSI/SAS жёсткие диски, USB-диски) имеют имена:
  • /dev/sda — первый диск;
  • /dev/sdb — второй диск;
  • и т.д.
Диски обозначаются /dev/sdX, где X — a, b, c, d, e, … в зависимости от порядкового номера диска на шине.
Раздел диска обозначается числом после его имени. Например, /dev/sdb4 — четвертый раздел второго диска.

⁠53.1.6. Разделы, необходимые для работы ОС

Для работы ОС на жестком диске (дисках) должны быть созданы, по крайней мере, два раздела: корневой (то есть тот, который будет содержать каталог /) и раздел подкачки (swap). Размер последнего, как правило, составляет от однократной до двукратной величины оперативной памяти компьютера. Если на диске много свободного места, то можно создать отдельные разделы для каталогов /usr, /home, /var.

⁠53.2. Работа с наиболее часто используемыми компонентами

⁠53.2.1. Виртуальная консоль

Система Альт Виртуализация редакция PVE предоставляет доступ к виртуальным консолям, с которых можно осуществлять одновременно несколько сеансов работы в системе (login session).
Только что установленная система Альт Виртуализация редакция PVE предоставляет доступ только к первым шести виртуальным консолям, к которым можно обращаться, нажимая комбинации клавиш Alt+F1 — Alt+F6 (Ctrl+Alt+F1 — Ctrl+Alt+F6).

⁠53.2.2. Командные оболочки (интерпретаторы)

Для управления ОС используются командные интерпретаторы (shell).
После входа в систему пользователь увидит приглашение командной оболочки — строку, содержащую символ $. Роль командного интерпретатора — передавать команды операционной системе. С помощью командных интерпретаторов можно писать небольшие программы — сценарии (скрипты). Примеры командных оболочек Linux:
  • bash — широко распространённая командная оболочка, которая поддерживает историю команд, их редактирование и программирование с помощью сценариев;
  • zsh — командная оболочка с расширенными возможностями автодополнения, редактирования командной строки и настройки интерактивной работы.
Проверить, какая оболочка используется в данный момент, можно, выполнив команду:
$ echo $SHELL
Оболочкой по умолчанию является Bash (Bourne Again Shell).

⁠53.2.3. Командная оболочка Bash

В Bash имеется несколько приемов для работы со строкой команд. Например, можно использовать следующие сочетания клавиш:
  • Ctrl+A — перейти на начало строки;
  • Ctrl+U — удалить текст от курсора до начала строки и поместить его во внутренний буфер оболочки;
  • Ctrl+Y — вставить текст из внутреннего буфера оболочки в позицию курсора;
  • Ctrl+C — остановить текущую задачу.
Для ввода нескольких команд одной строкой можно использовать разделитель «;». По истории команд можно перемещаться с помощью клавиш ↑ («вверх») и ↓ («вниз»).
Чтобы найти конкретную команду в списке набранных, не пролистывая всю историю, можно нажать Ctrl+R и начать вводить символы ранее введенной команды.
Для просмотра истории команд можно воспользоваться командой history. Команды, присутствующие в истории, отображаются в списке пронумерованными. Чтобы запустить конкретную команду, необходимо набрать:
!номер команды
Если ввести:
!!
запустится последняя из набранных команд.
В Bash предусмотрено автодополнение имён команд, которое упрощает ввод длинных имён программ и команд. Для автодополнения необходимо нажать клавишу Tab.
При нажатии клавиши Tab Bash завершает имя команды, программы или каталога, если не существует нескольких альтернативных вариантов. Например, чтобы использовать программу декомпрессии gunzip, можно набрать следующую команду:
gu
Затем нажать клавишу Tab. Если существует несколько возможных вариантов завершения команды, необходимо повторно нажать клавишу Tab, чтобы получить список имен, начинающихся с gu.
В предложенном примере можно получить следующий список:
$ gu
guile gunzip gupnp-binding-tool
Если после gu ввести n (gunzip — это единственное имя, третьей буквой которого является «n»), а затем нажать клавишу Tab, оболочка самостоятельно дополнит имя. Чтобы запустить команду, нужно нажать Enter.
Программы, вызываемые из командной строки, Bash ищет в каталогах, определяемых в системной переменной $PATH. По умолчанию в этот перечень каталогов не входит текущий каталог, обозначаемый ./ (точка слеш). Поэтому для запуска программы из текущего каталога необходимо использовать команду (в примере запускается команда prog):
$ ./prog

⁠53.2.4. Команда

Простейшая команда состоит из одного «слова», например, команда cal, выводящая календарь на текущий месяц.
$ cal
    Октябрь 2026
Пн Вт Ср Чт Пт Сб Вс
          1  2  3  4
 5  6  7  8  9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31

⁠53.2.5. Команда и параметры

$ cal 1 2026
     Январь 2026
Пн Вт Ср Чт Пт Сб Вс
          1  2  3  4
 5  6  7  8  9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
Команда cal 1 2026 состоит из двух частей — собственно команды cal и «остального». То, что следует за командой, называется параметрами (или аргументами), и они вводятся для изменения поведения команды. В большинстве случаев, первое слово считается именем команды, а остальные — её параметрами.

⁠53.2.6. Команда и ключи

Для решения разных задач одни и те же действия необходимо выполнять по-разному. Например, для синхронизации работ в разных точках земного шара лучше использовать единое для всех время (по Гринвичу), а для организации собственного рабочего дня — местное время (с учётом сдвига по часовому поясу и разницы зимнего и летнего времени). И то, и другое время показывает команда date, только для работы по Гринвичу ей нужен дополнительный параметр -u (он же --universal).
$ date
Пт 23 окт 2026 15:57:55 EET
$ date -u
Пт 23 окт 2026 13:57:59 UTC
Такого рода параметры называются ключами или модификаторами выполнения. Ключ принадлежит данной конкретной команде и сам по себе смысла не имеет. Этим он отличается от других параметров (например, имён файлов, чисел), имеющих собственный смысл, не зависящий ни от какой команды. Каждая команда может распознавать некоторый набор ключей и соответственно изменять своё поведение. Один и тот же ключ может иметь совершенно разное значение в разных командах.
Для формата ключей нет жёсткого стандарта, однако существуют договорённости:
  • Если ключ начинается на -, то это однобуквенный ключ. За -, как правило, следует один символ, чаще всего буква, обозначающая действие или свойство, которое этот ключ придаёт команде. Так проще отличать ключи от других параметров.
  • Если ключ начинается на --, то он называется полнословным ключом. Полнословный формат ключа начинается на два знака --, за которыми следует полное имя обозначаемого этим ключом содержания.
Некоторые ключи имеют и однобуквенный, и полнословный формат, а некоторые — только полнословный.
Информацию о ресурсах каждой команды можно получить, используя ключ --help. К примеру, получить подсказку о том, что делает команда rm, можно, набрав в терминале rm --help.

⁠53.2.7. Обзор основных команд системы

Все команды, приведенные ниже, могут быть запущены в режиме консоли. Для получения более подробной информации используйте команду man. Пример:
$ man ls

Примечание

Параметры команд обычно начинаются с символа «-», и обычно после одного символа «-» можно указать сразу несколько опций. Например, вместо команды ls -l -F можно ввести команду ls -lF

Учетные записи пользователей

Команда su
Команда su позволяет изменить «владельца» текущего сеанса (сессии) без необходимости завершать сеанс и открывать новый.
Синтаксис:
su [ОПЦИИ...] [ПОЛЬЗОВАТЕЛЬ]
Команду можно применять для замены текущего пользователя на любого другого, но чаще всего она используется для получения пользователем прав суперпользователя (root).
При вводе команды su - запрашивается пароль суперпользователя (root), и, если пароль введён правильно, пользователь получает права администратора. Чтобы вернуться к правам пользователя, необходимо ввести команду:
exit
Более подробную информацию о режиме суперпользователя вы можете прочитать в главе Режим суперпользователя.
Команда id
Команда id выводит идентификаторы пользователя и групп, в которые он входит. Если имя пользователя не указано, отображаются сведения о текущем пользователе.
Синтаксис:
id [ОПЦИИ...] [ПОЛЬЗОВАТЕЛЬ]
Команда passwd
Команда passwd изменяет пароль, связанный с учетной записью пользователя.
Пользователь может изменять пароль, связанный со своей учетной записью.
Команда запрашивает у пользователя старый пароль, а затем дважды — новый. Новый пароль должен соответствовать техническим требованиям к паролям, заданным администратором системы.

Основные операции с файлами и каталогами

Команда ls
Команда ls (list) выводит в стандартный вывод содержимое каталогов.
Синтаксис:
ls [ОПЦИИ...] [ФАЙЛ...]
Основные опции:
  • -a — вывести список всех файлов, включая файлы, имена которых начинаются с точки;
  • -l — выводить информацию в длинном формате;
  • -R — выводить рекурсивно информацию о подкаталогах.
Команда cd
Команда cd предназначена для смены текущего каталога. Команда работает как с абсолютными, так и с относительными путями. Если каталог не указан, используется каталог, заданный переменной окружения $HOME (домашний каталог пользователя). Если указан абсолютный путь к каталогу, этот каталог становится текущим.
Для перехода в новый каталог пользователь должен имет право на выполнение, которое в данном случае трактуется как право на поиск.
Синтаксис:
cd [-L|-P] [КАТАЛОГ]
Опции:
  • -L — при изменении текущего каталога следовать по символическим ссылкам (режим по умолчанию);
  • -P — использовать физическую структуру каталогов, разрешая символические ссылки до перехода к каталогу.
Если в качестве аргумента задано «-», то это эквивалентно $OLDPWD.
Если переход выполнен по переменной окружения $CDPATH либо в качестве аргумента указан символ «-», после успешной смены каталога абсолютный путь к новому рабочему каталогу выводится в стандартный вывод.
Примеры:
  • находясь в домашнем каталоге перейти в его подкаталог docs/ (относительный путь):
    cd docs/
  • сделать текущим каталог /usr/bin (абсолютный путь):
    cd /usr/bin/
  • сделать текущим родительский каталог:
    cd ..
  • вернуться в предыдущий каталог:
    cd -
  • сделать текущим домашний каталог:
    cd
Команда pwd
Команда pwd выводит абсолютный путь текущего (рабочего) каталога.
Синтаксис:
pwd [-L|-P]
Опции:
  • -P — выводить физический путь без символических ссылок;
  • -L — выводить символические ссылки.
Команда rm
Команда rm служит для удаления файлов и каталогов. При удалении файла команда удаляет соответствующую запись из каталога. Если эта запись была последней жёсткой ссылкой на файл и файл не используется открытыми процессами, файловая система может освободить занимаемое им пространство.

Предупреждение

Команда rm не предоставляет штатного средства для отмены удаления. Восстановление удалённых данных не гарантируется.
Синтаксис:
rm [ОПЦИИ...] <ФАЙЛ>
Основные опции:
  • -f — не запрашивать подтверждение в случаях, когда оно предусмотрено поведением команды; игнорировать несуществующие файлы;
  • -i — запрашивать подтверждение перед каждым удалением;
  • -r, -R — рекурсивно удалять каталоги и их содержимое.
Пример. Удалить все файлы html в каталоге ~/html, запрашивая подтверждение перед удалением каждого файла:
$ rm -i ~/html/*.html
Команда mkdir
mkdir предназначена для создания каталогов.
Синтаксис:
mkdir [-p] [-m РЕЖИМ] <КАТАЛОГ...>
Основные опции:
  • -m — установить права доступа для создаваемых каталогов;
  • -p — перед созданием нового каталога предварительно создать все несуществующие вышестоящие каталоги. Если каталог уже существует, ошибка не выводится;
  • -v — выводить сообщение о каждом созданном каталоге.
Чтобы создать поддерево каталогов tmpdir/temp/dir, необходимо выполнить команду:
$ mkdir -p tmpdir/temp/dir
Команда rmdir
Команда rmdir предназначена для удаления пустых каталогов.
Синтаксис:
rmdir [-p] <КАТАЛОГ...>
Для команды rmdir доступна опция -p. При указании пути к каталогу команда удаляет указанный каталог и его пустые вышестоящие каталоги.
Например:
$ rmdir -p a/b/c
В данном случае после удаления c команда попытается удалить b, а затем a, если они также пусты.
Команда rmdir часто заменяется командой rm -rf, которая позволяет удалять каталоги, содержащие файлы и другие каталоги.
Команда cp
Команда cp предназначена для копирования файлов и каталогов.
Синтаксис:
cp [-fip] ИСХ_ФАЙЛ... ЦЕЛ_ФАЙЛ...
cp [-fip] ИСХ_ФАЙЛ... КАТАЛОГ
cp [-R] [[-H] | [-L] | [-P]] [-fip] ИСХ_ФАЙЛ... КАТАЛОГ
Основные опции:
  • -p — по возможности сохранять время изменения и время доступа к файлу, владельца, группу и права доступа;
  • -i — запрашивать подтверждение перед перезаписью существующего файла;
  • -r, -R — рекурсивно копировать содержимое каталогов.
Команда mv
Команда mv предназначена для перемещения файлов и каталогов.
Синтаксис:
mv [-fi] ИСХ_ФАЙЛ... ЦЕЛ_ФАЙЛ...
mv [-fi] ИСХ_ФАЙЛ... КАТАЛОГ
В первой синтаксической форме, при которой последний аргумент не является каталогом или символической ссылкой на каталог, mv перемещает исходный файл в целевой файл. При этом файл фактически переименовывается.
Во второй синтаксической форме mv перемещает исходные файлы в указанный каталог, сохраняя их исходные имена.
Основные опции:
  • -f — не запрашивать подтверждения перезаписи существующих файлов;
  • -i — запрашивать подтверждение перед перезаписью существующих файлов.
Команда cat
Команда cat позволяет просматривать содержимое файлов, копируя его в стандартный поток вывода и объединяя содержимое нескольких файлов.
Синтаксис:
cat [ОПЦИИ...] [ФАЙЛ...]
Основные опции:
  • -n, --number — нумеровать выводимые строки;
  • -E, --show-ends — отображать символ «$» в конце каждой строки.
Если файл не задан или задан как «-», данные считываются из стандартного ввода.
Команда head
Команда head выводит первые 10 строк каждого файла в стандартный вывод.
Синтаксис:
head [ОПЦИИ] [ФАЙЛ...]
Основные опции:
  • -n, --lines=[-]K — вывести указанное количество выводимых строк. Если указано отрицательное значение, например -n -3, выводятся все строки, кроме трёх последних;
  • -q, --quiet — не выводить заголовки с именами файлов.
Команда less
Команда less позволяет просматривать текст постранично (для выхода необходимо нажать q).
Синтаксис:
less ФАЙЛ
Команда grep
Команда grep предназначена для поиска строк, соответствующих заданному шаблону, в файлах или стандартном вводе.
Синтаксис:
grep [шаблон_поиска] <ФАЙЛ>

Поиск файлов

Команда find
Команда find используется для поиска файлов.
Синтаксис:
find [-H] [-L] [-P] [-Oуровень] [-D help|tree|search|stat|rates|opt|exec] [ПУТЬ…] [ВЫРАЖЕНИЕ]
В качестве пути для поиска можно использовать как абсолютные, так и относительные пути, а также список путей, разделенных пробелами. По умолчанию поиск выполняется в текущем каталоге. Если выражение не указано, используется выражение -print.
Ключи для поиска:
  • -name — поиск по имени файла;
  • -type — поиск по типу f=файл, d=каталог, l=ссылка(lnk);
  • -user — поиск по владельцу (имя или UID).
Когда выполняется команда find, можно выполнять различные действия над найденными файлами. Основные действия:
  • -exec команда \; — выполнить указанную команду. Запись команды должна заканчиваться экранированной точкой с запятой. Строка {} заменяется именем текущего файла с указанием пути к нему;
  • -execdir команда \; — то же, что и -exec, но команда выполняется из подкаталога, содержащего текущий файл;
  • -ok команда — эквивалентно -exec за исключением того, что перед выполнением команды запрашивается подтверждение. Команда выполняется только после подтверждения пользователя;
  • -print — вывод имени файла на экран.
Примеры:
  • найти в текущем каталоге обычные файлы (не каталоги), имя которых начинается с символа «~»:
    $ find . -type f -name "~*" -print
  • найти в текущем каталоге файлы, измененные позже, чем файл file.bak:
    $ find . -newer file.bak -type f -print
  • удалить все файлы с именами a.out или *.o, доступ к которым не осуществлялся в течение недели:
    find / \( -name a.out -o -name '*.o' \) -atime +7 -exec rm {} \;
  • удалить из текущего каталога и его подкаталогов все файлы нулевого размера, запрашивая подтверждение:
    find . -size 0c -ok rm {} \;
Команда whereis
whereis сообщает путь к исполняемому файлу программы, ее исходным файлам (если они имеются) и соответствующим страницам справочного руководства.
Синтаксис:
whereis [ОПЦИИ...] <ФАЙЛ>
Опции:
  • -b — выводить информацию только об исполняемых файлах;
  • -m — выводить информацию только о страницах справочного руководства;
  • -s — выводить информацию только об исходных файлах.

Мониторинг и управление процессами

Команда ps
Команда ps отображает список текущих процессов.
Синтаксис:
ps [ОПЦИИ...]
Команда ps, запущенная без параметров командной строки, выводит список процессов, связанных с текущим терминалом и принадлежащих текущему пользователю.
Основные опции:
  • -a — выводить информацию о процессах, ассоциированных с терминалами;
  • -f — выводить «полный» список;
  • -l — выводить «длинный» список;
  • -p список  — выводить информацию о процессах с перечисленными в списке PID;
  • -u список — выводить информацию о процессах с перечисленными идентификаторами или именами пользователей.
Команда kill
Команда kill посылает сигнал процессу с указанным идентификатором (по умолчанию — TERM, запрос на завершение процесса).
Синтаксис:
kill [-s] [сигнал] [идентификатор] [...]
kill [-l] [статус_завершения]
kill [-номер_сигнала] [идентификатор] [...]
Идентификатор — PID ведущего процесса задания или номер задания, предварённый знаком «%».
Основные опции:
  • -l — вывести список поддерживаемых сигналов;
  • -s сигнал, -сигнал — послать сигнал с указанным именем.
Если обычная команда kill не дает желательного эффекта, необходимо использовать команду kill с параметром -9 (kill -9 PID_номер).
Команда df
Команда df показывает количество доступного дискового пространства в файловой системе, в которой содержится файл, указанный в качестве аргумента. Если ни один файл не указан, показывается доступное место на всех смонтированных файловых системах. Размеры по умолчанию указываются в блоках по 1 Кбайт.
Синтаксис:
df [ОПЦИИ] [ФАЙЛ...]
Основные опции:
  • --total — подсчитать общий объем в конце;
  • -h, --human-readable — печатать размеры в удобочитаемом формате (например, 1K, 234M, 2G).
Команда du
Команда du подсчитывает использование диска каждым файлом, для каталогов подсчет происходит рекурсивно.
Синтаксис:
du [ОПЦИИ] [ФАЙЛ...]
Основные опции:
  • -a, --all — выводить общую сумму для каждого заданного файла, а не только для каталогов;
  • -c, --total —  подсчитать общий объем в конце. Может быть использовано для выяснения суммарного использования дискового пространства для всего списка заданных файлов;
  • -d, --max-depth=N —  выводить размер каталогов, находящихся не более чем на N уровней ниже каталогов, указанных в аргументах командной строки;
  • -S, --separate-dirs — выдавать отдельно размер каждого каталога, не включая размеры подкаталогов;
  • -s, --summarize — отобразить только сумму для каждого аргумента.
Команда which
Команда which выводит путь к исполняемому файлу, найденному при поиске по каталогам, указанным в переменной окружения PATH.
Синтаксис:
which [ОПЦИИ] <ФАЙЛ...>
Опция -a позволяет вывести все найденные совпадения, а не только первое.

Использование многозадачности

ОС Альт Виртуализация редакция PVE — это многозадачная система.
Для того чтобы запустить программу в фоновом режиме, необходимо набрать «&» после имени программы. После этого оболочка даст возможность запускать другие приложения.
Так как некоторые программы интерактивны — их запуск в фоновом режиме бессмысленен. Подобные программы просто остановятся, если их запустить в фоновом режиме.
Можно также запускать несколько независимых сеансов. Для этого в консоли необходимо набрать Alt и одну из клавиш, находящихся в интервале от F1 до F6. На экране появится новое приглашение системы, и можно открыть новый сеанс. Этот метод также позволяет вам работать на другой консоли, если консоль, которую вы использовали до этого, не отвечает или вам необходимо остановить зависшую программу.
Команда bg
Команда bg позволяет перевести задание на задний план.
Синтаксис:
bg [ИДЕНТИФИКАТОР ...]
Идентификатор — PID ведущего процесса задания или номер задания, предварённый знаком «%».
Команда fg
Команда fg позволяет перевести задание на передний план.
Синтаксис:
fg [ИДЕНТИФИКАТОР ...]
Идентификатор — PID ведущего процесса задания или номер задания, предварённый знаком «%».

Сжатие и упаковка файлов

Команда tar
Команда tar предназначена для объединения одного или нескольких файлов и каталогов в архив без сжатия (tarfile).
Упаковка файлов в архив чаще всего выполняется следующей командой:
tar -cf [имя создаваемого файла архива] [упаковываемые файлы и/или каталоги]
Пример использования команды упаковки архива:
$ tar -cf moi_dokumenti.tar Docs project.tex
Распаковка содержимого архива в текущий каталог выполняется командой:
$ tar -xf [имя файла архива]
Для сжатия файлов используются специальные программы сжатия: gzip, bzip2 и 7z.

⁠53.3. Стыкование команд в системе Linux

⁠53.3.1. Стандартный ввод и стандартный вывод

Многие команды системы имеют так называемые стандартный ввод (standard input) и стандартный вывод (standard output), часто сокращаемые до stdin и stdout. Ввод и вывод здесь — это входная и выходная информация для данной команды. Программная оболочка делает так, что стандартным вводом является клавиатура, а стандартным выводом — экран монитора.
Пример с использованием команды cat. По умолчанию команда cat читает данные из всех файлов, которые указаны в командной строке, и посылает эту информацию непосредственно в стандартный вывод (stdout). Следовательно, команда:
$ cat history-final masters-thesis
выведет на экран сначала содержимое файла history-final, а затем — файла masters-thesis.
Если имя файла не указано, команда cat читает входные данные из stdin и возвращает их в stdout. Пример:
$ cat
Hello there.
Hello there.
Bye.
Bye.
Ctrl-D
Каждая строка, вводимая с клавиатуры, отображается на экране после нажатия клавиши Enter. Для завершения ввода с клавиатуры обычно используют комбинацию клавиш Ctrl+D. В терминале эта комбинация сигнализирует о конце ввода (EOF, End of File), если буфер ввода пуст.

⁠53.3.2. Перенаправление ввода и вывода

При необходимости можно перенаправить стандартный вывод, используя символ >, и стандартный ввод, используя символ <.
Фильтр (filter) — программа, которая читает данные из стандартного ввода, некоторым образом их обрабатывает и результат направляет в стандартный вывод. Когда применяется перенаправление, в качестве стандартного ввода и вывода могут выступать файлы. Как указывалось выше, по умолчанию, stdin и stdout относятся к клавиатуре и к экрану соответственно. Команда sort является простым фильтром — она сортирует входные данные и посылает результат в стандартный вывод. Совсем простым фильтром является команда cat — она ничего не делает с входными данными, а просто пересылает их на выход.

⁠53.3.3. Использование состыкованных команд

Стыковку команд (pipelines) осуществляет командная оболочка, которая stdout первой команды направляет на stdin второй команды. Для стыковки используется символ |. Направить stdout команды ls на stdin команды sort:
$ ls | sort -r
notes
masters-thesis
history-final
english-list
Вывод списка файлов частями:
$ ls /usr/bin | more
Если необходимо вывести на экран последнее по алфавиту имя файла в текущем каталоге, можно использовать следующую команду:
$ ls | sort -r | head -1
где команда head -1 выводит на экран первую строку получаемого ей входного потока строк (в примере поток состоит из данных от команды ls), отсортированных в обратном алфавитном порядке.

⁠53.3.4. Недеструктивное перенаправление вывода

Перенаправление вывода с помощью символа > приводит к перезаписи целевого файла. Например, команда
$ ls > file-list
уничтожит содержимое файла file-list, если этот файл ранее существовал, и создаст на его месте новый файл. Если вместо этого перенаправление будет сделано с помощью символов >>, то вывод будет приписан в конец указанного файла, при этом исходное содержимое файла не будет уничтожено.

Примечание

Перенаправление ввода и вывода и стыкование команд осуществляется командными оболочками, которые поддерживают использование символов >, >> и |. Сами команды не способны воспринимать и интерпретировать эти символы.

⁠Глава 54. Средства управления дискреционными правами доступа

⁠54.1. Команда chmod

Команда chmod предназначена для изменения прав доступа файлов и каталогов.
Синтаксис:
chmod [ОПЦИИ] РЕЖИМ[,РЕЖИМ]... <ФАЙЛ>
chmod [ОПЦИИ] --reference=ИФАЙЛ <ФАЙЛ>
Основные опции:
  • -R — рекурсивно изменять режим доступа к файлам, расположенным в указанных каталогах;
  • --reference=ИФАЙЛ — использовать режим файла ИФАЙЛ.
Команда chmod изменяет права доступа каждого указанного файла в соответствии с правами доступа, указанными в параметре РЕЖИМ. Режим может быть представлен как в символьном виде, так и в числовом (восьмеричном) виде, представляющем битовую маску новых прав доступа.
Формат символьного режима следующий:
[ugoa...][[+-=][разрешения...]...]
Здесь разрешения — это ноль или более букв из набора «rwxXst» или одна из букв из набора «ugo».
Каждый аргумент — это список символьных команд изменения прав доступа, разделённых запятыми. Каждая такая команда начинается с нуля или более букв «ugoa», которые указывают, чьи права доступа к файлу будут изменены:
  • u — владелец файла;
  • g — пользователи, входящие в группу, к которой принадлежит файл (за исключением владельца);
  • o — все остальные пользователи, не являющиеся ни владельцем, ни членами группы;
  • a — все категории пользователей (u, g и o).
Если не задана ни одна буква, то автоматически будет использована буква «a», но биты, установленные в umask, не будут затронуты.

Примечание

Категории пользователей при проверке стандартных прав доступа не пересекаются: права группы не распространяются на владельца файла, а права остальных пользователей — на владельца и членов группы.
Операторы:
  • + — добавляет выбранные права доступа;
  • - — удаляет выбранные права доступа;
  • = — задаёт только указанные права, заменяя существующие.
Буквы «rwxXst» задают биты доступа для пользователей:
  • r — чтение;
  • w — запись;
  • x — выполнение (или поиск для каталогов);
  • X — выполнение/поиск только если это каталог или файл с установленным битом выполнения;
  • s — установка битов setuid (для владельца) или setgid (для группы);
  • t — sticky-бит, предотвращающий удаление файла другими пользователями.
Числовой режим состоит из не более чем четырёх восьмеричных цифр (от 0 до 7). Каждая цифра формируется суммированием значений соответствующих битов: 4, 2 и 1. Пропущенные разряды дополняются ведущими нулями:
  • первый разряд — установка битов setuid (4), setgid (2) и sticky (1);
  • второй разряд — права доступа для владельца: чтение (4), запись (2) и выполнение (1);
  • третий разряд — права доступа для группы: чтение (4), запись (2) и выполнение (1);
  • четвертый разряд — права доступа для остальных пользователей (не входящих в данную группу): чтение (4), запись (2) и выполнение (1).
Примеры:
  • установить права, позволяющие владельцу читать и писать в файл f1, а членам группы и прочим пользователям только читать. Команду можно записать двумя способами:
    $ chmod 644 f1
    $ chmod u=rw,go=r f1
    
  • разрешить выполнение файла f2 всем пользователям:
    $ chmod +x f2
  • ограничить удаление и переименование файлов в каталоге пользователями, не являющимися владельцами этих файлов или владельцем каталога f3:
    $ chmod +t f3
  • дать всем права на чтение, запись и выполнение, а также на установку идентификатора группы при выполнении файла f4:
    $ chmod a=rwx,g+s f4
    $ chmod 2777 f4
    

⁠54.2. Команда chown

Команда chown изменяет владельца и/или группу для каждого заданного файла.
Синтаксис:
chown [КЛЮЧ]…[ВЛАДЕЛЕЦ][:[ГРУППА]] <ФАЙЛ>
chown [ОПЦИИ] --reference=ИФАЙЛ <ФАЙЛ>
Основные опции:
  • -R — рекурсивно изменять файлы и каталоги;
  • --reference=ИФАЙЛ — использовать владельца и группу файла ИФАЙЛ.
Изменить владельца может только владелец файла или суперпользователь.
Владелец не изменяется, если он не задан в аргументе. Группа также не изменяется, если не задана, но если после имени ВЛАДЕЛЬЦА стоит символ «:», подразумевается изменение группы на основную группу указанного владельца. Поля ВЛАДЕЛЕЦ и ГРУППА могут быть заданы как числовыми, так и символьными значениями.
Примеры:
  • поменять владельца каталога /u на пользователя test:
    chown test /u
  • поменять владельца и группу каталога /u:
    chown test:staff /u
  • поменять владельца каталога /u и вложенных файлов на test:
    chown -hR test /u

⁠54.3. Команда chgrp

Команда chgrp изменяет группу для каждого заданного файла.
Синтаксис:
chgrp [ОПЦИИ] ГРУППА <ФАЙЛ>
chgrp [ОПЦИИ] --reference=ИФАЙЛ <ФАЙЛ>
Основные опции:
  • -R — рекурсивно изменять файлы и каталоги;
  • --reference=ИФАЙЛ — использовать группу файла ИФАЙЛ.

⁠54.4. Команда umask

Команда umask задает маску создания файло и каталогов — набор прав доступа, которые не предоставляются при создании объектов файловой системы:
  • файлы создаются с базовым режимом 666;
  • каталоги — с 777;
  • umask вычитается из этого режима.
Синтаксис:
umask [-p] [-S] [режим]
Опции:
  • -p — если РЕЖИМ не указан, выводит данные в форме, которую можно повторно использовать в качестве входных данных;
  • -S — выводит права доступа в символьном формате (по умолчанию маска выводится в восьмеричном формате).
Для установки маски указывается её значение в восьмеричном формате. Три младшие восьмеричные цифры соответствуют правам доступа владельца, группы и остальных пользователей. Биты, установленные в маске, запрещают соответствующие права в базовом режиме доступа.
Например, umask 022 запрещает права на запись для группы и остальных пользователей. При этом базовый режим 777 преобразуется в 755, а 666 — в 644.
Если маска не указана, выводится её текущее значение:
$ umask
0022

$ umask -S
u=rwx,g=rx,o=rx
Команда umask является встроенной командой командного интерпретатора bash.

⁠54.5. Команда chattr

Команда chattr управляет расширенными атрибутами файловых систем ext3 и ext4.
Синтаксис:
chattr [ -RVf ] [+-=aAcCdDeFijmPsStTux] [ -v версия ] <ФАЙЛЫ> …
Опции:
  • -R — рекурсивно изменять атрибуты каталогов и их содержимого. Символические ссылки игнорируются;
  • -V — выводить расширенную информацию и версию программы;
  • -f — подавлять сообщения об ошибках;
  • -v версия — установить номер версии/генерации файла.
Формат символьного режима:
+-=[aAcCdDeFijmPsStTux]
Оператор «+» добавляет указанные атрибуты к существующим; оператор «-» снимает указанные атрибуты; оператор «=» устанавливает только указанные атрибуты.
Символы «aAcCdDeFijmPsStTux» обозначают атрибуты, которые можно устанавливать для файлов и каталогов:
  • a — разрешена только запись в режиме добавления (append-only);
  • A — не обновлять время последнего доступа (atime) к файлу;
  • c — автоматически сжимать файл при записи на диск;
  • C — не использовать механизм Copy-on-Write для файла;
  • d — не включать файл в резервное копирование при использовании команды dump;
  • D — выполнять синхронное обновление каталогов;
  • e — использовать extents для сопоставления блоков файла с блоками на диске; этот атрибут нельзя снять с помощью chattr);
  • F — выполнять регистронезависимый поиск по именам внутри каталога;
  • i — неизменяемый файл (immutable);
  • j — записывать данные файла в журнал файловой системы перед записью непосредственно в файл;
  • m — не сжимать файл;
  • P — обеспечивать иерархическую структуру идентификаторов проектов для каталога;
  • s — безопасное удаление (перед удалением файла все его блоки заполняются нулями и записываются на диск);
  • S — выполнять синхронную запись изменений файла на диск;
  • t — не объединять фрагмент последнего блока файла с другими файлами в файловых системах, поддерживающих tail-merging;
  • T — считать каталог корнем иерархии каталогов при работе алгоритма распределения блоков Orlov;
  • u — сохранять содержимое файла при его удалении, что позволяет запросить восстановление удаленного файла;
  • x — запрашивать использование режима прямого доступа (DAX), если ядро поддерживает DAX.
Не все атрибуты поддерживаются или используются всеми файловыми системами. Дополнительные сведения приведены в документации соответствующей файловой системы.

⁠54.6. Команда lsattr

Команда lsattr показывает расширенные атрибуты файлов.
Синтаксис:
lsattr [ -RVadlpv ] <ФАЙЛЫ> …
Опции:
  • -R — рекурсивно выводить атрибуты каталогов и их содержимого. Символические ссылки игнорируются;
  • -V — выводить расширенную информацию и версию программы;
  • -a — выводить все файлы в каталоге, включая скрытые файлы (имена которых начинаются с «.»);
  • -d — выводить каталоги так же, как и файлы, вместо того, чтобы просматривать их содержимое;
  • -l — выводить параметры, используя длинные имена вместо одного символа;
  • -p — выводить номер проекта файла;
  • -v — выводить номер версии/генерации файла.

⁠54.7. Команда getfacl

Команда getfacl показывает списки контроля доступа (ACL) — расширенные права, дополняющие традиционные.
Синтаксис:
getfacl [ --aceEsRLPtpndvh ] <ФАЙЛ> …
Опции:
  • -a — выводить только ACL файла;
  • -d — выводить только ACL по умолчанию;
  • -c — не показывать заголовок (имя файла);
  • -e — показывать все эффективные права;
  • -E — не показывать эффективные права;
  • -s — пропускать файлы, имеющие только основные записи;
  • -R — для подкаталогов рекурсивно;
  • -L — следовать по символическим ссылкам, даже если они не указаны в командной строке;
  • -P — не следовать по символическим ссылкам, даже если они указаны в командной строке;
  • -t — использовать табулированный формат вывода;
  • -p — не удалять ведущие «/» из пути файла;
  • -n — показывать числовые значения пользователя/группы.
Формат вывода:
1: # file: somedir/
2: # owner: lisa
3: # group: staff
4: # flags: -s-
5: user::rwx
6: user:joe:rwx			#effective:r-x
7: group::rwx			#effective:r-x
8: group:cool:r-x
9: mask:r-x
10: other:r-x
11: default:user::rwx
12: default:user:joe:rwx	#effective:r-x
13: default:group::r-x
14: default:mask:r-x
15: default:other:---
В строках 1–3 указаны имя файла, владелец и группа-владелец.
В строке 4 указаны биты setuid (s), setgid (s) и sticky (t): либо буква, обозначающая бит, либо тире (-). Эта строка включается, если какой-либо из этих битов установлен, и опускается в противном случае, поэтому она не будет отображаться для большинства файлов.
Строки 5, 7 и 10 относятся к традиционным битам прав доступа к файлу, соответственно, для владельца, группы-владельца и всех остальных. Эти три элемента являются базовыми. Строки 6 и 8 являются элементами для отдельных пользователя и группы. Строка 9 — маска эффективных прав. Этот элемент ограничивает эффективные права, предоставляемые всем группам и отдельным пользователям. Маска не влияет на права для владельца файла и всех остальных. Строки 11—15 показывают ACL по умолчанию, ассоциированный с данным каталогом.

⁠54.8. Команда setfacl

Команда setfacl изменяет ACL файлов и каталогов. Параметры задают операции над ACL, после чего указываются файлы и каталоги, к которым эти операции применяются.
Синтаксис:
setfacl [-bkndRLPvh] [{-m|-x} acl_spec] [{-M|-X} acl_file] <ФАЙЛ> …
setfacl --restore=file
Опции:
  • -b — удалить все ACL;
  • -k — удалить ACL по умолчанию;
  • -n — не пересчитывать маску эффективных прав, обычно setfacl пересчитывает маску (кроме случая явного задания маски), чтобы маска включала максимальный набор прав доступа, предоставляемых отдельным пользователям и группам;
  • -d — установить ACL по умолчанию;
  • -R — рекурсивно для подкаталогов;
  • -L — переходить по символическим ссылкам на каталоги (имеет смысл только в сочетании с -R);
  • -P — не переходить по символическим ссылкам на каталоги (имеет смысл только в сочетании с -R);
  • --mask — пересчитать маску эффективных прав;
  • -m — изменить текущий ACL файла;
  • -M — прочитать записи ACL для модификации из файла;
  • -x — удалить записи из ACL файла;
  • -X — прочитать записи ACL для удаления из файла;
  • --restore=file — восстановить резервную копию прав доступа, созданную командой getfacl –R или ей подобной. Все права доступа дерева каталогов восстанавливаются, используя этот механизм. В случае если вводимые данные содержат элементы для владельца или группы-владельца, и команда setfacl выполняется пользователем с именем root, то владелец и группа-владелец всех файлов также восстанавливаются. Эта опция не может использоваться совместно с другими опциями за исключением опции --test;
  • --set=acl — установить ACL файла, заменив текущий ACL;
  • --set-file=file — прочитать записи ACL для установления из файла;
  • --test — режим тестирования (ACL не изменяются).
При использовании опций --set, -m и -x должны быть перечислены записи ACL в командной строке. Элементы ACL разделяются запятыми.
При чтении ACL из файла при помощи опций --set-file, -M и -X команда setfacl принимает множество элементов в формате вывода команды getfacl. В строке обычно содержится не больше одного элемента ACL.
Команда setfacl использует следующие форматы элементов ACL:
  • права доступа отдельного пользователя (если не задан UID, то права доступа владельца файла):
    [d[efault]:] [u[ser]:]uid [:perms]
    
  • права доступа отдельной группы (если не задан GID, то права доступа группы-владельца):
    [d[efault]:] g[roup]:gid [:perms]
    
  • маска эффективных прав:
    [d[efault]:] m[ask][:] [:perms]
    
  • права доступа всех остальных:
    [d[efault]:] o[ther][:] [:perms]
    
Элемент ACL является абсолютным, если он содержит поле perms и является относительным, если он включает один из модификаторов: «+» или «^». Абсолютные элементы могут использоваться в операциях установки или модификации ACL. Относительные элементы могут использоваться только в операции модификации ACL. Права доступа для отдельных пользователей, группы, не содержащие никаких полей после значений UID, GID (поле perms при этом отсутствует), используются только для удаления элементов.
Значения UID и GID задаются именем или числом. Поле perms может быть представлено комбинацией символов «r», «w», «x», «-» или цифр (0—7).
Изначально файлы и каталоги содержат только три базовых элемента ACL: для владельца, группы-владельца и всех остальных пользователей. Существует ряд правил, которые следует учитывать при установке прав доступа:
  • не могут быть удалены сразу три базовых элемента, должен присутствовать хотя бы один;
  • если ACL содержит права доступа для отдельного пользователя или группы, то ACL также должен содержать маску эффективных прав;
  • если ACL содержит какие-либо элементы ACL по умолчанию, то в последнем должны также присутствовать три базовых элемента (т. е. права доступа по умолчанию для владельца, группы-владельца и всех остальных);
  • если ACL по умолчанию содержит права доступа для всех отдельных пользователей или групп, то в ACL также должна присутствовать маска эффективных прав.
Для того чтобы помочь пользователю выполнять эти правила, команда setfacl создает права доступа, используя уже существующие, согласно следующим условиям:
  • если права доступа для отдельного пользователя или группы добавлены в ACL, а маски прав не существует, то создается маска с правами доступа группы-владельца;
  • если создан элемент ACL по умолчанию, а трех базовых элементов не было, тогда делается их копия и они добавляются в ACL по умолчанию;
  • если ACL по умолчанию содержит какие-либо права доступа для конкретных пользователя или группы и не содержит маску прав доступа по умолчанию, то при создании эта маска будет иметь те же права, что и группа по умолчанию.
Пример. Изменить разрешения для файла test.txt, принадлежащего пользователю liza и группе docs, так, чтобы:
  • пользователь ivan имел права на чтение и запись в этот файл;
  • пользователь misha не имел никаких прав на этот файл.
Исходные данные
$ ls -l test.txt
-rw-r-r-- 1 liza docs 8 янв 22 15:54 test.txt
$ getfacl test.txt
# file: test.txt
# owner: liza
# group: docs
user::rw-
group::r--
other::r--
Установить разрешения (от пользователя liza):
$ setfacl -m u:ivan:rw- test.txt
$ setfacl -m u:misha:--- test.txt
Просмотреть разрешения (от пользователя liza):
$ getfacl test.txt
# file: test.txt
# owner: liza
# group: docs
user::rw-
user:ivan:rw-
user:misha:---
group::r--
mask::rw-
other::r--

Примечание

Символ «+» (плюс) после прав доступа в выводе команды ls -l указывает на использование ACL:
$ ls -l test.txt
-rw-rw-r--+ 1 liza docs 8 янв 22 15:54 test.txt

⁠Глава 55. Режим суперпользователя

⁠55.1. Какие бывают пользователи?

Linux — система многопользовательская, а потому пользователь — ключевое понятие для организации всей системы доступа в Linux. Файлы всех пользователей в Linux хранятся раздельно, у каждого пользователя есть собственный домашний каталог, в котором он может хранить свои данные. Доступ других пользователей к домашнему каталогу пользователя может быть ограничен.
Суперпользователь в Linux — это выделенный пользователь системы, на которого не распространяются ограничения прав доступа. Именно суперпользователь имеет возможность произвольно изменять владельца и группу файла. Ему открыт доступ на чтение и запись к любому файлу или каталогу системы.
Среди учётных записей Linux всегда есть учётная запись суперпользователя — root. Поэтому вместо «суперпользователь» часто говорят «root». Множество системных файлов принадлежат root, множество файлов только ему доступны для чтения или записи. Пароль этой учётной записи — одна из самых больших драгоценностей системы. Именно с её помощью системные администраторы выполняют самую ответственную работу.

⁠55.2. Как получить права суперпользователя?

Для опытных пользователей, умеющих работать с командной строкой, существует два различных способа получить права суперпользователя.
Первый — это зарегистрироваться в системе под именем root.
Второй способ — воспользоваться специальной утилитой su (shell of user), которая позволяет выполнить одну или несколько команд от лица другого пользователя. По умолчанию эта утилита выполняет команду sh от пользователя root, то есть запускает командный интерпретатор. Отличие от предыдущего способа в том, что всегда известно, кто именно запускал su, а значит, ясно, кто выполнил определённое административное действие.
В некоторых случаях удобнее использовать не su, а утилиту sudo, которая позволяет выполнять только заранее заданные команды.

Важно

Для того чтобы воспользоваться командами su и sudo, необходимо быть членом группы wheel. Пользователь, созданный при установке системы, по умолчанию уже включён в эту группу.
В дистрибутивах Альт для управления доступом к важным службам используется подсистема control. control — механизм переключения между неким набором фиксированных состояний для задач, допускающих такой набор.
Команда control доступна только для суперпользователя (root). Для того чтобы посмотреть, что означает та или иная политика control (разрешения выполнения конкретной команды, управляемой control), надо запустить команду с ключом help:
# control su help
Запустив control без параметров, можно увидеть полный список команд, управляемых командой (facilities) вместе с их текущим состоянием и набором допустимых состояний.

⁠55.3. Как перейти в режим суперпользователя?

Для перехода в режим суперпользователя наберите в терминале команду (минус важен!):
su -
Если воспользоваться командой su без ключа, то происходит вызов командного интерпретатора с правами root. При этом значение переменных окружения, в частности $PATH, остаётся таким же, как у пользователя: в переменной $PATH не окажется каталогов /sbin, /usr/sbin, без указания полного имени будут недоступны команды route, shutdown, mkswap и другие. Более того, переменная $HOME будет указывать на каталог пользователя, все программы, запущенные в режиме суперпользователя, сохранят свои настройки с правами root в каталоге пользователя, что в дальнейшем может вызвать проблемы.
Чтобы избежать этого, следует использовать su -. В этом режиме su запустит командный интерпретатор в качестве login shell, и он будет вести себя в точности так, как если бы в системе зарегистрировался root.

⁠Глава 56. Управление пользователями

⁠56.1. Общая информация

Пользователи и группы внутри системы обозначаются цифровыми идентификаторами — UID и GID, соответственно.
Пользователь может входить в одну или несколько групп. По умолчанию он входит в группу, совпадающую с его именем. Чтобы узнать, в какие еще группы входит пользователь, введите команду id, вывод её может быть примерно следующим:
uid=1000(test) gid=1000(test) группы=1000(test),16(rpm)
Такая запись означает, что пользователь test (цифровой идентификатор 1000) входит в группы test и rpm. Разные группы могут иметь разный уровень доступа к тем или иным каталогам; чем в большее количество групп входит пользователь, тем больше прав он имеет в системе.

Примечание

В связи с тем, что большинство привилегированных системных утилит в дистрибутивах Альт имеют не SUID-, а SGID-бит, будьте предельно внимательны и осторожны в переназначении групповых прав на системные каталоги.

⁠56.2. Команда useradd

Команда useradd регистрирует нового пользователя или изменяет информацию по умолчанию о новых пользователях.
Синтаксис:
useradd [ОПЦИИ...] <ИМЯ ПОЛЬЗОВАТЕЛЯ>
useradd -D [ОПЦИИ...]
Некоторые опции:
  • -b каталог — базовый каталог для домашних каталогов пользователей;
  • -c комментарий — произвольная текстовая строка (обычно используется для указания фамилии и имени);
  • -d каталог — каталог, который будет использоваться в качестве домашнего каталога пользователя. По умолчанию имя домашнего каталога формируется на основе базового каталога и имени пользователя;
  • -D — показать или изменить настройки по умолчанию для useradd;
  • -e дата — дата устаревания новой учётной записи;
  • -g группа — имя или числовой идентификатор начальной группы пользователя. Указанная группа должна существовать;
  • -G группы — список дополнительных групп пользователя. Группы перечисляются через запятую без пробелов;
  • -m — создать домашний каталог пользователя;
  • -M — не создавать домашний каталог пользователя;
  • -p пароль — зашифрованное значение пароля, полученное с помощью функции crypt (не рекомендуется);
  • -s оболочка — регистрационная оболочка учётной записи (по умолчанию /bin/bash);
  • -u UID — числовой идентификатор пользователя.
Команда useradd имеет множество параметров, которые позволяют менять её поведение по умолчанию. Например, можно принудительно указать, какой будет UID или какой группе будет принадлежать пользователь:
# useradd -u 1500 -G usershares new_user

⁠56.3. Команда passwd

Команда passwd поддерживает традиционные опции passwd и утилит shadow.
Синтаксис:
passwd [ОПЦИИ...] [ИМЯ ПОЛЬЗОВАТЕЛЯ]
Возможные опции:
  • -d, --delete — удалить пароль для указанной учетной записи;
  • -f, --force — принудительно выполнить операцию;
  • -k, --keep-tokens — сохранить не истекшие пароли;
  • -l, --lock — заблокировать указанную учетную запись;
  • --stdin — прочитать новый пароль из стандартного ввода;
  • -S, --status — вывести сведения о состоянии пароля в указанной учетной записи;
  • -u, --unlock — разблокировать указанную учетную запись;
  • -?, --help — показать справку и выйти;
  • --usage — показать короткую справку по использованию;
  • -V, --version — показать версию программы и выйти.
Код выхода: при успешном завершении passwd возвращает код выхода 0. Код выхода 1 означает ошибку. Текстовое описание ошибки выводится в стандартный поток ошибок.
При изменении собственного пароля пользователь должен указать текущий пароль, после чего дважды ввести новый пароль.
Только суперпользователь может обновить пароль другого пользователя.

⁠56.4. Добавление нового пользователя

Для добавления нового пользователя используйте команды useradd и passwd:
# useradd test1

# passwd test1
passwd: updating all authentication tokens for user test1.

You can now choose the new password or passphrase.

A valid password should be a mix of upper and lower case letters, digits, and
other characters.  You can use a password containing at least 7 characters
from all of these classes, or a password containing at least 8 characters
from just 3 of these 4 classes.
An upper case letter that begins the password and a digit that ends it do not
count towards the number of character classes used.

A passphrase should be of at least 3 words, 11 to 72 characters long, and
contain enough different characters.

Alternatively, if no one else can see your terminal now, you can pick this as
your password: "Burst*texas$Flow".

Enter new password:
Weak password: too short.
Re-type new password:
passwd: all authentication tokens updated successfully.
В результате описанных действий в системе появился пользователь test1 с некоторым паролем. Если пароль оказался слишком слабым с точки зрения системы, она об этом предупредит (как в примере выше). Пользователь в дальнейшем может поменять свой пароль при помощи команды passwd — но если он попытается поставить слабый пароль, система откажет ему (в отличие от root) в изменении.
В Альт Виртуализация редакция PVE для проверки паролей на слабость используется модуль PAM passwdqc.

⁠56.5. Настройка парольных ограничений

В Альт Виртуализация редакция PVE для проверки паролей на соответствие требованиям сложности используется подключаемый модуль аутентификации (Pluggable Authentication Modules, далее — PAM) passwdqc.
Основной конфигурационный файл — /etc/passwdqc.conf.
Файл passwdqc.conf состоит из 0 или более строк следующего формата:
опция=значение
Пустые строки и строки, начинающиеся со знака решетки («#»), игнорируются. Символы пробела между опцией и значением не допускаются.
Опции, которые могут быть переданы в модуль (в скобках указаны значения по умолчанию): min=N0,N1,N2,N3,N4 (min=disabled,24,11,8,7) — минимально допустимая длина пароля.
Используемые типы паролей по классам символов (алфавит, число, спецсимвол, верхний и нижний регистр) определяются следующим образом:
  • тип N0 используется для паролей, состоящих из символов только одного класса;
  • тип N1 используется для паролей, состоящих из символов двух классов;
  • тип N2 используется для парольных фраз, требования к длине, парольная фраза должна также состоять из достаточного количества слов;
  • типы N3 и N4 используются для паролей, состоящих из символов трех и четырех классов, соответственно.
Ключевое слово disabled используется для запрета паролей выбранного типа N0 — N4 независимо от их длины.

Примечание

Каждое следующее число в настройке min не должно превышать предыдущее.
При определении количества классов символов, заглавные буквы, используемые в качестве первого символа и цифры, используемые в качестве последнего символа пароля, не учитываются.
max=N (max=72) — максимально допустимая длина пароля. Эта опция может быть использована, чтобы запретить пользователям устанавливать пароли, которые могут быть слишком длинными для некоторых системных служб. При max=8 длинные пароли обрабатываются особым образом: пароли длиннее 8 символов не отклоняются, а обрезаются до 8 символов при проверке надежности (пользователь при этом предупреждается), но сохраняются целиком.
passphrase=N (passphrase=3) — минимальное число слов в парольной фразе (значение 0 отключает поддержку парольных фраз).
match=N (match=4) — минимальная длина подстроки, совпадающей с известными данными (имя, логин и т.д.). При обнаружении такая подстрока игнорируется при оценке сложности, но пароль не отклоняется. Значение 0 отключает поиск подстроки. Поиск подстроки нечувствителен к регистру и может обнаружить и удалить общую подстроку, написанную в обратном направлении.
similar=permit|deny (similar=deny) — запрет (deny) или разрешение (permit) установки пароля, похожего на старый. Пароли считаются похожими, если имеется достаточно длинная общая подстрока, и при этом новый пароль с частично удаленной подстрокой будет слабым.
random=N[,only] (random=47) — длина случайно сгенерированной парольной фразы (в битах). При флаге only пользователь не может задавать собственные пароли. Длина может быть от 24 до 136. Значение 0 отключает эту функцию. Любая парольная фраза, содержащая предложенную случайно сгенерированную строку, будет разрешена вне зависимости от других возможных ограничений.
enforce=none|users|everyone (enforce=users) — область применения политики:
  • users — политика применяется к обычным пользователям;
  • everyone — политика применяется ко всем, включая root;
  • none — модуль PAM будет только предупреждать о слабых паролях.
retry=N (retry=3) — количество запросов нового пароля, если пользователь с первого раза не сможет ввести достаточно надежный пароль и повторить его ввод.
Пример конфигурации:
min=8,7,4,4,4
enforce=everyone
В указанном примере пользователи (включая root) не смогут задать:
  • одноклассовые пароли — короче 8 символов;
  • двухклассовые — короче 7;
  • парольные фразы и сложные пароли — короче 4 символов.

⁠56.6. Управление сроком действия пароля

Для управления сроком действия паролей используется команда chage.

Примечание

Должен быть установлен пакет shadow-change:
# apt-get install shadow-change
chage изменяет количество дней между сменой пароля и датой последнего изменения пароля.
Синтаксис команды:
chage [опции] логин
Основные опции:
  • -d, --lastday LAST_DAY — дата последней смены пароля (YYYY-MM-DD) или количество дней с 1 января 1970;
  • -E, -expiredate EXPIRE_DAYS — дата окончания действия учетной записи (количество дней с 1 января 1970). Дата также может быть указана в формате ГГГГ-ММ-ДД. Значение -1 удаляет дату окончания действия учетной записи;
  • -I, --inactive INACTIVE — количество дней неактивности до блокировки учетной записи. Пользователь, чья учетная запись заблокирована, должен обратиться к системному администратору, прежде чем снова сможет использовать систему. Значение -1 отключает этот режим;
  • -l, --list —  показать текущие настройки;
  • -m, --mindays MIN_DAYS — минимальный интервал между сменами пароля (0 — без ограничений);
  • -M, --maxdays MAX_DAYS — максимальный срок действия пароля. Когда сумма MAX_DAYS и LAST_DAY меньше текущего дня, у пользователя будет запрошен новый пароль до начала работы в системе. Эта операция может предваряться предупреждением (параметр -W). При установке значения -1 проверка действительности пароля выполняться не будет;
  • -W, --warndays WARN_DAYS — за сколько дней до истечения срока предупреждать пользователя о необходимости смены пароля.
Примеры:
  • установить для пользователя test максимальный срок действия пароля — 5 дней:
    # chage -M 5 test
    
  • получить информацию о «возрасте» учётной записи пользователя test:
    # chage -l test
    Последний раз пароль был изменён				: мар 13, 2025
    Срок действия пароля истекает					: мар 18, 2025
    Пароль будет деактивирован через				: никогда
    Срок действия учётной записи истекает				: никогда
    Минимальное количество дней между сменой пароля			: -1
    Максимальное количество дней между сменой пароля		: 5
    Количество дней с предупреждением перед деактивацией пароля	: -1
    

Примечание

Глобальные настройки (для вновь создаваемых пользователей) по умолчанию задаются в файле /etc/login.defs (параметры PASS_MAX_DAYS, PASS_MIN_DAYS и др.).

⁠56.7. Настройка неповторяемости пароля

Для настройки истории паролей используется модуль PAM pam_pwhistory, который сохраняет хеши предыдущих паролей каждого пользователя и запрещает повторное использование паролей, входящих в историю.

Предупреждение

После данной настройки системный каталог станет доступным для записи пользователям группы pw_users (создайте эту группу и включите туда пользователей).

Предупреждение

База используемых паролей ведется в файле /etc/security/opasswd, в который пользователи должны иметь доступ на чтение и запись. При этом они могут читать хеши паролей остальных пользователей. Не рекомендуется использовать на многопользовательских системах.
Создайте файл /etc/security/opasswd и дайте права на запись пользователям:
# install -Dm0660 -gpw_users /dev/null /etc/security/opasswd
# chgrp pw_users /etc/security
# chmod g+w /etc/security
Для настройки ограничения необходимо изменить файл /etc/pam.d/system-auth-local-only, добавив директиву pam_pwhistory.so после директивы pam_passwdqc.so в стеке password:
password        required        pam_passwdqc.so config=/etc/passwdqc.conf
password        required        pam_pwhistory.so debug use_authtok remember=10 retry=3
Параметры модуля:
  • use_authtok — использовать пароль, полученный от предыдущего модуля PAM;
  • remember=10 — хранить историю из 10 предыдущих паролей пользователя;
  • retry=3 — разрешить пользователю до трёх попыток ввода нового пароля.
База истории паролей хранится в файле /etc/security/opasswd. В нём содержатся хеши предыдущих паролей пользователей.
При попытке повторно использовать пароль из истории пользователь получит сообщение об ошибке:
Password has been already used. Choose another.
По умолчанию проверка истории паролей не применяется к суперпользователю root. Чтобы включить проверку и для него, добавьте параметр enforce_for_root:
password        required        pam_pwhistory.so use_authtok enforce_for_root remember=10 retry=3

⁠56.8. Модификация пользовательских записей

Для изменения параметров учётных записей пользователей применяется утилита usermod.
Например, команда:
# usermod -G audio,rpm,test1 test1
заменяет список дополнительных групп пользователя test1 указанными группами: audio, rpm и test1. Членство в других дополнительных группах при этом удаляется.
Чтобы добавить пользователя в указанные дополнительные группы, сохранив его членство в остальных группах, используйте параметр -aG:
# usermod -aG audio,rpm,test1 test1
Изменения вступят в силу при следующем входе пользователя в систему.
Для изменения имени пользователя используется команда:
# usermod -l test2 test1
Она изменяет имя учётной записи test1 на test2. При этом домашний каталог автоматически не переименовывается.
Команда:
# usermod -L
блокирует пароль пользователя test2, а команда:
# usermod -U
снимает блокировку пароля.
Для неинтерактивного задания или изменения паролей нескольких пользователей применяется утилита chpasswd. На стандартный вход ей передают список паролей, в котором каждая строка содержит имя пользователя и пароль, разделённые двоеточием:
имя_пользователя:пароль

⁠56.9. Удаление пользователей

Для удаления учётных записей пользователей применяется утилита userdel.
Команда:
# userdel test2
удаляет учётную запись пользователя test2, но не удаляет его домашний каталог.
Если требуется также удалить домашний каталог пользователя и его почтовый ящик, используйте параметр -r:
# userdel -r test2
Перед удалением учётной записи рекомендуется завершить все процессы пользователя. Наличие работающих процессов может привести к ошибке при выполнении команды userdel.

⁠Глава 57. Система инициализации systemd

⁠57.1. Запуск системы

Запуск операционной системы включает следующие основные этапы:
  1. Инициализация оборудования прошивкой BIOS или UEFI.
  2. Запуск загрузчика операционной системы (например, GRUB). В загрузчике можно задать параметры запуска ядра.
  3. Загрузка ядра Linux.
  4. Запуск первого пользовательского процесса — процесса с идентификатором PID 1.
Первый пользовательский процесс системы отвечает за запуск необходимых системных процессов и служб, а также за управление их работой.
Посмотреть иерархию процессов можно с помощью команды:
$ pstree -p 1
Используемая система инициализации определяется программой, запущенной в качестве первого пользовательского процесса (PID 1).

⁠57.2. Система инициализации

Система инициализации — это совокупность программ и механизмов, обеспечивающих запуск системы, служб и процессов после загрузки ядра, а также управление их состоянием.
В ОС Альт Виртуализация редакция PVE используется система инициализации systemd.

⁠57.3. Управление службами в systemd

Для управления службами в ОС Альт Виртуализация редакция PVE используется команда systemctl. Команды service и chkconfig, применявшиеся в системах с SysVinit, в некоторых случаях сохраняют совместимость с systemd. Однако для управления службами рекомендуется использовать systemctl.
⁠

Таблица 57.1. Команды управления службами

Команды service и chkconfig
Команды systemd
Назначение
service <name_service> start
systemctl start <name_service>.service
Запускает службу
service <name_service> stop
systemctl stop <name_service>.service
Останавливает службу
service <name_service> restart
systemctl restart <name_service>.service
Перезапускает службу
service <name_service> reload
systemctl reload <name_service>.service
Перечитывает конфигурацию службы, если она поддерживает эту операцию
service <name_service> condrestart
systemctl try-restart <name_service>.service
Перезапускает службу, только если она уже работает
service <name_service> status
systemctl status <name_service>.service
Показывает текущее состояние службы
chkconfig <name_service> on
systemctl enable <name_service>.service
Настраивает автоматический запуск службы
chkconfig <name_service> off
systemctl disable <name_service>.service
Отключает автоматический запуск службы
chkconfig <name_service>
systemctl is-enabled <name_service>.service
Показывает, включён ли автоматический запуск службы
chkconfig --list
systemctl list-unit-files --type=service
Выводит список файлов модулей служб и состояние их включения

⁠Глава 58. Что происходит в системе

⁠58.1. Введение в журналирование

Для обеспечения работоспособности системы важно отслеживать происходящие в ней события. Однако из-за сложности компьютерных систем обработка всех событий вручную затруднительна. Поэтому системную информацию необходимо фильтровать, классифицировать и сохранять в журналах для последующего анализа.
В ОС Альт Виртуализация редакция PVE для сбора и записи системных сообщений используется служба systemd-journald. Она собирает сообщения ядра, системных служб и пользовательских процессов, в том числе сообщения, передаваемые через интерфейс syslog библиотеки GNU C Library (glibc), а также сообщения, поступающие через стандартные потоки вывода и ошибок служб.
Журналы systemd-journald хранятся в структурированном бинарном формате, поэтому для их просмотра рекомендуется использовать утилиту journalctl.
По умолчанию журналы хранятся в каталоге /var/log/journal.

⁠58.2. Просмотр журналов

Для просмотра сообщений системного журнала используется команда journalctl. Например:
  • journalctl -b — выводит сообщения с момента текущей загрузки системы;
  • journalctl -f — выводит последние записи журнала и продолжает отображать новые записи по мере их поступления.
  • journalctl _PID=1 —  выводит сообщения, связанные с процессом с идентификатором PID 1.
Для ознакомления с другими возможностями команды используйте справочную страницу:
$ man journalctl
Некоторые службы ведут собственные журналы. Например, веб-сервер Apache может записывать сообщения в отдельные файлы. Сведения о расположении и настройке таких журналов следует искать в документации соответствующей службы и её конфигурационных файлах. Обычно журналы хранятся в каталоге /var/log/.
Файл конфигурации службы systemd-journald — /etc/systemd/journald.conf. Справочную информацию о нём можно получить с помощью команды man journald.conf.

⁠58.3. Очистка и ограничение размера журналов

По мере накопления сообщений системный журнал занимает всё больше дискового пространства. Чтобы предотвратить переполнение файловой системы, необходимо контролировать размер журналов и при необходимости удалять устаревшие записи.
Узнать общий объём файлов системного журнала можно с помощью команды:
# journalctl --disk-usage
Для удаления старых архивных файлов журналов можно использовать следующие параметры:
  • --vacuum-size — удаляет наиболее старые архивные файлы, пока их суммарный размер не станет меньше указанного значения. Например, следующая команда удаляет архивные файлы журналов, пока их суммарный размер не станет меньше указанного значения:
    # journalctl --vacuum-size=200M
  • --vacuum-time — удаляет архивные файлы, содержащие записи старше указанного периода. Например, для удаления архивных файлов старше одного месяца выполните:
    # journalctl --vacuum-time=1months

Примечание

Эти параметры воздействуют только на архивные файлы журналов, а не на активные файлы. Поэтому фактический размер журнала после очистки может превышать заданное значение. Команда journalctl --disk-usage учитывает как активные, так и архивные файлы.

⁠58.4. Настройка ротации и хранения журналов

Параметры хранения и ротации журналов задаются в файле /etc/systemd/journald.conf. Например:
  • SystemMaxUse=1G — ограничивает общий объём дискового пространства, используемого постоянными журналами;
  • SystemMaxFileSize=200M — ограничивает размер отдельного файла постоянного журнала;
  • MaxFileSec=20day — задаёт максимальный период хранения записей в одном файле до перехода к следующему файлу журнала;
  • MaxRetentionSec=1months — задаёт максимальный период хранения записей журнала.

Примечание

После внесения изменений в файл /etc/systemd/journald.conf необходимо перезапустить службу systemd-journald:
# systemctl restart systemd-journald

Примечание

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

⁠58.5. Учёт входов пользователей и анализ состояния системы

Сведения о сеансах работы пользователей в системе можно получить с помощью следующих команд:
  • last — выводит сведения о предыдущих сеансах входа пользователей в систему;
  • w — показывает сведения о пользователях, вошедших в систему в данный момент, и выполняемых ими процессах;
  • who — выводит сведения о пользователях, вошедших в систему в данный момент.
Для анализа состояния и загрузки системы можно использовать следующие утилиты:
  • ps, top, vmstat — для получения сведений о процессах, использовании процессорного времени и оперативной памяти;
  • du, df — для анализа использования дискового пространства;
  • ss — для просмотра состояния сетевых соединений и сокетов.

⁠Глава 59. Документация

Каждый объект системы Linux сопровождается документацией, описывающей его назначение и способы использования. От пользователя системы не требуется заучивать все возможные варианты взаимодействия с ней. Достаточно понимать основные принципы её устройства и уметь находить справочную информацию.
Не пренебрегайте чтением документации: она поможет избежать многих сложностей, сэкономить время и усилия при установке, настройке и администрировании системы, найти нужное приложение и быстро разобраться в нём.

⁠59.1. Экранная документация

Почти все операционные системы семейства UNIX и Linux предоставляют экранную документацию. Она включает описания системных команд, ресурсов и конфигурационных файлов, которые можно просматривать непосредственно в терминале.

⁠59.1.1. man

Для доступа к экранной документации используется команда man (сокращение от manual). Каждая страница руководства посвящена одному объекту системы. Для просмотра страницы руководства по программе, необходимо выполнить команду man название_программы. К примеру, если вы хотите узнать, какие опции есть у команды date, вы можете ввести команду:
$ man date
Экранная документация обычно предназначена для пользователей, имеющих некоторое представление о назначении команды. Поэтому в ней, как правило, приводятся технические сведения без подробных пояснений. Тем не менее, экранная документация оказывается очень ценной в том случае, если вы помните название команды, но её синтаксис просто выпал у вас из памяти.
Поиск по описаниям man осуществляется командой apropos. Если вы точно не знаете, как называется необходимая вам программа, то поиск осуществляется по ключевому слову, к примеру, apropos date или при помощи ввода слова, обозначающего нужное действие, после команды man -k (например, man -k copy). Слово, характеризующее желаемое для вас действие, можно вводить и на русском языке. При наличии русского перевода страниц руководства man результаты поиска будут выведены на запрашиваемом языке.
«Страница руководства» занимает, как правило, больше одной страницы экрана. Для того чтобы читать было удобнее, man запускает программу постраничного просмотра текстов. Страницы перелистывают пробелом, для выхода из режима чтения описания команд man необходимо нажать на клавиатуре q. Команда man man выдаёт справку по пользованию самой командой man.
Документация в подавляющем большинстве случаев пишется на простом английском языке. Необходимость писать на языке, который будет более или менее понятен большинству пользователей, объясняется постоянным развитием Linux. Дело не в том, что страницу руководства нельзя перевести, а в том, что её придётся переводить всякий раз, когда изменится описываемый ею объект! Например, выход новой версии программного продукта сопровождается изменением его возможностей и особенностей работы, а следовательно, и новой версией документации.
Тем не менее некоторые актуальные руководства доступны на русском языке. Переводы страниц руководства на русский язык входят в пакет man-pages-ru. Установив этот пакет, вы добавите в систему руководства, для которых есть перевод, и man по умолчанию будет отображать их на русском языке.

⁠59.1.2. info

Другой источник информации о Linux и составляющих его программах — справочная подсистема info. Страница руководства, несмотря на обилие ссылок различного типа, остаётся «линейным» текстом, структурированным только логически. Документ в формате info представляет собой гипертекст, в котором небольшие страницы объединены в дерево. В каждом разделе документа info всегда есть оглавление, из которого можно перейти к нужному подразделу, а затем вернуться обратно (ссылки для перемещения по разделам текста помечены *). Для получения вспомогательной информации о перемещении по тексту используйте клавишу h. Полное руководство info вызывается командой info info. Команда info, введённая без параметров, предлагает пользователю список всех документов info, установленных в системе.

⁠59.2. Документация по пакетам

Дополнительным источником информации об интересующей вас программе, в основном на английском языке, является каталог /usr/share/doc — место хранения разнообразной документации.
Вместе с программным обеспечением пакет обычно содержит документацию, которая располагается в каталоге /usr/share/doc/имя_пакета. Например, документация к пакету file-5.45 находится в /usr/share/doc/file-5.45. Для получения полного списка файлов документации, относящихся к пакету, воспользуйтесь командой rpm -qd имя_установленного_пакета.
В документации к пакету могут находиться такие файлы, как README, FAQ, TODO, СhangeLog и другие. В файле README содержится основная информация о программе — имя и контактные данные авторов, назначение, полезные советы и пр. FAQ содержит ответы на часто задаваемые вопросы; этот файл стоит прочитать в первую очередь, если у вас возникли проблемы или вопросы по использованию программы, поскольку большинство проблем и сложностей типичны, вполне вероятно, что в FAQ вы тут же найдёте готовое решение. В файле TODO перечислены задачи, которые разработчики планируют реализовать. В файле СhangeLog записана история изменений в программе от версии к версии.
Для получения сведений об установленном пакете, в том числе адреса сайта программы, можно использовать команду rpm -qi имя_установленного_пакета. В выводе команды среди прочих сведений будет указан адрес сайта, если он задан в метаданных пакета.

⁠Часть VII. Техническая поддержка продуктов «Базальт СПО»

⁠Глава 60. Покупателям нашей продукции

«Базальт СПО» предоставляет следующие виды технической поддержки:
  • Поддержка продукта входит в стоимость лицензии и включает регулярный выпуск обновлений, исправление ошибок и устранение уязвимостей в течение всего срока жизненного цикла дистрибутива.
  • Поддержка пользователей обеспечивает качественную эксплуатацию продукта. Техническая поддержка эксплуатации продуктов «Базальт СПО» предоставляется в соответствии с условиями SLA. Доступны три уровня SLA («Базовый», «Стандартный» и «Расширенный»).
Право на получение консультационной и технической поддержки вы приобретаете при покупке большинства продуктов торговой марки Альт. Сроки и объём помощи указаны в сертификате технической поддержки.
Условия технической поддержки можно найти на странице сайта «Базальт СПО»: https://www.basealt.ru/support.

⁠Глава 61. Пользователям нашей продукции

Независимо от того, скачали вы дистрибутив или приобрели его, вы можете задавать вопросы и обсуждать их с сообществом пользователей Альт на форуме и в списках рассылки.
Помощь сообщества:
Ресурсы компании «Базальт СПО»:
Форум и списки рассылки читают опытные пользователи, профессиональные системные администраторы и разработчики «Базальт СПО». Сообщество пользователей и специалистов поможет найти ответ на ваш вопрос или предложит решение возникшей проблемы. При обращении за помощью к сообществу не гарантируются полнота и своевременность ответов. Тем не менее участники сообщества стараются отвечать на вопросы, поступающие в списки рассылки.