Низкая скорость дисковых операций гостя kvm

покажите `mount | grep home`

ну и традиционно уже - попробуйте на Федоре (и более современной гостевой ОС тоже не помешало бы)

/dev/sda2 on /home type reiserfs (rw,noexec,nosuid,nodev)

Менять хост-генту на федору нет возможности. linux-гостя щаз поставлю.
По ходу разбирательств возник вопрос - можно-ли (и как) уже созданный и набитый инфой qcow2 образ, сделать preallocated? Он изначально был создан динамически растущим и есть подозрение, что он по мере роста так лажает.

да, это одно из подозрений. при росте, qcow2 увеличивается на 4k, что может оказаться совсем мало - отсюда и тормоза. Можно или сконвертировать его в raw через qemu-img, или просто забить его нулями, внутри гостевой ОС

mount options для репозитория имиджей ВМ обычно оптимизируют. Как минимум noatime, nodiratime

и еще, поменяйте cache на none

qcow2 вообще неторопливая штука, неплохо бы перетащить это дело на LVM...

Как минимум noatime, nodiratime

там не только образы VM. Так бы я ещё notail добавил.

поменяйте cache на none

Ради теста поменяю, конечно. Но в интернетах всё указывает на то, что writeback, как минимум, не медленнее, чем всё остальное.
Результаты по линукс-гостю подоспели:

dd if=/dev/zero of=test bs=4k count=1M
1048576+0 записей получено
1048576+0 записей отправлено
 скопировано 4294967296 байт (4,3 GB), 113,501 c, 37,8 MB/c

Поглядываю я в сторону lvm, но пока понимания «как это сделать правильно» нету.

Даже если неправильно сделаешь - все равно будет быстрее, чем qcow2 :)
Хотя что там можно сделать неправильно, даже не знаю. Разве что, накосячить с alignment'ом разделов, если HDD с Advanced Format'ом (аппаратный 4К сектор).

Можно или сконвертировать его в raw через qemu-img

Всмысле qcow2 -> raw -> qcow2 ? Мне-бы оставить возможность делать снапшоты, а в raw они, AFAIK, не поддерживаются.
Или снапшоты - не тру и бэкапы делать надо тупым копированием образа при выключенном госте? Как оно правильней?

аппаратный 4К сектор

Не. Аппаратный raid с

Array stripe size in number of blocks : 64
Array sector size : 512

Рейзер? :)
Нуну.

Да, рейзер. После того, как на ext3 кончились иноды при 40+% свободного места. (Вот я тогда знатно затупил глядя на это.) Может, и не лучший выбор, конечно.

прямой блочный доступ конечно немного быстрее, но qcow2 с современным qemu работает почти так же как raw

стоп, там еще и снепшоты есть? тогда точно будут тормоза, COW как алгоритм не оптимален, поэтому на нем тормозит у всех.

я имел ввиду один плоский имидж, без снимков

ну, с таким раскладом даже не знаю, вряд ли кто либо это проверял вообще когда либо

сделайте LVM, и избавьтесь от снимков для начала

укажи cache=... , иначе qcow2 аццки тормозит.

Ну и про снапшоты уже сказали.

да, в случае сбоев на сервере с cache=... образ может серьёзно покорёжиться.

Кстати, о прямом доступен на LVM.
У меня на нем с aio=native больше IOPS'ов, а с aio=threads - больше линейная скорость чтения... оба случая замерялись с cache=none.

Было-же указано
<driver name='qemu' type='qcow2' cache='writeback' io='native'/>
Снапшоты были, но были удалены. Тормоза начались уже после удаления.
Конверчу в raw.

сконвертировать его в raw через qemu-img

Оно! По ощущениям, стало даже быстрее, чем на хосте. Видать, кэширование сказывается.

существенно больше, или полпопугая? :)

Где-то на треть в обе стороны. Т.е. существенно. Но использую native, т.к. iops'ы важнее линейки.

интересно, у меня немного другие показатели. Правда я пользуюсь стабильным RHEL, и железом которое не является узким местом (недавно одна ВМ показала 1.6 миллион iops)

кэширование я бы все таки отключил

Отключил. Странно, но разницы при переходе writeback->none не заметил. Хотя и не искал особо.