​​Один из подписчиков поделился со мной интересным проектом — Proxmox Helper Scripts. Это большой набор bash скриптов для управления гипервизором, виртуалками и контейнерами через консоль.

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

Я изучил некоторые скрипты. Это очень простой bash код, который можно посмотреть, понять, изучить и что-то взять на вооружение. Мне один раз предложили решить комплексную задачу по автоматизации развёртывания VM в Proxmox для тестовой среды. Я сначала согласился, набросал черновики, но потом отказался от задачи, так как не было времени довести до ума. Думал, потом доделаю и выложу в статье или заметке, но так и не доделал. Для тех, кому интересно, использовал стандартные CLI команды Proxmox.

Набор Proxmox Helper Scripts — это продукт для домашнего использования любителями этой виртуализации. Готовые LXC контейнеры для установки тоже на это намекают (Home Assistant, Pi-hole, Syncthing, CrowdSec и т.д.). Я лично для себя там ничего полезного не нашёл, но в целом идея нормальная. Свою аудиторию она найдёт. Автор активно пилит скрипты. Видно по почти ежедневным обновлениям репозитория. Я попробовал установить некоторые LXC контейнеры. Сделано удобно, мне понравилось. На выходе полностью работающий сервис в обычном контейнере.

👍 Отдельно отмечу скрипт по установке тёмной темы интерфейса управления. Он устанавливает качественную и проработанную тёмную тему - PVEDiscordDark.

⇨ Сайт / Исходники

p.s. Отдельное спасибо всем, кто шлёт в личку что-то интересное. Я обычно всё проверяю, но не всё становится заметками.

#proxmox

​​Наконец-то произошло это знаменательное событие и в веб интерфейсе 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