Информация
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
Контакты
Оплата
Новости
Доставка
Загрузки
Форум
Настройка
    info@proxmox.su
    +7 (495) 320-70-49
    Заказать звонок
    Аспро: ЛайтШоп
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Аспро: ЛайтШоп
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Аспро: ЛайтШоп
    Телефоны
    +7 (495) 320-70-49
    Заказать звонок
    0
    0
    0
    Аспро: ЛайтШоп
    • +7 (495) 320-70-49
      • Назад
      • Телефоны
      • +7 (495) 320-70-49
      • Заказать звонок
    • info@proxmox.su
    • Москва, Бакунинская улица, 69с1
    • Пн-Пт: 09-00 до 18-00
      Сб-Вс: выходной
    • 0 Сравнение
    • 0 Избранное
    • 0 Корзина
    Главная
    Форум
    Proxmox Виртуальная Среда
    повреждение файла на qcow vmdisks

    Форумы: Proxmox Виртуальная Среда, Proxmox Backup Server, Proxmox Mail Gateway, Proxmox Datacenter Manager
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    повреждение файла на qcow vmdisks, Proxmox Виртуальная Среда
     
    Nemo
    Guest
    #1
    0
    13.12.2019 10:09:00
    Привет, у нас большие проблемы с повреждением файлов на виртуальных машинах qemu. Это началось около месяца назад, похоже, и возможно, связано с нашим последним обновлением pve. Файлы можно выявить с помощью команды: debsums -c на гостях Debian, также команда: qemu-img check <image.qcow2> показывает значительное повреждение. На гостевой машине я вижу файлы с правильным размером и временными метками, но содержащие только нулевые байты. Некоторые из них также частично затираются; я нашел один файл с 4096 нулевыми байтами в начале, после которых идет нормальный контент на этой позиции. В основном, эти файлы, по всей видимости, были созданы незадолго до перезагрузки (ядровые модули или свежеустановленное ПО). Сначала мы подозревали, что причиной могло быть включение discard на образах и выполнение fstrim, но теперь это кажется временным совпадением. Также мы подозревали, что что-то не так с подлежащим glusterfs, но за годы до этого ничего подобного не проявлялось, и он не обновлялся уже какое-то время, так что пока мы это исключили. Это очень предварительные предположения о причине, однако; я публикую их в основном для того, чтобы найти аналогии, если кто-то другой испытывает подобные явления. Извините за грубое сообщение; я хотел донести информацию, чтобы подтвердить или опровергнуть свои наблюдения. Не стесняйтесь задавать вопросы по любым деталям, которые вас интересуют. Версия pve: pve-manager/5.4-13/aee6f0ec (работающее ядро: 4.15.18-23-pve), так что на данный момент все свежо, кроме libpve-common-perl/stable 5.0-56, который мы еще не обновляли (мы стараемся сократить количество циклов питания насколько это возможно). Мне кажется, что один отчет об ошибке может быть связан с этим: https://bugs.launchpad.net/qemu/+bug/1846427 Однако версии, похоже, различаются (хотя я не знаю, как версии соотносятся): команда: ~# dpkg -l | grep qemu
    ii  pve-qemu-kvm                         3.0.1-4                        amd64        Полная виртуализация на аппаратном обеспечении x86
    ii  qemu-server                          5.0-54                         amd64        Инструменты сервера Qemu Это все, что я пока собрал...
     
     
     
    Nemo
    Guest
    #2
    0
    04.02.2020 10:47:00
    Обновление: Мы отключили discard для всех гостей. Мы могли бы спровоцировать повреждение, создавая машины с включенным discard, но это стало более сложным и редким. Поэтому это может зависеть от нагрузки или количества параллельных виртуальных машин с включенным discard. Трудно сказать. Тем не менее, мы начали воссоздавать каждую виртуальную машину в кластере, так как мы также столкнулись с повреждением файлов на машинах с отключенным discard, зачастую после обновлений apt, иногда просто так. Мы подозреваем, что данные могут случайно попадать на поврежденные блоки в образе qcow. Также мы обнаружили, что у нас было повреждение в образах, созданных с помощью qemu-img convert из, казалось бы, безошибочных (qemu-img check) файлов образов. Это повреждение проявлялось только через debsums -c. В целом, это тревожная проблема. Тем временем мы обновили glusterfs и Proxmox. Возможно, однажды я снова попытаюсь спровоцировать повреждение, но сейчас мы довольно заняты спасением данных и систем.
     
     
     
    Alwin
    Guest
    #3
    0
    04.02.2020 11:34:00
    Похоже, что проблема связана с оборудованием. Обновлены ли прошивка и BIOS устройства?
     
     
     
    Nemo
    Guest
    #4
    0
    05.02.2020 15:13:00
    BIOS версии 2017 и 2018, пять машин, два разных комплекта оборудования. Было бы маловероятно, что все они показывают одни и те же симптомы одновременно. Но все же стоит это учитывать.
     
     
     
    Alwin
    Guest
    #5
    0
    05.02.2020 16:16:00
    Пожалуйста, также обновитесь, так как PVE 5 будет достигать конца жизненного цикла приблизительно в июле. Это принесет новый пакет pve-qemu-kvm. https://pve.proxmox.com/wiki/FAQ
     
     
     
    Nemo
    Guest
    #6
    0
    11.02.2020 13:29:00
    PVE сейчас 6.1.7, а glusterfs 7.1. У нас все еще есть образы, показывающие свежие повреждения, но я сейчас думаю, что они начинают появляться только когда записывается один из зануленных блоков, так что это не совсем новые ошибки. В данный момент мы слишком заняты сохранением операций, чтобы проводить дополнительные тесты, но, возможно, я найду на это время позже.
     
     
     
    Alwin
    Guest
    #7
    0
    11.02.2020 14:07:00
    Это с отключенной или включенной функции отбрасывания?
     
     
     
    csepely.peter
    Guest
    #8
    0
    15.09.2020 12:37:00
    Привет, Немо. У нас те же проблемы, похоже, в данный момент затронуты связанные клоны ВМ. У нас есть NVME-хранилище под GlusterFS, но с HDD таких проблем нет. После некоторых тестов, Gluster 5.5, Debian Buster, на XFS с настройками по умолчанию GlusterFS, файлы внутри qcow коррумпированы. Первое решение: используйте RAW-образы. Второе решение: отключите опцию performance.write-behind на затронутом томе. С наилучшими пожеланиями, Питер.
     
     
     
    jan.svoboda
    Guest
    #9
    0
    17.12.2020 10:49:00
    У меня была такая же проблема (https://forum.proxmox.com/threads/cloning-a-running-vm-make-the-clone-corrupted.78771/), и после отключения функций performance.write-behind и performance.flush-behind на узле GlusterFS все стало в порядке, больше нет поврежденных ВМ.
     
     
     
    Страницы: 1
    Читают тему
    +7 (495) 320-70-49
    info@proxmox.su

    Конфиденциальность Оферта
    © 2026 Proxmox.su
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры