Короткий ответ

Когда thin pool pve/data (storage local-lvm на pve1) заполнен, qemu перестаёт писать: гости stall, снимки и backup падают. Смотрите два процента: Data% и Meta%. Лечение — расширить пул (lvextend) или удалить ненужные тома (старые образы, не чужие VM). Не lvremove /dev/pve/vm-101-disk-0 как способ «освободить место».

Авторасширение (thin_pool_autoextend) должно сработать до 100%. Если уже 100% — ручное расширение с свободного PV.

Симптомы и как отличить

Типичная картина:

  • несколько VM на local-lvm одновременно «замерли»;
  • lvs показывает data Data% ≈ 100;
  • в dmesg: Thin pool ... out of data space или metadata;
  • GUI ещё рисует диски, Start новых VM падает.

Отличия:

Что видноНе пул хостаКуда смотреть
Одна VM, df 100% внутригостевая ФСДиск VM заполнен
pvesm inactive, lvs живактивацияХранилище
ZFS, не LVMпул rpoolZFS degraded
Высокий wait при Data% 50%диск/SANIO wait

Возможные причины

  1. Выросли гости, снимки, неудалённые vm-xxx-disk.
  2. Metadata LV маленький: Data% ещё 70, Meta% 100 — тоже стоп.
  3. fstrim из гостей не доходит, discarded блоки не вернулись.
  4. Backup snapshot на thin не удалился.
  5. Нет autoextend: закончился свободный экстент в VG pve.
  6. Утечка: каждый день полный vzdump на тот же local-lvm.

Диагностика

pveversion
pvesm status
lvs -a -o lv_name,lv_size,data_percent,metadata_percent,pool_lv,segtype,vg_name
vgs -o vg_name,vg_size,vg_free
pvs

Ищите LV data типа thin-pool в VG pve. Список потребителей:

lvs -a pve | grep -E 'vm-|data'
pvesm list local-lvm

Журнал:

dmesg | grep -iE 'thin|dm-thin|ENOSPC' | tail
journalctl -k -b | grep -i thin | tail

Решение

Сценарий A. Есть свободное место в VG

Расширьте data-пул (имена сверьте своим lvs; классика установщика PVE — pve/data):

vgdisplay pve
lvextend -L +50G pve/data
lvs -a pve/data

Для metadata, если Meta% критичен, используйте документированный lvextend --poolmetadatasize на тот же thin pool, не создавая «второй» metadata вручную наугад.

После расширения IO гостей часто отмирает сам. Проверьте qm status 101.

Сценарий B. VG полный, расширять некуда

Добавьте PV (новый диск в VG) без потери существующих PV, затем lvextend. Либо удалите мусор: неиспользуемые ISO на local, старые unused volumes в pvesm list, шаблоны. Unused в GUI — всё равно сверьте, что нет scsi0 в чужом конфиге.

Сценарий C. Снимки и leftover thin

Удалите ненужные snapshot VM штатно (qm delsnapshot), не lvremove. См. snapshot не удаляется.

Сценарий D. Гости не делают discard

Включите discard=on на scsi и fstrim в госте (или weekly timer), чтобы блоки возвращались в пул. Это профилактика и постепенное освобождение, не мгновенные 100→10%.

Сценарий E. Metadata 100%

Приоритетнее Data%. Без метаданных thin не мапит блоки. Расширяйте metadata, затем разберите, почему autoextend не сработал (dmeventd, lvm.conf).

Почему autoextend молчит и как не спутать с заполнением гостя

dmeventd должен видеть thin pool. Если служба не запущена, thin_pool_autoextend_threshold в lvm.conf не сработает, и вы узнаете о проблеме на 100%.

systemctl status lvm2-monitor dmeventd --no-pager
grep -E 'thin_pool_autoextend|monitoring' /etc/lvm/lvm.conf | grep -v '^[[:space:]]*#'
lvs -o+seg_monitor pve/data

Свободное в VG = 0 ГБ означает: autoextend некуда расти, даже если мониторинг жив. Тогда только новый PV или удаление ненужных LV.

Не путайте df внутри 101 с Data% пула. Гость может быть на 20% при пуле 99%, если другие VM и снимки съели блоки. И наоборот: гость 100%, пул 40% — это диск VM, lvextend pve/data гостю не поможет.

Удаление ISO с local не освобождает thin. fstrim в госте с discard=on — да, постепенно. Массовый trim всех VM сразу создаст IO wait; делайте по одной.

Как проверить, что проблема устранена

lvs -a -o lv_name,data_percent,metadata_percent,lv_size pve
vgs
pvesm status
qm status 101
dmesg | tail

Data% и Meta% с запасом (цель не «едва ниже 100», а рабочий порог < 80%). VM пишут на диск, journal гостя без ENOSPC. Тестовый маленький snapshot на некритичной VM создаётся и удаляется. vgs VG Free не ноль, если рассчитываете на autoextend.

Если не помогло

  • После lvextend гости всё ещё pause: сбросьте IO, иногда нужен qm stop/start конкретной VM, если qemu получил фатальный ENOSPC — см. зависшая VM.
  • Meta% сразу снова 100: слишком много мелких снимков.
  • Пул на iSCSI: сначала LUN, потом LVM.
  • Скрипты thin_check/thin_repair — только по документации LVM на остановленных гостях, не первый шаг.
  • GUI показывает другое % чем lvs: верьте lvs.

Профилактика

  • Алерт Data% > 75–80 и Meta% > 60.
  • Не складывать vzdump на тот же local-lvm, что и диски.
  • Регулярный fstrim гостей virtio-scsi.
  • Не держать вечные снимки «на всякий случай».
  • Запас в VG специально под autoextend.

FAQ

Почему сумма дисков VM больше размера пула — это уже авария?

Нет, это overcommit. Авария — фактические выделенные блоки.

Можно ли сжать диск VM, чтобы освободить пул?

Только после уменьшения ФС в госте и безопасного shrink. Иначе порча. Проще удалить ненужные тома/снимки или расширить пул.

lvextend pve/data затрагивает VM 101?

Расширяет пул, не раздел гостя. Гость свой df не увидит больше, пока не resize scsi0.

Нужно ли останавливать все VM перед lvextend пула?

Обычно нет. Это операция VG/LV пула. Окно всё равно желательно на загруженном I/O.

Чем local отличается от local-lvm здесь?

local — файлы на корне (ISO, контейнеры иногда). Заполнение local-lvm не лечится apt clean на корне, если VG отдельный.