Я смог воспроизвести эту проблему, и это не связано с аппаратным обеспечением. pve-manager/4.4-13/7ea56165 (работает на ядре: 4.4.44-1-pve) с виртуальными машинами CentOS 6 и 7, использующими драйвер диска virtio, изображениями qcow2 на NFS (мне удалось стабильного воспроизведения на трех разных NFS-серверах). Все было нормально, затем вы делаете снимок, проверяете образ диска с помощью 'qemu-img check' и обнаруживаете множество утечек кластеров и сотни (иногда тысячи) повреждений. Операционная система виртуальной машины считает, что диск поврежден, и проблемы начинают нарастать. Если повезёт, ОС переводит свои тома в режим только для чтения. Попытка откатить изменения к снимку завершается неудачей из-за повреждения. Это не происходит, когда мы используем локальное хранилище (lvm-thin), только NFS и .qcow2. Это поведение началось с Proxmox 4 - с 3.x мы всегда могли делать и восстанавливать снимки, когда это требовалось. Сегодня я создал новую большую виртуальную машину CentOS 7 (диск на 500 Гб) с использованием SCSI-драйвера (по умолчанию), изображения .qcow2 на NFS, и пока не смог повредить изображение .qcow2, делая снимки, так что, возможно, дело в использовании virtio.

Обновлено: pve-manager/4.4-13/7ea56165 (работающий kernel: 4.4.49-1-pve) Никакой разницы это не дало: ВМ 1, CentOS 7, virtio, диск 500 ГБ qcow2, повреждается на 100% каждый раз, когда я пытаюсь сделать снимок. Примеры результатов проверки qemu-img ниже. ВМ 2, CentOS 7, virtio, диск 500 ГБ qcow2, не повреждается. Я могу делать несколько снимков, откатываться и т.д., без повреждений или утечек, обнаруженных qemu-img check. Действие, которое вызывает проблему с повреждением, — это создание снимка. Если оставить в покое, я не вижу никаких повреждений в нормальной работе. Теперь, когда я понимаю, что могу делать снимки, если перемещу образ диска на lvm-thin или если создам ВМ с SCSI-диском, я могу обойти это, но это неприятный баг, если ты этого не ожидаешь. Я не уверен, когда это начало происходить, так как мы не часто делаем снимки, но этого не происходило в Proxmox 3.x, и сейчас происходит с 4.4. Я еще не знаю, имеет ли значение ОС ВМ (у нас была проблема с ВМ на CentOS 6 и 7, но это мог быть ошибка выборки, так как большинство ВМ, с которыми мы работали, использовали CentOS 6 или 7). Я проведу несколько тестов с ВМ на Ubuntu, когда появится минутка. Вот повреждения, которые произошли после создания снимка с ВМ на CentOS 7 virtio qcow2: Конечный смещение изображения: 537288376320 ОШИБКА кластер 7988422 refcount=1 reference=2 ОШИБКА кластер 7996583 refcount=1 reference=2 ОШИБКА кластер 7996616 refcount=1 reference=2 ОШИБКА кластер 7996653 refcount=1 reference=2 ОШИБКА кластер 7998877 refcount=1 reference=2 ОШИБКА кластер 8000268 refcount=1 reference=2 ОШИБКА кластер 8000269 refcount=1 reference=2 ОШИБКА кластер 8001931 refcount=1 reference=2 ОШИБКА кластер 8001990 refcount=1 reference=2 ОШИБКА кластер 8021195 refcount=1 reference=2 ОШИБКА кластер 8029356 refcount=1 reference=2 ОШИБКА кластер 8029357 refcount=1 reference=2 ОШИБКА кластер 8029358 refcount=1 reference=2 ОШИБКА кластер 8029359 refcount=1 reference=2 ОШИБКА кластер 8029362 refcount=1 reference=2 ОШИБКА кластер 8029878 refcount=1 reference=2 ОШИБКА кластер 8032113 refcount=1 reference=2 ОШИБКА кластер 8032137 refcount=1 reference=2 ОШИБКА кластер 8032141 refcount=1 reference=2 ОШИБКА кластер 8032147 refcount=1 reference=2 ОШИБКА кластер 8032151 refcount=1 reference=2 ОШИБКА кластер 8033532 refcount=1 reference=2 ОШИБКА кластер 8033759 refcount=1 reference=2 ОШИБКА кластер 8034310 refcount=1 reference=2 ОШИБКА кластер 8034311 refcount=1 reference=2 ОШИБКА кластер 8034312 refcount=1 reference=2 ОШИБКА кластер 8034313 refcount=1 reference=2 ОШИБКА кластер 8034459 refcount=1 reference=2 ОШИБКА кластер 8034460 refcount=1 reference=2 ОШИБКА OFLAG_COPIED L2 кластер: l1_index=975 l1_entry=79e4c60000 refcount=1 ОШИБКА OFLAG_COPIED кластер данных: l2_entry=7a04a70000 refcount=1 ОШИБКА OFLAG_COPIED L2 кластер: l1_index=976 l1_entry=7a04c80000 refcount=1 ОШИБКА OFLAG_COPIED кластер данных: l2_entry=7a04ed0000 refcount=1 ОШИБКА OFLAG_COPIED кластер данных: l2_entry=7a0d9d0000 refcount=1 ОШИБКА OFLAG_COPIED кластер данных: l2_entry=7a130c0000 refcount=1 ОШИБКА OFLAG_COPIED кластер данных: l2_entry=7a130d0000 refcount=1 ОШИБКА OFLAG_COPIED кластер данных: l2_entry=7a198b0000 refcount=1 ОШИБКА OFLAG_COPIED кластер данных: l2_entry=7a19c60000 refcount=1 ОШИБКА OFLAG_COPIED L2 кластер: l1_index=979 l1_entry=7a64cb0000 refcount=1 ОШИБКА OFLAG_COPIED кластер данных: l2_entry=7a84ac0000 refcount=1 ОШИБКА OFLAG_COPIED кластер данных: l2_entry=7a84ad0000 refcount=1 ОШИБКА OFLAG_COPIED кластер данных: l2_entry=7a84ae0000 refcount=1 ОШИБКА OFLAG_COPIED кластер данных: l2_entry=7a84af0000 refcount=1 ОШИБКА OFLAG_COPIED кластер данных: l2_entry=7a84b20000 refcount=1 ОШИБКА OFLAG_COPIED L2 кластер: l1_index=981 l1_entry=7aa4ce0000 refcount=1 ОШИБКА OFLAG_COPIED кластер данных: l2_entry=7aa4f30000 refcount=1 ОШИБКА OFLAG_COPIED кластер данных: l2_entry=7aa4f40000 refcount=1 ОШИБКА OFLAG_COPIED кластер данных: l2_entry=7aa4f50000 refcount=1 ОШИБКА OFLAG_COPIED кластер данных: l2_entry=7aa4f60000 refcount=1 ОШИБКА OFLAG_COPIED кластер данных: l2_entry=7aa4f70000 refcount=1 ОШИБКА OFLAG_COPIED кластер данных: l2_entry=7aa4f80000 refcount=1 ОШИБКА OFLAG_COPIED L2 кластер: l1_index=1007 l1_entry=7de4ee0000 refcount=1 ОШИБКА OFLAG_COPIED кластер данных: l2_entry=7e04cf0000 refcount=1 ОШИБКА OFLAG_COPIED L2 кластер: l1_index=1008 l1_entry=7e04f00000 refcount=1 ОШИБКА OFLAG_COPIED кластер данных: l2_entry=7e05120000 refcount=1 ОШИБКА OFLAG_COPIED кластер данных: l2_entry=7e05190000 refcount=1 ОШИБКА OFLAG_COPIED кластер данных: l2_entry=7e05330000 refcount=1 ОШИБКА OFLAG_COPIED кластер данных: l2_entry=7e07940000 refcount=1 Найдено 66 ошибок на изображении. Данные могут быть повреждены, или дальнейшие записи на изображение могут его испортить. 8388608/8388608 = 100.00% выделено, 0.00% фрагментировано, 0.00% сжатых кластеров Конечный смещение изображения: 549840879616

Нет, это не так. Я только что добавил это в одну из тестовых виртуалок (CentOS 7, диск virtio). Установил на госте, завершил работу, включил через интерфейс Proxmox, перезагрузил. Проверил, что qemu-guest-agent работает на госте. Сделал снимок, никаких улучшений: по данным qemu-img check: 9275 утекших кластеров 27822 повреждений.

Это план для новых виртуальных машин, но у нас есть множество, которым нужны снимки при обновлениях, настроенные на virtio. Я пытался изменить тип диска на один из них на scsi, но он не загрузился. Если есть простой способ это исправить, мы можем вернуться и изменить старые виртуальные машины, которые используют virtio, на scsi и не переживать. РЕДАКТИРОВАНИЕ - я забыл установить порядок загрузки после удаления и повторного добавления диска с использованием scsi. Так что, похоже, просто переключение на scsi решит проблему, и у нас есть обходной путь. Меня интригует, что эта проблема, у нас возникшая при миграции виртуальных машин с кластера Proxmox 3.x на 4.x, не замечена большим количеством людей. Может, дело в том, что большинство использует стандартный (scsi), а те, кто выбрал virtio, не часто делают снимки.

У меня было впечатление, что virtio рекомендован, если ОС виртуальной машины поддерживает его, поэтому мы до сих пор использовали virtio для виртуальных машин на CentOS/Ubuntu/Debian. Я не замерял скорость с scsi и virtio, но после экспериментов с тестовыми ВМ за последние несколько дней у меня сложилось впечатление, что значительной разницы нет. Намного более заметное влияние оказывает использование .qcow2 по сравнению с .raw, и скорость дисков NFS-сервера тоже имеет большое значение. В принципе, меня беспокоит, что ошибка qemu-коррупции при создании снимка есть в Prox 4 по сравнению с 3, но у нас есть обходной путь — переключение на scsi, так что всё в порядке. Спасибо за все ваши предложения — обсуждение помогло мне разобраться.

Итак, эта ошибка возникает только при использовании "устаревшего" и "непредложенного" режима, верно?