Ошибка «TASK ERROR: QEMU exited with code 1» появляется в Proxmox VE в момент запуска виртуальной машины и означает, что процесс QEMU/KVM завершился аварийно ещё до старта гостевой системы. Само по себе сообщение не содержит причины — это лишь код завершения, а реальную причину нужно искать в журнале задачи чуть выше этой строки или в логе самой ВМ.
Чаще всего сбой связан с недоступностью диска или ISO-образа, нехваткой оперативной памяти, конфликтом настроек EFI/TPM, некорректной конфигурацией qemu-server или проблемами после обновления Proxmox. Ниже разберём, как локализовать причину и устранить её без переустановки гипервизора.
Где искать реальную причину ошибки
Строка «exited with code 1» — это только следствие. Первичная диагностика начинается с журнала задачи в веб-интерфейсе: раскройте упавшую задачу двойным кликом и посмотрите строки непосредственно перед кодом ошибки. Именно там обычно написано, чего не хватило QEMU — файла, прав, устройства или памяти.
Если веб-интерфейс не даёт деталей, подключитесь к узлу по SSH и посмотрите системный журнал:
journalctl -u pve-guests -n 100 --no-pager
cat /var/log/syslog | grep -i qemu
Также полезно проверить конфигурацию конкретной ВМ — она хранится в файле /etc/pve/qemu-server/<VMID>.conf. Ошибка в одном из параметров (несуществующий путь, отключённое хранилище) — типичный источник сбоя.
- 🔍 Откройте журнал задачи и найдите строку перед «QEMU exited with code 1»
- 📄 Проверьте файл конфигурации ВМ на предмет битых путей и параметров
- 💾 Убедитесь, что все задействованные хранилища активны в разделе Datacenter → Storage
- 🧠 Проверьте свободную оперативную память командой
free -h
Недоступный диск или ISO-образ
Самая частая причина — ВМ ссылается на диск или ISO, который физически недоступен. Это происходит после отключения внешнего хранилища, удаления файла вручную, сбоя NFS/CIFS-шары или миграции между узлами. QEMU не может открыть образ и завершается с кодом 1.
Проверьте, существуют ли файлы, указанные в конфиге ВМ. Для локальных хранилищ путь обычно выглядит как /var/lib/vz/images/<VMID>/, для LVM и ZFS — как тома соответствующих пулов. Если хранилище сетевое, убедитесь, что оно смонтировано: df -h покажет актуальное состояние.
Отдельный случай — «забытый» ISO в виртуальном приводе. Если ISO-файл был удалён, а в конфигурации ВМ осталась строка вида ide2: local:iso/имя_файла.iso,media=cdrom, машина не стартует. Решение простое: в настройках оборудования ВМ отключите CD/DVD-привод или выберите Do not use any media.
Нехватка оперативной памяти и hugepages
Если суммарная память, выделенная запускаемым ВМ, превышает физически доступную, QEMU завершится с ошибкой. Это особенно актуально для машин с включённым ballooning, когда фактическое потребление выше ожидаемого, и для конфигураций с hugepages.
Проверьте текущее состояние памяти на узле:
free -h
cat /proc/meminfo | grep -i huge
Если в конфигурации ВМ вручную прописан параметр hugepages, а соответствующие страницы не зарезервированы на хосте, запуск будет падать. Временное решение — убрать параметр из конфига или закомментировать его символом #, затем повторить запуск.
⚠️ Внимание: не уменьшайте память работающим в production ВМ «вслепую». Сначала остановите некритичные машины, освободите ресурсы и только потом перезапускайте проблемную ВМ — иначе можно уронить соседние сервисы из-за OOM.
Проблемы с EFI, TPM и типом машины
Виртуальные машины с UEFI (OVMF) требуют корректного EFI-диска. Если EFI-диск был удалён, повреждён или находится на недоступном хранилище, QEMU не сможет инициализировать прошивку и завершится с кодом 1. Аналогично ведёт себя связка с TPM 2.0 — состояние TPM хранится в отдельном файле, и его отсутствие ломает запуск.
Проверьте в конфигурации ВМ строки вида efidisk0: и tpmstate0:. Убедитесь, что указанные тома существуют. Если EFI-диск утерян безвозвратно, его можно пересоздать: удалите строку efidisk0 из конфига, затем через веб-интерфейс добавьте новый EFI Disk в разделе Hardware → Add. Учтите, что для Windows с уже установленной системой это может потребовать восстановления загрузчика.
Если ВМ не стартует после переноса конфига между узлами, проверьте параметр machine в конфиге. Разные версии QEMU на узлах могут не поддерживать один и тот же тип машины — попробуйте сменить его на просто «pc» (последняя совместимая версия подставится автоматически).
Ошибки после обновления Proxmox
Обновление пакетов pve-qemu-kvm или ядра иногда ломает запуск ВМ: меняются зависимости, версии библиотек, поведение отдельных параметров. Характерный признак — машины работали до обновления и перестали сразу после него.
Что стоит проверить в такой ситуации:
- 🔄 Выполните
apt update && apt full-upgrade, чтобы доустановить все зависимости — частичное обновление нередко оставляет систему в несогласованном состоянии - 📦 Проверьте, нет ли «битых» пакетов:
dpkg --configure -a - 🧪 Попробуйте запустить ВМ вручную через
qm start <VMID>— вывод в терминале часто подробнее, чем в веб-интерфейсе - 📋 Сверьте версии пакетов на всех узлах кластера командой
pveversion -v, если ВМ мигрирует между ними
☑️ Быстрая диагностика QEMU exited with code 1
Ручной запуск и чтение конфигурации
Когда веб-интерфейс показывает только код завершения, запуск из консоли даёт максимум информации. Команда qm start <VMID> выводит ошибки QEMU напрямую в терминал. Ещё подробнее результат даёт генерация полной командной строки QEMU без фактического запуска:
qm showcmd <VMID> --prettyЭта команда показывает, с какими аргументами Proxmox собирается запускать виртуальную машину. Здесь можно увидеть несуществующие пути, конфликтующие устройства и «левые» параметры, попавшие в конфиг при ручном редактировании.
Типичные строки ошибок и их смысл
«Could not open '/путь/к/файлу': No such file or directory» — файл диска или ISO отсутствует. «failed to find romfile» — проблема с BIOS/EFI-прошивкой. «cannot set up guest memory» — нехватка RAM или проблема с hugepages. «Property ... not found» — устаревший или неверный параметр в конфиге ВМ.
Сводная таблица причин и решений
| Симптом из лога | Вероятная причина | Действие |
|---|---|---|
| No such file or directory | Удалён диск или ISO | Восстановить файл или убрать ссылку из конфига |
| Cannot allocate memory | Нехватка RAM на узле | Остановить лишние ВМ, уменьшить выделение памяти |
| Ошибка с efidisk / tpmstate | Утерян EFI/TPM-диск | Пересоздать диск через Hardware → Add |
| Ошибка после apt upgrade | Несогласованные пакеты | apt full-upgrade, dpkg --configure -a |
| Ошибка при миграции между узлами | Разные версии QEMU на узлах | Выровнять версии пакетов, сменить тип machine |
⚠️ Внимание: перед редактированием файла /etc/pve/qemu-server/<VMID>.conf сделайте его копию. Некорректная правка конфига может сделать ВМ невидимой для кластера до исправления синтаксиса.
Если ни одна из типовых причин не подтвердилась, а в логе задачи нет ничего, кроме самого кода завершения, проверьте целостность файловой системы узла и свободное место в корневом разделе — переполненный /var тоже способен блокировать запуск QEMU.
«QEMU exited with code 1» — это не диагноз, а код завершения. Реальная причина всегда находится в строках лога выше: недоступный диск, нехватка памяти, EFI/TPM или последствия обновления.
Часто задаваемые вопросы
Можно ли исправить ошибку без доступа к SSH?
Частично — через веб-интерфейс доступны журнал задачи, отключение ISO, пересоздание EFI-диска и изменение объёма памяти. Но для просмотра syslog, ручного запуска qm start и правки конфигов потребуется консоль: SSH или shell прямо в веб-интерфейсе узла.
Почему ВМ перестала запускаться после перезагрузки сервера?
Возможная причина — сетевое хранилище (NFS/CIFS) не успело смонтироваться к моменту автозапуска ВМ либо не смонтировалось вовсе. Проверьте статус хранилищ и при необходимости увеличьте задержку автозапуска в настройках ВМ (параметр Start/Shutdown order).
Поможет ли переустановка Proxmox?
Крайне редко. Ошибка почти всегда связана с конфигурацией конкретной ВМ или состоянием хранилищ, а не с самим гипервизором. Переустановка оправдана только при подтверждённом повреждении системных пакетов, и даже тогда сначала стоит попробовать apt install --reinstall pve-qemu-kvm.
Ошибка появляется только на одном узле кластера — в чём дело?
Скорее всего, узлы различаются: версии пакетов, набор доступных хранилищ, состояние памяти. Сравните вывод pveversion -v на обоих узлах и убедитесь, что хранилища, используемые ВМ, подключены именно к проблемному узлу.
Где Proxmox хранит логи запуска виртуальных машин?
Основные источники — журнал задачи в веб-интерфейсе, системный журнал (journalctl, /var/log/syslog) и вывод команды qm start <VMID>. Отдельного постоянного лог-файла для каждой ВМ по умолчанию не ведётся, поэтому ручной запуск из терминала — самый информативный способ диагностики.