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

Снимок PVE на pve1 — не файл «на удаление руками». qm delsnapshot 101 <name> запускает merge/commit цепочки. Если задача висит: lock, IO, живой vzdump, недостаточно места для merge. Не lvremove и не rm *.qcow2 с хоста — отрежете текущий диск running VM.

Сначала qm listsnapshot 101, lock, кто держит qemu.

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

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

  • GUI Snapshot: delete 99% часами;
  • в конфиге 101.conf секции [snap...] после ошибки;
  • backup оставил внутренний снимок;
  • Data% thin не уменьшился.

Отличия:

Что видноКуда
VM не выключаетсяЗависшая VM
Backup падает на snapshotvzdump
Нет места mergeLVM-thin
После кривого rm VM не стартуетСтарт VM

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

  1. Lock от другой задачи.
  2. Merge не хватает места (qcow/LVM).
  3. VM в D-state, qemu не коммитит.
  4. Имя снимка в GUI не совпадает (опечатка, leftover).
  5. Снимок vzdump не тот, что user snapshot.
  6. Редко: оборванный qemu-img commit.

Диагностика

pveversion
qm status 101
qm listsnapshot 101
qm config 101
ls -l /var/lock/qemu-server/lock-101.conf
pvesm status
lvs -a | grep 101

Для qcow directory:

# путь из pvesm path / конфига, не выдумывайте
pvesm path local:101/vm-101-disk-0.qcow2

Журнал задачи Delete snapshot в GUI. IO:

iostat -x 1 3
ps aux | grep -E 'qemu-img|vzdump|101' | grep -v grep

Решение

Сценарий A. Lock, задачи нет

qm unlock 101
qm delsnapshot 101 <snapname>

Имя из listsnapshot. Дождитесь Task OK.

Сценарий B. Delete идёт, просто долго

Merge читает/пишет весь диск. Смотрите IO, не запускайте второй delete. Не stop VM посреди commit без нужды — риск полуслитой цепочки. Если нужно остановить — дождитесь конца или чините IO.

Сценарий C. Нет места

Расширьте thin/directory, повторите delete. Для qcow commit может временно требовать место.

Сценарий D. Снимок есть в GUI, тома нет

Не invent lvcreate. Сверьте 101.conf секции snapshot. Иногда достаточно убрать stale секцию после backup конфига и когда тома реально нет — это уже ручная правка, только если понимаете формат. Предпочтительнее support/копия конфига до правки.

Сценарий E. Нужен откат к снимку, а не удаление

qm rollback 101 <snapname> — это не delete. Rollback на running требует остановки. Не путайте кнопки.

Цепочка дисков и почему Data% не падает

На LVM-thin delete snapshot — это merge/discard в пуле. Data% может не снизиться без TRIM. На qcow — qemu-img info покажет backing file; после успешного delsnapshot backing у живого диска должен исчезнуть.

qm config 101
qm listsnapshot 101
# для qcow, путь из storage:
qemu-img info --backing-chain /var/lib/vz/images/101/*.qcow2 2>/dev/null | head

Если qemu-img info на запущенной VM — только чтение info, не check/commit. qemu-img commit вручную параллельно PVE — путь к порче.

Снимок с RAM (vmstate) держит файл состояния; delete тяжелее и дольше. Для «на всякий случай перед патчем гостя» хватает disk-only.

Не делайте snapshot на local-lvm при Data% 95%: создание и последующий delete оба требуют запас. Сначала место, потом снимок.

Если delete упал, в 101.conf могла остаться секция [mysnap]. Не вырезайте её редактором, пока lvs показывает snap LV: рассинхрон cfg и backend хуже, чем «лишняя строка».

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

qm listsnapshot 101
qm status 101
lvs -a | grep 101

Снимка нет в списке. VM running или штатно stopped. Гость пишет на диск (тест файл). Lock нет. Thin Data% мог остаться высоким — блоки не всегда возвращаются без discard.

Пока delete идёт, qm status 101 может показывать running — это нормально для online commit. Не Start/Stop/Migrate в это время. В Task log смотрите block-commit/job ready. Если задача stopped с ошибкой block node is in use, ищите второй qemu-img или leftover backup. lsof на qcow/LV подтвердит, кто держит файл, без rm.

Снимки на шаблонах, из которых клонируют, не удаляйте «для места», пока клоны ссылаются на цепочку: сначала unlink/full clone политика, потом delete.

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

  • Rollback вместо delete нажали — живёте на старом состоянии; backup свежих данных нужен извне.
  • Цепочка qcow из внешних qemu-img snapshot — PVE GUI может не видеть; работайте осознанно с остановленной VM.
  • HA дёргает VM во время merge — отключите HA на время.
  • После delete VM не грузится — не продолжайте delete других snap; restore.
  • ZFS: zfs list -t snapshot vs GUI — удаление только через PVE, чтобы cfg совпал.

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

  • Короткая жизнь снимков (часы/дни), не месяцы.
  • Не снимок вместо backup.
  • Не копить 10 snap на SQL.
  • Алерт на застрявшие задачи snapshot.
  • Место в пуле с запасом под merge.
  • Перед патчем гостя — vzdump/PBS, снимок только на короткое окно и сразу delete после проверки.
  • Не запускать migrate/vzdump параллельно с qm delsnapshot на том же VMID 101.

FAQ

Можно ли удалить снимок на running VM?

Часто да (commit в фоне). Зависит от storage. Если GUI требует stop — не обходите rm.

Чем snapshot PVE отличается от vzdump snapshot?

User snapshot живёт в конфиге VM. vzdump создаёт временный для копирования. leftover после failed backup — частая причина «лишнего» snap.

qm delsnapshot --force?

Только если понимаете, что форс пропускает проверки. Не первая опция.

RAM snapshot включён — delete тяжелее?

Да, состояние памяти. Для длинных тестов лучше диск-only, если политика позволяет.

Нужно ли выключать guest agent?

Нет для delete. Agent нужнее для freeze при создании.

Можно ли удалить снимок через ZFS/zfs destroy, если GUI врёт?

Нет как первый шаг. Сначала qm delsnapshot, чтобы /etc/pve/qemu-server/101.conf совпал с backend. Голый zfs destroy оставляет секцию снимка в конфиге и ломает Start.