Pull to refresh

Comments 54

Отличный пост, спасибо. От proxmox отказался потому, что основная система помимо виртуализации должна ещё на телевизор Kodi показывать. Пробрасывать виртуальную машину на основной экран вместе с аппаратным ускорением я счёл геморройным. Правда, сейчас взял бы Ubuntu Server LTS, а не Debian.

У меня для таких целей есть отдельная Android-приставка с Kodi и примаунченной шарой, а сервер в коридоре жужжит :)

У меня тоже в коридоре. В шкафу. А оттуда через стену в зал. Плюс там хорошая звуковая карта. Акустика работает независимо от экрана. Можно музыку включить автономно тем же Kodi.

Ого, а управляете чем? — если приложение для телефона, то какое?
Меня официальное Kore не устраивает тем, что там нельзя музыку по папочкам проигрывать, приходится использовать проприетарное Yatse, но должен признать, что оно достаточно неплохое.


Для управления TV, приставкой и звуком использую универсальный пульт с гироскопом MeLE F10 Deluxe:


прикольная штука

Yatse. Разработчик — очень контактный швед. Активная разработка, очень хороший комбайн. Из ключевых фишек — возможность их меню share в андроид бросать все подряд на экран Kodi. YouTube, прямой стрим своего видео с телефона.
Связался с автором Yatse, он обещал рассказать про новые фичи, которые он планирует и прочее. Там сильно расширяется поддержка других медиасервисов помимо Kodi. Если получится, приеду его на хабр с гуглопееводчиком. Или пусть на английском пишет, здесь это не проблема. Я все равно пост планировал по headless Kodi.
Я всё таки настроил снова себе Proxmox c пробросом аппаратного ускорения в контейнер и установил в нём Ubuntu 16.04 с KDE plasma 5 и Kodi. Проброс в виртуальную машину был бы круче, но у меня дешевая материнка, на ней нет IOMMMU. Проброс видеокарты и аудио в lxc-containert делается довольно просто — нужно всего лишь развернуть в проксмоксе убунту-контейнер из стандартного шаблона, дописать пару строк в стандартно сгенерированный конфиг lxc и один раз запустить простенький скрипт внутри контейнера. После этого можно пользоваться контейнером как основным десктопом или как htpc (в моём случае и то и другое). Как настроить такое я описывал на stackexchange. Дальше я устанавливал kubuntu-desktop, но, правда, пришлось установить slim, т.к. я не смог запустить sdm. В моём случае видеокарта — AMD встроенная в проц.

В proxmox классно то, что он ставится по сути на чистый Debian, пользуюсь в качестве десктопа, аналогично можно вместо wm поставить kodi (не самое чистое решение конечно, но работает прекрасно).

Это неплохой вариант, если устраивает debian-desktop. LXC/qemu desktop помимо «чистоты» позволяет более современное ПО ставить, другие дистрибутивы, под qemu, если пробросить видеокарту через iommu, можно вообще хоть на винде сидеть. Можно даже два десктопа на одном сервере так поднять. По идее, Ryzen в этом плане открывает новые горизонты: при невысокой цене работает ECC и IOMMU даже на недорогих материнках. На практике там пока что проблемы с IOMMU groups и ECC не на всех материнках полностью гладко работает, но может быть, скоро эти проблемы будут решены. На Intel такое только на серверных чипсетах можно запилить.
Знаете, я когда-то гнался за отдельной виртуализацией каждого сервиса, но в конце-концов в рамках домашнего NAS от этого для меня больше проблем, чем пользы.

Более свежее ПО — в рамках десктопа с proxmox прекрасно работает testing репозитарий Дебиана, ставил из него всё, что нужно.

Всегда за безопасность, но придерживаюсь рационального (для меня) подхода, что не везде виртуализация нужна.
Согласен, в крайности ударяться не стоит, но, мне кажется, отделить сервер-гипервизор и десктоп — как раз случай когда виртуализация избавляет от проблем и предоставляет нужную гибкость.
Кстати, а какое свежее ПО в вашем случае используете, которого нет в Jessie? Лично я тяну из backports только видеодрайвер (т.к. для skylake нужен свежий) и браузер.
Софт для разработки: gcc6, всякие библиотеки типа boost последних версий, python >=3.5. Ещё KDE plasma, у меня 4K монитор, а поддержка high-dpi на новых версиях значительно лучше. Хочу даже на Arch/Manjaro перейти, именно что бы легко было последние версии нужного софта использовать. На ноуте вот KDE-Neon поставил — не нарадуюсь :)
а чем XMBC не понравился? Старенький? я думал его задача просто показывать фильмы из папки, запоминать на каком месте я остановил просмотр и предлагать продолжить с этого места.
у меня стоит Jessie с иксами, на него накатил Proxmox, через одну виртуалку вывожу свои компы в всемирную сеть. Ну и мне хватает простой самбы что бы я мог делать на шарах все, а ребенок и жена только читать.
Как минимум поддержка пультами типа Yatse уже дропнута. Даже в старом Debian уже его нет. У меня сейчас Debian Stretch.
Спасибо за статью, почерпнул для себя некоторые моменты. У меня очень похожий сетап, тоже All-in-One проксмос, тоже zfs, тоже сервисы на докере и nginx аналогично настроен. У меня два All-in-one сервера уже ~5 лет работают. Последний вариант уже почти год — работает отлично. Отличия:
1) Я всё же установил proxmox на флешку. Последние версии проксмокса работают с флешек как часы — никаких проблем. Плюс флешки довольно легко клонировать и, если одна помирает, можно склонировать её образ на новую.
2) NAS установлен в отдельной виртуальной машине, в эту машину проброшены диски через virtio. Не могу сказать, что это обеспечивает сказочную производительность дисковой подсистемы, но с настройками «по умолчанию» выходит 40-50 MB/s, мне хватает хватает и я даже не пытался добиться большего.
3) All-in-one включает роутер, который реализован как виртуальная машина с openwrt.
4) Там же десктоп/htpc в виде lxc контейнера с пробросом видеокарты (lxc.cgroup.devices.allow, lxc.mount.entry). На контейнере Ubuntu 16.04 и KDE plasma 5 с Kodi, аппаратное ускорение работает ОК, при том что видео встроенное в дешевый AM1-процессор от AMD и используется 4К монитор.
5) Виртуалка с роутером и NAS лежит прямо на флешке, на которой proxmox. Когда стартует Proxmox, он стартует роутер и NAS, а затем уже с хранилища на NAS стартуют остальные виртуалки/контейнеры.
Ну и для докер контейнеров у меня отдельная вирт. машина, а не lxc.

Вам спасибо, за интерес и не менее интересные коментарии :)


1) С флешкой у меня не завелось, все флешки в доме перепробовал. :) Сколько с root на флешке не связывлся и дома и на работе, всегда система либо очень сильно тормозит, либо вообще не заводится.
Вот и в последний раз даже USB3.0 флешку специально для этого купил, думал таких проблем не будет, ан нет, даже это не спасло. Может у вас какая-то супер-флешка?


2) У меня тоже была такая идея, но хотелось реализации именно на хосте а не в виртуальной машине, потому что a) только так можно получить живую производительность, и b) обе системы прекрассно работают и делят между собой одни ресурсы и могут использовать один и тот же пул zfs.

флешки обычные на 16/32 GB, usb 3.0, но стоят в портах 2.0. Я, правда, выбирал чтобы не самые тормознутые, но без фанатизма, по 8-10 евро брал примерно. Proxmox довольно мало обращается к диску сам по себе, роутер тоже, даже обычный убунту-сервер, сам по себе большой производительности от диска не требует. А какие у Вас были проблемы? Что именно тормозило?
Я устанавливал прямо обычным установщиком Proxmox'a, с флешки на флешку, как тут описано. Обратите внимание на rootdelay. Дополнительно настраивал что бы меньше обращений к диску было, как советуют во всяких («устаревших») мануалах по установке линукса на SSD, но не знаю, какую роль эти настройки играют, наверное, и без них ок. Главное чтобы свопа на флешке не было, наверное.
Вот мои настройки:
> systemctl enable tmp.mount

> cat /etc/fstab
/dev/pve/root / ext4 commit=120,noatime,nodiratime,errors=remount-ro 0 1
UUID=219E-7546 /boot/efi vfat defaults 0 1
#/dev/pve/swap none swap sw 0 0
proc /proc proc defaults 0 0

> tail -n3 /etc/default/tmpfs
RAMTMP=yes
RAMRUN=yes
RAMLOCK=yes

2.b) Ну они и так делят ресурсы и используют один и тот же пул zfs. У меня настроено и через NFS и через ZFS-over-iSCSI, оба варианта поддерживаются в Proxmox. Мне кажется, лучше максимально разделить службы по контейнерам/вм в данном случае. С производительностью, наверное, сложнее, но люди же используют SAN и добиваются очень большой производительности, так что, наверное, при желании, можно и это настроить.

Флешки пробовал разные, но подозреваю все они сильно хуже по скорости случайной записи чем флешки в приведенной вами ссылке, думаю что проблема именно в этом.
FreeNAS тормозил над каждым действием в веб-морде.
Proxmox 4.4 и 5.0 beta1 и Debian 8 устанавилвались очень долго, но в конце установки выдавал ошибку. Debian не грузился с ошибкой что не может найти root-раздел. Из опций только noatime,nodiratime указал при установке.
Спасибо за информацию, в следующий раз куплю нормальную флешку и обязательно попробую еще раз!

Debian не грузился с ошибкой что не может найти root-раздел

Это лечится через rootdelay в аргументах grub, я выше ссылку давал.
Спасибо за информацию, в следующий раз куплю нормальную флешку и обязательно попробую еще раз!
У меня в одном из серверов стоит Lexar JumpDrive S23 16GB, которая по сегодняшним меркам так себе, но для Proxmox хватает вполне.

Домашний NAS — а что в качестве железного сервера? ZFS с дедупликацией какие ресурсы потребляет?

Не советую применять дедупликацию в ZFS где-либо, кроме промышленного файлового хранилища, лучше просто использовать lz4 сжатие.

Домашний NAS — а что в качестве железного сервера?

CPU: AMD FX-8300 Vishera
RAM: 16GB DDR3
HDD: 3x2TB (raidz) TOSHIBA DT01ACA200


ZFS с дедупликацией какие ресурсы потребляет?

Здесь пишут что нужно расчитывать 20GB RAM на каждый TB данных


На деле у меня два датастора со включенной дедупликацией, общий объем данных в которых ~850GB, примерно треть в них повторяется. Данные обновляются редко (музыка и фотографии)
Остальные данные около ~400GB хранятся на датасторах без дедупликации но с lz4 сжатием на лету.
Эти данные находятся в постоянном в доступе (раздаются торрентом или проигрываются удаленно).


CPU: утилизируется на 2-5%
RAM: используется почти все 16G, 4G из которых выделено в контейнер с докером, но при этом в swap не лезет (~500M всегда свободно строго)


Прелесть дедупликации что ее можно в любой момент выключить/включить.

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

Возможно я что-то не так понимаю, но ведь полного исключения и не нужно?
Чем плохо то что сдедуплицированные данные такими и останутся на всегда? — ведь основной процесс дедупликации просто перестанет работать, не так ли?

При дедуплицации в системе будет всегда присутствовать т.н. Dedup table (DDT), по которому и происходит привязка дублей. На неё и требуется ОЗУ.

Если интересно, готов рассказать про многие вопросы ZFS, т.к. являюсь контрибьютором. В планах статья-howto с описанием дел на настоящий момент.
статья-howto с описанием дел на настоящий момент

было бы очень интересно!
Будет ли когда-нибудь шифрование из коробки? Будет ли более «производительная» дедупликация, я имею ввиду с меньшими требованиями к ресурсам, особенно оперативке? Что на счёт ssd-кеширования? Как я понимаю, сейчас ZIL и L2ARC не позволяют полноценный кеш организовать, по сравнению с bcache, например?
Отвечу сразу здесь:
Будет ли когда-нибудь шифрование из коробки?

Да, уже год активно дорабатывается и шлифуется. При чём оно разрабатывается с учётом всех недостатков реализации от Oracle, а также позволит штатными send/recieve и scrub отправлять и проверять данные на целостность без ключа.

Будет ли более «производительная» дедупликация, я имею ввиду с меньшими требованиями к ресурсам, особенно оперативке?

В целом производительность будет улучшаться в следующем мажорном выпуске, но явных проблем с дедупликацией нет. Требование к ОЗУ связано напрямую с deduplication table (структура, в которой хранится соответствие контрольной суммы и блока), если DDT в неё не помещается, то будет ухудшение производительности.
Отдельно упомяну, что в бета-релизе проведена большая работа по оптимизации управления данными в ОЗУ (сокращённо ABD)

Что на счёт ssd-кеширования

ZIL выносит журнал на отдельный носитель, а L2ARC очень похож на bcache со своими особенностями. Вот отличная статья по этому поводу.
Отдельно стоит отметить, что в случае ZFS часто хватает просто добавить ОЗУ, ARC прекрасно борется с вымыванием кеша.
На своём десктопе использую 2 WD RED в виде mirror с 16гб ОЗУ, после прогрева кеша машина работает не хуже, чем с ZFS на бюджетном SSD.

Требование к ОЗУ связано напрямую с deduplication table (структура, в которой хранится соответствие контрольной суммы и блока),

В том то и дело, что требования к ОЗУ гигантские, как мне кажется. Допустим у нас 10TB данных, средний блок 64k — выходит ~156*10^6 блоков. Хеш одного блока пусть будет 32 бита, тогда выходит что нужно 10TB/64kB*4=625MB ОЗУ. Даже если взять 8 байтный хеш — всё равно выходит ~1 GB. В случае коллизии (вероятность которой примерно 10^-11 для 8 байтного хеша) можно просто сверить весь блок.
В том то и дело, что требования к ОЗУ гигантские

Вы о выше упомянутых 20гб? Это очень завышенная оценка, FreeBSD даёт оценку в ~ 5 гб на 1тб.
Тут прекрасно описан метод работы DDT, там же приводятся конкретные цифры — 320 байт на каждую запись (уникальный блок).

Вообще есть прекрасная возможность заранее получить точные цифры — у zdb есть возможность имитации дедупликации:
zdb -S название_пула

На выходе будет Total allocated blocks, перемножив его на 320 байт получим требуемое количество ОЗУ. Также там приводится коэффициент дедупликации.

Вот симуляция для моего пула (бекапы, /home, /, немного виртуалок, одним словом дедуплицировать особо нечего):
Simulated DDT histogram
bucket              allocated                       referenced          
______   ______________________________   ______________________________
refcnt   blocks   LSIZE   PSIZE   DSIZE   blocks   LSIZE   PSIZE   DSIZE
------   ------   -----   -----   -----   ------   -----   -----   -----
     1    9.79M    767G    611G    613G    9.79M    767G    611G    613G
     2     894K   47.7G   39.0G   39.3G    1.89M    101G   82.4G   83.1G
     4     112K   3.52G   2.28G   2.37G     541K   17.0G   11.1G   11.6G
     8    32.9K   1.17G    925M    968M     348K   13.1G   10.1G   10.6G
    16    12.0K    529M    397M    418M     239K   10.1G   7.62G   8.03G
    32    10.5K    925M    726M    734M     480K   42.3G   33.0G   33.4G
    64      892   39.7M   30.0M   31.3M    80.0K   3.71G   2.77G   2.89G
   128      419   23.1M   18.7M   19.2M    73.7K   4.19G   3.40G   3.47G
   256      208   13.6M   10.9M   11.1M    73.1K   4.86G   3.92G   3.99G
   512       76   4.90M   3.85M   3.91M    49.4K   3.29G   2.60G   2.64G
    1K       13   1.01M    827K    840K    16.4K   1.20G    981M    999M
    2K        2    130K   5.50K      8K    6.19K    508M   19.1M   24.8M
    8K        5    640K    404K    404K    41.8K   5.22G   3.30G   3.30G
 Total    10.8M    821G    655G    656G    13.6M    974G    772G    776G

dedup = 1.18, compress = 1.26, copies = 1.01, dedup * compress / copies = 1.48



На мои 800гб корневого пула, вообще не оптимизированного для dedup (а также 230гб бекапов с размером блока 1МБ) он дал всего лишь коэффициент 1.18, при этом на DDT потребуется 10.8М*320=3456мб ОЗУ. Оракл не рекомендует включать дедупликацию при коэффициенте меньше 2, я с ними полностью согласен.

Дедупликация — это прекрасно, но практически бесплатное lz4 сжатие (а для большинства HDD оно только ускоряет) в случае неповторяющихся данных намного целесообразнее.

Полезная ссылка.
Мне, кажется, столько большая константа (320, когда достаточно не более 8+4 на dataHash+blockID) портит всю малину. 1-2 гигабайта на 10ТБ было бы no-brainer, а так… Но это, конечно, лишь мои фантазии, наверняка у разработчиков были свои причины, из-за которых вышло 320.
Стоит уточнить цифры для ZFS:
— используемый sha256 (ваш dataHash) = 32 байт
— block pointer (ваш blockID) (blkptr_t) = 128 байт

Это только базовые цифры для минимального варианта реализации. Также там точно есть счётчик повторений, глубже копать не стал, но эти цифры уже дают понимание, что требования не такие уж и раздутые.

Причина такого большого block pointer кроется в самой идее ZFS, и от этого никуда не деться. По этому базовый блок 128кб, он позволяет уменьшить накладные расходы. Больше блок — меньше накладные расходы, но при чтении файла с размером больше блока придётся прочитать ещё 1 полный блок (где находится окончание файла).
используемый sha256 (ваш dataHash) = 32 байт
но зачем хранить весь sha256 в оперативке? достаточно было бы первые 4-8 байт, а в случае коллизий уже пересчитывать полный. То же самое с block pointer, можно было бы пересчитывать сокращённую форму в blkptr_t налету.
А зачем весь blkptr_t, не достаточно было бы blk_dva (32 байта)? Можно ли хранить не blkptr_t/blk_dva а только смещение на адрес, по которому этот самый blkptr_t можно узнать/вычислить?

Мне нравится ваш ход мыслей! :)
По предложениям ответить не могу, т.к. в нутра этой части не лазил, но мы всегда открыты к предложениям! Если готовы — можете внести свои предложения в виде issue, или сразу пулл реквестом, помогу с любым вопросом в части оформления, а другие участники всегда подскажут по коду, сообщество очень доброжелательное.

обязательно пишите! — мы все очень сильно ждем :)

Вопрос, ответ на который кажется очевидным, но всё же. Если ZFS+дедупликацию использовать для хранения несжатых бэкапов Proxmox на самом сервере — какие ресурсы это потребует, с учётом того что коэффициент будет наверняка очень высоким, сохранится ли 20 гигабайт на терабайт данных, не будет ли проблем с самим проксмоксом? Сервер 48 гигабайт РАМ+терабайт SATA (ZFS) +2x200 SSD — сможет ли справиться с этой задачей без больших потерь памяти? Стоит ли включить дедупликацию на SSD, где лежат образы виртуалок?
Вопрос навеян Вашим комментарием "Не советую применять дедупликацию в ZFS где-либо, кроме промышленного файлового хранилища".

Для бекапов можно еще рассмотреть вариант snapshot + zfs send, тогда и без дедупликации все ок.

Всё верно, в таком случае используется snapshot, он позволяет создавать инкрементальные срезы хоть каждую минуту. Но сразу оговорюсь, что не стоит подменять им полноценный бекап на другую машину (а в таком случае снапшоты также прекрасно передаются по сети в инкрементальном режиме).


Вообще, после zfs я уже не представляю, как можно жить без снапшотов и хеширования данных. На моей машине настроено создание снапшота всей системы раз в 15 минут, и это никак не влияет ни на производительность, ни на простои (см. https://github.com/zfsonlinux/zfs-auto-snapshot )


Спасибо всем за поддержку, статье быть, и не одной:)

Буду очень ждать)

По поводу установки на флеш или hdd — вообще без разницы, т.к. тот же ZFS прекрасно отделяет и резервирует систему.

Сомнительно выглядит установка OMV и Proxmox на одну физическую систему. В виртуалку ставить ZFS не имеет никакого смысла по понятным причинам, а в вашем сетапе кто гарантирует, что кастомное ядро Proxmox будет нормально работать с нутром от OMV?

А какаое конкретно нутро вы имеете ввиду? OMV состоит их стандартных демонов и веб-морды к ним, никаких хитрых и дополнительных модулей ядра он не использует.
Плагин ZFS — да, требует модуль ядра zfs, но он и так уже присутствует в Proxmox, потому мы и выпилили его из зависимостей. В остальном это всего лишь управлялка.


Кстати, что мне показалось странным, в зависимостях плагина можно обнаружить пакет pve-headers, а это означает что разработчик допускает возможность совместной установки плагина с кастомным ядром Proxmox.


списки зависимостей

openmediavult:


perl:any libjs-extjs5 php5-fpm libpam-modules php5-cgi php5-cli php5-pam sudo ethtool python3-dialog acl ifenslave resolvconf iproute2 xfsprogs jfsutils ntfs-3g hdparm sdparm ifupdown mdadm postfix libsasl2-modules bsd-mailx python3-dbus cpufrequtils rsyslog logrotate smartmontools openssl openssh-server openssh-blacklist-extra uuid tzdata nfs-kernel-server proftpd-basic wget util-linux samba samba-common-bin rsync apt-utils snmpd avahi-daemon libnss-mdns iptables monit acpid beep gdisk rrdtool collectd cron anacron cron-apt quota quotatool whiptail lvm2 watchdog ca-certificates perl libjson-perl liblocale-po-perl proftpd-mod-vroot libjavascript-minifier-xs-perl coreutils xmlstarlet mount parted bash diffutils lsof socat rrdcached locales nginx bash-completion python3 python3-apt pm-utils wpasupplicant systemd systemd-sysv btrfs-tools samba-vfs-modules pciutils python3-pyudev python3-natsort jq ntp python3-netifaces udev apt-transport-https python3-lxml debconf debconf-2.0 init-system-helpers

openmediavault-zfs:


linux-headers-amd64 pve-headers linux-headers-3.16.0-4-all openmediavault openmediavault-omvextrasorg zfs-dkms zfsutils-linux zfsutils zfs-zed

В остальном гарантий вам конечно же никто не даст, но для себя я проверил все работает как часы, что будет дальше? — поживем увидим :)

В свое время собирали Proxmox на ZFS для офиса. Были неприятно удивлены невозможности делать клоны машин со снапшотов (только с текущего состояния) и откатывать не до последнего снепшота. Судя по комментариям на форумах — это стандартное ограничение ZFS, из-за чего пришлось от него отказаться (сейчас CEPH). Может быть я что-то делал неправильно, или оно так у всех?
Сам ZFS позволяет делать clone со снапшотов (в рамках понятий ZFS), скорее всего это не реализовано в веб-интерфейсе proxmox (он также не видит созданные мной вручную снапшоты).
OMV 3.x весьма странное создание. ИМХО ему еще нужно время на стабилизацию состояния.
Вместо:
apt install build-essentials

Нужно:
apt install build-essential
спасибо, исправил
Пытаюсь всё это повторить на DEBIAN 9.5, Proxmox и openmediavault 4.x. но выбивает ошибку:

dpkg -i openmediavault_*.deb
(Чтение базы данных … на данный момент установлен 79921 файл и каталог.)
Подготовка к распаковке openmediavault_4.1.12_all.deb …
Распаковывается openmediavault (4.1.12) на замену (4.1.12) …
Настраивается пакет openmediavault (4.1.12) …
Creating users/groups ...
Updating local package archive ...
Updating service units ...
Failed to preset unit: Unit file /etc/systemd/system/openmediavault-beep-up.service is masked.
/usr/bin/deb-systemd-helper: error: systemctl preset failed on openmediavault-beep-up.service: No such file or directory
dpkg: ошибка при обработке пакета openmediavault (--install):
подпроцесс установлен сценарий post-installation возвратил код ошибки 1
Обрабатываются триггеры для rsyslog (8.24.0-1) …
При обработке следующих пакетов произошли ошибки:
openmediavault


Пока ничего не нагулил.
Failed to preset unit: Unit file /etc/systemd/system/openmediavault-beep-up.service is masked.

Попробуйте размаскировать юнит и переконфигурировать пакет:


systemctl unmask openmediavault-beep-up.service
dpkg --configure openmediavault_*.deb
Вот у меня старая машинка с 8 гигами рамы и 4х2тб сата файлопомойка. Хочется всё это привести в приличный вид. ZFS в таком конфиге неприменим. Но простенькую виртуализацию иногда надо. Как думаете, что если вывернуть матрёшку наизнанку и поставить на железо omv 5, а туда уже просто добавить proxmox 6 как пакет без всяких zfs? Вопрос скорее про зависимости и осмысленность такого конфига вцелом.
Ставьте на него proxmox без zfs, и уже на базе виртуалки или контейнера поднимайте файловый сервер

Ну, виртуалка точно смысла не имеет. Либо контейнер, либо прямо на хост из репозитория OMV поставить. Смысл вопроса в другом: технически же можно и наоборот — поставить на хост OMV, и туда уже пакетом подтянуть PVE. И там и сям в основе debian. Вопрос что менее криво? Допускаю, что даже некий третий вариант: minimal netinstall debian и потом и то и другое из пакетов накатить. Может так даже лучше зависимости разрулятся. Тогда вопрос, что ставить первым?

Sign up to leave a comment.

Articles