Администрирование и не только: Руководство администратора Proxmox VE R 6.0 Глава 3.

Proxmox VE Administration Guide

Администрирование host системы

Proxmox VE основан на известном дистрибутиве Debian Linux. Это означает, что у вас есть доступ ко всему миру пакетов Debian, и базовая система хорошо документирована. Руководство администратора Debian доступно в интернете и содержит полное введение в операционную систему Debian (см. [Hertzog13]). Стандартная установка Proxmox VE использует репозитории по умолчанию из Debian, поэтому вы получаете исправления ошибок и обновления безопасности через этот канал. Кроме того, мы предоставляем наш собственный репозиторий пакетов для развертывания всех связанных пакетов Proxmox VE. Это включает в себя обновления некоторых пакетов Debian, когда это необходимо.
Мы также поставляем специально оптимизированное ядро Linux, где мы включаем всю необходимую виртуализацию и контейнер.
особенности. Это ядро включает драйверы для ZFS и несколько драйверов оборудования. Например, мы поставляем драйверы сетевых карт Intel для поддержки их новейшего оборудования. Следующие разделы будут посвящены темам, связанным с виртуализацией. Они либо объясняют вещи, которые отличаются на Proxmox VE, либо задачи, которые обычно используются на Proxmox VE. Для других тем, пожалуйста, обратитесь к стандартной документации Debian.

Репозитории Пакетов
Все системы на базе Debian используют APT в качестве инструмента управления пакетами. Список репозиториев определяется в файле /etc/apt/sources.list и .list файлами, присутствующими внутри /etc/apt/sources.d/. Обновления могут быть установлены непосредственно с помощью apt-get или через графический интерфейс. В apt sources.list файлах перечислите один репозиторий пакетов в строке, причем наиболее предпочтительный источник указывается первым. Пустые строки игнорируются, а символ # в любом месте строки помечает оставшуюся часть этой строки как комментарий. Информация, доступная из настроенных источников, получается программой apt update. Файл /etc/apt/sources.list:
```
deb http://ftp.debian.org/debian buster main contrib
deb http://ftp.debian.org/debian buster-updates main contrib
# security updates
deb http://security.debian.org buster/updates main contrib
```
Кроме того, Proxmox VE предоставляет три различных репозитория пакетов.
1. Репозиторий Proxmox VE Enterprise
  Это стандартный, стабильный и рекомендуемый репозиторий, доступный для всех пользователей подписки Proxmox VE. Он содержит самые стабильные пакеты и подходит для production использования. Репозиторий pve-enterprise включен по умолчанию: Файл /etc/apt/sources.list
```
deb https://enterprise.proxmox.com/debian/pve buster pve-enterprise
```
  Как только обновления доступны, пользователь root@pam получает уведомление по электронной почте о доступных новых пакетах. В графическом интерфейсе можно просмотреть журнал изменений каждого пакета (если он доступен), будут показаны все детали обновления. Таким образом, вы никогда не пропустите важные исправления безопасности.
  Обратите внимание, что для доступа к этому репозиторию требуется действительный ключ подписки. Мы предлагаем различные уровни поддержки, и вы можете найти более подробную информацию на https://www.proxmox.com/en/proxmox-ve/pricing.
  
  Примечание
  
  Вы можете отключить этот репозиторий, закомментировав приведенную выше строку с помощью # (в начале строки). Это предотвращает сообщения об ошибках, если у вас нет ключа подписки. В этом случае настройте репозиторий pve-no-subscription.
2. Proxmox VE No-Subscription Repository
  Как следует из названия, вам не нужен ключ подписки для доступа к этому репозиторию. Он может быть использован для тестирования и непроизводственного использования. Его не рекомендуется запускать на производственных серверах, так как эти пакеты не всегда тщательно протестированы и проверены. Мы рекомендуем настроить этот репозиторий в файле /etc/apt/sources.list. Файл /etc/apt/sources.list
```
deb http://ftp.debian.org/debian buster main contrib
deb http://ftp.debian.org/debian buster-updates main contrib
# PVE pve-no-subscription repository provided by proxmox.com,
# NOT recommended for production use
deb http://download.proxmox.com/debian/pve buster pve-no-subscription
# security updates
deb http://security.debian.org buster/updates main contrib
```
3. Proxmox VE Test Repository
  Наконец, существует репозиторий под названием pvetest. Он содержит последние пакеты и активно используется разработчиками для тестирования новых функций. Как обычно, вы можете настроить это с помощью /etc/apt/sources.list, добавив следующую строку: sources.list запись для pvetest
```
deb http://download.proxmox.com/debian/pve buster pvetest
```
  Внимание!
  
  Репозиторий pvetest должен (как следует из названия) использоваться только для тестирования новых функций или исправления ошибок.
4. Proxmox VE Ceph Repository
  Это основной репозиторий Ceph Proxmox VE и содержит пакеты Ceph для производственного использования. Вы также можете использовать этот репозиторий для обновления только клиента Ceph.
  Файл /etc/apt/sources.list.d/ceph.list
```
deb http://download.proxmox.com/debian/ceph-nautilus buster main
```
5. Proxmox VE Ceph Testing Repository
  Этот репозиторий Ceph содержит пакеты Ceph перед их перемещением в основной репозиторий и используется для тестирования нового выпуска Ceph на Proxmox VE.
  Файл /etc/apt/sources.list.d/ceph.list
```
deb http://download.proxmox.com/debian/ceph-nautilus buster test
```
6. Proxmox VE Ceph Luminous Repository For Upgrade
  Это сборка Ceph Luminous release для Proxmox VE 6.0, она может быть использовано для обновления кластера Proxmox VE с Ceph Luminous, развернутого до выхода нашего выпуска 6.0, основанного на Debian Buster, и только после этого обновить Ceph сам по себе.
  Файл /etc/apt/sources.list.d/ceph.list
```
deb http://download.proxmox.com/debian/ceph-luminous buster main
```
7. SecureApt
  Мы используем GnuPG для подписи файлов выпуска внутри этих репозиториев, а APT использует эти подписи для проверки того, что все пакеты из надежного источника.
  Ключ, используемый для проверки, уже установлен, если вы устанавливаете с нашего установочного компакт-диска. Если вы устанавливаете другими способами, вы можете вручную загрузить ключ с помощью:
```
# wget http://download.proxmox.com/debian/proxmox-ve-release-6.x.gpg -O /etc/apt/trusted.gpg.d/proxmox-ve-release-6.x.gpg
```
  Пожалуйста, проверьте контрольную сумму впоследствии:
```
# sha512sum /etc/apt/trusted.gpg.d/proxmox-ve-release-6.x.gpg
acca6f416917e8e11490a08a1e2842d500b3a5d9f322c6319db0927b2901c3eae23cfb5cd5df6facf2b /etc/apt/trusted.gpg.d/proxmox-ve-release-6.x.gpg
```
  или
```
# md5sum /etc/apt/trusted.gpg.d/proxmox-ve-release-6.x.gpg
f3f6c5a3a67baf38ad178e5ff1ee270c /etc/apt/trusted.gpg.d/proxmox-ve-release -6.x.gpg
```

Обновления Системного Программного Обеспечения
Мы регулярно обновляем пакеты во всех репозиториях. Вы можете установить эти обновления с помощью GUI, или вы можете напрямую запустить команду CLI apt-get:
```
apt-get update
apt-get dist-upgrade
```
Примечание

Система управления пакетами apt является чрезвычайно гибкой и предоставляет бесчисленное множество функций - см. man apt-get или [Hertzog13] для получения дополнительной информации.

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

Совет

Мы рекомендуем запускать регулярные обновления, так как важно получать последние обновления для системы безопасности.

Настройки Сети
Настройка сети может быть выполнена либо с помощью графического интерфейса пользователя, либо путем ручного редактирования файла /etc/network/interfaces, который содержит всю конфигурацию сети. Страница руководства interfaces(5) содержит полное описание формата. Все инструменты Proxmox VE стараются сохранить прямые изменения пользователя, но использование графического интерфейса по-прежнему предпочтительнее, потому что он защищает вас от ошибок. После того, как сеть настроена, вы можете использовать традиционные инструменты Debian ifup и ifdown команды для запуска и остановки интерфейсов.

Примечание

Proxmox VE не записывает изменения непосредственно в /etc/network/interfaces . Вместо этого мы записываем во временный файл с именем /etc/network/interfaces.new и фиксируем эти изменения при перезагрузке узла.
1. Соглашения Об Именах
  В настоящее время мы используем следующие соглашения об именах устройств:
  - Устройства Ethernet: en*, имена сетевых интерфейсов systemd. Эта схема именования используется для новых установок Proxmox VE начиная с версии 5.0.
  - Устройства Ethernet: eth[N], где 0 ≤ N ( eth0, eth1 , . . . ) Эта схема именования используется для хостов Proxmox VE, которые были установлены до выпуска 5.0. При обновлении до версии 5.0 имена сохраняются как есть.
  - Имена мостов: vmbr[N], где 0 ≤ N ≤ 4094 ( vmbr0 - vmbr4094 )
  - Bonds: bond[N], где 0 ≤ N ( bond0 , bond1 , . . . )
  - сети VLAN: Просто добавьте номер VLAN к имени устройства, разделенному точкой (eno1.50, bond1.30 ).
  Это облегчает отладку сетевых проблем, потому что имя устройства подразумевает тип устройства
  
  Имена Сетевых Интерфейсов Systemd
  Systemd использует двухсимвольный префикс en для сетевых устройств Ethernet. Следующие символы зависят от драйвера устройства и того, какая схема соответствует первой.
  - o<index>[n<phys_port_name>|d<dev_port>] - устройство на плате
  - s<slot>[f<function>][n<phys_port_name>|d<dev_port>] - устройство по ID автоопределения
  - [P<domain>]p<bus>s<slot>[f<function>][n<phys_port_name>|d<dev_port>] - устройства по ID шины
  - x<MAC> - устройство по MAC-адресу
  Наиболее распространенные шаблоны:
  - eno1 - первая на материнской плате сетевая карта
  - enp3s0f1 — это сетевой адаптер на шине PCI 3 слот 0 и использует функцию сетевого адаптера 1.
  Дополнительные сведения см. В разделе схемы именования сетевых устройств.
2. Выбор конфигурации сети
  В зависимости от текущей сетевой организации и ваших ресурсов можно выбрать мостовую, маршрутизируемую или маскирующую сетевую настройку.
  
  Proxmox VE сервер в частной локальной сети, использует внешний шлюз для выхода в интернет
  Мостовая модель имеет наибольший смысл в этом случае, и это также режим по умолчанию на новых установках Proxmox VE. Каждая гостевая система будет иметь виртуальный интерфейс, подключенный к мосту Proxmox VE. Это похоже на то, что гостевая сетевая карта напрямую подключена к новому коммутатору в вашей локальной сети, хост Proxmox VE играет роль коммутатора.
  
  Proxmox VE сервер у хостинг-провайдера, с открытыми диапазонами IP для гостей
  Для этой настройки можно использовать Мостовую или Маршрутизируемую модель, в зависимости от того, что позволяет поставщик услуги.
  
  Proxmox VE сервер у хостинг-провайдера, с одним публичным IP-адресом
  В этом случае единственный способ получить исходящий доступ к сети для ваших гостевых систем-использовать Маскировку. Для входящего доступа к сети вашим гостям необходимо настроить Переадресацию портов(Port Forwarding).
  Для дополнительной гибкости можно настроить VLAN (IEEE 802.1 q) и сетевое соединение, также известное как "агрегация каналов". Таким образом, можно построить сложные и гибкие виртуальные сети.
3. Конфигурация по умолчанию с использованием моста
  
  Мосты похожи на физические сетевые коммутаторы, реализованные в программном обеспечении. Все виртуальные машины могут совместно использовать один мост или создать несколько мостов для разделения сетевых доменов. Каждый хост может иметь до 4094 мостов.
  Программа установки создает один мост с именем vmbr0, который подключен к первой карте Ethernet. Соответствующая конфигурация в /etc/network/interfaces может выглядеть следующим образом:
  
  Виртуальные машины ведут себя так, как если бы они были напрямую подключены к физической сети. Сеть, в свою очередь, рассматривает каждую виртуальную машину как имеющую свой собственный MAC, даже если есть только один сетевой кабель, соединяющий все эти виртуальные машины с сетью.
4. Маршрутизируемая конфигурация
  Большинство хостинг-провайдеров не поддерживают вышеуказанную настройку. По соображениям безопасности они отключают сеть, как только обнаруживают несколько MAC-адресов на одном интерфейсе.
  
  Совет
  
  Некоторые поставщики позволяют регистрировать дополнительные MAC адреса в своем интерфейсе управления. Это позволяет избежать проблемы, но неудобно настраивать, потому что вам необходимо зарегистрировать MAC для каждой из ваших виртуальных машин.
  
  Вы можете избежать этой проблемы, "маршрутизируя" весь трафик через один интерфейс. Это гарантирует, что все сетевые пакеты используют один и тот же MAC-адрес.
  
  Общий сценарий состоит в том, что у вас есть общедоступный IP-адрес (предположим, 198.51.100.5 для этого примера) и дополнительный IP-диапазон для ваших виртуальных машин ( 203.0.113.16/29 ). Для таких ситуаций рекомендуется следующая настройка:
5. Маскировка (NAT) с iptables
  Маскировка позволяет гостям, имеющим только частный IP-адрес, получить доступ к сети, используя IP-адрес хоста для исходящего трафика. Каждый исходящий пакет перезаписывается iptables, чтобы появиться как исходящий от хоста, и ответы переписываются соответственно, чтобы быть направленными к исходному отправителю.
6. Linux Bond
  Связывание (также называемое объединением сетевых карт или агрегацией каналов) - это метод привязки нескольких сетевых карт к одному виртуальному сетевому устройству. Этим можно достичь различных целей, например сделать сеть отказоустойчивой, повысить производительность или и то, и другое вместе.
  
  Высокоскоростное оборудование, такое как Fibre Channel и связанное с ним коммутационное оборудование, может быть довольно дорогим. При выполнении агрегации каналов две сетевые карты могут отображаться как один логический интерфейс,что приводит к двойной скорости. Это встроенная функция ядра Linux, которая поддерживается большинством коммутаторов. Если ваши узлы имеют несколько портов Ethernet, вы можете распределить свои точки отказа, запустив сетевые кабели на разные коммутаторы, и связанное соединение будет переключаться на один кабель или другой в случае неполадок в сети.
  
  Агрегированные связи могут улучшить задержки динамической миграции и повысить скорость репликации данных между узлами кластера Proxmox VE.
  
  Есть 7 режимов для связывания:
  - Round-robin (balance-rr): Передача сетевых пакетов в последовательном порядке от первого доступного связанного сетевого интерфейса (NIC) до последнего. Этот режим обеспечивает балансировку нагрузки и отказоустойчивость.
  - Active-backup (active-backup): Только один из связанных в bond сетевых интерфейсов активен. Другой связанный интерфейс становится активным, если и только если активный интерфейс выходит из строя. MAC-адрес одного логического связанного интерфейса виден извне только на одном сетевом адаптере (порту), чтобы избежать искажений в сетевом коммутаторе. Этот режим обеспечивает отказоустойчивость.
  - XOR (balance-xor): Передача сетевых пакетов на основе [(source MAC address XOR’d with destination MAC address) modulo NIC slave count]. Это выбирает тот же ведомый сетевой адаптер для каждого MAC-адреса назначения. Этот режим обеспечивает балансировку нагрузки и отказоустойчивость.
  - Broadcast (broadcast): Передает сетевые пакеты по всем связанным сетевым интерфейсам. Этот режим обеспечивает отказоустойчивость.
  - IEEE 802.3ad Dynamic link aggregation (802.3ad)(LACP): Создает группы агрегации с одинаковыми настройками скорости и дуплекса. Использует все связанные сетевые интерфейсы в активной группе агрегаторов в соответствии со спецификацией 802.3 ad.
  - Adaptive transmit load balancing (balance-tlb): Linux bonding driver mode, который не требует специальной поддержки сетевых коммутаторов. Исходящий сетевой пакетный трафик распределяется в соответствии с текущей нагрузкой (вычисленной относительно скорости) на каждом ведомом устройстве сетевого интерфейса. Входящий трафик получен одним в настоящее время назначенным ведомым сетевым интерфейсом. Если этот принимающий интерфейс отказывает, другой связанный интерфейс берет на себя MAC-адрес отказавшего принимающего интерфейса.
  - Adaptive load balancing (balance-alb): Включает balance-tlb plus receive load balancing (rlb) для трафика IPV4 и не требует специальной поддержки сетевых коммутаторов. Балансировка нагрузки на прием достигается путем согласования ARP. Драйвер связи перехватывает ответы ARP, отправленные локальной системой на их выходе, и перезаписывает исходный аппаратный адрес с уникальным аппаратным адресом одного из подчиненных сетевых карт в едином логическом связанном интерфейсе так, чтобы различные сетевые узлы использовали различные MAC-адреса для своего сетевого пакетного трафика.
  Если коммутатор поддерживает протокол LACP (IEEE 802.3 ad), рекомендуется использовать соответствующий режим соединения (802.3 ad). В противном случае обычно следует использовать режим активного резервного копирования. Если вы собираетесь запустить сеть кластера на связанных интерфейсах, то вы должны использовать активный-пассивный режим на связанных интерфейсах, другие режимы не поддерживаются. Следующая конфигурация связи может использоваться в качестве распределенной/общей сети хранения. Преимущество будет заключаться в том, что вы получите больше скорости, и сеть будет отказоустойчивой.
  
  Пример: Используйте bond с фиксированным IP-адресом
  
  Еще одна возможность это использовать bond непосредственно в качестве порта для моста . Это может быть использовано для создания гостевой сети отказоустойчивой.
  
  Пример: Использование bond в качестве порта моста
7. VLAN 802.1Q
  Виртуальная локальная сеть (VLAN) - это широковещательный домен, который разделен и изолирован в сети на втором уровне. Таким образом, можно иметь несколько сетей (4096) в физической сети, каждая из которых независима от других.
  
  Каждая сеть VLAN идентифицируется номером, часто называемым тегом. Сетевые пакеты затем помечаются, чтобы определить, к какой виртуальной сети они принадлежат.
  
  VLAN для гостевых сетей
  Proxmox VE поддерживает эту настройку из коробки. Тег VLAN можно указать при создании виртуальной машины. Тег VLAN является частью конфигурации гостевой сети. Сетевой уровень поддерживает различные режимы для реализации VLAN, в зависимости от конфигурации моста:
  - VLAN awareness on the Linux bridge: В этом случае виртуальная сетевая карта каждого гостя назначается тегу VLAN, который прозрачно поддерживается мостом Linux. Режим магистрали также возможен, но требует конфигурирования в гостевой системе.
  - "Традиционная" VLAN на Linux bridge: В отличие от метода VLAN awareness, этот метод не является прозрачным и создает устройство VLAN с соответствующим мостом для каждой VLAN. То есть, создание гостя на VLAN 5, например, создало бы два интерфейса eno1.5 и vmbr0v5, которые остались бы, пока не произойдет перезагрузка.
  - Open vSwitch VLAN: В этом режиме используется функции OVS VLAN.
  - Guest configured VLAN: Vlan назначаются внутри гостя. В этом случае настройка полностью выполняется внутри гостя и не может быть подвержена влиянию извне. Преимущество заключается в том, что вы можете использовать более одной VLAN на одной виртуальной сетевой карте.
  VLAN на хосте
  Разрешить связь хоста с изолированной сетью. Можно использовать VLAN-теги для любого сетевого устройства (сетевой карты, облигации, мост). В общем, вы должны настроить VLAN на интерфейсе с наименьшими уровнями абстракции между собой и физической сетевой картой.
  
  Например, в конфигурации по умолчанию, где вы хотите разместить адрес управления хостом на отдельной VLAN.
  
  Пример: Используем VLAN 5 для IP управления Proxmox VE с традиционным мостом Linux
  
  Пример: Используем VLAN 5 для IP управления Proxmox VE с VLAN aware Linux bridge
  
  Следующий пример-та же самая настройка, но связь используется, чтобы сделать эту сеть отказоустойчивой.
  
  Пример: Используем VLAN 5 с bond0 для IP управления Proxmox VE с традиционным Linux bridge

Синхронизация Времени
Стек кластера Proxmox VE в значительной степени зависит от того, что все узлы имеют точно синхронизированное время. Некоторые другие компоненты, такие как Ceph, также отказываются работать должным образом, если локальное время на узлах не синхронизировано.

Синхронизация времени между узлами может быть достигнута с помощью "сетевого протокола времени" (NTP). Proxmox VE использует systemd-timesyncd в качестве NTP-клиента по умолчанию, предварительно настроенного для использования набора общедоступных серверов. Эта настройка работает из коробки в большинстве случаев.
1. Использование пользовательских NTP серверов
  В некоторых случаях может потребоваться не использовать серверы NTP по умолчанию. Например, если ваши узлы Proxmox VE не имеют доступа к интернету (например, из-за ограничительных правил брандмауэра), вам необходимо настроить локальные серверы NTP и настроить systemd-timesyncd, на их использование:
  
  Файл /etc/systemd/timesyncd.conf
```
[Time]
NTP=ntp1.example.com ntp2.example.com ntp3.example.com ntp4.example.com
```
  После перезапуска службы синхронизации (systemctl restart systemd-timesyncd ) необходимо проверить, что вновь настроенные серверы NTP используются, проверив журнал (journalctl --since -1h -u systemd-timesyncd):

Внешний Metric Server
Начиная с Proxmox VE 4.0, вы можете определить внешние метрические серверы, на которые будут отправляться различные статистические данные о ваших хостах, виртуальных машинах и хранилищах. В настоящее время поддерживаются:
- Graphite (см. http://graphiteapp.org)
- InfluxDB (см. https://www.influxdata.com/time-series-platform/influxdb/)
Определения серверов сохраняются в файле /etc/pve/status.cfg
1. Конфигурирование сервера Graphite
  Определением сервера является:
  
  Где ваш порт по-умолчанию 2003 и ваш путь по-умолчанию к proxmox
  
  Proxmox VE отправляет данные по UDP, поэтому сервер graphite должен быть настроен для этого.
2. Конфигурация плагина Influxdb
  Определение:
  
  Proxmox VE отправляет данные по UDP, поэтому сервер graphite должен быть настроен для этого. Вот пример конфигурации для influxdb (на вашем сервере influxdb ):
  
  При такой конфигурации сервер прослушивает все IP-адреса на порту 8089 и записывает данные в базу данных proxmox.
3. Несколько определений и пример
  Идентификатор является необязательным, но если вы хотите иметь несколько определений одного типа, то идентификаторы должны быть определены и отличаются друг от друга.
  
  Вот пример окончательного status.cfg

Мониторинг Работоспособности Дисков
Хотя рекомендуется использовать надежное и избыточное хранилище, он(мониторинг) может быть очень полезен для мониторинга работоспособности локальных дисков.
Начиная с Proxmox VE 4.3, пакет smartmontools¹ устанавливается и требуется. Это набор инструментов для мониторинга и управления системой S. M. A. R. T. для локальных жестких дисков.
Вы можете получить статус диска, выполнив следующую команду:
```
# smartctl -a /dev/sdX
```
где /dev/sdX-это путь к одному из ваших локальных дисков.
Если на выходе написано:
```
SMART support is: Disabled
```
вы можете включить его с помощью команды:
```
# smartctl -s on /dev/sdX
```
Для получения более подробной информации о том, как использовать smartctl, пожалуйста, см. man smartctl. По умолчанию smartmontools daemon smartd активен и включен, а также сканирует диски в каталоге /dev/sdX и /dev/hdX каждые 30 минут на наличие ошибок и предупреждений и отправляет сообщение электронной почты root, если обнаруживает проблему.

Дополнительные сведения о настройке smartd см. в разделах man smartd и man smartd.conf.

Если вы используете жесткие диски с аппаратным raid-контроллером, скорее всего, существуют инструменты для мониторинга дисков в массиве raid и самого массива. Для получения дополнительной информации об этом обратитесь к поставщику вашего raid-контроллера.
¹ домашняя страница smartmontools https://www.smartmontools.org

Диспетчер логических томов (LVM)
Большинство людей устанавливают Proxmox VE непосредственно на локальный диск. Установочный компакт-диск Proxmox VE предлагает несколько вариантов управления локальными дисками, а текущая установка по умолчанию использует LVM. Установщик позволяет выбрать один диск для такой установки и использует этот диск в качестве физического тома для группы томов (VG) pve . Следующие выходные данные выводятся из тестовой установки с использованием небольшого диска 8 ГБ:

Установщик выделяет три логических Тома (LV) внутри этого VG:

root

Форматируется как ext4 и содержит операционную систему.

swap

Раздел подкачки

data

Этот том использует LVM-thin и используется для хранения образов виртуальных машин. LVM-thin предпочтительнее для этой задачи, поскольку он обеспечивает эффективную поддержку снимков и клонов.

Для версий Proxmox VE до 4.1 установщик создает стандартный логический том под названием “data", который монтируется в каталоге /var/lib/vz.

Начиная с версии 4.2, логический том "data" представляет собой пул LVM-thin, используемый для хранения гостевых образов на основе блоков, а /var/lib/vz - это просто каталог в корневой файловой системе.
1. Оборудование
  Мы настоятельно рекомендуем использовать аппаратный RAID-контроллер (с BBU) для таких настроек. Это повышает производительность, обеспечивает резервирование и упрощает замену дисков (с возможностью горячей замены).
  
  Сама LVM не нуждается в специальном оборудовании, а требования к памяти очень низки.
2. Загрузчик
  По умолчанию мы устанавливаем два загрузчика. Первый раздел содержит стандартный загрузчик GRUB. Второй раздел-это системный раздел EFI (ESP), который позволяет загружать системы EFI.
3. Создание группы томов
  Предположим , что у нас есть пустой диск /dev/sdb, на котором мы хотим создать группу томов с именем “vmdata”.
  
  Осторожно!
  
  Обратите внимание, что следующие команды уничтожат все существующие данные на /dev/sdb.
  
  Сначала создайте раздел.
```
# sgdisk -N 1 /dev/sdb
```
  Создайте физический том (PV) без подтверждения c размером метаданных 250 КБ.
```
# pvcreate --metadatasize 250k -y -ff /dev/sdb1
```
  Создайте группу томов с именем “vmdata " на /dev/sdb1
```
# vgcreate vmdata /dev/sdb1
```
4. Создание дополнительного LV для /var/lib/vz
  Это можно легко сделать, создав новый тонкий LV.
```
# lvcreate -n <Name> -V <Size[M,G,T]> <VG>/<LVThin_pool>
```
  Пример из реальной жизни:
```
# lvcreate -n vz -V 10G pve/data
```
  Теперь файловая система должна быть создана на LV.
```
# mkfs.ext4 /dev/pve/vz
```
  Наконец, это должно быть смонтировано.
  
  Внимание!
  
  убедитесь, что /var/lib/vz пуст. На установке по умолчанию это не так.
  
  Чтобы сделать его всегда доступным, добавьте следующую строку в /etc/fstab.
```
# echo ’/dev/pve/vz /var/lib/vz ext4 defaults 0 2’ >> /etc/fstab
```
5. Изменение размера тонкого пула
  Изменение размера LV и пула метаданных может быть достигнуто с помощью следующей команды.
```
# lvresize --size +<size[\M,G,T]> --poolmetadatasize +<size[\M,G]> < VG>/<LVThin_pool>
```
  Примечание
  
  При расширении пула данных необходимо также расширить пул метаданных.
6. Создание тонкого пула LVM
  Тонкий пул должен быть создан поверх группы томов. Как создать группу томов смотрите раздел LVM.
```
# lvcreate -L 80G -T -n vmstore vmdata
```

ZFS на Linux

ZFS-это комбинированная файловая система и менеджер логических томов, разработанная компанией Sun Microsystems. Начиная с Proxmox VE 3.4, родной порт ядра Linux файловой системы ZFS вводится как дополнительная файловая система, а также как дополнительный выбор для корневой файловой системы. Нет необходимости вручную компилировать модули ZFS - все пакеты включены.

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

ОБЩИЕ ПРЕИМУЩЕСТВА ZFS

Простота настройки и управления с помощью Proxmox VE GUI и CLI.
Надежность
Защита от повреждения данных
Сжатие данных на уровне файловой системы
Создание снимков
Copy-on-write клонирование
Различные уровни RAID : RAID0, RAID1, RAID10, RAIDZ-1, RAIDZ-2 и RAIDZ-3
Возможность использовать SSD для кэша
Самовосстановление
Непрерывная проверка целостности
Дизайн для высоких емкостей запоминающего устройства
Защита от повреждения данных
Асинхронная репликация по сети
Открытый исходный код
Шифрование
...

Оборудование
ZFS сильно зависит от памяти, поэтому вам нужно по крайней мере 8 ГБ, для начала. На практике используйте столько, сколько вы можете получить для вашего оборудования/бюджета. Для предотвращения повреждения данных мы рекомендуем использовать высококачественную ОЗУ ECC.

Если вы используете выделенный кэш и / или диск журнала, вы должны использовать SSD корпоративного класса (например, Intel SSD DC S3700 Series). Это может значительно повысить общую производительность.

Важно

Не используйте ZFS поверх аппаратного контроллера, который имеет свое собственное управление кэшем. ZFS должна напрямую взаимодействовать с дисками. Адаптер HBA - это то, что нужно, или что-то вроде контроллера LSI, переведенного в режим «IT»(initiator target).

Если вы экспериментируете с установкой Proxmox VE внутри виртуальной машины (вложенная виртуализация), не используйте virtio для дисков этой виртуальной машины, поскольку они не поддерживаются ZFS. Вместо этого используйте IDE или SCSI (работает также с типом контроллера virtio SCSI).
Установка в качестве корневой файловой системы
При установке с помощью программы установки Proxmox VE можно выбрать ZFS для корневой файловой системы. Вам нужно выбрать тип RAID во время установки:

RAID0

также называется "чередование". Емкость такого Тома - это сумма емкостей всех дисков. Но RAID0 не добавляет избыточности, поэтому сбой одного диска делает том непригодным для использования.

RAID1

также называют "зеркалированием". Данные записываются одинаково на все диски. В этом режиме требуется как минимум 2 диска одинакового размера. Результирующая емкость-это емкость одного диска.

RAID10

комбинация RAID0 и RAID1. Требуется не менее 4 дисков.

RAIDZ-1

вариация на тему RAID-5, одинарная четность. Требуется не менее 3 дисков.

RAIDZ-2

вариация на RAID-5, двойная четность. Требуется не менее 4 дисков.

RAIDZ-3

вариация на RAID-5, тройная четность. Требуется не менее 5 дисков.

Программа установки автоматически разбивает диски на разделы, создает пул ZFS с именем rpool и устанавливает корневую файловую систему в ZFS subvolume rpool/ROOT/pve-1.

Следующий подраздел называется rpool/data он создается для хранения образов виртуальных машин. Чтобы использовать это с инструментами Proxmox VE, установщик создает следующую запись конфигурации в /etc/pve/storage.cfg:

После установки можно просмотреть состояние пула ZFS с помощью команды zpool:

Команда zfs используется для настройки и управления файловыми системами ZFS. Следующая команда выводит список всех файловых систем после установки:
Загрузчик
В зависимости от того, загружается ли система в режиме EFI или legacy BIOS, программа установки Proxmox VE устанавливает grub или systemd-boot в качестве основного загрузчика. См. главу о загрузчиках хостов Proxmox VE раздел 3.10 для получения дополнительной информации.
Администрирование ZFS
В этом разделе приведены некоторые примеры использования для общих задач. ZFS сама по себе очень мощная и предоставляет множество опций. Основными командами для управления ZFS являются zfs и zpool . Обе команды поставляются с подробными страницами руководства, которые можно прочитать с помощью:
```
# man zpool
# man zfs
```
Создание нового zpool
Для создания нового пула необходим хотя бы один диск. Ashift должен иметь тот же размер сектора (2 в степени ashift) или больше, что и базовый диск.
```
zpool create -f -o ashift=12 <pool> <device>
```
Чтобы активировать сжатие
```
zfs set compression=lz4 <pool>
```
Создать новый пул с RAID-0
Минимум 1 Диск
```
zpool create -f -o ashift=12 <pool> <device1> <device2>
```
Создать новый пул с RAID-1
Минимум 1 Диск
```
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>
```
Создать новый пул с кэшем (L2ARC)
Для повышения производительности можно использовать выделенный раздел диска кэша (используйте SSD). В качестве <устройства> можно использовать больше устройств, как показано в разделе " Создание нового пула с RAID*".
```
zpool create -f -o ashift=12 <pool> <device> cache <cache_device>
```
Создать новый пул с журналом (ZIL)
Для повышения производительности можно использовать выделенный раздел диска кэша(SSD). В качестве <устройства> можно использовать больше устройств, как показано в разделе " Создание нового пула с RAID*".
```
zpool create -f -o ashift=12 <pool> <device> log <log_device>
```
Добавление кэша и журнала в существующий пул
Если у вас есть пул без кэша и журнала. Первый раздел SSD на 2 раздела с parted или gdisk

Важно

Всегда используйте таблицы разделов GPT.

Максимальный размер лог-устройства должен быть примерно в два раза меньше размера физической памяти, поэтому обычно это довольно мало. Остальная часть SSD может использоваться в качестве кэша.
```
zpool add -f <pool> log <device-part1> cache <device-part2>
```
Замена неисправного устройства
```
zpool replace -f <pool> <old device> <new device>
```
Замена неисправного загрузочного устройства при использовании systemd-boot
```
sgdisk <healthy bootable device> -R <new device>
sgdisk -G <new device>
zpool replace -f <pool> <old zfs partition> <new zfs partition>
pve-efiboot-tool format <new disk's ESP>
pve-efiboot-tool init <new disk's ESP>
```
Примечание

ESP означает системный раздел EFI, который устанавливается как раздел #2 на загрузочных дисках, устанавливаемых установщиком Proxmox VE с версии 5.4. Дополнительные сведения см. В разделе Настройка нового раздела для использования в качестве синхронизированного ESP.
Активация уведомлений по электронной почте
ZFS поставляется с демоном событий, который отслеживает события, генерируемые модулем ядра ZFS. Демон также может отправлять электронные письма на события ZFS, такие как ошибки пула. Более новые пакеты ZFS поставляют демон в отдельном пакете, и вы можете установить его с помощью apt-get :
```
# apt-get install zfs-zed
```
Для активации демона необходимо отредактировать файл /etc/zfs/zed.d/zed.rc выберите нужный редактор и раскомментируйте параметр ZED_EMAIL_ADDR:
```
ZED_EMAIL_ADDR="root"
```
Обратите внимание, что Proxmox VE пересылает почту root на адрес электронной почты, настроенный для пользователя root.

Важно

Единственным параметром, который требуется, является ZED_EMAIL_ADDR . Все остальные настройки являются необязательными.
Ограничение использования памяти ZFS
Для предотвращения нехватки производительности хоста рекомендуется использовать не более 50% (по умолчанию) системной памяти для ZFS ARC. Используйте любимый редактор, чтобы изменить конфигурацию в файле /etc/modprobe.d/zfs и вставить: options zfs zfs_arc_max=8589934592 Этот пример настройки ограничивает использование до 8 ГБ. Важно Если ваша корневая файловая система ZFS, вы должны обновлять initramfs каждый раз, когда это значение изменяется: update-initramfs -u

Своп на ZFS

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

Мы настоятельно рекомендуем использовать достаточно памяти, чтобы вы не сталкивались с ситуациями нехватки памяти. Если вам нужно или вы хотите добавить swap, предпочтительно создать раздел на физическом диске и использовать его в качестве swapdevice. Вы можете оставить немного свободного места для этой цели в расширенных настройках установщика. Кроме того, вы можете снизить значение “swappiness”. Хорошее значение для серверов составляет 10:

sysctl -w vm.swappiness=10

Чтобы сделать подкачку постоянной, откройте файл /etc/sysctl.conf в своем любимомредакторе по вашему выбору и добавьте следующую строку:

vm.swappiness=10

Таблица 3.1: Значения параметра Linux kernel swappiness

Значение	Стратегия
vm.swappiness = 0	Ядро будет использовать swap только для того, чтобы избежать состояния нехватки памяти
vm.swappiness = 1	Минимальное количество подкачки, не отключая его полностью.
vm.swappiness = 10	Это значение иногда рекомендуется для повышения производительности при наличии достаточного объема памяти в системе.
vm.swappiness = 60	Значение по умолчанию.
vm.swappiness = 100	Kernel swap будет использоваться агрессивно.

Зашифрованные наборы данных ZFS
ZFS на Linux версии 0.8.0 представила поддержку собственного шифрования наборов данных. После обновления с предыдущих версий ZFS на Linux, функция шифрования может быть включена для каждого пула:

Внимание!

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

Примечание

Рекомендуется либо разблокировать наборы данных хранилища вручную после загрузки, либо написать пользовательский модуль для передачи ключевого материала, необходимого для разблокировки при загрузке, в ZFS load-key.

Внимание!

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

Шифрование должно быть настроено при создании datasets/zvols, и по умолчанию наследуется дочерним наборам данных. Например, чтобы создать зашифрованный набор данных tank/encrypted_data и настроить его как хранилище в Proxmox VE, выполните следующие команды:

Все гостевые volumes/disks, созданные в этом хранилище, будут зашифрованы с использованием общего ключа родительского набора данных. Чтобы фактически использовать хранилище, связанный ключевой материал должен быть загружен с помощью ZFS load-key:

Также можно использовать (случайный) ключевой файл вместо запроса парольной фразы, задав свойства keylocation и keyformat либо во время создания, либо с помощью zfs change-key для существующих наборов данных:

Внимание!

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

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

Смотри свойства encryptionroot , encryption , keylocation , keyformat и keystatus, команды zfs unload-key и zfs change-key и раздел шифрование в man ZFS для более детальной информации и продвинутого использования.

Управление Сертификатами
1. Сертификаты для связи внутри кластера
  Каждый кластер Proxmox VE создает свой собственный (самозаверяющий) Центр сертификации (ЦС) и генерирует сертификат для каждого узла, который подписывается вышеупомянутым ЦС. Эти сертификаты используются для зашифрованной связи со службой pveproxy кластера и функций Shell/Console, во время использования SPICE.
  
  Сертификат CA и ключ хранятся в Proxmox Cluster File System (pmxcfs) Глава 7.
2. Сертификаты для API и web GUI
  REST API и web GUI предоставляются службой pveproxy, которая работает на каждом узле.
  У вас есть следующие параметры для сертификата, используемого pveproxy :
  1. По умолчанию для конкретного узла,используетсясертификат который находится в файле /etc/pve/nodes/NODENAME/pve-ssl.pem. Этот сертификат подписан центром сертификации кластера и поэтому по умолчанию не является доверенным для браузеров и операционных систем.
  2. Используйте внешний сертификат (например, подписанный коммерческим центром сертификации).
  3. Используйте ACME (например, Let’s Encrypt), чтобы получить доверенный сертификат с автоматическим обновлением.
  Для вариантов 2 и 3 используется файлы /etc/pve/local/pveproxy-ssl.pem (и /etc/pve/local/pveproxy-ssl.key, который должен быть без пароля) . Управление сертификатами осуществляется с помощью команды Proxmox VE Node management (см. pvenode(1) man-page).
  
  Внимание!
  
  Не заменяйте и не изменяйте вручную автоматически созданные файлы сертификатов узлов в /etc/pve/local/pve-ssl.pem и /etc/pve/local/pve-ssl.key или CA сертификаты кластера в /etc/pve/pve-root-ca.pem и /etc/pve/priv/pve-root-ca.key.
  
  Получение сертификатов через ACME
  
  Proxmox VE включает в себя реализацию протокола ACME среды автоматического управления сертификатами, позволяя администраторам Proxmox VE взаимодействовать с Let's Encrypt для легкой настройки доверенных сертификатов TLS, которые принимаются из коробки на большинстве современных операционных систем и браузеров.
  
  В настоящее время реализованы две конечные точки ACME: Let's Encrypt (LE) и его промежуточная среда (см. https://letsencrypt.org), оба используют автономный вызов HTTP. Из-за ограничений скорости вы должны использовать LE staging для экспериментов. Есть несколько предварительных условий для использования Let's Encrypt:
  1. Порт 80 узла должен быть доступен из интернета.
  2. На порту 80 не должно быть другого слушателя.
  3. Запрошенный домен (sub)должен разрешиться в общедоступный IP-адрес узла.
  4. Вы должны принять ToS Let’s Encrypt.
  На данный момент графический интерфейс использует только учетную запись ACME по умолчанию.
  
  Пример: Образец вызова pvenode для использования Let's Encrypt сертификатов
  
  Переход от промежуточного к обычному каталогу ACME
  
  Изменение каталога ACME для учетной записи не поддерживается. Если вы хотите переключить учетную запись из промежуточного каталога ACME в обычный, доверенный, вам нужно деактивировать ее и создать заново.
  Эта процедура также необходима для изменения учетной записи ACME по умолчанию, используемой в графическом интерфейсе.
  
  Пример: Изменение учетной записи ACME по умолчанию из промежуточного каталога в обычный каталог
  
  Автоматическое продление сертификатов ACME
  
  Если узел был успешно настроен с предоставленным ACME сертификатом (либо через pvenode, или через графический интерфейс), сертификат будет автоматически обновлен с помощью pve-daily-update.service. В настоящее время обновление будет предпринято, если срок действия сертификата истек или истечет в течение следующих 30 дней.

Загрузчик Хоста
Proxmox VE в настоящее время использует один из двух загрузчиков в зависимости от установок диска, выбранных в программе установки.
Для систем EFI, установленных с ZFS в качестве корневой файловой системы используется systemd-boot. Во всех остальных развертываниях используется стандартный загрузчик grub (обычно это относится и к системам, установленным поверх Debian)
1. Схема разбиения на разделы, используемая установщиком
  Установщик Proxmox VE создает 3 раздела на загрузочных дисках, выбранных для установки. Загрузочными диски являются:
  - Для установок с ext4 или xfs выбранный диск
  - Для установок ZFS все диски, принадлежащие первому vdev:
    - Первый диск для RAID0
    - Все диски для RAID1, RAIDZ1, RAIDZ2, RAIDZ3
    - Первые два диска для RAID10
  Создаваемые разделы:
  - Загрузочный раздел BIOS размером 1 Мб (gdisk type EF02)
  - Системный раздел EFI размером 512 МБ (ESP, gdisk type EF00)
  - третий раздел, охватывающий параметр set hdsize или оставшееся пространство, используемое для выбранного типа хранилища
  grub в режиме BIOS (--target i386-pc) устанавливается на загрузочный раздел BIOS всех загрузочных дисков для поддержки старых систем.
2. Grub
  grub был стандартом де-факто для загрузки систем Linux в течение многих лет и довольно хорошо документирован².
  
  Образы ядра и initrd берутся из каталога /boot и его конфигурационный файл / boot/grub/grub.cfg обновляется в процессе установки ядра.
  
  Конфигурирование
  Изменения конфигурации grub выполняются с помощью файла по умолчанию /etc/default/grub или фрагментов конфигурации в каталоге /etc/default/grub.d. Чтобы перегенерировать файл /boot/grub/grub.cfg после изменения конфигурации выполнить:
```
update-grub
```
  ²Grub Manual https://www.gnu.org/software/grub/manual/grub/grub.html
3. Systemd-boot
  systemd-boot - это легкий загрузчик EFI. Он считывает образы ядра и initrd непосредственно из EFI Service Partition(ESP), где он установлен. Основное преимущество прямой загрузки ядра из ESP заключается в том, что ему не нужно повторно устанавливать драйверы для доступа к хранилищу. В контексте ZFS как корневой файловой системы, это означает, что вы можете использовать все дополнительные функции в своем корневом пуле вместо их части. Которое также присутствует в реализации ZFS в grub или необходимости создать отдельный небольшой загрузочный Пул ³.
  
  В установках с избыточностью (RAID1, RAID10, RAIDZ *) все загрузочные диски (входящие в первый vdev) разбиты с ESP. Это гарантирует загрузку системы даже в случае сбоя первого загрузочного устройства. ESP поддерживается в синхронизированном состоянии с помощью kernel postinstall hook script /etc/kernel/postinst.d/zz-pve-efiboot. Скрипт копирует определенные версии ядра и образы initrd в EFI/proxmox/ в корне каждого ESP и создает соответствующие конфигурационные файлы в loader/entries/proxmox-*.conf. Этот pve-efiboot-tool script, управляет синхронизацией как самих ESP так и их содержания.
  
  По умолчанию настроены следующие версии ядра:
  - текущее запущенное ядро
  - версия, недавно установленная при обновлении пакетов
  - два последних уже установленных ядра
  - последняя версия предыдущей серии ядер (например, 4.15, 5.0), если применимо
  - любые ядра, выбранные вручную (см. ниже)
  ESP не монтируются во время обычной работы, в отличие от grub, который поддерживает ESP, установленный на /boot/efi. Это помогает предотвратить повреждение файловой системы для ESP, отформатированных в vfat, в случае сбоя системы и избавляет от необходимости вручную редактировать /etc/fstab в случае сбоя основного загрузочного устройства.
  
  Конфигурирование
  systemd-boot настраивается через файл loader/loader.conf в корневом каталоге EFI System Partition (ESP). Подробности смотри loader.conf(5) manpage
  
  Каждая запись загрузчика помещается в отдельный файл в каталоге loader/entries/
  
  К примеру entry.conf выглядит так (/ссылается на корень ESP):
  
  Ручное добавление ядра в загрузку
  Если вы хотите добавить определенное ядро и образ initrd в список загрузочного ядра, используйте pve-efiboot-tool kernel add.
  
  Например, выполните следующие действия, чтобы добавить ядро с ABI версии 5.0.15-1-pve в список ядер, которые будут установлены и синхронизированы со всеми ESP:
```
pve-efiboot-tool kernel add 5.0.15-1-pve
```
  pve-efiboot-tool kernel list покажет список всех версий ядра, выбранных для загрузки:
  
  Запустите pve-efiboot-tool remove, чтобы удалить ядро из списка выбранных вручную ядер, например:
```
pve-efiboot-tool kernel remove 5.0.15-1-pve
```
  Примечание
  
  Необходимо запустить pve-efiboot-tool refresh, чтобы обновить все системные разделы EFI (ESPs) после ручного добавления или удаления ядра как было описано выше.
  
  Создание новых разделов для использования в качестве синхронизированных ESP
  Чтобы отформатировать и инициализировать раздел как синхронизированный ESP, например, после замены отказавшего vdev в rpool или при преобразовании существующей системы, которая предшествует механизму синхронизации, можно использовать pve-efiboot-tool из pve-kernel-help.
  
  Внимание!
  
  Команда format отформатирует <partition>, убедитесь, что вы передали правильный device/partition!
  
  Например, чтобы отформатировать пустой раздел /dev/sda2 как ESP, выполните следующие действия:
```
pve-efiboot-tool format /dev/sda2
```
  Чтобы настроить существующий размонтированный ESP, расположенный на /dev/sda2, для включения в Proxmox VE kernel update synchronization mechanism, выполните следующие действия:
```
pve-efiboot-tool init /dev/sda2
```
  После этого /etc/kernel/pve-efiboot-uuids должен содержать новую строку с UUID вновь добавленного раздела. Команда init также автоматически инициирует обновление всех настроенных ESP.
  
  Обновление конфигурации на всех ESP
  Чтобы скопировать и настроить все загрузочные ядра и синхронизировать все ESP, перечисленные в файле /etc/kernel/pve-efiboot-uuids, вам просто нужно запустить:
```
pve-efiboot-tool refresh
```
  (Эквивалент запуска update-grub на системах, загружаемых с помощью grub).
  Это необходимо, если вы вносите изменения в командную строку ядра или хотите синхронизировать все ядра и initrd после их восстановления.
  ³Загрузка ZFS root с grub https://github.com/zfsonlinux/zfs/wiki/Debian-Stretch-Root-on-ZFS
4. Редактирование командной строки ядра
  Вы можете изменить командную строку ядра в следующих местах, в зависимости от используемого загрузчика:
  
  Grub
  Командная строка ядра должна быть помещена в переменную GRUB_CMDLINE_LINUX_DEFAULT в файле /etc/default/grub. Запуск update-grub добавляет это содержимое ко всем записям linux в /boot/grub/grub.cfg
  
  Systemd-boot
  Командная строка ядра должна быть размещена в виде строки в /etc/ kernel/cmdline. Запуск /etc/kernel/postinst.d/zz-pve-efiboot устанавливает ее в качестве строки параметров для всех файлов конфигурации в loader/entries/proxmox-*.conf.