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

Цель — остановить процесс qemu VM 101, сохранив том на local-lvm/rpool. Порядок: ACPI (qm shutdown) → qm stop с таймаутом → только потом точечный kill этого kvm, никогда qm destroy. Destroy удаляет конфиг и диски. Зависание часто маскирует полный thin pool, застрявший snapshot merge или backup.

Не режьте питание всего pve1, пока не убедитесь, что висит один гость, а не HBA.

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

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

  • в консоли VNC курсор есть, гость не отдаёт ACPI;
  • qm status 101 долго running, Shutdown task timeout;
  • qm guest cmd 101 ping не отвечает;
  • на хосте iowait, dstate у kvm.

Отличия:

Что видноСкорее не «завис qemu»Куда смотреть
Не стартует после Stoplock/storageVM не запускается
Гость жив, но тормозитsteal/диск/сетьVM работает медленно
Все VM на пуле stallthin/ZFS/NFSВысокий IO wait
Stop ждёт snapshotmergeSnapshot не удаляется

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

  1. Гость игнорирует ACPI (залипший kernel, BSOD без auto reboot).
  2. qemu-guest-agent завис, GUI Shutdown шлёт агенту, не ACPI.
  3. Диск гостя не отвечает: thin 100%, NFS stale, iSCSI session drop.
  4. Застрявший backup snapshot/fleecing, lock.
  5. Мёртвый vCPU в D-state из-за HBA.
  6. Редко: баг после live-migration, процесс kvm без рабочего monitor.

Диагностика

pveversion
qm status 101 --verbose
qm config 101
ps -o pid,stat,wchan,cmd -C kvm | grep 101
pvesm status
lvs -a
zpool status rpool

Колонка STAT = D — ждёт диск, kill бесполезен, пока не оживёт storage. Сначала хранилище и IO wait.

qm agent 101 ping
timeout 5 qm guest cmd 101 ping
ls -l /var/lock/qemu-server/lock-101.conf

Агент мёртв — Shutdown через agent не сработает, нужен ACPI или stop.

Решение

Сценарий A. Гость глухой, диск живой

Попробуйте ACPI явно (не через зависший агент):

qm shutdown 101 --timeout 120 --forceStop 0

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

qm stop 101 --timeout 60
qm status 101

qm stop в PVE шлёт SIGTERM qemu, затем SIGKILL по таймауту. Дождитесь конца задачи. Сразу второй Stop не спасает, создаёт lock.

Сценарий B. Stop висит, kvm в D-state

Не kill -9 этот pid: D-state не обрабатывает сигналы. Верните IO (NFS session, iSCSI, thin space). Когда STAT станет S/R, qm stop завершится. Параллельно не запускайте vzdump на этом томе.

Сценарий C. Нужен жёсткий kill конкретного qemu

Только если STAT не D, storage online, qm stop не убивает процесс:

# pid только этой VM, проверьте cmdline на ',101,' и id 101
ps aux | grep -E '[k]vm.*101'

Затем штатный путь всё ещё qm stop. Если задача PVE умерла, а kvm жив — qm stop 101 ещё раз. Ручной kill последнего куска — крайняя мера, после неё qm status и qemu-img info на томе до нового start.

Сценарий D. Зависший backup держит VM

Дождитесь или корректно отмените задачу vzdump в GUI (не kill -9 vzdump). См. backup vzdump. После снятия lock:

qm unlock 101
qm status 101

Сценарий E. Reset вместо выключения

Если политика позволяет потерять несохранённое в госте, но диск писать можно:

qm reset 101

Reset не замена stop при мёртвом storage: получите ту же D-state.

Журнал qemu и отличие pause от hang

Зависшая VM 101 может быть в paused из-за backup/migrate/watchdog, а не в «глухом» qemu. Это видно в qm status 101 --verbose и в QMP. Pause с консистентным диском безопаснее kill: дождитесь конца задачи. Hang с D-state — другой класс.

qm status 101 --verbose
grep -E 'pause|watchdog|io-error' /var/log/syslog | tail
ls -l /var/run/qemu-server/101.pid /run/qemu-server/101.pid 2>/dev/null

PID-файл нужен, чтобы не убить чужой kvm. Сравните PID с ps. Если pid-файла нет, а процесс есть — задача PVE уже разъехалась с qemu, qm stop всё равно предпочтительнее ручного kill. После аварийного stop в госте ожидайте journal replay; для Windows — chkdsk не запускайте «на всякий случай», если ФС чистая.

Не используйте echo b > /proc/sysrq-trigger на хосте ради одной VM. Это reset всего pve1 и риск для остальных гостей на local-lvm и rpool.

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

qm status 101
ls /var/lock/qemu-server/lock-101.conf 2>/dev/null || echo 'no lock'
pvesm status

Либо stopped без lock, либо после намеренного start — running и агент/пинг гостя. lvs/zfs list для vm-101-disk-0 без ошибки. Хостовый iowait упал, если виноват был этот kvm. Повторный чистый qm stop/qm start на pve1 проходит за нормальное время.

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

  • После stop диск не открывается: qemu-img check на копии, не на единственном томе.
  • VM сразу снова freeze: диск заполнен внутри гостя или thin.
  • Зависает только с SPICE/USB passthrough: уберите usb0/hostpci для теста.
  • Узел целиком stall: это уже хост, не VM; смотрите rpool и HBA.
  • HA пытается поднять 101 на втором узле при живом qemu на первом — риск split: остановите HA на время ремонта.

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

  • qemu-guest-agent в госте и watchdog там, где уместно.
  • Мониторинг D-state kvm и iowait.
  • Не копить десятки снимков на 101.
  • Thin pool autoextend и алерт до 80%.
  • Shutdown через ACPI с запасом timeout в HA, не мгновенный kill всех VM при drain.

FAQ

Чем shutdown отличается от stop?

shutdown просит ОС. stop выдёргивает qemu (как питание). Для зависшего ядра stop уместен; для живой БД — сначала попытаться ACPI.

Можно ли выключить VM рубильником на PDU хоста?

Только если висит весь pve1 и это согласованный hard reset узла. Для одной VM — нет.

Почему qm stop пишет timeout, а kvm жив?

Обычно IO. Смотрите wchan процесса. Пока D-state, таймаут будет снова.

Нужно ли sync на хосте перед kill qemu?

Хостовый sync не сбросит кэш гостя. Важнее живой backend диска. После аварийного stop в госте будет journal replay — это нормально.

Уничтожит ли qm stop --skiplock диск?

Скип lock не удаляет том, но игнорирует защиту от параллельной операции. Используйте, только если видите застрявший lock и нет второго qemu на этот VMID.