Как спасти зависшую QEMU-виртуалку из-за нехватки памяти (4 ГБ) без потери данных

Как спасти зависшую QEMU-виртуалку из-за нехватки памяти (4 ГБ) без потери данных

Выделили виртуальной машине всего 4 ГБ оперативной памяти, она зависла, SSH перестал принимать новые подключения, а существующие сессии висят. При этом на хосте работа ещё выполняется, и терять её категорически не хочется. Разбираем реальный случай и полное решение.

Симптомы проблемы

На хосте в top видно примерно такую картину:

top - 13:07:51 up 1 day, 17:08, 20 users,  load average: 2.67, 2.68, 2.09
Tasks: 481 total,   2 running, 478 sleeping,   0 stopped,   1 zombie
%Cpu(s): 12.5 us,  2.1 sy,  0.1 ni, 74.0 id,  0.1 wa,  0.3 hi,  0.0 si,  0.0 st 
MiB Mem :  31516.1 total,   1330.1 free,  19451.1 used,  11517.2 buff/cache     
MiB Swap:  37660.0 total,  37659.2 free,      0.8 used.  12065.0 avail Mem 

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
   7462 root      21   0 9779840   4.1g  31892 R 225.9  13.4      8,33 qemu-system-x86

Процесс qemu-system-x86 жрёт CPU под 200 %+ и держит ровно выделенные 4.1 ГБ. Хост при этом имеет свободную память, значит проблема внутри гостя.

Виртуальная машина была запущена прямой командой (не через libvirt):

sudo qemu-system-x86_64 \
    -enable-kvm \
    -m 4096 -smp 2 \
    -machine pc-q35-7.2 \
    -cpu host \
    -drive file=/var/lib/libvirt/images/debian13.qcow2,if=virtio,format=qcow2 \
    -boot order=c \
    -netdev bridge,br=virbr0,id=net0 \
    -device virtio-net-pci,netdev=net0,mac=52:54:00:12:34:56 \
    -vga qxl \
    -device virtio-tablet \
    -spice port=5930,disable-ticketing=on \
    -device intel-hda -device hda-duplex \
    -monitor stdio

Ключевые моменты:

• Монитор выведен в stdio (тот же терминал, откуда запускали).
• Новые SSH-подключения не принимаются, старые зависают.
• Диск — qcow2, значит можно делать внутренние снимки.

Решение: сохраняем состояние через QEMU Monitor

Самое важное — не убивать процесс qemu-system-x86. Пока он жив, состояние гостя ещё можно сохранить.

Шаг 1. Попадаем в монитор QEMU

Найдите терминал, из которого запускали виртуалку. Нажмите Enter. Должно появиться приглашение:

QEMU 7.2.18 monitor - type 'help' for more information
(qemu)

Если видите (qemu) — вы уже внутри. Команда help выдаст полный список доступных команд (stop, savevm, cont, info snapshots и т.д.).

Шаг 2. Останавливаем эмуляцию

stop

Проверяем статус:

info status

Ожидаемый ответ: VM status: paused

Теперь CPU гостя полностью заморожен, ничего не теряется.

Шаг 3. Создаём снимок состояния

savevm work_20250927

Имя снимка может быть любым. Команда может выполняться от нескольких секунд до минуты (зависит от объёма занятой памяти). Дождитесь возврата приглашения (qemu).

Проверяем, что снимок создался:

info snapshots

Должна появиться запись с вашим тегом (work_20250927).

Шаг 4. Корректно выходим и запускаем заново с большим объёмом памяти

quit

Теперь запускаем машину уже с 8 ГБ (или больше) и сразу загружаем сохранённый снимок:

sudo qemu-system-x86_64 \
    -enable-kvm \
    -m 8192 -smp 2 \
    -machine pc-q35-7.2 \
    -cpu host \
    -drive file=/var/lib/libvirt/images/debian13.qcow2,if=virtio,format=qcow2 \
    -boot order=c \
    -netdev bridge,br=virbr0,id=net0 \
    -device virtio-net-pci,netdev=net0,mac=52:54:00:12:34:56 \
    -vga qxl \
    -device virtio-tablet \
    -spice port=5930,disable-ticketing=on \
    -device intel-hda -device hda-duplex \
    -monitor stdio \
    -loadvm work_20250927

Виртуальная машина поднимется ровно в том состоянии, в котором вы её сохранили, но уже с достаточным количеством оперативной памяти.

Что делать, если терминал с монитором тоже завис

1. Мягко приостановить процесс: ``bash sudo kill -STOP 7462 ``
2. Сделать резервную копию диска: ``bash sudo cp /var/lib/libvirt/images/debian13.qcow2 /var/lib/libvirt/images/debian13.qcow2.bak ``
3. При необходимости снять core-dump: ``bash sudo gcore -o /tmp/qemu-save 7462 ``

После этого процесс можно завершать (kill -9), но данные, которые были только в оперативной памяти гостя, уже не вернуть. Поэтому приоритет всегда за работой через монитор и savevm.

Как запускать QEMU правильно в будущем

Чтобы больше не ловить такие ситуации, сразу давайте больше памяти и выводите монитор в удобное место:

sudo qemu-system-x86_64 \
    -enable-kvm \
    -m 8192 -smp 4 \
    -machine pc-q35-7.2 \
    -cpu host \
    -drive file=/var/lib/libvirt/images/debian13.qcow2,if=virtio,format=qcow2 \
    -boot order=c \
    -netdev bridge,br=virbr0,id=net0 \
    -device virtio-net-pci,netdev=net0,mac=52:54:00:12:34:56 \
    -vga qxl \
    -device virtio-tablet \
    -spice port=5930,disable-ticketing=on \
    -device intel-hda -device hda-duplex \
    -monitor telnet:127.0.0.1:4444,server,nowait \
    -serial mon:stdio

Теперь в любой момент можно подключиться к монитору:

telnet 127.0.0.1 4444

и выполнить stop → savevm → cont без необходимости искать исходный терминал.

Полезные команды монитора QEMU (шпаргалка)

Выводы

Главная ошибка — слишком маленький объём RAM при запуске (-m 4096). Когда гость начинает активно использовать память, он уходит в тяжёлый thrashing и «замирает» с точки зрения сети и интерактивности.

Самый надёжный способ спасти работу:

1. Попасть в QEMU Monitor (-monitor stdio или telnet).
2. Выполнить stop.
3. Сделать savevm.
4. Перезапустить машину с увеличенным -m и параметром -loadvm.

Этот подход работает именно потому, что диск в формате qcow2 и поддерживает внутренние снимки. Используйте его каждый раз, когда виртуальная машина начинает вести себя странно из-за нехватки ресурсов.