Ошибка Proxmox I/O error чаще всего появляется в журнале виртуальной машины в момент записи на диск: гостевая система зависает, в консоли видны строки вида blk_update_request: I/O error, dev sda, а сама ВМ переходит в состояние paused или перестаёт отвечать. Первое действие в такой ситуации — проверить состояние физического диска и хранилища на стороне гипервизора, а не перезагружать виртуальную машину вслепую.
Проблема почти никогда не находится внутри гостевой ОС. Ошибка ввода-вывода означает, что QEMU/KVM не смог выполнить операцию чтения или записи на уровне хоста: сбойный сектор на диске, переполненное хранилище, деградировавший пул ZFS или отвалившийся iSCSI-лун. В этой статье разберём, как локализовать источник сбоя, какие команды использовать для диагностики и как вернуть виртуальные машины в работу без потери данных.
Что означает ошибка ввода-вывода в Proxmox
Сообщение I/O error — это общий сигнал ядра о том, что блочное устройство вернуло ошибку при операции чтения или записи. В контексте Proxmox VE цепочка выглядит так: гостевая ОС обращается к виртуальному диску, QEMU транслирует запрос в файл образа (qcow2, raw) или блочное устройство (LVM-thin, ZFS zvol, Ceph RBD), а дальше запрос уходит на физический носитель. Сбой на любом звене этой цепочки вызывает ошибку внутри ВМ.
Типичные симптомы, сопровождающие ошибку:
- 🔴 Виртуальная машина зависает или уходит в статус
pausedбез явной причины; - 📄 В журнале задач появляются сообщения
qemu: block I/O errorилиscsi bus error; - 💽 Внутри гостевой системы файловая система перемонтируется в режим read-only;
- ⏱️ Резервное копирование через Proxmox Backup Server или
vzdumpпрерывается с ошибкой чтения; - 🐌 Резко растёт задержка дисковых операций (iowait) на хосте.
⚠️ Внимание: если гостевая ФС ушла в read-only, не выполняйте принудительный сброс ВМ до выяснения причины. Повторные запуски на сбойном диске могут усугубить повреждение данных. Сначала снимите диагностику на хосте.
Первичная диагностика: журналы и состояние хранилищ
Начните с системного журнала гипервизора. Вам нужно найти, какое именно устройство или пул вернул ошибку. Выполните на хосте:
journalctl -k | grep -iE "i/o error|ata|nvme|scsi"Эта команда покажет сообщения ядра о сбоях блочных устройств. Обратите внимание на имена устройств (sda, nvme0n1) и коды ошибок — они укажут на конкретный физический диск. Дополнительно посмотрите общий журнал: journalctl -xe и лог задач в веб-интерфейсе Proxmox (раздел Datacenter → Tasks).
Далее проверьте состояние хранилищ. Для ZFS используйте zpool status — там видны деградировавшие (DEGRADED) и отказавшие (FAULTED) устройства, а также счётчики ошибок чтения, записи и контрольных сумм. Для локальных хранилищ полезно убедиться, что каталог смонтирован и не переполнен: df -h и pvesm status.
Проверка здоровья дисков через SMART
Если журнал указывает на конкретный диск, проверьте его атрибуты SMART. Утилита smartctl из пакета smartmontools покажет ключевые показатели здоровья носителя:
smartctl -a /dev/sdaОсобое внимание обратите на атрибуты Reallocated Sector Count, Current Pending Sector и Offline Uncorrectable — рост этих значений указывает на физическую деградацию поверхности. Для NVMe-дисков смотрите поля Percentage Used, Media and Data Integrity Errors и температуру. Точную интерпретацию атрибутов лучше сверять с документацией производителя диска, так как нормирование значений различается между вендорами.
Запустить расширенный самотест диска можно командой smartctl -t long /dev/sda, а результат позже посмотреть через smartctl -l selftest /dev/sda. Длительный тест занимает заметное время и выполняется в фоне — на нагруженном продакшен-хосте планируйте его на период минимальной нагрузки.
Типовые причины по типам хранилищ
Источник ошибки сильно зависит от того, какое хранилище использует виртуальная машина. Ниже — сводка типичных сценариев.
| Тип хранилища | Частая причина I/O error | Что проверить |
|---|---|---|
| Локальный каталог (dir) | Переполнение раздела или сбойный диск | df -h, SMART, журнал ядра |
| LVM-thin | Переполнение thin-пула из-за overprovisioning | lvs — столбец Data% |
| ZFS | Деградация vdev, ошибки контрольных сумм | zpool status |
| NFS / iSCSI | Обрыв сети, таймауты, недоступность таргета | Сетевые интерфейсы, dmesg, доступность сервера |
| Ceph (RBD) | Недоступность OSD, нездоровое состояние кластера | ceph -s, состояние OSD |
Отдельно выделим переполнение LVM-thin пула: это одна из самых коварных причин. Пока в thin-пуле есть место, всё работает; как только физическое пространство заканчивается, все ВМ на этом пуле начинают получать ошибки записи одновременно. Контролируйте заполнение через lvs и настройте оповещения.
⚠️ Внимание: при переполнении LVM-thin или ZFS-пула не пытайтесь «просто перезагрузить» хост — это не освободит место. Сначала удалите ненужные снапшоты, переместите диски ВМ на другое хранилище или расширьте пул.
Восстановление виртуальных машин после сбоя
Когда причина на хосте устранена (диск заменён, пул восстановлен, место освобождено), виртуальные машины нужно аккуратно вернуть в работу. Порядок действий зависит от того, успела ли повредиться файловая система гостя.
☑️ Порядок восстановления ВМ после I/O error
Для образов qcow2 перед запуском полезно выполнить проверку целостности:
qemu-img check /var/lib/vz/images/100/vm-100-disk-0.qcow2Внутри гостевой Linux-системы, которая ушла в read-only, после перезапуска выполните fsck для повреждённого раздела (раздел должен быть отмонтирован). Для Windows-гостей используйте chkdsk. Если гостевая ФС повреждена серьёзно и восстановление не помогает, самый надёжный путь — развернуть ВМ из последней рабочей резервной копии.
Профилактика: как не допустить повторения
Большинство случаев Proxmox I/O error предотвращаются базовым мониторингом. Необходимо отслеживать три вещи: здоровье дисков через SMART, заполнение хранилищ и состояние пулов ZFS или Ceph. Для этого подойдут как встроенные средства (регулярный zpool scrub, оповещения smartd), так и внешние системы мониторинга, если они есть в вашей инфраструктуре.
Также критично наличие актуальных резервных копий. Регулярные бэкапы через vzdump или Proxmox Backup Server превращают отказ диска из катастрофы в плановую процедуру восстановления. Периодически проверяйте, что копии действительно восстанавливаются, — бэкап без проверки восстановления нельзя считать надёжным.
Почему ZFS сообщает об ошибках, которые SMART не видит
ZFS хранит контрольные суммы всех блоков и обнаруживает «тихие» повреждения данных (bit rot), которые диск считает успешно прочитанными. Поэтому рост счётчиков CKSUM в zpool status — серьёзный сигнал даже при «здоровом» SMART. Регулярный scrub позволяет находить и исправлять такие повреждения за счёт избыточности (mirror, raidz).
Часто задаваемые вопросы
Можно ли просто перезагрузить ВМ при I/O error?
Перезагрузка не устраняет причину: если сбой на стороне хоста (диск, пул, сеть), ошибка вернётся сразу или через короткое время. Сначала выполните диагностику на гипервизоре, устраните источник и только потом запускайте ВМ с проверкой файловой системы.
ВМ перешла в статус paused — что это значит?
QEMU приостанавливает виртуальную машину, когда не может выполнить дисковую операцию, например при переполнении хранилища или потере доступа к сетевому диску. Это защитный механизм: после устранения причины ВМ можно продолжить без потери состояния.
Ошибки CKSUM в zpool status — это опасно?
Ошибки контрольных сумм означают, что ZFS обнаружила повреждённые данные. Если пул избыточный (mirror, raidz), данные обычно автоматически исправляются с исправной копии. Растущие счётчики CKSUM на конкретном устройстве — повод проверить этот диск и запланировать его замену.
Как проверить, не переполнен ли LVM-thin пул?
Выполните lvs на хосте и посмотрите столбец Data% для thin-пула (обычно называется data в группе pve). Значения, близкие к полному заполнению, требуют немедленных действий: удаления снапшотов, переноса дисков ВМ или расширения пула.
Гостевая система ушла в read-only — данные потеряны?
Не обязательно. Перевод ФС в read-only — защитная реакция ядра гостевой ОС на ошибки записи. После устранения причины на хосте и проверки fsck система часто полностью восстанавливается. Однако файлы, которые записывались в момент сбоя, могут быть повреждены — проверьте их целостность.