У меня та же проблема. Кто-нибудь решил это?

Привет, HuHu, спасибо большое, ты направил меня на правильный путь! У меня получилось: в файле /usr/share/perl5/PVE/API2/Ceph.pm я добавил строку после строки номер 205: Код: 205: $devname =~ s|/dev/||; 206: $devname =~ s|cciss/|cciss!|; #<-- новая строка потому что в данном случае имя устройства должно быть "cciss!c0dx", а не "cciss/c0dx". После изменения этого файла я смог создать OSD по командной строке (не через интерфейс). С наилучшими пожеланиями.

После нескольких тестов я наткнулся на непонятную ситуацию в /usr/share/perl5/PVE/CephTools.pm, строка 240 [PERL] dir_glob_foreach('/sys/block', '.*', sub { [/PERL] Проверка в /sys/block и я не вижу никакой информации о будущем OSD-устройстве /dev/xxx. Так что совершенно очевидно, что команда pveceph createosd /dev/xxx не работает, потому что [PERL] my $diskinfo = $disklist->{$devname}; die "не удалось получить информацию об устройстве '$devname'\n" [/PERL] в /usr/share/perl5/PVE/API2/Ceph.pm, строка (207) возвращает пустой $disklist. На данный момент у меня нет представления, в чем может быть проблема. Это задача для специалиста по PVE-PERL.

Сегодня у меня была такая же проблема с PVE 3.3, и это тоже помогло мне на RAID-контроллерах HP P400. Может быть, вместо того, чтобы жестко задавать ограничения, стоит добавить таблицу конфигураций с выражениями устройств, которые известны по умолчанию, и задокументировать возможные проблемы с различным оборудованием.

pveceph разработан для работы с локальными дисками, и, думаю, нет смысла запускать его через iscsi.

Это также не имеет для меня смысла (требует слишком много памяти).

Dietmar, это определенно не решения, относящиеся к разработке Proxmox, а пользователей. Существует множество сценариев использования, которые требуют других, кроме как сырых, прямых SATA/SAS устройств! В том числе и наш. Мы планируем построить крупный кластер, и если мы не сможем использовать разделы, это будет означать потерю *половины* всех отсеков для просто Proxmox OS! Не очень разумно. Мы используем узлы Dell Cloud в конфигурации 3 узла/2U. Это 4 диска на узел с 2 процессорами, всего 12 дисков в корпусе. Нет возможности установить 2xSSD внутри шасси, а USB-накопители ненадежны. Это значит, что мы создаем RAID10 массив из 4x80G разделов на дисках, а все пространство, которое мы хотим использовать для Ceph, - это разделы. Мы также добавим выделенные узлы хранения, но на начальном этапе нам нужно просто использовать то, что у нас уже есть. Мы планировали начать с 30 узлов... Это будет 120x3TB SATA дисков. Тратить половину отсеков для создания RAID1 только для ОС и, возможно, журналирования, абсолютно не имеет финансового смысла, каждый отсек и порт SATA/SAS очень ценны. Теперь я остаюсь с вопросом, насколько это будет проблематично управлять без использования инструментов pveceph для создания OSD (что еще делает pveceph, что он сохраняет и т.д.) и какие проблемы это вызовет. Мне удалось активировать 4 OSD из разделов, используя привычные инструменты Ceph, но теперь я сталкиваюсь с тайм-аутами и прочими проблемами в интерфейсе Proxmox при попытке управлять всем этим...

Да, обычные инструменты ceph, похоже, работают, но я не знаю, что еще делает pveceph, так что не понимаю, будет ли это работать на практике. Честно говоря, это нужно сделать как-то, неважно как. Если это невозможно, то это остановит весь процесс. Но мы еще не на том этапе, чтобы развертывание ceph было практичным, нужно сначала закупить больше оборудования (коммутаторы 10G и т.д.). Также меня беспокоит, действительно ли нам нужно устанавливать полный proxmox только на узлы хранения? Это много лишнего кода, который увеличивает потенциальную уязвимость для хакеров. Я также еще не разобрался, поддерживают ли инструменты pveceph jerasure + кэширование, так что для них тоже может понадобиться использовать стандартные инструменты ceph. В общем, есть вероятность, что pveceph вреден для всего proxmox.