Инвентаризация чужих виртуалок: что вообще досталось в наследство

MAATRIX

Бывает хуже, чем достаться в наследство одному серверу без документации: вам достаётся физическая машина, а на ней — гипервизор с десятком виртуалок, часть из которых даже не запущена. У каждой своё имя, свой набор ресурсов, и ни одной строчки о том, зачем она нужна и можно ли её выключить. Проблема не в том, чтобы разобраться в одной системе — их несколько, они изолированы друг от друга, а самая опасная из них может как раз оказаться той, что сейчас выключена и месяцами не подавала признаков жизни. Ниже — порядок инвентаризации: как получить список VM средствами самого гипервизора, определить назначение каждой и не потерять то, что нужно раз в год, а не каждый день.

Список VM через гипервизор, а не через угадывание

Первое, что нужно сделать — получить список виртуальных машин из самого гипервизора, а не из блокнота прежнего админа или переписки в чате (если такая переписка вообще нашлась). Команда для этого зависит от того, что именно вам досталось.

Proxmox VE. Список виртуалок и их текущий статус:

qm list

Вывод показывает VMID, имя, статус (running/stopped), объём памяти, размер диска и PID процесса. Если на ноде есть LXC-контейнеры (отдельный слой виртуализации, не то же самое, что VM), их список — отдельной командой:

pct list

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

qm config <vmid>
# либо напрямую файлом
cat /etc/pve/qemu-server/<vmid>.conf

Голый KVM через libvirt (без Proxmox поверх). Список всех доменов, включая выключенные — ключевой флаг --all, без него virsh покажет только запущенные:

virsh list --all
virsh dominfo <domain>
virsh dumpxml <domain>

dumpxml — самый информативный вывод: там видно диски, их пути в хранилище, сетевые интерфейсы и мосты, к которым VM подключена, выделенные vCPU и память.

VMware ESXi (standalone, без vCenter). Список виртуалок с внутренними ID:

vim-cmd vmsvc/getallvms
vim-cmd vmsvc/power.getstate <vmid>
vim-cmd vmsvc/get.summary <vmid>

Если инфраструктура под vCenter, удобнее открытый CLI govc (govc ls, govc vm.info <path>) или PowerCLI — но для разовой инвентаризации на одном хосте vim-cmd работает без установки чего-либо дополнительного.

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

Определяем назначение: по имени, по содержимому, по нагрузке

Назначение VM редко удаётся установить одним способом — обычно нужно сопоставить три источника, потому что каждый по отдельности может ввести в заблуждение.

По имени. Самый быстрый, но самый ненадёжный источник. Имя vm-101-backup-old звучит однозначно, но «old» может значить как «устарела, можно сносить», так и «старая версия для сверки перед закрытием квартала». Имена вроде test, tmp, vm2 не говорят вообще ничего — и именно они чаще всего оказываются либо забытыми, либо, наоборот, критичными: у обеих крайностей одинаково невыразительное имя.

По содержимому. Единственный способ узнать точно — заглянуть внутрь. Для запущенной VM это просто: подключиться по SSH или консоли гипервизора и посмотреть систему теми же приёмами, что для обычного сервера (ps auxf, ss -tulpn, список пакетов). Для выключенной VM без входа внутрь тоже можно получить много информации, не включая её:

# Proxmox: какой диск и хранилище закреплены за VM
qm config <vmid> | grep -E 'scsi|virtio|ide|sata'

# libvirt: список блочных устройств VM
virsh domblklist <domain>

# монтирование qcow2-образа в read-only, без запуска VM
modprobe nbd max_part=8
qemu-nbd --connect=/dev/nbd0 --read-only /path/to/disk.qcow2
mkdir -p /mnt/vmcheck && mount -o ro /dev/nbd0p1 /mnt/vmcheck
ls /mnt/vmcheck
umount /mnt/vmcheck && qemu-nbd --disconnect /dev/nbd0

Монтирование образа в режиме только для чтения — самый безопасный способ заглянуть в содержимое выключенной VM: /etc/hostname, конфиги сервисов, домашние директории и логи — без риска что-то сломать и без запуска самой системы. Для Windows-гостя вместо mount понадобится libguestfs (guestfish, virt-cat) — он же читает и qcow2-образы Linux без ручного nbd.

По нагрузке. Для запущенных VM история потребления CPU, памяти и диска — надёжный источник, если в гипервизоре включён сбор метрик (в Proxmox — встроенный RRD-график во вкладке Summary, доступный и через pvesh get /nodes/<node>/qemu/<vmid>/rrddata). Ровная низкая нагрузка почти всегда означает вспомогательную роль — мониторинг, DNS, прокси. Резкие пики раз в сутки или раз в неделю по расписанию — признак пакетной задачи (бэкап, синхронизация, отчёт), и этот паттерн стоит поймать до того, как решать судьбу VM.

Риск нерегулярной нагрузки: VM для годовой отчётности

Это отдельная и самая коварная категория риска. Представьте: VM выключена, судя по метрикам — простаивает большую часть года, диск занимает ощутимое место, имя ни о чём не говорит («srv-fin-2» или того хуже — «test3»). По формальным признакам — кандидат на удаление. А по факту это единственная машина, где установлена нужная версия бухгалтерского софта (типичный случай — старая конфигурация 1С или специализированное ПО для сдачи отчётности), которую включают раз в год, готовят отчёт или сверку и выключают обратно до следующего цикла.

Такие VM не паранойя — это частый паттерн в унаследованной инфраструктуре: годовая отчётность, продление лицензий, сверка с контрагентами или сезонный расчёт — рутинные процессы, физически привязанные к конкретному софту на конкретной машине, но происходящие настолько редко, что за время между двумя запусками успевает смениться админ, а сам факт существования VM забывается.

Как отличить забытую VM от VM с годовым циклом, не дожидаясь, пока кто-то из бизнеса о ней вспомнит (или не вспомнит — и тогда проблему обнаружат только в момент, когда VM понадобится и её уже не будет):

• История запусков за длинный период, а не за последний месяц. Метрики гипервизора обычно хранят RRD-данные за год — смотрите весь доступный график: единичный пик активности одиннадцать месяцев назад и есть искомый паттерн.
• Логи гипервизора о старте/остановке VM. В Proxmox история задач хранится в /var/log/pve/tasks/ и доступна через pvesh get /cluster/tasks — там видны даты qmstart/qmshutdown за прошлые периоды. В libvirt то же самое ищите в /var/log/libvirt/qemu/<domain>.log.
• Название и содержимое установленного софта внутри. Смонтировав диск в режиме чтения, проверьте файлы в характерных директориях — папки вроде «Отчет_2025», «Баланс_Q4», конфиги 1С прямо укажут на назначение.
• Внутренние cron/планировщик и лицензии с датой истечения. Задача, запускающаяся раз в год определённого числа, почти всегда означает закрытие периода. Файл лицензии с датой окончания «31.12» — тот же сигнал.
• Прямой вопрос бизнесу до, а не после отключения. Спросить бухгалтерию или финансовый отдел, есть ли системы, которыми пользуются раз в год — самый быстрый способ, но он работает, только если спросить заранее.

Практическое правило: VM с пропуском активности в квартал и более должна быть явно подтверждена как ненужная кем-то из бизнеса, прежде чем её тронут — молчание не считается подтверждением. Нет подтверждения — переводите VM в статус «выключена, задокументирована, не трогается» и возвращайтесь к вопросу позже.

Распределение ресурсов: кто сколько ест и почему это не мелочь

После того как назначение каждой VM прояснилось хотя бы приблизительно, стоит свести общую картину распределения ресурсов физической машины — она часто объясняет застарелые проблемы вроде тормозов на одной из VM без явной причины.

Соберите по каждой VM выделенные vCPU, память и фактическое потребление, сравните с физическими ресурсами хоста:

# Proxmox: сколько всего выделено против того, что реально есть на ноде
qm list | awk '{print $2, $4}'   # имя и объём памяти по каждой VM
free -h                           # реальная память хоста
nproc                             # физические ядра хоста

# libvirt: то же самое по каждому домену
for d in $(virsh list --all --name); do
  echo "== $d =="
  virsh dominfo "$d" | grep -E 'CPU|Memory'
done

Часто выясняется, что сумма выделенной памяти по всем VM превышает физическую память хоста в полтора-два раза — это overcommit, сам по себе не проблема (не все VM используют выделенный максимум одновременно), но именно из-за него гипервизор в момент пиковой нагрузки начинает отбирать память у одних VM в пользу других через баллонинг — подробно об этом механизме и его рисках читайте в статье про ballooning памяти. Если среди унаследованных VM есть чувствительная к задержкам (база данных, торговая система), проверьте её место в схеме overcommit в первую очередь — жалобы вроде «сервер иногда подтормаживает без причины» часто объясняются именно перевыделением ресурсов.

То же касается vCPU: если на четырёхъядерном хосте суммарно выделено двадцать vCPU по всем VM (обычная практика), при одновременной пиковой нагрузке нескольких VM производительность каждой просядет — в логах это выглядит не как явная ошибка, а как необъяснимые скачки времени отклика.

Сеть и хранилища: на что ещё завязана каждая VM

Список VM и их назначение — не полная картина без двух дополнительных срезов: к какой сети подключена каждая VM и где физически лежат её диски.

Сеть. Уточните для каждой VM, к какому мосту (bridge) или VLAN она подключена, и есть ли статический IP или проброс портов с самого гипервизора:

# Proxmox: сетевые интерфейсы VM прямо в конфиге
qm config <vmid> | grep net

# libvirt: IP-адрес запущенной VM (через qemu-guest-agent или ARP)
virsh domifaddr <domain>

# список мостов на хосте
brctl show   # либо: ip link show type bridge

Отдельно проверьте правила проброса портов и firewall на гипервизоре — часто именно там, а не внутри VM, настроен NAT или port forward, который ждёт следующего включения выключенной сейчас машины.

Хранилище. Проверьте, где физически лежит диск каждой VM — на локальном хранилище хоста, на подключённом по сети (NFS, iSCSI, Ceph) или через passthrough конкретного физического устройства:

# Proxmox: список хранилищ и их занятость
pvesm status

# libvirt: путь к диску конкретного домена
virsh domblklist <domain> --details

Это важно по двум причинам. Во-первых, если несколько VM используют одно сетевое хранилище, у них общая точка отказа, о которой не знает ни одна из команд, работающих с этими VM по отдельности. Во-вторых, VM с passthrough физического устройства (USB-токен лицензии, отдельная сетевая карта) нельзя просто перенести на другой хост — такую привязку легко упустить, если смотреть только на CPU и память.

Оформляем результат: таблица инвентаризации виртуалок

Финальный шаг — свести всё собранное в единую таблицу, которую можно передать дальше или использовать как рабочий документ. Формат подойдёт любой (markdown-файл, простая таблица в общем документе), но набор колонок стоит держать одинаковым для всех VM:

Колонка «уверенность» — не формальность, а рабочий инструмент: она отделяет VM, назначение которых доказано (логами, содержимым, подтверждением от бизнеса), от тех, что определены по косвенным признакам. Именно строки с низкой уверенностью и статусом «выключена» — те, где решение об удалении нужно откладывать до прояснения. После того как таблица собрана, стоит зафиксировать хотя бы её минимальную версию в постоянном виде — какой объём документации оставлять после себя, разобрано в статье про минимальную документацию чужой системы.

Частые вопросы