Я ранее делал пару заметок на тему бесплатных инструментов для организации SSO: Keycloak и Authentik. Первый более навороченный и сложный для больших организаций. Второй попроще и больше подходит для небольших инфраструктур, в том числе личных сервисов. По настройке и возможностям мне Authentik понравился больше. Жду подходящий проект, чтобы его внедрить. Уже давно решил, что где-нибудь его попробую.

Тут как раз на днях посмотрел видео про настройку Basic Auth на базе Authentik. Очень востребованная лично для меня функциональность. Я люблю использовать Basic Auth в Nginx для того, чтобы скрыть от посторонних глаз то, что не должно быть в публичном доступе: различные управляющие веб панели, типа postfixadmin или phpmyadmin, веб доступ к 1С и т.д.

▶️ Authentik и basic http аутентификация

Автор по шагам показал, как это сделать на примере Traefik и Nginx. Там ничего особо сложного, но из-за скудной документации по этой теме некоторые вещи неочевидны. С инструкцией всё понятно. Посмотрел наглядно, как это выглядит. Мне понравилось. С учётом того, как часто я использую Basic Auth, точно пригодится. Вот ссылка на документацию по теме. Там реально всего пару предложений и пример конфига.

У автора серия из 3-х публикаций про Authentik:
▶️ Настройка authentik по-быстрому
▶️ OIDC авторизация с помощью Authentik на примере Portainer

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

#sso #nginx

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

Порядок настройки следующий:

1️⃣ Сохраняю список правил в файл /etc/iptables.sh. Адаптирую под текущие условия гипервизора: меняю имена сетевых интерфейсов, IP адреса. Делаю его исполняемым. Обычно сразу же проверяю, просто запустив его.

# mcedit /etc/iptables.sh
# chmod +x /etc/iptables.sh
# bash /etc/iptables.sh
# iptables -L -v -n

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

2️⃣ Убеждаюсь, что после выполнения скрипта появился файл-экспорт с набором правил /etc/iptables.rules. Добавляю применение правил в файл /etc/network/interfaces:

iface enp5s0 inet manual
post-up iptables-restore < /etc/iptables.rules

Вешаю загрузку правил iptables на поднятие wan интерфейса.

3️⃣ Перезагружаю сервер и убеждаюсь, что всё нормально поднимается, правила применяются, доступ к серверу у меня есть.

4️⃣ Если нужно добавить или изменить какое-то правило, то правлю файл iptables.sh, а когда закончу, запускаю его. Он обновляет набор правил в iptables.rules, так что после перезагрузки хоста изменённые правила сохранятся.

Если у вас хост Proxmox выполняет роль шлюза, то не забудьте проверить, что параметр net.ipv4.ip_forward=1 активен в /etc/sysctl.conf. Без него NAT для виртуалок не заработает. Точнее не сам нат, а передача пакетов между локальным и wan интерфейсом. Если в качестве шлюза для VM выступает отдельная VM, то как минимум из набора правил исчезает NAT и всё, что касается локалки и проброса портов. А на шлюз уезжает этот же шаблон с правилами и там правится по месту.

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

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

#proxmox #iptables

▶️ Очередная подборка авторских IT роликов, которые я лично посмотрел и посчитал интересными/полезными. Как обычно, ниже те видео из моих подписок за последнее время (обычно беру период в 2 недели), что мне показались интересными и полезными.

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

⇨ Настройка DNS over HTTPS в OPNsense
Небольшой ролик про DNS over HTTPS для тех, кто не знает, что это такое и как работает. Тут автор кратко рассказал о технологии и на практике показал, как это работает и как настраивается на своём софтовом шлюзе OPNsense.

⇨ Netbird Update - How to add the new "Relays" feature to your netbird install.
Рассказ про бесплатную, open source платформу для построения VPN сетей - netbird.io. Вышло крупное обновление продукта. Автор рассказал, как его установить и что в нём нового. Вообще, это интересный продукт. Я видел его обзор у разных блогеров, писал заметку про него. Один из лучших open source проектов из этой области.

⇨ Vinchin - Backup система для ВСЕГО!
Обзор системы для бэкапа Vinchin. Автор прошёлся по основным возможностям. Я в своё время примерно то же самое оформил в отдельную статью на сайте. Система, в принципе, неплохая. Мне понравилась.

⇨ Building a Low-Power, Fully Loaded Plex Server
Подробное описание сборки сервера под популярный медиасервер Plex для дома. Автор поставил задачу собрать тихий и маломощный в плане потребления электричества сервер на базе Mini ITX. Интересно посмотреть, что у него в итоге получилось.

⇨ Администрирование Линукс. Стабильность и безопасность системы
Короткое видео с наглядным примером эксплуатации уязвимости ярда Linux CVE-2024-1086. Я, кстати, об этой уязвимости писал в своё время. На видео примерно то же самое делается, что у меня в заметке.

#видео

Когда только начинал работать с виртуализацией на Linux, очень хотелось сесть за сервер и прямо на нём что-то сделать. Но на тот момент ни XenServer, ни VmWare не позволяли это сделать. На экране сервера был небольшой список простых действий типа настроек сети или перезагрузки. И ничего, что относилось бы к управлению виртуальными машинами. После экспериментов с VMware Workstation и Hyper-V было как-то непривычно и неудобно.

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

В Proxmox решить эту задачу очень просто. Под капотом там обычная система Debian, на которую можно установить графическую оболочку. Более того, как это сделать, рассказано в официальной Wiki проекта. Там это названо так:

⇨ Developer Workstations with Proxmox VE and X11

Всё, что вам надо сделать, так это установить туда xfce, браузер и менеджер управления графическими оболочками в системе. Предупреждаю, что делать это на продуктовых серверах - плохая практика.

Выполняем непосредственно гипервизоре:

# apt install xfce4 chromium lightdm

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

# adduser webuser

Запускаем графическую оболочку:

# systemctl start lightdm

Можно подключать монитор к серверу, заходить в систему и подключаться к локальному веб интерфейсу по адресу https://localhost:8006.

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

Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#proxmox

Пока была возможность, решил проверить, какой штраф на дисковые операции накладывает виртуализация в Proxmox. В моей работе чаще всего именно дисковая подсистема является узким местом серверов. CPU обычно хватает, память сейчас недорога и легко расширяется. С дисками проблем больше всего.

Взял тестовый сервер Proxmox, в котором есть железный RAID контроллер без кэша и собранный RAID10 из 4-х HDD. Воткнул туда дополнительно обычный SSD AMD Radeon R5 R5SL480G 480ГБ. RAID10 подключил как обычный LVM storage, а SSD как LVM-Thin.

Нарезал там LV для хоста:

# lvcreate -V 10G -n test_ssd --thinpool SSD-RADEON/SSD-RADEON
# lvcreate -L 10G -n test_raid10 raid10

Сделал фс ext4 и смонтировал:

# mkfs.ext4 /dev/SSD-RADEON/test_ssd
# mkfs.ext4 /dev/raid10/test_raid10
# mount /dev/SSD-RADEON/test_ssd /mnt/SSD-RADEON
# mount /dev/raid10/test_raid10 /mnt/raid10

Прогнал серию из 10-ти тестов для каждого хранилища с помощью dd:

# dd if=/dev/zero of=/mnt/raid10/tempfile bs=1M count=2000 oflag=direct
# dd if=/dev/zero of=/mnt/SSD-RADEON/tempfile bs=1M count=2000 oflag=direct

Далее взял fio и прогнал тесты с его помощью:

Линейное чтение: 
# fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=1M -iodepth=32 -rw=read -runtime=30 -filename=/dev/raid10/test_raid10

Линейная запись: 
# fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=1M -iodepth=32 -rw=write -runtime=30 -filename=/dev/raid10/test_raid10

Пиковые IOPS случайной записи: 
# fio -ioengine=libaio -direct=1 -invalidate=1 -name=test -bs=4k -iodepth=128 -rw=randwrite -runtime=30 -filename=/dev/raid10/test_raid10

Так для обоих дисков. С dd сделал по 10 тестов, с fio по 5. Потом создал VM на Debian 12, создал для неё такие же диски, выбрав параметры:

▪️Device: SCSI
▪️Cache: Default (No cache)
▪️IO thread: yes
▪️Async IO: Default (io_uring)

Настройки все по умолчанию. И там выполнил точно такие же тесты. Свёл всё в одну таблицу. Я тут приводить точные цифры тестов не буду, так как они не имеют принципиального значения. Цифры можете сами посмотреть. Перейду сразу к выводам.

Разброс в производительности не более 9%. А если точно, то разница между хостом и VM только в одном тесте на запись была 9%, в остальных случаях 2-6%. Немного удивило то, что в паре тестов в VM результаты были выше на 2%, чем на хосте. Я несколько раз перепроверял, но ситуация воспроизводилась снова. Не знаю, с чем это может быть связано.

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

#proxmox #disk #perfomance

Завершу тему с тестированием дисков информацией про кэширование в Proxmox VE. У него стандартный набор режимов, которые будут плюс-минус такие же и у рейд контроллеров. Сделаю в формате небольшой шпаргалки, а подробности с картинками есть в документации.

▪️None - режим по умолчанию. Если не хочется разбираться в этой теме, то можете оставлять этот режим и не заморачиваться. Он универсален для сервера общего назначения. Гипервизор никак не вмешивается в операции ввода-вывода. VM работает как-будто напрямую с хранилищем. Может отправлять данные в очередь хранилища на запись, либо дожидаться реальной записи.

▪️Writethrough - операции записи VM идут напрямую в хранилище, как и в режиме none. В этом режиме добавляется кэш гипервизора, который используется только для чтения. То есть мы получаем такую же надёжность записи, как и в none, но добавляется кэш на операции чтения. Если у вас сервер отдаёт много статики, то можете включить этот режим.

Железный рейд контроллер без батарейки обычно работает в таком же режиме.

▪️Directsync - кэширование гипервизора не используется вообще, как в none. Отличие этого режима в том, что мы заставляем VM работать с хранилищем только в режиме реальной записи с подтверждением. То есть виртуалка не использует очередь хранилища. Затрудняюсь придумать пример, где это реально надо. Никогда не использовал этот режим.

▪️Writeback - операции записи и чтения кэшируются гипервизором. VM будет получать подтверждения о записи, когда данные попадут в кэш гипервизора, а не хранилища. Это существенно увеличивает быстродействие дисков VM. Особенно если у гипервизора много свободной оперативной памяти для кэша. Если будет сбой сервера и данные из кэша хоста не успеют записаться, то мы получим потерю информации с разными последствиями для системы. Она скорее всего выживет, но если там работала СУБД, то база может оказаться битой.

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

▪️Writeback (unsafe) - то же самое, что Writeback, но с одним отличием. В режиме Writeback гостевая VM может отправить команду на запись данных в реальное хранилище, а не кэш гипервизора. У неё есть возможность принудительно поддерживать консистентность данных. В режиме unsafe команда на запись в хранилище всё равно перехватывается кэшем хоста. Это обеспечивает максимальное быстродействие VM и максимальную ненадёжность сохранности данных. Я этот режим использую на тестовых гипервизорах.

❗️Все эти режимы имеют смысл при использовании типа диска RAW. Например, при использовании LVM Storage или обычных raw файлов с хранением в директории хоста. Во всех остальных случаях (qcow2, zfs) кэширование лучше не трогать и оставлять его в режиме none. Также следует аккуратно менять режимы при использовании raid контроллера с батарейкой, встроенной памятью и включенным кэшированием. Будет неочевидно, какой режим выбрать - тот или иной кэш гипервизора или самого контроллера, либо их обоих. Надо тестировать на своей нагрузке. Я в таких случаях оставляю кэш контроллера и не использую кэш гипервизора. Просто интуитивно так делаю. Как лучше, я не знаю.

🔹Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#proxmox #disk

Я написал большую и насколько смог подробную статью по настройке кластера на базе Proxmox VE. По современным требованиям законодательства я вынужден промаркировать её как реклама, так как сервера для её написания мне предоставил хостер Selectel, а я оставил на него ссылки. Никаких требований непосредственно по рекламе предъявлено не было, кроме одного – в статье должно быть показано, как я заказываю услуги через панель управления. По содержанию и тексту не было ни единой правки. Всё продумал, настроил и написал лично я от и до.

Статья получилась универсальной без привязки к конкретным услугам, так как я использую обычные арендные сервера с установленной бесплатной версией Proxmox VE, а в качестве общих хранилищ для кластера – сетевые диски, подключаемые через iSCSI интерфейс. Настройка подобных дисков плюс-минус везде одинаковая. Разница если и будет, то в типе аутентификации или её отсутствии.

В статье отражены следующие моменты:

▪️Настройка Proxmox VE на серверах с двумя NVMe M.2 дисками, объединёнными в программный RAID1 на базе mdadm для отказоустойчивости на уровне дисков.
▪️Объединение трёх идентичных серверов в обычный кластер с локальными дисками и ручной миграцией виртуальных машин без их остановки.
▪️Настройка сети виртуальных машин с VLAN с помощью встроенной Proxmox SDN.
▪️Подключение к серверам сетевых дисков по iSCSI, добавление их в Proxmox и создание на их базе общих хранилищ для дисков виртуальных машин в формате LVM.
▪️Настройка HA (High Availability) на примере виртуальной машины и LXC контейнера. Я настраиваю HA, аварийно выключаю одну из нод кластера и показываю, как с неё автоматически переезжают ресурсы на работающие ноды.

На выходе мы получаем универсальное и относительно бюджетное (в сравнении с другими кластерами) решение для размещения виртуальных машин и LXC контейнеров. Оно закрывает задачи размещения нагрузки на локальных дисках для максимальной производительности и отказоустойчивой нагрузки высокой доступности на базе сетевых дисков с общим доступом.

Остались нерассмотренными пара других полезных конфигураций:

◽️Репликация виртуальных машин в кластере на базе файловых хранилищ в формате zfs.
◽️Использование кластера Ceph для виртуальных машин, построенного на базе этих же трёх нод кластера.

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

⇨ Установка и настройка кластера Proxmox VE

Настройка кластера высокой доступности на базе Proxmox VE представляет из себя относительно простую, рядовую задачу. При этом выполнить её можно на любом железе, от самого бюджетного десктопного оборудования до серверных платформ. Сочетание софтовых решений по отказоустойчивости дисков на базе mdadm или zfs вкупе с функциональностью HA кластера Proxmox позволяют реализовать относительно (!) высокую доступность на любом поддерживаемом этой системой оборудовании. А так как сама система на базе ОС Debian и ядра Linux, поддерживает она практически любое более-менее современное железо.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#proxmox #статья

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

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

Итак, проблемы могут возникнуть, когда у вас будет примерно такая сетевая карта:

# lspci | grep Ethernet
04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller

По умолчанию у вас будет установлен драйвер r8169. Проверить так:

# lsmod | grep r81
r8169

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

Проблема может через 10 минут пройти сама, а может и нет, и поможет только перезагрузка. В логах могут быть какие-то упоминания проблем с сетевой картой, типа таких:

[01448.532276] r8169 0000:09:00.0 enp3s0: rtl_rxtx_empty_cond == 0 (loop: 42, delay: 100).

А может и вообще ничего не быть. Известное мне решение только одно – использовать драйвер r8168. Это решение широко освещено на официальном форуме Proxmox. Там можно найти множество веток с обсуждением подобной проблемы.

Драйвер можно скачать самому и собрать его. Взять можно, например, тут. Там есть инструкция по сборке, она несложная. Можно взять готовый пакет для Debian из non-free репозитория: r8168-dkms. Установить его можно так. Добавляем себе в систему репозитории non-free и non-free-firmware. То есть в файле /etc/apt/sources.list должна быть строка:

deb http://ftp.ru.debian.org/debian bookworm main contrib non-free non-free-firmware

Ставим необходимые пакеты:

# apt install pve-headers r8168-dkms

Во время установки r8168-dkms должен собраться и установиться драйвер r8168, а предыдущий r8169 отключиться и добавиться к заблокированным во время загрузки.

Есть ещё один пакет с этим драйвером, собранный специально под PVE. Я не знаю, чем он отличается от обычного дебиановского. Брать тут. Его достаточно просто скачать и установить:

# wget https://github.com/nathanhi/r8168/releases/download/pve8%2F8.054.00-1-bpo12/r8168-dkms_8.054.00-1-bpo12_all.deb
# dpkg -i r8168-dkms_8.054.00-1-bpo12_all.deb

Описанные выше действия могут как помочь, так и нет. Например, на одном сервере я вообще не видел сетевой карты. После установки драйвера r8168, она определялась в системе и начинала нормально работать. А иногда ничего не менялось и сеть как отваливалась периодически, так и продолжала отваливаться. Тогда приходилось делать что-то типа такого:

#!/bin/bash
IP="10.20.1.2"
if ! ping -c 1 -W 5 "$IP" > /dev/null 2>&1; then
  echo "$(date): $IP недоступен. Перезапуск сетевой службы..."
  systemctl restart networking
else
  echo "$(date): $IP доступен."
fi

Ставил подобный bash скрипт в cron на исполнение каждую минуту. В моменты редких зависаний он перезапускал сеть и всё продолжало нормально работать.

☝️ А резюме всего этого такое. Если у вас сетевая карта Realtek, то либо замените её, либо не ставьте туда Proxmox. Есть высокая вероятность, что нормально он всё равно работать не будет, а вы только время потеряете на отладку и решение проблем.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#proxmox #ошибка

В Proxmox есть давняя проблема с LXC контейнерами. Внутри них вы видите нагрузку LA (Load Average) не контейнера, а хоста. Это сбивает с толку мониторинг. Например Zabbix, если к контейнеру прикреплён стандартный шаблон Linux.

Давно знаю про эту проблему. В реальной работе редко использую LXC, отдавая предпочтение обычным виртуалкам. Если сталкивался со спамом уведомлений на эту тему, то обычно просто отключал соответствующий триггер.

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

Достаточно добавить соответствующий ключ запуска к службе lxc, запуск которой описан в файле /usr/lib/systemd/system/lxcfs.service. Вместо

ExecStart=/usr/bin/lxcfs /var/lib/lxcfs

делаем:

ExecStart=/usr/bin/lxcfs -l /var/lib/lxcfs

Перечитываем настройки и перезапускаем службу:

# systemctl daemon-reload
# systemctl restart lxcfs.service

Это решение в лоб, чтобы было понятно, что конкретно делаем. Более корректно менять настройки systemd через переопределение их в override.conf. Для этого создаём файл /etc/systemd/system/lxcfs.service.d/override.conf:

# systemctl edit lxcfs

Пишем туда:

[Service]
ExecStart=
ExecStart=/usr/bin/lxcfs -l /var/lib/lxcfs/

И тоже перечитываем настройки и перезапускаем службу:

# systemctl daemon-reload
# systemctl restart lxcfs.service

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

После этого надо остановить все контейнеры и запустить заново. Теперь внутри LXC вы будете видеть LA непосредственно контейнера.

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

В LXC Merge request для решения этого вопроса принят ещё в 2018 году. Вот ответ на форуме от сотрудника поддержки:

"Seems like it's working well for some users, but to be honest i don't see any reason to make it default still. it's rather easy to add the flag and it's a specific use case..."

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

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

#proxmox #lxc

На днях обновились два продукта Proxmox, которые я активно использую: Virtual Environment 9.0 и Backup Server 4.0. Прежде чем перейти к содержанию обновлений, сделаю предупреждение. Не торопитесь обновлять свои сервера. У Proxmox есть некоторый шанс получить проблемы после обновления, особенно для большого обновления со сменой релиза Debian. Я сам лично много раз сталкивался с ними. Делал тут по этому поводу заметки. Плюс, опыт других людей говорит о том же.

Расскажу про своё отношение к обновлению гипервизоров. Если рядом нет подменного сервера, на который можно быстро восстановить работу виртуальных машин, то я его не обновляю без веских оснований. Процесс этот откладываю на максимально комфортное время, когда это можно сделать. Обычно какие-то длинные праздники, типа майских или новогодних. То же самое для кластера. Обновлять надо очень аккуратно и понимать, что ты будешь делать, если он вдруг не переживёт обновление. Уронить прод от неаккуратного обновления гораздо проще, чем получить проблемы от каких-то уязвимостей, которых во-первых, не так много, чтобы это было опасно в закрытом контуре, во-вторых, обновления приходят регулярно и если постоянно обновляться по мере их выхода, то частота этого процесса сама по себе по теории вероятности принесёт рано или поздно проблемы.

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

📌Ключевые обновления Proxmox VE:

🔥Обычные LVM тома, не Thin, теперь поддерживают снэпшоты. У меня это самый популярный формат хранения. Из-за того, что он не поддерживал снепшоты, иногда приходилось использовать qcow2 диски, но они не очень удобны из-за ряда особенностей. В описании указано, что хранилища типа Directory, NFS, и CIFS тоже получили такую функциональность. Но по описанию я не очень понял, относится ли это, к примеру, к RAW дискам, расположенным в директории. Из описания вроде бы да (Directory, NFS, and CIFS storages also gain additional support for snapshots as volume chains), но я не понимаю, как это технически реализовано. Надо будет на практике проверять. Вроде бы автоматически создаётся qcow2 файл для накопления изменений относительно базового диска.
◽️Добавлена функциональность SDN Fabric для построения отказоустойчивых управляемых и динамически маршрутизируемых сетей. У меня таких вообще нет, так что попробовать не придётся. Это в основном актуально для больших кластеров.
◽️Дополнительные графики с метриками. Будет полезно. Я частенько их смотрю для беглой оценки работы VM.
◽️Новый мобильный веб интерфейс. Лично я им вообще не пользуюсь. Заходил очень редко в исключительных ситуациях. Не знаю, зачем он нужен. Изредка можно и версию для ПК открыть.

Из основного это всё. Как я понимаю, триггером для релиза был переход на Debian 13, поэтому непосредственно в функциональности изменений немного.

📌 Ключевые обновления Proxmox BS:

🔥Поддержка S3-совместимых хранилищ. Этого реально не хватало. Подобные хранилища очень популярны и относительно дёшевы. Теперь можно спокойно брать дедики с небольшими локальными дисками и подключать более дешёвые S3 хранилища.
◽️Автоматический запуск синхронизации при подключении съёмного хранилища. Можно руками подключить внешний диск или подключить скриптами и бэкап на него будет автоматически синхронизирован. Потом его можно отмонтировать.
◽️Много мелких исправлений в интерфейсе, в уведомлениях, в очистке старых данных и некоторых других моментах.

Я наверное первые обновления сделаю, когда выйдут версии 9.1 и 4.1.

#proxmox