а lio никто не использует?

Благодарю.

Так это вроде и есть tgt? Тот который стандартный ядерный.

Неа
http://stgt.sourceforge.net/
http://linux-iscsi.org/wiki/Features

Странно, что везде про его установку говорят "yum install targetcli -y", так что да, я использую

может, кому будет интересно.

А оно не корнями в quadstor случаем?

нет

На базе двух популярных описаний покажу:
http://linux-iscsi.org/wiki/Network_RAID1
https://www.suse.com/documentation/sle-ha-12/book_sleha/index.html?page=/documentation/sle-ha-12/book_sleha/data/sec_ha_cluster-md_create.html

Что не  так:
1) внутренняя метадата. В DRBD всегда использую внешний 1gb-диск
2) lvm. Зачем он в 2019 году? Какие задачи решает в направлении SDS(software defined storage)? игра в нарезку, которая затем превращается в игру в тормозящие снапшоты - это не очень серьёзно
3) у drbd отличный cli/обвязка, которая позволяет решать задачи "раз в день синхронизируемой реплики" (т.е. отложенной реплики) или управлять аутентификацией.
Да, можно аутентификацию вынести в iscsi-уровень - для этого нужна прослойка, выполяющая это вместе со стеком управления VM
4) Архитектура. Я бы обратил внимание на то, что сейчас 2019 год.
https://blog.pythian.com/btrfs-performance-compared-lvmext4-regards-database-workloads/  , например

На счёт lvm - не согласен, просто он очень пытается не нарушать философию Unix, из-за этого создается много слоев и небольшая путаница. Но сам по себе он очень простой и быстрый, кроме того он может быть shared. Если же нужны снапшоты, то есть thin-lvm, производительность thin-lvm даже лучше чем zfs, при этом снапшоты также не замедляют работу.

У того-же BTRFS есть сабволумы, но они годятся только для управления кусками файловой системы, использовать BTRFS для размещения виртуальных дисков или чего-то подобного вообще абсурд, когда как даже swapfile размещать на BTRFS крайне не рекомендуется

OCFS2 для размещения дисков-как-файлов очень хорош.
Т.е. мне сложно понять, зачем нарезать и сложно перенарезать LVM'ом - если raw/qcow2 - это просто fallocate

BTRFS как domu FS, конечно же.
В Dom0 её никто не тянет

qcow2 - это не просто fallocate

Про снапшоты - вопрос лишь в том, в каком месте у вас точка восстановления и кто его может делать.
В обычном ops-подходе точка восстановления - VM
В DevOps - application. Тут как раз BTRFS subvolume идеален

О, согласен :)
Т.е. хорошо, что вы знаете, что qcow -это ещё один лишний слой абстракции со своими плюшками.

Так что raw - вполне единственный вариант в случае отсутствия целостной архитектуры SDS.
Ceph - хороший пример наличия архитектуры SDS

Проще говоря,
datapath  "диск -> fs_dom0 -> raw -> fs_domu" наитивнее и гибче.
Это shared nothing топология, да

Есть у кого shared storage топология?

Но мы далеко от one уже ушли