Какой формат QEMU не стоит использовать?

Выдели виртуалке отдельный SSD как RAW-диск. :)

А если серьёзно — разницы в производительности QCOW2 и IMG (RAW-образов) быть не должно, за исключением просадок производительности qcow2 в двух случаях:

• При выделении новых блоков в образе;
• При использовании снапшотов.

Также обрати внимание, что RAW-образы всегда занимают 100% объёма виртуального диска, а qcow2 могут занимать только те блоки, которые заняты внутри VM.

redhat советует lvm разделы.

Если нужны миграция, снапшоты, клаудинит, то лучше qcow2

raw on lvm thin provisioning

redhat советует lvm разделы.

+1

Thin provisioning под СУБД?

используй LVM

АПВС?

Ну, мне кажется странным рекомендация использования thin provisioning под СУБД, и поэтому я уточнил. Вдруг Вы этот момент (субд) пропустили.

Так-то можно сказать, что СУБД должны быть только на живом железе.
Но thin чуть экономит место, вроде как имеет более быструю работу снапшотов и при этом не особо будет тормозить БД по сравнению с обычным lvm, если конечно база не растёт на гиг в час.
Соответсвенно если СУБД не для прод задач, то я бы посоветовал тонкий lvm либо qcow2, в целях экономии места.

Лучше не стоит БД класть в виртуалку.

Dimez

Лучше не стоит БД класть в виртуалку.

Почему? Конторка небольшая, бэкапы ежедневные (ночные), БД УТ-шка и у бухов соответственно бухгалтерия. Даже если что-то пойдёт не так, можно будет развернуть вчерашний день и восстановиться.

Всем спасибо за советы! Остановился на родном qemu-вском формате *.qcow2

Но thin .... не особо будет тормозить БД по сравнению с обычным lvm

Вы местами не попутали?

Лучше не стоит БД класть в виртуалку.

Почему?

задача в топике

требуется скорость работы

я как-то криво предложение построил. ну ты же понял в чем смысл.

требуется скорость работы

Успешно эксплуатирую mssql + 1c на виртуалках в продакшене. На скорость жалоб нет (понятно, что на голом железе быстрее, но просадка незначительная). У меня в виртуалку с mssql проброшены разделы с четырёх разных raid-1 массивов, собранных из ssd (под систему, под data, под log, под temp). Никаких qcow, естественно :)

postgres версионник, те сам по себе в некотором роде COW, городить сверху еще один слой это ппц, пробрось raw device.

Не внимательно прочитали?

Лучше не стоит БД класть в виртуалку.

Саму БД не стоит, не сервер СУБД, а БД, собстно как у вас и сделано:

У меня в виртуалку с mssql проброшены разделы с четырёх разных raid-1 массивов, собранных из ssd (под систему, под data, под log, под temp). Никаких qcow, естественно