LVM + xfs + qcow2

Без контекста эти вопросы имеют мало смысла. Что за оборудование, для каких целей, и т.д.

1) Это стандартное решение.

2) Не понятно. Выражайтесь яснее.

3) LVM тоже умрет.

Даже, если заставишь активироваться деградированный том, то не хватит метаданных для работы ФС.

Но думать в таком ключе как-то неправильно.

2) он предлагает подключить два диска как два отдельных хранилища.

Да, все верно, по другому же не подключить)))

А в каком ключе правильно, при текущей задаче?

Хороший у вас парсер)

ТС: быстродействие не отличается, надежность тоже не отличается.

Отдавать в ВМ lv, без всяких фс.

Raid 5 ( sda , sdb, sdb ) -> LVM -> vg-vms-> lv-centos7-1, lv-debian-2

Если упомянул надёжность, то допускать деградацию до нерабочего состояния верхнего уровня вообще нельзя. Разницы большой нет, сломалось целиком, или только половина.

В таком случае система сожрет все пространство, а требуется динамика

Это не так.

Можно на тонких томах. Да и снимки на них лучше.

Имеется ввиду, VM сожрет все пространство выделяемое ей lvm. Qcow2 формат сжимает данные и динамический расширяет по факту до предела заданного значения

сожрет все пространство выделяемое ей lvm

Пространство выделяет не LVM, а вы. Не выделяйте все сразу.

Qcow2 формат сжимает данные

Некоторые ФС тоже сжимают данные. И над блочным устройством можно организовать компрессию: откройте для себя VDO.

И — ШОК — даже некотроые SSD сжимают данные аппаратно прозрачным образом. Иначе как из спеков об это узнать невозможно.

Qcow2 можно раскатать прямо поверх тома без прокладок в виде ФС. lvm+Qcow2 - все уже есть в zfs и даже больше.

Qcow2 формат сжимает данные

Этой фичей никто почти не пользуется, т.к. производительность проседает и и хуже совместима.

А динамическое распределение и не всегда так уж нужно. Можно сразу выделить, а потом расширять вручную снаружи, а потом внутри. Но в любом случае надо учесть и само расширение и потребление места.

LVM поверх raid1, raid10, raid5. А виртуалкам отдавайте обычные lv, либо thin lv.

Вопрос сформируйте точнее. Что важнее надежность, производительность, или, исключающее первое и второе, бюджет?

Что за «2 диска», что за виртуалки. Причем/зачем тут xfs?

+1

3) LVM тоже умрет.

не всегда

Сам lvm не умрет, но тома распределенные на пропавший диск можно считать мертвыми. Смысла делить на тома с ФС нет. Если хранить образы в отдельных разделах без ФС, то оставшиеся смогут работать. Но по-умолчанию распределяется место последовательно, вроде. Можно задать равномерное распределение, вроде, то снимки или другие связанные разделы вероятно тоже распределит на разные диски.

LVM, кстати, не обязательно поверх программного raid делать. Lvm может конфигурировать raid и некоторые другие внутри себя, используя тот же device-mapper, хоть и дает меньший контроль.

тома распределенные на пропавший диск можно считать мертвыми

это само собой. Если умрет диск на котором расположены данные и копии нет, что будет?)

по-умолчанию распределяется место последовательно, вроде. Можно задать равномерное распределение, вроде, то снимки или другие связанные разделы вероятно тоже распределит на разные диски

это пусть ТС идет и читает man lcvreate, man lvm итд

Lvm может конфигурировать raid

Если говорить об LVM поверх зеркала например, то «поверх raid» наверное проще будет и понятнее, а дальше все зависит от задачи... Проще потому, что есть у тебя VG - добавляй ему разные PV (быстрый, зеркалируемый, дорогой, дешевый)... Когда создаешь/мувишь lv - выбирай как надо. Да и по производительности и надежности, не уверен, что LVM со «своим raid» будет выгоднее LVM поверх raid в простейших случаях

Я пробовал lvm+ext+qcow - долго, ли, коротко... - Пришёл к zfs в итоге.

В qcow, если сделать снепшот, и забыть про него, и через пол годика вспомнить, можно удивиться и молиться потом в ожидании когда он буквально несколько часов удаляется... На фиг на фиг сей цирк. Городить lvm + thin lvm + ext + qcow - ну это уже переборно. В общем, юзаю proxmox + zfs, а к ней прикручиваю сейчас вот такое: https://github.com/Corsinvest/cv4pve-autosnap , по идее, будет и реплика, и снепшоты. И производительность адекватная.

P.S. кучу снепшотов и zfs, кстати, очень долго удаляет. Так что, тоже, к их кол-ву, всегда лучше подходить с умом.

lvm + thin lvm + ext + qcow

А зачем тогда ext и qcow? Отдавать гостю lv, снепшоты средствами lvm.

На счет zfs сказать ничего не могу. Кстати, какова разница в производительности zfs, lvm и lvm thin, касательно работы со снепшотами?

А зачем тогда ext и qcow? Отдавать гостю lv, снепшоты средствами lvm.

Да я по всякому пробовал... В общем, снепшоты в lvm, нельзя реплицировать на другой хост, в qcow снапшоты долго удаляются. - Короче, плюнул и перешёл на zfs.

Кстати, какова разница в производительности zfs, lvm и lvm thin, касательно работы со снепшотами?

Детально не вникал, мне важен функциональность. Там где дисковые операции - я всё равно стараюсь покупать ssd серверные.

lvm + thin lvm + ext + qcow

зачем этот набор из костылей? лучше zfs ничего нет и не будет в обозримом времени.

Qcow2 формат сжимает данные и динамический расширяет по факту до предела заданного значения

qemu может освобождать неиспользуемое место и в raw-образах дисков, реально занятый объем в файле образа можно посмотреть, например, командой du. При использовании xfs с включенными reflink снимки образов дисков можно делать почти мгновенно командой cp --reflink

При большом количестве снапшотов ZFS значительно быстрее LVM и thin LVM. Точнее, при большом количестве LVM совсем раком становится.