У меня серьезные проблемы с производительностью диска при настройке гостевой системы KVM. Используя простой dd test, раздел на хосте, на котором находятся образы qcow2 (зеркальный RAID-массив), записывает более 120 МБ / с, а мой гость получает письма от От 0,5 до 3 МБ / с.
time dd if=/dev/zero of=/tmp/test oflag=direct bs=64k count=16000.Кажется, есть много руководств по настройке производительности kvm, и я в конце концов доберусь до них, но похоже, что на данный момент я должен получить значительно лучшую производительность, чем это, так что похоже, что что-то уже очень не так.
Обновление 1
И вдруг, когда я вернусь и попробую сейчас, это 26,6 МБ / с; это больше похоже на то, что я ожидал от qcrow2. Я оставлю вопрос на тот случай, если у кого-то есть идеи относительно того, в чем могла быть проблема (и в случае, если она таинственным образом вернется снова).
Обновление 2
Я перестал беспокоиться о производительности qcow2 и просто переключился на LVM поверх RAID1 с необработанными образами, все еще используя virtio, но установив cache = 'none' и io = 'native' на диске. Производительность записи теперь прибл. 135 МБ / с используя тот же базовый тест, что и выше, поэтому, похоже, нет особого смысла выяснять, в чем была проблема, когда ее можно так легко решить полностью.
Ну да, файлы qcow2 не предназначены для невероятно высокой производительности. Вам больше повезет с необработанными разделами (или, желательно, с LV).
Как добиться максимальная производительность с QCOW2:
qemu-img create -f qcow2 -o preallocation=metadata,compat=1.1,lazy_refcounts=on imageXYZ
Самым важным из них является предварительное выделение ресурсов, которое, по словам разработчиков qcow2, дает хороший импульс. Это почти наравне с LVM сейчас! Обратите внимание, что это обычно включено в современных (Fedora 25+) дистрибутивах Linux.
Также вы можете предоставить небезопасный кеш, если это не производственный экземпляр (это опасно и не рекомендуется, полезно только для тестирования):
<driver name='qemu' cache='unsafe' />
Некоторые пользователи сообщают, что в некоторых тестах эта конфигурация превосходит LVM / небезопасную конфигурацию.
По всем этим параметрам последняя версия QEMU 1.5+ необходимо! Опять же, они есть в большинстве современных дистрибутивов.
Я добился отличных результатов для изображения qcow2 с этой настройкой:
<driver name='qemu' type='raw' cache='none' io='native'/>
который отключает гостевые кеши и включает AIO (асинхронный ввод-вывод). Запуск вашего dd команда дала мне 177 МБ / с на хосте и 155 МБ / с на гостевом компьютере. Образ размещается на том же томе LVM, на котором проводился тест хоста.
Мой qemu-kvm версия 1.0+noroms-0ubuntu14.8 и ядро 3.2.0-41-generic из запаса Ubuntu 12.04.2 LTS.
В старых версиях Qemu / KVM бэкэнд Qcow2 работал очень медленно, когда не был предварительно выделен, тем более, если он использовался без включенного кеша обратной записи. Смотрите здесь для получения дополнительной информации.
В более поздних версиях Qemu файлы Qcow2 работают намного быстрее, даже если не используется предварительное выделение (или предварительное выделение только метаданных). Тем не менее, объемы LVM остаются быстрее.
Замечание о режимах кеширования: обратная запись cache является предпочтительным режимом, если только не используется гость без или отключенной поддержки сброса / барьеров дискового кеша. На практике гостевые системы Win2000 + и любые варианты монтирования Linux EXT4, XFS или EXT3 + через барьер - это штраф. С другой стороны, cache = unsafe должно никогда использоваться на производственных машинах, так как очистка кеша не распространяется на хост-систему. Неожиданное завершение работы хоста может буквально разрушить файловую систему гостя.
У меня возникла точно такая же проблема. В виртуальной машине RHEL7 у меня есть целевое программное обеспечение LIO iSCSI, к которому подключаются другие машины. В качестве базового хранилища (backstore) для моих iSCSI LUN я сначала использовал LVM, но затем переключился на образы на основе файлов.
Короче говоря: когда резервное хранилище подключено к контроллеру хранилища virtio_blk (vda, vdb и т. Д.) - производительность от клиента iSCSI, подключенного к цели iSCSI, была в моей среде ~ 20 IOPS, с пропускной способностью (в зависимости от размера IO) ~ 2- 3 МБ / с. Я изменил контроллер виртуального диска на виртуальной машине на SCSI, и теперь я могу получить более 1000 операций ввода-вывода в секунду и пропускную способность 100+ МБ / с от моих клиентов iSCSI.
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2' cache='none' io='native'/>
<source file='/var/lib/libvirt/images/station1/station1-iscsi1-lun.img'/>
<target dev='sda' bus='scsi'/>
<address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>
Если вы запускаете виртуальную машину с помощью одной команды, в качестве аргументов вы можете использовать
kvm -drive file = / path_to.qcow2, if = virtio, cache = off <...>
У меня получилось с 3 МБ / с до 70 МБ / с.