Skip to main content

Установка ВМ Ubuntu Server 24.04 для Syslog-сервера в Proxmox VE

1. Назначение

Виртуальная машина предназначена для развёртывания централизованного Syslog-сервера на Ubuntu Server 24.04 с использованием:

rsyslog        — приём и раскладка удалённых syslog-сообщений;
logrotate      — ежедневная ротация и архивирование логов;
Zabbix agent 2 — передача выбранных событий и счётчиков в Zabbix.

В базовой инструкции используется Ubuntu Server Minimal 24.04, rsyslog, logrotate, набор диагностических утилит и Zabbix agent 2.

2. Параметры виртуальной машины

Рекомендуемые параметры ВМ в Proxmox:

Name:          SMR-SRV-OT-SYSLOG
OS:            Ubuntu Server 24.04 LTS
BIOS:          SeaBIOS или OVMF
Machine:       q35 или default i440fx
CPU:           2–4 vCPU
RAM:           4–8 GB
Disk:          200 GB
Disk bus:      SCSI
SCSI Controller: VirtIO SCSI single
Network:       VirtIO
Bridge:        vmbr0 или vmbr1, в зависимости от нужной сети

Для Syslog-сервера ключевой ресурс — диск. Объём 200 GB под такую задачу выглядит разумно, особенно если логи будут храниться локально, ротироваться ежедневно и сохраняться за несколько недель.

3. Создание ВМ в Proxmox

В веб-интерфейсе Proxmox открыть:

Datacenter
└── Node
    └── Create VM

3.1. General

Node:      нужный Proxmox-узел
VM ID:     автоматически или вручную
Name:      SMR-SRV-OT-SYSLOG

3.2. OS

Выбрать ISO:

Ubuntu Server 24.04 LTS ISO

Тип ОС:

Linux
Version: 6.x - 2.6 Kernel

3.3. System

Рекомендуемый вариант:

Graphic card: Default
Machine:      Default или q35
BIOS:         SeaBIOS
SCSI Controller: VirtIO SCSI single
Qemu Agent:   включить

После установки Ubuntu желательно установить qemu-guest-agent.

3.4. Disks

Параметры диска:

Bus/Device: SCSI
Storage:    local-lvm или нужное хранилище Proxmox
Disk size:  200G
Cache:      Default / No cache
Discard:    включить, если storage поддерживает thin provisioning
IO thread:  включить

3.5. CPU

Sockets: 1
Cores:   2 или 4
Type:    host

Для Syslog-сервера обычно достаточно 2 vCPU, но при большом количестве источников логов можно выделить 4 vCPU.

3.6. Memory

Memory: 4096 MB

Если планируется много Zabbix-проверок и большой поток логов:

Memory: 8192 MB

3.7. Network

Сетевой адаптер:

Model:  VirtIO (paravirtualized)
Bridge: vmbr0 или vmbr1

Если Syslog-сервер должен принимать события из сети 10.44.100.0/24, подключить адаптер к:

Bridge: vmbr1

Если нужен доступ к интернету для обновлений через сеть 192.168.1.0/24, можно использовать vmbr0, либо добавить второй адаптер.

Практичная схема для двух сетей:

net0 → vmbr0 — обновления, интернет, администрирование;
net1 → vmbr1 — приём логов из VLAN 2100 / сети 10.44.100.0/24.

4. Установка Ubuntu Server 24.04

При установке выбрать минимальный серверный вариант.

Рекомендуемая разметка для диска 200 GB:

/boot      автоматически
/          основная система
/var/log   желательно отдельным разделом или отдельным LVM-томом
swap       4–8 GB

Для Syslog-сервера логично выделить большую часть места под /var/log.

Пример:

/          40 GB
/var/log   150 GB
swap       8 GB
резерв     остаток

Если установщик используется с автоматической LVM-разметкой, после установки нужно проверить, куда реально попадает /var/log. Для Syslog-сервера нежелательно, чтобы активные логи быстро заполнили корневой раздел.

5. Базовая настройка Ubuntu после установки

Обновить систему:

# Обновляем список пакетов
sudo apt update

# Устанавливаем доступные обновления
sudo apt upgrade -y

Установить базовые пакеты:

# Устанавливаем rsyslog, logrotate и диагностические утилиты
sudo apt install -y rsyslog logrotate nano iputils-ping tcpdump arping bash-completion lsof qemu-guest-agent

В исходной инструкции дополнительно используются tcpdump, arping, bash-completion и lsof для диагностики и проверки ротации логов.

Включить QEMU Guest Agent:

# Включаем агент гостевой ВМ для корректного взаимодействия с Proxmox
sudo systemctl enable --now qemu-guest-agent

6. Настройка времени

Задать часовой пояс:

# Проверяем доступность часового пояса
timedatectl list-timezones | grep Samara

# Устанавливаем часовой пояс
sudo timedatectl set-timezone Europe/Samara

# Проверяем результат
timedatectl status
date

Настроить NTP через systemd-timesyncd:

# Устанавливаем systemd-timesyncd
sudo apt install -y systemd-timesyncd

# Открываем конфигурацию
sudo nano /etc/systemd/timesyncd.conf

Пример содержимого:

[Time]
NTP=192.168.1.1 0.pool.ntp.org 1.pool.ntp.org
FallbackNTP=2.pool.ntp.org 3.pool.ntp.org

Применить:

# Перезапускаем службу синхронизации времени
sudo systemctl restart systemd-timesyncd

# Включаем NTP-синхронизацию
sudo timedatectl set-ntp true

# Проверяем состояние
timedatectl status
systemctl status systemd-timesyncd --no-pager

В нормальном состоянии должно быть:

System clock synchronized: yes
NTP service: active

В исходной инструкции для Ubuntu Server используется systemd-timesyncd, с основным NTP-сервером 192.168.1.1 и резервными публичными NTP-серверами.

7. Настройка статического IP-адреса

Проверить имя сетевого интерфейса:

# Показываем сетевые интерфейсы
ip -br link
ip -br addr

Посмотреть netplan-файлы:

# Смотрим текущие файлы netplan
ls -l /etc/netplan/

Создать отдельный файл статической настройки:

# Создаем отдельный файл для статического IP
sudo nano /etc/netplan/99-static-syslog.yaml

Пример для одного интерфейса:

network:
  version: 2
  renderer: networkd
  ethernets:
    ens18:
      dhcp4: false
      addresses:
        - 10.44.100.X/24
      nameservers:
        addresses:
          - 192.168.1.1

Если у ВМ есть интерфейс в сеть с интернетом, например 192.168.1.0/24, основной шлюз лучше указывать только там:

network:
  version: 2
  renderer: networkd
  ethernets:
    ens18:
      dhcp4: false
      addresses:
        - 192.168.1.X/24
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses:
          - 192.168.1.1

    ens19:
      dhcp4: false
      addresses:
        - 10.44.100.X/24

Права на файл:

# Ограничиваем права на netplan-файл
sudo chmod 600 /etc/netplan/99-static-syslog.yaml

Проверить и применить:

# Проверяем синтаксис
sudo netplan generate

# Безопасно применяем настройки с возможностью отката
sudo netplan try

Если работа выполняется из консоли Proxmox, можно применить сразу:

# Применяем настройки
sudo netplan apply

Проверка:

# Проверяем адреса, маршруты и DNS
ip -br addr
ip route
resolvectl status

# Проверяем шлюз и DNS
ping -c 4 192.168.1.1
ping -c 4 ya.ru

В исходной инструкции статический IP настраивается через netplan, с предварительной проверкой имени интерфейса и безопасным применением через netplan try.

8. Подготовка каталогов для логов

Создать базовый каталог:

# Создаем базовый каталог для удалённых логов и alert-файлов
sudo mkdir -p /var/log/remote/_alerts

Назначить владельца:

# Назначаем владельцем системного пользователя syslog
sudo chown -R syslog:syslog /var/log/remote

Ограничить доступ:

# Закрываем каталог от лишнего доступа
sudo chmod 0750 /var/log/remote
sudo chmod 0750 /var/log/remote/_alerts

Проверить:

# Проверяем права на каталоги
ls -ld /var/log/remote
ls -ld /var/log/remote/_alerts

Ожидаемо:

drwxr-x--- ... syslog syslog ... /var/log/remote
drwxr-x--- ... syslog syslog ... /var/log/remote/_alerts

9. Включение rsyslog

# Запускаем rsyslog и добавляем его в автозагрузку
sudo systemctl enable --now rsyslog

# Проверяем статус
sudo systemctl status rsyslog --no-pager

10. Конфигурация rsyslog

Создать конфигурационный файл:

# Создаем файл конфигурации удалённого syslog-приёма
sudo touch /etc/rsyslog.d/10-remote-collector.conf

# Открываем файл
sudo nano /etc/rsyslog.d/10-remote-collector.conf

В этот файл переносится конфигурация из основной инструкции 10-remote-collector.conf.

Логика конфигурации:

1. Включается приём UDP/514 и TCP/514.
2. Все сообщения от каждого устройства пишутся в:
   /var/log/remote/<IP_ИСТОЧНИКА>/all.log

3. Дополнительно выполняется раскладка:
   /var/log/remote/<IP_ИСТОЧНИКА>/facility/<facility>.log
   /var/log/remote/<IP_ИСТОЧНИКА>/severity/<severity>.log

4. Для Zabbix создаются alert-файлы:
   /var/log/remote/_alerts/<ПОДСЕТЬ>/high.log
   /var/log/remote/_alerts/<ПОДСЕТЬ>/alerts_critical.log
   /var/log/remote/_alerts/<ПОДСЕТЬ>/alerts_warning.log
   /var/log/remote/_alerts/<ПОДСЕТЬ>/alerts_behavior.log

В исходной инструкции используется раскладка по IP источника, facility, severity и отдельные alert-файлы для Zabbix по подсетям /24.

После заполнения файла проверить синтаксис:

# Проверяем синтаксис rsyslog
sudo rsyslogd -N1

Если ошибок нет:

# Перезапускаем rsyslog
sudo systemctl restart rsyslog

# Проверяем состояние службы
sudo systemctl status rsyslog --no-pager

Проверить, что открыт порт 514:

# UDP/514
sudo ss -ulpn | grep ':514'

# TCP/514
sudo ss -tlpn | grep ':514'

При необходимости посмотреть входящий UDP-трафик:

# Смотрим входящие syslog-пакеты
sudo tcpdump -ni any udp port 514

11. Проверка приёма Syslog

Локальная проверка именно через UDP/514:

# Отправляем тестовое сообщение на локальный UDP/514
logger -n 127.0.0.1 -P 514 -d -p user.err -t TEST "Проверка записи в high.log через UDP 514"

Проверить, куда записалось сообщение:

# Ищем тестовое сообщение
sudo grep -R "Проверка записи в high.log через UDP 514" /var/log/remote/

Ожидаемые каталоги для источника 127.0.0.1:

/var/log/remote/127.0.0.1/
/var/log/remote/_alerts/127.0.0.0/

Проверка с другого Linux-узла:

# UDP
logger --server <IP_SYSLOG_SERVER> --udp --port 514 -p user.err -t TEST "Проверка удаленного syslog по UDP"

# TCP
logger --server <IP_SYSLOG_SERVER> --tcp --port 514 -p user.err -t TEST "Проверка удаленного syslog по TCP"

Проверка файлов:

# Показываем созданные файлы
sudo find /var/log/remote -type f | sort

# Смотрим полный лог источника
sudo tail -n 20 /var/log/remote/<IP_ИСТОЧНИКА>/all.log

В исходной инструкции отдельно подчёркнуто, что для проверки именно удалённого ruleset нужно отправлять сообщение на UDP/514, а не просто выполнять локальный logger без указания сервера.

12. Настройка Cisco для отправки Syslog

На коммутаторе Cisco:

conf t
!
service timestamps log datetime msec localtime show-timezone
service timestamps debug datetime msec localtime show-timezone
!
logging host <IP_SYSLOG_SERVER>
logging trap informational
logging facility local7
no logging console
!
end
wr

Проверка на Cisco:

show logging
show running-config | include logging

Тестовое сообщение:

send log 5 TEST_LEVEL5_SYSLOG

На Syslog-сервере:

# Ищем тестовое сообщение от Cisco
sudo grep -R "TEST_LEVEL5_SYSLOG" /var/log/remote/

13. Настройка logrotate

Создать файл:

# Создаем конфиг logrotate для удалённых syslog-логов
sudo touch /etc/logrotate.d/remote-syslog

# Открываем файл
sudo nano /etc/logrotate.d/remote-syslog

Содержимое:

/var/log/remote/*/*.log
/var/log/remote/*/*/*.log
{
    daily
    rotate 30

    missingok
    notifempty

    compress
    delaycompress

    dateext
    dateyesterday
    dateformat -%Y%m%d

    create 0640 syslog syslog
    sharedscripts
    postrotate
        systemctl kill -s HUP rsyslog.service >/dev/null 2>&1 || true
    endscript
}

Пояснение:

daily                 — ротация раз в день;
rotate 30             — хранить 30 ротаций;
missingok             — не считать ошибкой отсутствие файла;
notifempty            — не ротировать пустые файлы;
compress              — сжимать старые логи;
delaycompress         — не сжимать самый свежий ротированный файл сразу;
dateext               — использовать дату в имени;
dateyesterday         — использовать дату предыдущего дня;
dateformat -%Y%m%d    — формат имени, например all.log-20260426;
create 0640 syslog syslog — создавать новый файл с нужными правами;
postrotate HUP rsyslog — заставить rsyslog переоткрыть файлы.

В исходной инструкции для logrotate используется ежедневная ротация, хранение 30 ротаций, сжатие старых логов, дата предыдущего дня в имени файла и HUP для rsyslog после ротации.

Проверить без реального выполнения:

# Debug-проверка logrotate без фактической ротации
sudo logrotate -d -f -v /etc/logrotate.d/remote-syslog

При необходимости выполнить реальную принудительную ротацию:

# Принудительная ротация, использовать аккуратно
sudo logrotate -f -v /etc/logrotate.d/remote-syslog

Проверка результата:

# Смотрим файлы после ротации
sudo find /var/log/remote -type f | sort

Проверка записи после ротации:

# Отправляем тестовое сообщение после logrotate
logger -n 127.0.0.1 -P 514 -d -p user.err -t TEST "Проверка после logrotate"

# Проверяем запись
sudo grep -R "Проверка после logrotate" /var/log/remote/

14. Установка Zabbix agent 2

Скачать пакет подключения репозитория Zabbix 7.0 для Ubuntu 24.04:

# Скачиваем пакет репозитория Zabbix
wget https://repo.zabbix.com/zabbix/7.0/ubuntu/pool/main/z/zabbix-release/zabbix-release_latest_7.0+ubuntu24.04_all.deb

Установить пакет:

# Устанавливаем пакет репозитория
sudo dpkg -i zabbix-release_latest_7.0+ubuntu24.04_all.deb

Обновить список пакетов:

# Обновляем список пакетов
sudo apt update

Установить агент:

# Устанавливаем Zabbix agent 2
sudo apt install -y zabbix-agent2

15. Доступ Zabbix к логам

Так как логи создаются с владельцем и группой syslog:syslog, пользователя zabbix нужно добавить в группу syslog:

# Добавляем пользователя zabbix в группу syslog
sudo usermod -aG syslog zabbix

Проверить:

# Проверяем группы пользователя zabbix
id zabbix

В выводе должна быть группа:

syslog

Перезапустить агент:

# Перезапускаем агент после изменения групп
sudo systemctl restart zabbix-agent2

Исходная инструкция использует именно добавление пользователя zabbix в группу syslog, так как файлы логов создаются с правами syslog:syslog.

16. Настройка Zabbix agent 2

Открыть файл:

# Открываем основной конфиг Zabbix agent 2
sudo nano /etc/zabbix/zabbix_agent2.conf

Задать параметры:

# Кто имеет право опрашивать агент по passive checks.
# Разрешаем подключения от серверов и/или proxy из сети 10.10.99.0/24.
Server=10.10.99.0/24

# Куда агент сам будет подключаться за active checks
# и куда будет отправлять данные по active items.
ServerActive=<IP_ZABBIX_SERVER_OR_PROXY>:10051

# Имя этого хоста в Zabbix.
# Должно совпадать с именем хоста, созданного в веб-интерфейсе Zabbix.
Hostname=SMR-SRV-OT-SYSLOG

Пример:

Server=10.10.99.0/24
ServerActive=10.10.99.7:10051
Hostname=SMR-SRV-OT-SYSLOG

Запустить и включить агент:

# Добавляем агент в автозагрузку и запускаем
sudo systemctl enable --now zabbix-agent2

# Перезапускаем и проверяем статус
sudo systemctl restart zabbix-agent2
sudo systemctl status zabbix-agent2 --no-pager

В исходной инструкции для мониторинга логов рекомендуется использовать активные элементы Zabbix, а в конфигурации agent 2 задаются Server, ServerActive и Hostname.

17. Примеры элементов данных Zabbix

17.1. Аварийные события

Файл:

/var/log/remote/_alerts/192.168.1.0/alerts_critical.log

Тип элемента:

Zabbix agent (active)

Ключ:

logrt[/var/log/remote/_alerts/192.168.1.0/alerts_critical\.log,"PM-4-ERR_DISABLE|SPANTREE-2-BLOCK_BPDUGUARD|UDLD-4-UDLD_PORT_DISABLED|SPANTREE-2-CHNL_MISCFG|STORM_CONTROL-3-SHUTDOWN"]

17.2. Предупреждения

Файл:

/var/log/remote/_alerts/192.168.1.0/alerts_warning.log

Ключ:

logrt[/var/log/remote/_alerts/192.168.1.0/alerts_warning\.log,"SPANTREE-2-LOOPGUARD_BLOCK|SPANTREE-2-ROOTGUARD_BLOCK|STORM_CONTROL-3-FILTERED"]

17.3. Накопительные признаки

Файл:

/var/log/remote/_alerts/192.168.1.0/alerts_behavior.log

Общий ключ:

logrt.count[/var/log/remote/_alerts/192.168.1.0/alerts_behavior\.log,"MAC_MOVE-4-NOTIF|SW_MATM-4-MACFLAP_NOTIF|SPANTREE-5-TOPOTRAP|SPANTREE-5-ROOTCHANGE"]

Для сети 10.44.100.0/24 путь нужно заменить:

/var/log/remote/_alerts/10.44.100.0/alerts_critical.log
/var/log/remote/_alerts/10.44.100.0/alerts_warning.log
/var/log/remote/_alerts/10.44.100.0/alerts_behavior.log

В исходной инструкции для ротируемых alert-файлов используются logrt[], а для подсчёта повторяемости MAC flapping и STP-событий — logrt.count[].

18. Финальная проверка

Проверить rsyslog:

# Проверяем статус rsyslog
sudo systemctl status rsyslog --no-pager

# Проверяем UDP/514 и TCP/514
sudo ss -ulpn | grep ':514'
sudo ss -tlpn | grep ':514'

Проверить тестовую запись:

# Отправляем финальное тестовое сообщение
logger -n 127.0.0.1 -P 514 -d -p user.err -t TEST "Финальная проверка syslog"

# Ищем его в логах
sudo grep -R "Финальная проверка syslog" /var/log/remote/

Проверить logrotate:

# Проверяем logrotate без реальной ротации
sudo logrotate -d -f -v /etc/logrotate.d/remote-syslog

Проверить Zabbix agent:

# Проверяем статус агента и группы пользователя zabbix
sudo systemctl status zabbix-agent2 --no-pager
id zabbix

Проверить отправку с Cisco:

send log 5 TEST_LEVEL5_SYSLOG
show logging

На Syslog-сервере:

# Ищем тестовое сообщение Cisco
sudo grep -R "TEST_LEVEL5_SYSLOG" /var/log/remote/

19. Итоговый порядок

1. Создать ВМ в Proxmox.
2. Выделить диск 200 GB.
3. Подключить Ubuntu Server 24.04 ISO.
4. Установить Ubuntu Server Minimal.
5. Желательно выделить отдельный раздел или LVM-том под /var/log.
6. Настроить статический IP.
7. Обновить систему.
8. Установить rsyslog, logrotate, диагностические утилиты и qemu-guest-agent.
9. Настроить время и NTP.
10. Создать /var/log/remote/_alerts.
11. Настроить /etc/rsyslog.d/10-remote-collector.conf.
12. Проверить rsyslogd -N1.
13. Перезапустить rsyslog и проверить порт 514.
14. Проверить приём тестового syslog-сообщения.
15. Настроить logrotate для /var/log/remote.
16. Проверить logrotate в debug-режиме.
17. Установить Zabbix agent 2.
18. Добавить пользователя zabbix в группу syslog.
19. Настроить Server, ServerActive и Hostname.
20. Создать активные элементы данных Zabbix на базе logrt[] и logrt.count[].
21. Проверить получение сообщений от Cisco.

Такой вариант даёт отдельную ВМ под Syslog-сервер с диском 200 GB, централизованным приёмом логов, ежедневной ротацией, подготовленными alert-файлами и возможностью дальнейшей обработки событий через Zabbix agent 2.

После установки Ubuntu желательно установить qemu-guest-agent - объясни подробнее


qemu-guest-agent — это агент внутри виртуальной машины, через который Proxmox может корректно взаимодействовать с гостевой ОС.

То есть Proxmox видит не просто «чёрный ящик с Ubuntu», а может получать от неё часть информации и отдавать ей корректные команды.

Зачем он нужен

Без qemu-guest-agent Proxmox всё равно будет запускать ВМ, но часть функций будет работать хуже или не работать.

С агентом Proxmox может:

корректно выключать ВМ из веб-интерфейса;
корректно перезагружать ВМ;
видеть IP-адреса внутри ВМ;
лучше обрабатывать snapshot/backup;
передавать гостевой ОС команду на freeze/thaw файловой системы при backup;
получать более точную информацию о состоянии ВМ.

Для Syslog-сервера это особенно полезно, потому что сервер будет постоянно писать логи на диск. При резервном копировании лучше, чтобы Proxmox мог аккуратнее согласовать состояние файловой системы внутри Ubuntu.

Что будет без него

Если агент не установлен, кнопки в Proxmox всё равно будут:

Start
Stop
Shutdown
Reboot
Reset

Но есть разница.

Без qemu-guest-agent

Команда Shutdown может работать менее надёжно. Proxmox отправляет ACPI-сигнал, а дальше зависит от того, как гостевая ОС его обработает.

Также Proxmox может не видеть IP-адрес ВМ в интерфейсе.

С qemu-guest-agent

Proxmox может обратиться к агенту внутри Ubuntu и выполнить более корректное завершение работы.

Для ВМ это выглядит ближе к команде:

shutdown now

а не к грубому отключению питания.

Как включить в Proxmox

В настройках виртуальной машины:

VM
└── Options
    └── QEMU Guest Agent

Поставить:

Enabled

Также при создании ВМ в разделе System можно сразу включить галочку:

Qemu Agent

После изменения параметра ВМ лучше полностью выключить и включить заново, не просто перезагрузить:

Shutdown → Start

Как установить в Ubuntu Server 24.04

Внутри Ubuntu выполнить:

# Обновляем список пакетов
sudo apt update

# Устанавливаем QEMU Guest Agent
sudo apt install -y qemu-guest-agent

# Включаем агент в автозагрузку и сразу запускаем
sudo systemctl enable --now qemu-guest-agent

# Проверяем статус службы
sudo systemctl status qemu-guest-agent --no-pager

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

active (running)

Как проверить со стороны Proxmox

После установки агента и включения опции в настройках ВМ в Proxmox можно проверить:

VM
└── Summary

Там Proxmox обычно начинает показывать IP-адреса ВМ.

Также через Shell Proxmox можно проверить командой:

# Проверяем, отвечает ли guest-agent внутри ВМ
qm agent <VMID> ping

Например, если ID виртуальной машины 100:

# Проверяем доступность агента для ВМ 100
qm agent 100 ping

Если всё работает, команда вернётся без ошибки.

Можно посмотреть сетевые интерфейсы ВМ:

# Показываем сетевые интерфейсы гостевой ОС через guest-agent
qm agent 100 network-get-interfaces

Важное отличие от драйверов VirtIO

qemu-guest-agent — это не драйвер сетевой карты и не драйвер диска.

Для Ubuntu драйверы VirtIO обычно уже встроены в ядро Linux. Поэтому сетевой адаптер VirtIO и SCSI-диск VirtIO работают без отдельной установки драйверов.

qemu-guest-agent нужен именно для управления и обмена служебной информацией между Proxmox и гостевой ОС.

Для инструкции можно добавить так

После установки Ubuntu Server необходимо установить qemu-guest-agent. Он нужен для корректного взаимодействия Proxmox с гостевой ОС: штатного выключения и перезагрузки ВМ, отображения IP-адресов в интерфейсе Proxmox, а также более корректной работы операций резервного копирования и snapshot.

Команды:

# Обновляем список пакетов
sudo apt update

# Устанавливаем QEMU Guest Agent
sudo apt install -y qemu-guest-agent

# Включаем агент в автозагрузку и запускаем его
sudo systemctl enable --now qemu-guest-agent

# Проверяем состояние службы
sudo systemctl status qemu-guest-agent --no-pager
Back to top