KVM Проблема с дисками

А в dmesg хоста что?

Где находятся vdi виртуалок, на локальных дисках, на NFS/iscsi?

Версия драйвера virtio в винде?

Режим кэша?

Пробовали переносить vdi на lvm?

Меняли платформы это как? (Версия KVM старовата)

Меняли платформы это как? В смысле всю систему целиком меняли (мать проц)

Режим кэша? hypervisor default

Диски виртуалок лежат на локальнм диске хост машины

Версия драйвера virtio в винде? 6.1.7600.16385 в настройка стоит оптимальная производительность. Флаг разрешить кеширование

Почему qcow2, а не lvm? Ты часто мигрируешь виртуалки между стораджами?

это глубинный глюк проектирования. Стореджи надо подключать к вм напрямую, а не запихивать внутрь квм.

Простите я вас совершенно не понял.

qcow2 выбран как наиболее родной и рекомендуемый формат для KVM

Простите я вас дезинформировал 1.3.2 это версия KVM Manager

Версия самого QEMU 2.5.0

Радикальный метод решения проблемы.

И какой у гипервизора дефолт? Чего написано в параметре cache=none?

Спасибо вам огромное это меня вывело на верный путь. Установка у проблемных разделов cache mode=writeback позволило запустить систему в режиме записи.

Понять бы теперь чем мне это грозит?

Не, какой версии .iso с драйверами.

virtio-win-0.1.126.iso

снэпшоты делаете?

нет

Для чего используется эта конструкция с виртуалками?

Тогда нафига cow? raw надо было и не на файловой системе а на LVM.

Это сервер архивации

Проблема уже вроде устранена сменой типа кеширования.

Отвечу вам LVM показался рискованным так как иногда qcow вынимаются и подцепляются к другим виртуалкам.

1. Если не используются снепшоты и тонкие диски то лучше использовать RAW a не qcow2. Они проще, метадаты которая может сломаться нету

2. LVM это тоже идея, и если хост тот же (или LVM раздается с центрального SAN) то никаких сложностей там нет в подключении к другим машинам

3. EIO который ловит QEMU не означает поломаный диск, он означает что qemu не смог прочесть или записать в виртуальный диск, и чтоб не сломать данные на диске машина была переведена в паузу. Вполне возможно что тормозит сам хост, особенно если идет рандомная запись или чтение с серьезной нагрузкой на большие механические диски. Конкретно что с производительностью разбирайтесь сами.

4. Убунта как виртуальный хост - фу. Повторяться почему в сотый раз не буду. Просто попрошу назвать имена ну хотя бы десятка коммиттеров из каноникал в qemu/kvm/virtio/etc или столько же имен профессиональных тестировщиков которые там занимаются этими системами.

5. На хосте надо проверить IO scheduler, рекомендуется deadline.

Не на всех ВМ помогло игра с типом кеширования. Видимо всетаки раздел ломается безвозвратно. Я не понимаюпочему qemu-img check не выявляет проблему.

Что характерно система ставится в паузу в самый последний момент загрузки ОС уже когда почти все готово.

qemu-img check проверяет метадату qcow и целостность тома, а не проверяет каждый блок на ошибки. Я бы все таки начал смотреть в сторону производительности дисков (и замену ОС на нормальную для kvm)

ОС нормальную для kvm

Это такое политкорректное название центоси теперь? Не то что бы имею что-то против, но всё же надо учесть, что «ОС нормальная для kvm» может оказаться ненормальной для используемой железяки и стать причиной букета новых проблем.

Это же мальчик из тех. поддержки РедХата. Угадай какая ОС нормальная.

«ОС нормальная для kvm» может оказаться ненормальной для используемой железяки

Знаешь серверные "железяки", на которых убунта работает лучше, чем центось?

DL380 G5 - там драйвер для массива из 7 центоси убрали, а убунта встала, не помню 14.04 или или 16.04 проверял тогда. Иногда на ноут надо было сервачёк развернуть в качестве шлюза или мониторинга - центось замыкала и зависала, убунта работала.

https://www.centos.org/forums/viewtopic.php?t=47011

Да видел я это всё, но как-то стрёмно было включать то, что было зачем-то отключено, будешь потом ССЗБ

DL380 G5 - там драйвер для массива из 7 центоси убрали, а убунта встала

https://www.centos.org/forums/viewtopic.php?f=49&t=47011 — оно?

на ноут

серверные «железяки»

в качестве шлюза или мониторинга

ОС <…> для kvm

Okay

Okay

Конечно окай
А вообще да, сейчас больше докер

т.е. засунуть хранилище в квм не стремно, а включить hpsa_allow_any или установить elrepo драйвер не стремно :) ок.

я тебе как доктор, говорю, стореджи к вм надо подключать напрямую. мимо qemu-kvm. iscsi, nfs, gluster, cifs, ceph ... как угодно. диски для вм должны быть минимальны только для запуска систем и локальных сервисов.

я писал не про квм а про совместимость ос и железа.

сорян, ты не тс, не посмотрел :)

ничего политкорректного, где идет разработка и отладка всем известно. А что делают другие дистры кроме сборки, обычно вообще без какого либо тестирования? Серьезно, покажите мне тех кто профессионально занимается разработкой, отладкой и тестированием KVM и подсистем в убунте и я возьму свои слова обратно

cciss что ли? эта древность должна была быть прибита вместе с тем кто ее придумал. Столько проблем никогда ни с одним драйвером не бывало. HP занялись самодеятельностью, понапихали файлов туда где их быть не должно, и типа весь остальной линукс должен прогнуться под их идиотизм? Не зря ведь они эту идею бросили