После обновления lvm возросла запись / чтение на дисках при использовании кеширования, что это может быть?
Откатился с ядра 3.10.0-693.21.1.el7.x86_64 обратно на 3.10.0-514.26.2.el7.x86_64, проблема осталась. Пробовал поставить 4.4.120-1.el7.elrepo.x86_64, проблема также сохраняется.
Откатил LVM вместе с зависимостями от 2.02.171-8 к 2.02.166-1, проблема также сохранилась.
Мягко говоря, я в замешательстве.Обновление от 13 марта: проблему для себя решил.
Я произвел чистую установку CentOS 7.4 со всеми актуальными пакетами, на ней проблему не удалось воспроизвести. Сравнил конфигурацию хранилища LVM из каталога /etc/lvm/backup, откуда выяснил, что на всех серверах metadata_format стоит в 1, а на свежей установке у хранилища стоит 2.
Что удалось выяснить - если система была обновлена с первых версий 7 ветки (точно не помню, возможно 7.1 или 7.2 изначально была установлена), то при подключении кеширования с помощью команды lvcreate без явного указания cachemetadataformat (по умолчанию стоит auto), почему-то ставилась 1 версия. А в новой установке при тех же условиях ставилась 2 версия.
Сама проблема воспроизводилась следующим образом - режим кешировния writeback, cachemetadataformat в 1. При записи на такое хранилище, процесс вел себя достаточно странно: помимо записываемых данных (которые по логике должны попадать в кеш и на диск), система производила чтение каких-то данных с HDD (в значительно больших объемах, чем велась запись), эти данные писались в кеш на SSD, а после завершения записи этот объем данных записывался обратно на HDD. Это очень хорошо видно в связке использования fio + iostat, виртуальные машины здесь не причем, проблема воспроизводится и без них.
Решение простое: отключаем кеширование и явно указываем версию мета-данных. Ниже пример команд, может кому-то пригодятся (переменные замените под себя):lvconvert --uncache ${VG_NAME}/${LV_NAME}
lvcreate --type cache --cachemetadataformat 2 --cachemode writeback -L${SIZE}G -n ${LV_NAME}_cache ${VG_NAME}/${LV_NAME} /dev/${SSD}
Очень похоже, что поменялся алгоритм кеширования. Но у меня встречный вопрос, а почему бы не использовать ceph?! Ваша конфигурация как раз очень хорошо под это дело подходит, KVM/QEMU отлично работает с ceph напрямую. При этом вы получите практически моментальную миграцию виртуалок, очень гибкую работу с распределеенм хранилищем, снапшоты, бекапы, восстановление, клонирование, миграцию, забудете про lvm и raid, получите или быстрый кеш на ssd, или быстрый пул. В дополнение, практически неограниченно растущее хранилище данных и облачное хранилище, вылет одно любого сервера не скажется никак на доступности данных для виртуалок. 
Из минусов - память на каждый терабайт дисков нужно гигабайт памяти, и нужна сеть 10гб между серверами.
Настройка не займет больше 30 минут и часа чтения документации. Диски не нужно делать в raid! На каждом из серверов достаточно отвести по 8-100 гигов для рутового раздела и загрузки, все остальное нужно просто отдать в ceph.