Привет всем! Извините, что поднимаю старую тему. Может, кто-нибудь объяснит технически, почему LXC не может работать на ZFS через iSCSI? Как раз когда я снова начал это изучать, наткнулся на эту тему, где впервые услышал о том, что LXC не поддерживается на ZFS через iSCSI. Спасибо, Tmanok.

Ну, признаюсь, я никогда полностью не реализовывал ZFS через iSCSI с PVE, и вы, возможно, правы, @LnxBil, но у меня такое ощущение, что дело не совсем в этом. В Blockbridge мы были первой компанией по хранению данных, которая создала плагин Docker для хранения, когда они только начали выпускать Storage API. Мы даже реализовали весь наш стек хранения данных внутри Docker контейнера как симулятор. Обеспечение iSCSI из контейнера было непросто, но мы справились. Интегрировались с Docker Swarm, а затем с K8s мы путем создания плагина, который подключал iSCSI диски к базовому хосту и передавал их контейнерам с файловой системой или без нее. Это та же концепция, которую мы используем сейчас с плагином Blockbridge PVE - создается iSCSI диск, он подключается, а затем монтируется в PVE LXC. Плагин также следит за перемещением диска, когда нужна миграция LXC. Так что, в теории, это должно быть возможно. Blockbridge: ультра-низкая задержка, общая хранилище на базе NVMe для Proxmox - https://www.blockbridge.com/proxmox

Ну что ж, это в любом случае решающий фактор. MPIO имеет меньшую задержку, более высокую пропускную способность и работает параллельно, а LAGs не представляются протоколу iSCSI как что-то с несколькими путями, просто больше полосы пропускания. К сожалению, это означает, что iSCSI не может использовать одни и те же физические каналы с LAGs. Плагины и патчи ядра были бы отличным решением для конкретной SAN, я уверен, но только при очень регулярных обновлениях и тестировании, в чем я сильно сомневаюсь. NFS с .raw снимками тоже был бы очень полезен, но, увы, это невозможно. Если бы только контейнеры могли использовать .qcow2 или .raw, улучшенные по функциональности. Спасибо, ребята, Tmanok.