​​Наконец-то произошло это знаменательное событие и в веб интерфейсе Proxmox стало можно сортировать виртуальные машины не только по VMID, но и по имени. Буквально на днях, когда собирал тестовый кластер из виртуалок, думал, как же неудобно сделано. На тестовом сервере десятки виртуалок с разными системами и я никак не могу их отсортировать.

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

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

#proxmox

​​Ребята, я вам сейчас расскажу реальную тему. Знаю, как вы все любите Proxmox и заметки о нём. Как только выходит обновление, мне обязательно об этом пишут в личку или в чате.

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

Запросы (1, 2) на официальном форуме этой возможности висят от 2020 года с комментариями разработчиков о том, что когда-нибудь это будет сделано. Я поискал по этой теме информацию и там же на форуме видел, что работа над этим функционалом ведётся. Уже кое-что реализовано в виде cli команд для переезда виртуалок между разнородными серверами. Это будет часть нового функционала. Но окончательно обещают единое управление не раньше 2024 года.

Там же на форуме я нашёл ссылку на шикарный проект — https://cluster-manager.fr. Это менеджер кластеров и одиночных серверов. Сделано в виде приложения под Windows. Скачиваете, запускаете и добавляете все свои сервера и кластеры. Выглядит всё очень удобно и функционально.

Добавил пару серверов и потестил. Весь основной функционал работает. Само приложение шустрое. Управлять виртуалками даже одного сервера удобно. Это быстрее, чем заходить в веб интерфейс. Настройки все хранятся в json файле. Пароль не в открытом виде. Как зашифрован — не знаю. Пока добавил только свои тестовые сервера. Надо будет навести справки про эту панельку и немного погонять.

Сам автор пишет, что никакие данные не собирает. Предлагает в этом убедиться всем желающим, запустив Wireshark. Кто не умеет с ним работать, может научиться тут, как я 😁.

В общем, попробуйте. Мне очень понравилось. Странно, что раньше об этой панельки нигде не слышал.

#proxmox

​​В релизе Proxmox 7.3 была анонсирована утилита Proxmox Offline Mirror, которая вышла чуть раньше, в сентябре. Нигде не видел акцента на этом инструменте. Сам узнал случайно от одного из подписчиков. Но при этом сами разработчики Proxmox уделили много внимания этому инструменту. Создали отдельный поддомен для него и написали подробную инструкцию по использованию:

⇨ Proxmox Offline Mirror released!
⇨ https://pom.proxmox.com

По своей сути это репозиторий deb пакетов для продуктов компании: Proxmox VE, Proxmox Backup Server и Proxmox Mail Gateway. Также поддерживается стандартный репозиторий для Debian и в теории для любых deb пакетов. С помощью Proxmox Offline Mirror можно создать локальный репозиторий в сети без доступа к интернету.

Пакет с proxmox-offline-mirror живёт в стандартном репозитории proxmox и ставится через пакетный менеджер:
# apt install proxmox-offline-mirror

Настройку можно выполнить как интерактивно, запустив:
# proxmox-offline-mirror setup
так и сразу указав все параметры в одной команде. Пример для репозитория Debian:
# proxmox-offline-mirror config mirror add \
 --id debian-bullseye-security \
 --architectures amd64 \
 --architectures all \
 --repository 'deb http://deb.debian.org/debian-security bullseye-security main contrib non-free' \
 --key-path /etc/apt/trusted.gpg.d/debian-archive-bullseye-security-automatic.gpg \
 --sync true \
 --verify true \
 --base-dir /mnt/mirror/base-dir

Можно создавать не только репозитории с доступом по HTTP, но и локальные репозитории, которые можно переносить, к примеру, на флешке или монтировать на целевые хосты по NFS, SMB. Всё это подробно описано в документации. Она небольшая, написана кратко и понятно.

Я не до конца понял, почему Proxmox решил выпустить свой продукт по этой теме. Из каких-то удобств заметил только интерактивную настройку репозитория через консоль для подключения родных репозиториев. Всё остальное плюс-минус то же самое, что и у других подобных продуктов, типа aptly или apt-offline.

#proxmox

​​Я обычно не публикую новости обновлений за исключением нескольких продуктов, которые мне особенно нравятся и за которыми я пристально слежу и сразу же изучаю все нововведения новой версии. Такие продукты: Zabbix, Mikrotik и Proxmox. И вот последний вчера выпустил релиз 8.0. Я ждал его, так как он всегда обновляется вскорости после выхода новой версии Debian, так как собран на её пакетной базе. Но в этот раз это как-то совсем быстро случилось. Только недавно бету анонсировали и тут сразу релиз. Подозреваю, что обновляться пока не надо торопиться, только на тестовых машинах.

Пошёл сразу же смотреть нововведения в Press release. Обновления версий ядра и софта опускаю, отмечаю только новую функциональность бесплатной версии:

▪ Появилась автоматическая синхронизация пользователей и групп из LDAP хранилищ, в том числе Microsoft AD.

▪ Новый TUI (text-based user interface, то есть текстовый) интерфейс установщика. Стало как у Debian — два варианта установщика. Текстовый похож на дебиановский. Особо не понимаю, зачем на это тратить ресурсы разработки. Возможно GUI интерфейс в каких-то случаях не работает и спасает TUI.

▪ Сопоставление физических устройств (PCI и USB) и нод кластера. Можно создать виртуальное устройство, сопоставить его с реальными устройствами на конкретных нодах и добавить это устройство к VM. Теперь она сможет мигрировать только на те ноды, где есть сопоставление нужного устройства. До конца не понял, какую прикладную задачу это решает.

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

▪ Списки доступа (ACL) к сетевым ресурсам. Можно управлять доступом пользователей, например, к бриджам.

Навскидку нововведений как-то мало. Считай ничего значимого и нет, кроме сопоставления устройств. Это наиболее заметное улучшение функциональности.

Руководство по обновлению уже тоже готово: Upgrade from 7 to 8. Алгоритм примерно такой же как всегда:
1. Обновляемся до свежей версии своего релиза.
2. Устанавливаем утилиту pve7to8 и запускаем её.
3. Если все проверки утилиты прошли, обновляем файл с репозиторием на новую версию.
4. Запускаем обновление.

Если используете Ceph, внимательно читайте сноски, касающиеся его. Это важно, там есть свои нюансы.

Официальное видео от создателей:
⇨ What's new in Proxmox Virtual Environment 8.0
На нём продемонстрированы все перечисленные нововведения.

#proxmox

Дошли наконец-то руки проверить обновление Proxmox VE с 7 на 8-ю версию. Написал сразу статью, так как серверов таких много, обновлять рано или поздно придётся.

⇨ https://serveradmin.ru/obnovlenie-proxmox-7-do-8

Нюансов вообще никаких нет. Всё проходит штатно. Обращаю внимание только на один момент. Я и сам много раз сталкивался, и меня в комментариях постоянно спрашивали. Если увидите во время обновления ошибку:

Upgrade wants to remove package 'proxmox-ve'

То не пугайтесь. Она возникает у тех, кто накатывал Proxmox поверх Debian. Я часто это делаю, чтобы поставить гипервизор на mdadm. Так что ошибку эту знаю. Она возникает из-за конфликта пакетов proxmox-ve и linux-image-amd64, который остаётся от Debian. Его нужно просто удалить. Этот пакет относится к ядру Linux, а у Proxmox VE он свой, поэтому оригинальный не нужен.

# apt remove linux-image-amd64

Имя пакета может различаться из-за разных версий ядра.

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

#proxmox

​​Я давно слышал информацию об Альт Сервер Виртуализации, но до конца не понимал, что это такое. Решил разобраться. Из описания не совсем понятно, что на практике из себя представляет этот продукт. В описании видно, что он почти полностью состоит из open source компонентов и это не скрывается. Но при этом продаётся за деньги, хоть и относительно небольшие.

Я решил развернуть его у себя в редакции кластер виртуализации PVE. Помимо него есть ещё три:
◽базовый гипервизор KVM;
◽облачная виртуализация OpenNebula;
◽контейнерная виртуализация (LXC/LXD, Docker/Podman).

Установщик полностью на русском языке. Используется один ISO образ для всех редакций, которые можно выбирать в процессе установки. Помимо основных пакетов, можно выбрать дополнительные. Например, сразу установить агент мониторинга различных систем, или, к примеру, nginx сервер для проксирования, rsyslog, HAProxy для отказоустойчивого веб интерфейса и некоторый другой популярный софт.

У установщика есть широкие возможности по разбивке диска, что встречается не так часто. Можно установить систему на одиночный диск, на mdadm массив, на LVM, на BTRF. ZFS почему-то в списке не было. На разделы, соответственно, тоже можно вручную разбить.

После установки я увидел обычный Proxmox. В последней версии alt-server-v-10.1 версия PVE 7.2. Из примечательного, в alt используется пакетный менеджер apt-get, а пакеты rpm. Подключены только репозитории alt. То есть привязки к инфраструктуре компании Proxmox нет. Я так понял, что все пакеты в репозитории alt собираются разработчиками дистрибутива.

Отдельно отмечу хорошую документацию по продукту на русском языке. Если вы хотите посмотреть документацию на русском языке по Proxmox или OpenNebula, можно воспользоваться этой.

Собственно, становится понятно, за что нужно будет заплатить в коммерческом использовании (для физических лиц всё бесплатно). Если вам нужен Proxmox или OpenNebula с возможностью использования там, где можно брать только отечественное ПО, то Альт Сервер Виртуализации — это ваш случай. Он есть в реестре отечественного ПО, он привязан к репозиториям alt и по идее устойчив ко всяким санкциям, ограничениям и т.д. Также можно купить техподдержку.

⇨ Сайт / Загрузка / Обзор (кластер)

#виртуализация #отечественное #proxmox

Настраивал на днях на Proxmox Backup Server отправку email уведомлений. Использовал для этого почту Яндекса. Расскажу, как это сделал, так как там есть нюансы.

Ставим утилиты, которые нам понадобятся для настройки и диагностики:
# apt install -y libsasl2-modules mailutils

В почтовом ящике Яндекса создаём пароль для приложения. Без него не работает smtp аутентификация в сторонних приложениях. После этого создаём файл /etc/postfix/sasl_passwd следующего содержания:
smtp.yandex.ru mailbox@yandex.ru:sjmprudhjgfmrds
Формат такой: имя сервера, логин, пароль приложения.

Дальше создадим ещё один файл /etc/postfix/generic. Он нам нужен для того, чтобы заменять адрес отправителя. Яндекс разрешает отправлять только тому отправителю, кто является владельцем ящика. В нашем случае mailbox@yandex.ru, а pbs будет пытаться отправлять почту от системного пользователя root@servername.ru. Точно узнать почтовый адрес системного пользователя можно в лог файле postfix - /var/log/mail.log. Там вы увидите попытки отправки, где отправитель будет указан примерно так: 9D8CC3C81DE4: from=<root@pbs.servername.ru>.

Содержимое файла /etc/postfix/generic следующее:
root@pbs.servername.ru mailbox@yandex.ru
Заменили локальный ящик на ящик Яндекса.

Назначаем права и формируем хэш файлы:
# postmap hash:/etc/postfix/sasl_passwd hash:/etc/postfix/generic
# chmod 600 /etc/postfix/sasl_passwd /etc/postfix/generic

Редактируем конфигурационный файл postfix - /etc/postfix/main.cf. Приводим его к виду:

myhostname=pbs.servername.ru
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no
append_dot_mydomain = no
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
mydestination = $myhostname, localhost.$mydomain, localhost
mynetworks = 127.0.0.0/8
inet_interfaces = loopback-only
recipient_delimiter = +
compatibility_level = 2

relayhost = smtp.yandex.ru:465
smtp_use_tls = yes
smtp_sasl_auth_enable = yes
smtp_sasl_security_options =
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_tls_CAfile = /etc/ssl/certs/Entrust_Root_Certification_Authority.pem
smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_tls_session_cache
smtp_tls_session_cache_timeout = 3600s
smtp_tls_wrappermode = yes
smtp_tls_security_level = encrypt
smtp_generic_maps = hash:/etc/postfix/generic

До пустой строки то, что было по умолчанию, после - то, что добавил я. Пустое значение relayhost =, что было по умолчанию, я удалил.

Перечитываем конфигурацию postfix:
# postfix reload
И пробуем отправить тестовое письмо через консоль:
# echo "Message for test" | mail -s "Test subject" zeroxzed@gmail.com
В логе /var/log/mail.info должно быть примерно следующее:
Sep 29 21:47:24 pbs postfix/pickup[640930]: E282E3C820D6: uid=0 from=<root@pbs.servername.ru>
Sep 29 21:47:25 pbs postfix/cleanup[640993]: E282E3C820D6: message-id=<20230929184724.E282E3C820D6@pbs.servername.ru>
Sep 29 21:47:25 pbs postfix/qmgr[640929]: E282E3C820D6: from=<root@pbs.servername.ru>, size=348, nrcpt=1 (queue active)
Sep 29 21:47:25 pbs postfix/smtp[640994]: E282E3C820D6: to=<zeroxzed@gmail.com>, relay=smtp.yandex.ru[77.88.21.158]:465, delay=1.1, delays=0.34/0.01/0.51/0.2, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued on mail-nwsmtp-smtp-production-main-84.vla.yp-c.yandex.net 1696013245-PlXVUC7DXqM0-wnVoD1Uo)
Sep 29 21:47:25 pbs postfix/qmgr[640929]: E282E3C820D6: removed

Письмо успешно доставлено. Теперь надо указать почтовый ящик для локального пользователя root@pam, чтобы почта отправлялась на внешний ящик, а не локальный /var/spool/mail/root. Сделать это можно через web интерфейс в разделе Configuration ⇨ Access Control. Выбираем пользователя root и в свойствах указываем его ящик. Теперь вся почта, что настроена в PBS для пользователя root@pam будет попадать во внешний ящик.

Инструкция будет актуальна и для PVE, только замену адреса отправителя можно не настраивать через консоль, так как в веб интерфейсе есть настройка для этого: Datacenter ⇨ Options ⇨ Email from address.

#proxmox

​​В моём распоряжении временно оказался свежезаказанный сервер с Proxmox VE 8.1 на софтовом рейде mdadm. Пока он не был нагружен рабочей нагрузкой, у меня появилась ограниченная возможность протестировать производительность разных форматов дисков: raw и qcow2. Lvm хранилище не было создано, так что его проверить не получилось. Не стал гонять разные тесты, так как лично меня интересуют только диски и разница между ними.

Конфигурация сервера следующая:

◽CPU: Intel Silver 4314 (16x2.4 ГГц HT)
◽RAM: 64 ГБ — 4 × 16 ГБ DDR4 ECC Reg
◽2 × 960 ГБ SSD Micron_5300_MTFDDAK960TDS

Я так понял, что это бюджетные серверные SSD.

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

[readtest]
blocksize=4k
filename=/dev/sdb
rw=randread
direct=1
buffered=0
ioengine=libaio
iodepth=8
[writetest]
blocksize=4k
filename=/dev/sdb
rw=randwrite
direct=1
buffered=0
ioengine=libaio
iodepth=8

Если будете повторять тест, то не перепутайте имена дисков, потеряете все данные на них. Тест запускал на голом сервере, где кроме гипервизора и одной виртуалки на базе Debian 12 ничего не было, никакой нагрузки. Настройки диска дефолтные:

◽Cache: Default (No cache)
◽Bus/Deviace: SCSI
◽SCSI Controller: VirtIO SCSI single

Сама виртуалка вот такая:
◽CPU: 4 Cores
◽Memory: 8 GiB

Все настройки по умолчанию. То есть взял некий средний вариант виртуалки, который обычно сам использую для разных задач.

Чтобы исключить влияние файловой системы, в виртуалке тесты делал на отдельных виртуальных дисках, один из которых был qcow2, второй raw. Это были вторые диски помимо системного.

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

В общем, я провёл несколько тестов, перезагружал гипервизор и проводил снова. На деле я не заметил существенной разницы. Отличия были в пределах погрешностей, как по iops, так и по latency. В связи с этим можно спокойно брать диски qcow2 и не бояться, что они будут медленнее raw. Тестами это не подтверждается. Зато qcow2 экономят место на сервере, так как растут по мере заполнения. Плюс, позволяют делать снепшоты на лету.

Я, честно говоря, думал, что raw будет быстрее процентов на 10% на запись хотя бы из-за того, что у qcow2 должна быть лишняя прослойка за счёт copy-on-write. На деле я этого не заметил. Результат меня заинтересовал, так что попробую при случае ещё раз прогнать где-то эти тесты, только ещё lvm туда добавить. Хотя уже сейчас мне кажется, что там тоже всё это будет в пределах погрешности.

Если кому-то реально интересны цифры, то вот типичный результат теста, который я получал плюс-минус постоянно:

 read: IOPS=33.4k, BW=130MiB/s (137MB/s)(50.0GiB/392494msec)
  slat (usec): min=2, max=280, avg= 5.23, stdev= 1.27
  clat (usec): min=34, max=12271, avg=233.77, stdev=328.07
   lat (usec): min=95, max=12276, avg=239.00, stdev=327.98
 write: IOPS=71.8k, BW=280MiB/s (294MB/s)(50.0GiB/182675msec); 0 zone resets
  slat (usec): min=2, max=159, avg= 4.45, stdev= 1.62
  clat (usec): min=36, max=8373, avg=106.48, stdev=56.20
   lat (usec): min=44, max=8378, avg=110.93, stdev=56.07

Поясню, что usec это microsecond, то есть latency чтения 233.77 usec = 0,233 ms (миллисекунды). Результаты примерно 30-70к IOPS и 0,1-0,2мс latency при чтении и записи объёма в 50.0GiB. Вроде неплохой результат в общем смысле. Хорошая производительность.

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

#proxmox

​​При использовании виртуализации на базе QEMU (например, Proxmox) я всегда в обязательном порядке использую qemu-guest-agent, который позволяет гипервизору взаимодействовать с установленной системой. Для этого в свойствах виртуальной машины нужно включить использование агента, а на систему установить соответствующий пакет.

Для Debian пакет так и называется - qemu-guest-agent:

# apt install qemu-guest-agent
# systemctl enable --now qemu-guest-agent

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

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

# qm agent <vmid> ping

Если всё в порядке, то вы не увидите никакого вывода, а код завершения будет нулевой. Это был пример команды для хоста Proxmox. Если у вас другая система виртуализации, и там, к примеру, используется virsh для управления, то команда будет следующая:

# virsh qemu-agent-command vmname '{"execute": "guest-ping"}'

Команды будут похожие. Приведу ещё один пример с Proxmox и virsh, а дальше буду только для Proxmox приводить. Смотрим время на гостевой системе:

# qm agent 101 get-time
# virsh qemu-agent-command vmname '{"execute": "guest-get-time"}'

Для взаимодействия с агентом используется отдельный протокол QMP, который возвращает ответы на запросы в формате json, так что для взаимодействия с ним пригодится утилита jq.

Теперь посмотрим, какие команды агента поддерживает конкретная виртуальная машина:

# qm agent 101 info | jq -r '.supported_commands[] | select(.enabled==true) | .name'

Я сразу обработал вывод, выбрав только поддерживаемые команды, и выведя само название. Можете посмотреть на полный вывод без обработки. К сожалению, конкретно в proxmox вывод supported_commands не совпадает с реальным списком, который поддерживается, потому что некоторые команды, типа guest-exec выполняются немного в другом синтаксисе. Те команды, что не работают, выдадут ошибку, а вместе с ошибкой выводится список, который реально поддерживается:

# qm agent 101 get-cpustats
400 Parameter verification failed.
command: value 'get-cpustats' does not have a value in the enumeration '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 cmd <vmid> <command>

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

# qm agent 101 get-osinfo

{
  "id" : "debian",
  "kernel-release" : "6.1.0-13-amd64",
  "kernel-version" : "#1 SMP PREEMPT_DYNAMIC Debian 6.1.55-1 (2023-09-29)",
  "machine" : "x86_64",
  "name" : "Debian GNU/Linux",
  "pretty-name" : "Debian GNU/Linux 12 (bookworm)",
  "version" : "12 (bookworm)",
  "version-id" : "12"
}

И так далее. Инструмент простой для освоения и использования. Может пригодиться, если нужен будет какой-то свой мониторинг с уровня гипервизора, например, за списком VM на хосте со следующей информацией:

◽гостевая система;
◽диски и точки монтирования;
◽сетевые интерфейсы и ip адреса на них;
◽количество cpu и ram.

Можно и доступность гостя так проверять. Также с помощью агента можно запускать любые команды на гостевой машине:

# qm guest exec 101 "df"

#kvm #proxmox

У меня давняя привычка — прятать все непубличные службы за firewall. Это касается и веб интерфейса Proxmox. Если сервер настраиваю сам, то всегда на самом хосте настраиваю iptables. Мало того, что так проще всего ограничить доступ к гипервизору, так он еще и шлюзом может выступить для виртуальных машин, так как всё управление NAT тоже через правила iptables.

Если сервер настраивал не я, и тем более если к серверу нет доступа напрямую в консоль, настраивать firewall я уже не буду. Все эти вещи всегда делаю после установки системы и перед переносом рабочей нагрузки. Если по какой-то причине доступ к веб интерфейсу Proxmox не ограничили, сделать это можно отдельно для службы pveproxy, которая отвечает за веб интерфейс. Это безопасно и всегда можно исправить ошибки, если что-то пошло не так.

У службы pveproxy есть файл конфигурации /etc/default/pveproxy, в который можно добавить правила с ограничением доступа. По умолчанию файла нет, его нужно создать. Выглядит это примерно так:

ALLOW_FROM="10.0.0.1-10.0.0.5,192.168.0.0/22"
DENY_FROM="all"
POLICY="allow"

После этого службу надо перезапустить:

# systemctl restart pveproxy.service

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

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

LISTEN_IP="192.0.2.1"

Также там можно переназначить дефолтные tls сертификаты. Это удобно, если вы используете свои. Все эти возможности описаны в документации.

#proxmox

​​Давно уже вышло обновление Proxmox 8.1, в котором несмотря на то, что это не новая ветка, появилось много значительных изменений. Для тех, кто хочет сразу посмотреть видеообзор на них, предлагаю видео на канале RomNero, где помимо 8.1, показаны изменения версии 8.0 по сравнению с 7.4, если вы их пропустили:

▶️ Proxmox 8.1 Upgrade. Обзор. Как безопасно обновиться

Если бы не это видео, я бы так и не узнал, что в версии 8.1 столько изменений. Не привык обращать внимание на промежуточные обновления внутри релиза. Основные нововведения 8.1:

◽ Появилась возможность создания программно определяемых сетей (SDN, Software-Defined Networking). Теперь можно создавать сетевые сегменты, помещать в них виртуальные машины, назначать IP адреса. И управлять всем этим через веб интерфейс в отдельном разделе. Реализован встроенный DHCP сервер на базе dnsmasq.
◽ Расширили возможности настройки оповещений через внешние SMTP сервера. Плюс, добавили условия, по которым можно направлять уведомления через разные способы доставки.
◽ Добавили поддержку Secure Boot.
◽ Добавили массовые действия для виртуальных машин. Можно выделить пачку машин, и, к примеру, перезагрузить их разом или потушить.
◽ Теперь при создании виртуальных машин на Windows можно сразу в интерфейсе настройки VM добавить диск с драйверами virtio.

Изменения масштабные. Больше и полезнее, чем в 8.0. Надо будет на днях обновиться и потестировать всё это. Полный список нововведений и обзор от разработчиков:

⇨ https://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_8.1
▶️ https://www.proxmox.com/en/services/videos/proxmox-virtual-environment/what-s-new-in-proxmox-ve-8-1

#proxmox

​​Решил, не откладывая в долгий ящик, проверить работу SDN на Proxmox 8.1. У меня как раз стоял настроенный недавно чистый сервер, причём версии именно 8.1. Я даже не обратил внимание на нововведения этого релиза и настроил всё по старинке с ручным созданием бриджа, правилами iptables с NAT, для того, чтобы гипервизор выступал в роли шлюза для виртуальных машин. Сейчас сделаю всё то же самое, только через настройки SDN.

Если вы обновили до 8.1 с прошлых релизов, то необходимо выполнить подготовительные действия.

1️⃣ Устанавливаем дополнительные пакеты и запускаем службу:
# apt update
# apt install libpve-network-perl dnsmasq
# systemctl enable --now dnsmasq
Dnsmasq заработает на всех интерфейсах, слушая 53 порт. Обязательно отключите к нему доступ из вне с помощью firewall.

2️⃣ Добавляем в /etc/network/interfaces в самый конец:
# source /etc/network/interfaces.d/*

Теперь можно идти в GUI Proxmox, в раздел Datacenter ⇨ SDN ⇨ Zones. Добавляем новую зону типа Simple. Идём в Vnets, добавляем новую сеть, например vm. Имя этой сети будет задавать имя сетевого бриджа, который будет создан в системе. Выбираем созданную сеть и добавляем к ней подсеть. Например, 10.200.0.0/24, шлюз 10.200.0.1, в SNAT ставим галочку. Во вкладке DHCP Ranges указываете диапазон IP адресов, которые будут назначаться виртуалкам с этой сетью.

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

После того, как вы создали сеть в Vnets, в файле конфигураций /etc/network/interfaces.d/sdn появятся настройки обычного сетевого бриджа Linux. Если при создании сети вы выбрали использование SNAT, к параметрам бриджа добавятся правила для iptables, типа таких:

post-up iptables -t nat -A POSTROUTING -s '10.200.0.0/24' -o inet0 -j SNAT --to-source 214.42.6.135
post-up iptables -t raw -I PREROUTING -i fwbr+ -j CT --zone 1

При этом сам бридж уже будет в системе с указанным названием. В качестве IP адреса у него будет настроен адрес шлюза, который вы указали в настройках Subnet.

Для созданной зоны, в которую входит сеть, будет создана отдельная директория с настройками dnsmasq в /etc/dnsmasq.d/, а диапазон выбранных ip адресов будет указан в отдельном файле конфигурации с именем сети:

dhcp-option=tag:vmlocal-10.200.0.0-24,option:router,10.200.0.1
dhcp-range=set:vmlocal-10.200.0.0-24,10.200.0.0,static,255.255.255.0,infinite
interface=vm

Там же будут и привязки MAC адресов к IP. Вот в общем-то и всё. Реализовано всё довольно просто и удобно. Никакой уличной магии и собственных костылей. Взяли известные инструменты и добавили управление ими через веб интерфейс. Единственно, чего не хватает, непосредственно локального DNS сервера. Не знаю, почему от dnsmasq взяли только DHCP. Возможности настройки локального DNS сервера в GUI нет. Хотя ничто не мешает добавить их руками в dnsmasq.

При создании VM вы можете добавить созданную сеть в качестве сетевого интерфейса. После загрузки система получит IP адрес в соответствии с настройками подсети. И если вы включили SNAT, то у неё сразу будет доступ в интернет.

Для меня пока остался нерешённым один важный момент. Как аккуратно связать свои настройки iptables с настройками, которые делает SDN. Это нужно, потому что встроенный firewall по прежнему не умеет пробрасывать порты в VM. Технически то это не трудно, надо просто понять, как это сделать максимально удобно. Я привык их хранить в отдельном скрипте и подгружать при старте сервера. Пока просто вручную добавил туда правила от SDN.

Подводя итог, можно сказать, что теперь настроить гипервизор в качестве шлюза для виртуальных машин можно полностью в GUI. Получив в качестве бонуса интегрированный в веб интерфейс IPAM. И это я разобрал только самый простой вариант — Simple Zone для создания виртуальной сети в рамках одного гипервизора. Остальные настройки ещё более масштабные.

#proxmox

​​До появления Proxmox Backup Server я часто отдавал предпочтение при выборе гипервизора Hyper-V из-за того, что для Proxmox VE не было функционального инструмента для бэкапов VM, кроме его встроенного средства, которое делало только полные бэкапы.

С выходом PBS этот вопрос был закрыт, причём бескомпромиссно. Предложенное решение было лучше, чем любое другое бесплатное. Так что связка Proxmox VE + PBS аналогов сейчас не имеет по удобству, простоте настройки и эксплуатации.

Отдельно отметить и рассказать более подробно я хочу про Proxmox Backup Client. Это консольная утилита для Linux, которая позволяет делать бэкап на уровне файлов из виртуальной машины в PBS, даже если система находится на другом гипервизоре. То есть это полностью отвязанный от инфраструктуры Proxmox клиент, который позволяет складывать резервные копии в PBS. Таким образом этот сервер бэкапов может объединять в себе разнородную инфраструктуру.

Сразу перечислю основные ограничения этого клиента:

▪ бэкап только на уровне файлов или образов дисков, не системы целиком;
▪ официальная поддержка только deb дистрибутивов, для rpm люди сами собирают пакеты, так как исходники открыты;
▪ нет поддержки windows, вариант бэкапа данных оттуда только один - монтирование диска по smb к linux машине и бэкап этого примонтированного диска.

Использовать proxmox-backup-client очень просто. Я не буду подробно описывать его возможности, так как в оригинальной документации представлена исчерпывающая информация. Если хочется на русском, то можно обратиться к документации от altlinux. Кратко покажу пример установки и бэкапа.

Ставим Proxmox Backup Client на Debian:

# wget https://enterprise.proxmox.com/debian/proxmox-release-bookworm.gpg -O /etc/apt/trusted.gpg.d/proxmox-release-bookworm.gpg
# mcedit /etc/apt/sources.list.d/pbs-client.list
Вставляем туда для Debian 12
deb http://download.proxmox.com/debian/pbs-client bookworm main
Для Debian 11:
deb http://download.proxmox.com/debian/pbs-client bullseye main
Для Debian 10:
deb http://download.proxmox.com/debian/pbs-client buster main
Ставим клиента:
# apt update && apt install proxmox-backup-client

Теперь бэкапим корень сервера без примонтированных дисков. То есть делаем бэкап системы:

# proxmox-backup-client backup root.pxar:/ --repository 10.20.1.47:main

Здесь мы указали:
◽root.pxar - имя архива в формате pbs
◽/ - бэкапим корень системы
◽10.20.1.47 - адрес pbs сервера
◽main - имя datastore

По умолчанию используется учётная запись root@pam, то есть дефолтный админ. Разумеется, на проде так делать не надо, потому что у него полные права, в том числе на удаление архивов. Делайте отдельные учётки для разных систем с ограниченными правами. В PBS это организовано удобно и просто, так что разобраться не трудно. Для указания имени пользователя, нужно использовать такой вид репозитория: user01@pbs@10.20.1.47. То есть мы указали созданного вручную пользователя user01@pbs.

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

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

# proxmox-backup-client snapshot list --repository 10.20.1.47:main
# proxmox-backup-client mount host/debian12-vm/2024-02-06T19:19:12Z root.pxar --repository 10.20.1.47:main /mnt/backup

Очень быстро и удобно. При желании бэкапы можно шифровать.

#proxmox #backup

Посмотрел вчера видео на тему проброса видеокарты в Proxmox:

▶️ Проброс видео карты в Proxmox

Я сам ни разу этого не делал, так как не было нужды. Вообще не припомню в своём управлении ни одного сервера с видеокартой. Для проброса видеокарты нужно:

1️⃣ Отредактировать параметры ядра хоста, отключить некоторые стандартные драйвера видеокарты.
2️⃣ Пересобрать initramfs хоста, перегрузить его.
3️⃣ Выбрать особые настройки VM, отключить у неё экран.
4️⃣ После этого добавить в неё видеокарту.

Меня удивила немного неочевидная настройка всего этого дела. А особенно отсутствие потом возможности подключиться к консоли VM с проброшенной видеокартой. Это типичная история для проброса видеокарты, или частный случай автора? Прямого доступа к консоли виртуалки с проброшенной картой реально не будет? Это неудобно. И не понятно, почему так получается.

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

p.s. Рекомендую канал и сайт автора. Там есть интересные и полезные материалы.

#proxmox

​​У браузера Firefox и всех остальных, что созданы на его основе, есть отличительная особенность, которая кому-то нравится, кому-то нет. Всё зависит от ситуации. У этого браузера своё собственное хранилище сертификатов, куда можно добавлять доверенные центры сертификации, минуя системное хранилище ОС. Для централизованного управления это скорее минус, а для индивидуального использования больше плюс.

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

Уже предвещаю комментарии на тему того, что надо настраивать ACME, создавать доменные имена и получать валидные сертификаты. Либо использовать какой-то обратный прокси для получения сертификатов и проксирования запросов.

Всё это можно сделать. Но, к примеру, у меня наберётся с десяток одиночных гипервизоров, где я не буду всего этого делать, потому что нет смысла. Доступ из интернета к ним открывать не буду. Я работаю с ними один, к ним нет доступа из интернета. Они принадлежат разным проектам и не объединены между собой. Мне проще забрать с этих гипервизоров pve-root-ca.pem, добавить в браузер, чтобы не засорять систему и сохранить учётки для быстрого входа. Доступ к ним всё равно закрыт списками IP адресов на файрволе.

Для того, чтобы настроить доверие для самоподписанного сертификата Proxmox, который создаётся во время установки гипервизора, надо зайти в веб интерфейсе в раздел System ⇨ Certificates. Выбрать сертификат pve-root-ca.pem, открыть его исходный текст. Скопировать и сохранить его в любой текстовый файл, указав ему расширение .crt.

Далее идём в браузер на основе Firefox. Я использую портированный LibreWolf. Переходим в Settings ⇨ Privacy & Security ⇨ Certificates ⇨ View Certificates. Там делаем Import сохранённого сертификата. Теперь из этого браузера при входе на веб интерфейс Proxmox не будет предупреждения. У вас появится возможность сохранить данные аутентификации.

#proxmox

​​На днях вышло обновление Proxmox 8.2, в котором появилось несколько интересных нововведений. Самое полезное на мой взгляд - импорт виртуальных машин из VMware ESXi. Я не сразу понял, как это реализовано. Обновил тестовый гипервизор, всё там пересмотрел и не нашёл импорт. Полез в документацию.

1️⃣ Работает он следующим образом. В списке Storage, доступных для добавления, появился новый тип - ESXi. Для добавления нужно указать его адрес и рутовую учётку. После этого в списке этого хранилища будут отображаться виртуальные машины хоста ESXi, откуда можно быстро выполнить импорт. Сделано удобно с минимум необходимых телодвижений. Жду, когда то же самое появится для Hyper-V. Лично для меня это более актуально.

2️⃣ Второе значительное изменение - появилась возможность в качестве встроенного файрвола использовать nftables, а не iptables. Пока это надо явно включить. Переход на nftables только прорабатывают, собирают обратную связь. В будущих релизах он заменит iptables окончательно. Так что можно потихоньку переползать. Кто не знаком с nftables, у меня есть небольшая статья по базовым правилам.

3️⃣ Третье важное дополнение. В настройках встроенных бэкапов появилась новая вкладка Advanced с дополнительными настройками процесса снятия бэкапов. Туда переехали настройки по ограничению ширины канала при бэкапе. А также добавилась новая настройка Backup fleecing, которая включает режим буферизации на локальный диск. Перед передачей на внешнее хранилище, бэкап работающей машины может кэшироваться на отдельном локальном storage, который можно выбрать из подключенных. Это снизит нагрузку на работающую VM во время снятия бэкапа и в целом ускорит процесс, так как кэшировать можно на наиболее ненагруженное хранилище. Возможно будет иметь смысл выделить отдельное хранилище под это дело.

Остальные изменения не такие существенные, поэтому перечислю их кратко:
◽появилась утилита proxmox-auto-install-assistant для подготовки установочного образа с готовыми настройками для установки без участия человека;
◽в веб интерфейс добавлена возможность настройки проброса устройств в lxc контейнеры;
◽в настройках ACME можно добавить любой другой удостоверяющий центр, отличный от Let's Encrypt;
◽изменились некоторые настройки веб интерфейса: не активируется режим редактирования полей при попытке скопировать данные оттуда, актуально, к примеру, для поля Notes с описанием VM, также изменилось положение кнопки с отменой введённых настроек.

Посмотреть, как все изменения выглядят в веб интерфейсе, можно вот в этом видео:

▶️ https://www.proxmox.com/en/services/videos/proxmox-virtual-environment/whats-new-in-proxmox-ve-8-2

Нравится, как команда Proxmox оформляет все свои обновления. Максимально подробно и текстом, и в виде роликов. Другим компаниям бы брать пример.

#proxmox

​​Пока прошлые статьи писал про сертификаты и Proxmox, возник вопрос. А как добавить в доверенные сертификат от Proxmox Backup Server, чтобы браузер не ругался? У него почему-то нет CA сертификата в веб интерфейсе, как в VE, который можно добавить в доверенные.

Немного поискал информацию и нашёл в официальной wiki на эту тему отдельную статью. Меня в ней привлекло вот что. В самом конце рассматривается случай, когда PBS и VE стоят на одной машине (Using Certificates from Proxmox VE). Авторы предлагают для PBS использовать тот же сертификат, что и для VE.

Меня удивило, что сами разработчики допускают использование обоих продуктов на одном железе. Я слышал, что так можно сделать, но не думал, что это может быть рекомендованная комбинация. Но, судя по всему, разработчики вполне допускают такое использование этих двух продуктов. Я лично PBS запускаю в виртуалке на том же гипервизоре, когда мне это нужно. Не рискую ставить рядом на ту же систему, что и гипервизор. Опасаюсь каких-то подводных камней от такого использования.

Пошёл смотреть документацию по установке PBS. Там есть отдельный раздел Install Proxmox Backup Server on Proxmox VE. Так что технически никаких проблем нет. Можно ставить PBS на хост виртуализации. Есть единственное предупреждение:

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

Предупреждение очевидное. Надо это понимать. Лично мне локальные копии нужны, чтобы в случае чего оперативно восстановить виртуальную машину из локального бэкапа. Само собой, он не единственный.

В целом, я бы всё же не рекомендовал ставить на один хост и PBS, и VE. Мне кажется, лучше в виртуалке (или в lxc) поднимать. Я не сторонник что-то настраивать на самих гипервизорах. Тогда они становятся невзаимозаменяемыми. Если есть возможность, лучше всё переносить в виртуальные машины. Если умрёт сервер, то простое восстановление виртуальных машин из бэкапа вернёт всю функциональность. А если что-то на гипервизоре настроено, то надо восстанавливать, и предварительно бэкапить, его настройки. Где-то это может быть оправдано, где-то нет.

Я если что-то и делаю на гипервизоре, так это только iptables настраиваю с nat. Все настройки - это единственный конфиг для iptables. Нетрудно сохранить.

#proxmox

​​Если вдруг вам хочется чего-нибудь странного, то могу вам кое-что предложить. Например, запустить контейнеры Docker в LXC контейнере Proxmox. Я изначально думал, что это так просто не сработает. Всегда запускаю контейнеры в виртуалках. Тут решил попробовать в LXC, сразу заработало.

Создаёте обычный LXC контейнер с нужными ресурсами. В параметрах через веб интерфейс необходимо установить nesting=1. Далее запускаете его и устанавливаете Docker:

# apt install curl
# curl https://get.docker.com | bash -
# docker run --rm hello-world

Hello from Docker!
This message shows that your installation appears to be working correctly.

Всё работает. Никаких дополнительных настроек делать не пришлось. Проверял на Proxmox VE 8.2.2. В принципе, удобно. Получается можно спокойно в LXC изолировать контейнеры и запускать их. Мне казалось, что раньше это так не работало.

#proxmox #docker

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

С помощью Cloud-Init в Proxmox можно автоматически добавить в виртуальную машину:

- пользователей, пароли, ключи для SSH
- настройки DNS
- сетевые настройки
- выполнить принудительное обновление пакетов

Технически это выглядит следующим образом.

1️⃣ Вы настраиваете виртуальную машину так, как вам нужно. Ставите нужные пакеты, настраиваете ПО, если надо. Отдельно устанавливаете пакет с cloud-init:
# apt install cloud-init
Можно использовать готовые образы уже с cloud-init внутри:
https://cloud.debian.org/images/cloud/
https://cloud-images.ubuntu.com/
https://dl.astralinux.ru/ui/native/mg-generic/alse/cloud/
Proxmox поддерживает готовые образы, сформированные для OpenStack.

2️⃣ Из этой виртуальной машины делаете эталонный шаблон средствами Proxmox (пункт меню convert to template).

3️⃣ Создаёте из этого шаблона виртуальную машину. Добавляете к ней отдельное устройство Cloudinit Drive.

4️⃣ В настройках виртуальной машины есть отдельный раздел Cloud-init, где можно индивидуально для конкретной машины задать перечисленные выше настройки.

Без Cloud-Init пришлось бы руками лезть в новую виртуалку и менять эти параметры. А так они аккуратно задаются через интерфейс управления и потом применяются. Работает просто и удобно. Настраивается тоже без проблем.

Описанная выше инструкция с техническими подробностями есть в Wiki Proxmox. Там же FAQ по этой теме:

- Cloud-Init Support
- Cloud-Init FAQ

Каких-то подводных камней в этой настройке нет. Делается всё просто и почти сходу. Я специально проверил после написания заметки. Всё получилось сразу же, как я описал. Шаблон сделал свой, не брал готовый.

#proxmox

​​Для тех, кто пользуется Proxmox Backup Server (PBS) важное предостережение. Я им пользуюсь практически с момента релиза, но только недавно столкнулся с проблемой. Не допускайте исчерпания свободного места на сервере с бэкапами.

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

А тут проспал. Точнее, неправильно отреагировал на сложившуюся ситуацию. Были видно, что место заканчивается. Я зашёл, удалил некоторые бэкапы в ожидании увеличения свободного объёма для хранения. Была сделана копия большой виртуалки, которая тоже поехала в архив. Рассчитывал, что благодаря дедупликации, реального места будет занято не так много. Но ошибся.

То ли место не успело освободиться, то ли дедупликация в реальности сработала не так, как я ожидал, но в итоге было занято 100% доступного объёма хранилища и все процессы в нём встали. Он даже сам себя очистить не мог. Процесс Garbage Collect не запускался из-за недостатка свободного места. Я решил вопрос просто - очистил логи systemd:

# journalctl --vacuum-size=256M

Они занимали несколько гигабайт, так что мне хватило для того, чтобы отработал процесс Garbage Collect. Но он не удаляет данные, а только помечает их к удалению. Реально данные будут удалены через 24 часа и 5 минут после того, как сборщик мусора пометит их на удаление. И никакого способа вручную запустить реальную очистку хранилища нет. По крайней мере я не нашёл.

Очень внимательно прочитал несколько тем на официальном форуме по этой проблеме и везде совет один - освобождайте место или расширяйте хранилище, если у вас zfs, запускайте сборщик мусора и ждите сутки. Других вариантов нет, кроме полного удаления Datastore со всеми бэкапами. Тогда место освободится сразу.

Это особенность реализации дедупликации в PBS. Помеченные на удаления chunks реально удаляются через 24 часа. Форсировать этот процесс не получится.

#proxmox #backup