🖱 И вот ещё хороший вводный курс в Proxmox VE от Селектела:

• Магия виртуализации: вводный курс в Proxmox VE.
• Трактат о сущности механизма бэкапов в Proxmox VE.
• Кластеризация в Proxmox VE.

#напочитать #proxmox

​​Один из читателей сайта к статье о настройке proxmox написал комментарий по переносу виндовых виртуалок с hyperv на proxmox. Мне показалась информация полезной, поэтому оформляю в заметку и делюсь с вами. Самому тоже приходилось делать такие переносы, но инструкцию не составлял.

Для начала надо перенести vhdx образы на proxmox и сконвертировать в нужный вам формат. Например в qcow2:
qemu-img convert -O qcow2 /path/to/vhdx/VM.vhdx /path/to/qcow2/vm.qcow2

Далее создаём новую виртуалку, добавляем ей диск минимального размера (VirtIO SCSI). Он нужен будет позже, чтобы установить virtio драйвера на диск в систему. Добавляем к этой виртуалке сконвертированный диск как ide и делаем его загрузочным. Так же добавляем cd-rom и подключаем к нему virtio-win.iso последней версии. В настройках Hardware -> Bios меняем с дефолтного SeaBios на OVMF (UEFI).

Запускаем виртуалку. Должна загрузиться. Ставим все драйвера, в том числе на диск, а так же qemu-guest-agent. Выключаем.

Далее либо через правку конфига vm в консоли меняете путь от virtio диска минимального размера на рабочий, либо через веб интерфейс отцепляете оба диска и обратно подключаете системный диск как VirtIO SCSI. На этом всё.

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

#hyperv #proxmox

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

Для того, чтобы правильно настроить политику хранения, есть удобный калькулятор, где наглядно показано, какие именно бэкапы будут сохраняться при той или иной схеме - https://pbs.proxmox.com/docs/prune-simulator/

Например, я чаще всего использую схему, когда хранятся 7 последних дневных архива, 4 недельных и 6 или 12 месячных. То есть мы можем откатиться назад на любой день в течении последних 7-ми дней. Далее с 8-го по 30-й день у нас есть только 4 недельных бэкапа. А еще дальше только месячные бэкапы.

Для реализации такой схемы делаются следующие настройки параметров Backup Retention в Storage, куда будут складываться бэкапы:
◽ Keep Daily: 7
◽ Keep Weekly: 4
◽ Keep Monthly: 6
Остальные значения не указываем.

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

#proxmox

Я на прошлой неделе возился дома с домашней лабой на proxmox. Обновил старый nettop, который лежал без дела. Поставил в него ssd диск и 16 gb памяти. Решил добавить к кластеру proxmox. Для тестовых vm будет самое то - не шумит, мало места занимает, электричества крохи ест.

Но вот незадача. Стандартный драйвер Realtek в ядре Linux не заработал со встроенной сетевухой. Пришлось качать альтернативный и собирать его локально. Основная сложность в том, что когда не работает сеть, ты как без рук. Я уже отвык от такого режима работы. Пришлось файлы и репозитории на флешке таскать на этот nettop и вспоминать, как работать на сервере без сети.

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

https://serveradmin.ru/r8169-rtl_rxtx_empty_cond-0-loop-42-delay-100/

#proxmox #ошибка

В продуктах Proxmox не так давно появилась возможность использовать сторонние SMTP сервера для отправки уведомлений. Точнее, стало возможно через веб интерфейс настроить аутентификацию на внешнем сервере. В PVE вроде бы с 8-го релиза появилась эта настройка, в PBS не помню точно.

В разделе меню Notification обоих продуктов появился новый тип уведомлений SMTP, где можно указать привычные параметры внешних почтовых серверов. Тем не менее, если для отправки используется бесплатный почтовый сервис типа Yandex, Mail или Gmail, я предпочитаю настраивать по старинке через локальный Postfix, который так же использует внешний SMTP сервер с аутентификацией.

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

Настройка Postfix простая. Не помню, устанавливается ли он в свежих версиях PVE и PBS по умолчанию, но если нет, то надо поставить:

# apt install postfix

И затем добавить в конфиг /etc/postfix/main.cf, например, для Яндекса:

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

Если эти же параметры где-то выше уже объявлены, то закомментируйте их там. Создаём файл /etc/postfix/sasl_passwd такого содержания:

smtp.yandex.ru user01@yandex.ru:userpass123

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

Создайте файл /etc/postfix/generic:

root@pve user01@yandex.ru

Здесь мы настраиваем, чтобы все письма от локального пользователя root сервера с именем pve отправлялись с заменой адреса отправителя на user01@yandex.ru. Иначе Яндекс не примет письмо к отправке. У других почтовых сервисов может не быть таких ограничений и этот шаг можно будет пропустить.

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

# postmap /etc/postfix/generic /etc/postfix/sasl_passwd
# systemctl restart postfix

Можно проверять отправку. Проще всего это сделать в веб интерфейсе PVE. Для этого идём в раздел Datacenter ⇨ Notification. Там по умолчанию уже есть способ отправки типа sendmail с указанным Target mail-to-root. Это как раз отправка почты с помощью Postfix на ящик системного пользователя root@pam. Ящик для него можно указать в настройках пользователя: Datacenter ⇨ Permissions ⇨ Users ⇨ root ⇨ E-Mail.

Выбираем способ отправки sendmail и жмём Test. Можно сходить в консоль сервера и проверить лог отправки. Если всё прошло успешно, то в /var/log/mail.log будет примерно следующее:

pve postfix/pickup[941603]: 4C81718E07A1: uid=0 from=<user01@yandex.ru>
pve postfix/cleanup[941760]: 4C81718E07A1: message-id=<20240820202545.4C81718E07A1@pve>
pve postfix/qmgr[941604]: 4C81718E07A1: from=<user01@yandex.ru>, size=894, nrcpt=1 (queue active)
pve postfix/smtp[941762]: 4C81718E07A1: to=<superadmin@yandex.ru>, relay=smtp.yandex.ru[77.88.21.158]:465, delay=0.48, delays=0.03/0.02/0.17/0.26, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued on mail-nwsmtp-smtp-production-main-17.iva.yp-c.yandex.net 1724185545-jPUEPlgXtGk0-KOiggjh6)
pve postfix/qmgr[941604]: 4C81718E07A1: removed

Сервер успешно использовал relay=smtp.yandex.ru и отправил с его помощью письмо superadmin@yandex.ru, получив status=sent. Письмо ушло адресату, отправляющий сервер принял его в обработку.

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

#proxmox

Поискал по каналу и не нашёл ни одной заметки, где бы я рассказал и показал на практике, как я настраиваю 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