​​В релизе 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