ZFS / raidz1 + proxmox6

Не совсем по теме. Но я реальное не понимаю зачем в корень ставить ZFS, это особый вид мазохизма ?

в который потом вручную добавил четвертый как spares

Это какая команда?

Но я реальное не понимаю зачем в корень ставить ZFS, это особый вид мазохизма ?

Он в proxmox по умолчанию идёт, кажется.

А в чём проблема с / на zfs? В ногу себе можно и с lvm выстрелить.

Покажи:

lsblk
zpool status -v
zfs list
pvesm status
cat /etc/pve/storage.cfg

Ставлю всегда proxmox поверх debian, он у меня так и на 2гб slc диск влезал. Ну lvm более предсказуем все же чем zfs на linux :-)

Ну lvm более предсказуем все же чем zfs на linux :-)

Ну это да.

По мазохизму с zfs ) В некотором роде - да, если точнее - в учебных целях. К сожалению, как выяснилось после начала проблем, некоторые данные, которые я внес в ВМ, оказались в единственном экземпляре - мне их вырезали вместо копирования. В принципе, они где-то еще есть, и формально - не мой вопрос, но последняя подобная попытка восстановления заняла три недели )

Для завершения офтопа - понимаю, в чем проблема: я полагал, что система отреагирует так, как я привык, т.е. создаст пул дисков (целых дисков, как и спрашивала), а потом будет разбивать полученное пространство - в моем случае, под гипервизор и под данные. Оказалось не так.

Добавление было командой zpool add rpool spare sdd

сеть он тоже не поднял

lsblk:

sda       1.8T  0  disk
|-sda1    1007K 0  part
|-sda2    512M  0  part
|-sda3    1.8T  0  part
sdb       1.8T  0  disk
|-sdb1    1007K 0  part
|-sdb2    512M  0  part
|-sdb3    1.8T  0  part
sdc       1.8T  0  disk
|-sdc1    1007K 0  part
|-sdc2    512M  0  part
|-sdc3    1.8T  0  part
zd0       1.5T  0  part
|-zd0p1   350M  0  part
|-zd0p2   195G  0  part
|-zd0p3   1.3T  0  part

zpool status -v (в принципе, как и ожидалось, пул вроде исправен, поскольку умер spares, то есть даже ребилдить нечего)

rpool                       online
  raidz1-0                  online
     ata-TOSHIBA-...-part3  online
     ata-TOSHIBA-...-part3  online
     ata_TOSHIBA-...-part3  online
  spares
     sdd                    unavail

zfs list (сейчас после выполнения zfs mount -a)

NAME                     USED   AVAIL  REFER MOUNTPOINT
rpool                    53.5G  3.47T  139K   /rpool
rpool/ROOT               4.85G  3.47T  128K   /rpool/ROOT
rpool/ROOT/pve-1         4.85G  3.47T  4.85G  /
rpool/data               48.6G  3.47T  128K   /rpool/data
rpool/data/vm-100-disk0  48.6G  3.47T  48.6G  -

pvesm status

setlogsock(): type ='unix': path not available at /usr/share/perl5/PVE/SafeSyslog.pm line 38.
ipcc_send_rec[1] failed: Connection refused
ipcc_send_rec[2] failed: Connection refused
ipcc_send_rec[3] failed: Connection refused
Unable to load access control list: Connection refused

cat /etc/pve/storage.cfg

No such file or directory

Если нету каталога /etc/pve - не поднялся corosync. Разбирайся в причине. Возможно, не поднялся corosync, так-как ему что-то не понравилось с сетью.

Ок, попробую. А вот если поставить proxpox на другой носитель и импортировать в консоли пул - сработает? Сам же пул исправный.

/etc/pve - содержит конфиг вирт. машин. Сами виртуалки без конфигов не подтянутся. Пул можно импортировать хоть с liveCD для этого не нужно ставить никакого proxmox

Сеть в итоге поднялась, некоторые сервисы запустились, ssh - вручную, но без проблем. Почти не изменился ответ на pvesm status:

ipcc_send_rec[1] failed: Connection refused
ipcc_send_rec[2] failed: Connection refused
ipcc_send_rec[3] failed: Connection refused
Unable to load access control list: Connection refused

Застрял на

root@pve:/# systemctl status corosync.service
● corosync.service - Corosync Cluster Engine
   Loaded: loaded (/lib/systemd/system/corosync.service; enabled; vendor preset: enabled)
   Active: inactive (dead)
Condition: start condition failed at Fri 2020-01-31 18:01:58 MSK; 1min 35s ago
           └─ ConditionPathExists=/etc/corosync/corosync.conf was not met
     Docs: man:corosync
           man:corosync.conf
           man:corosync_overview

Jan 31 18:01:32 pve systemd[1]: Condition check resulted in Corosync Cluster Engine being skipped.
Jan 31 18:01:32 pve systemd[1]: Condition check resulted in Corosync Cluster Engine being skipped.

Кроме того, попытка запуска root@pve:/# systemctl start pve-cluster.service пишет в лог так же об отсутствии файлов ключей

Jan 31 18:02:15 pve pveproxy[2677]: /etc/pve/local/pve-ssl.key: failed to load local private key (key_file or key) at /usr/share/perl5/PVE/API
Jan 31 18:02:15 pve pveproxy[2678]: /etc/pve/local/pve-ssl.key: failed to load local private key (key_file or key) at /usr/share/perl5/PVE/API

pvedaemon.service и pveproxy.service стартовали без ошибок.

Может, утащить откуда-нибудь конфиг для corosync и подложить ему?

Черт его знает что делать в Вашей ситуации. Я вообще не понимаю в чем проблема, если честно. Ну пропал spare диск, ну и плевать. Но, не знаю опять-же, я не использовал zfs в корне, только под данные виртуальных машин, за годы на zfs on linux я не потерял ни одного байта. Но, у меня корень proxmox всегда на lvm и mdadm. Я пользователь proxmox уже с десять лет, и не было проблем никогда у меня с ним…

..слить контейнеры виртуальных машин..

Конфиг виртуалки не вытащите пока не запустите corosync, но образ диска rpool/data/vm-100-disk0
можно средствами zfs вытащить:

zfs snapshot rpool/data/vm-100-disk0@backup
zfs send rpool/data/vm-100-disk0@backup | gzip > ..../vm-100-disk0.zfs.gz
zfs destroy rpool/data/vm-100-disk0@backup

dd if=/dev/rpool/data/vm-100-disk0 | gzip ..../vm-100-disk0.raw.img.gz

Могу только предположить причину - с какой-то долей вероятности. Когда при установке размечались диски, их было в системе все четыре. И системный раздел, и загрузочный был выделен на всех четырех. В подтверждение тому постоянные сообщения о бедах на нем, т.е. диск находился в использовании, а spare - только часть диска, несмотря на добавление целого. После того, как четвертый диск уехал из системы, некоторые файлы стали недоступны.

Хотя тоже не складывается, я четвертый диск не прописывал при установке, добавлял позже... Короче, в «книгу грабель» с невыясненной причиной... С проксмоксом у самого проблем не было, но он у меня всегда висел на аппаратном рейде.

А вот за это спасибо, можно попробовать потом помухлевать с ВМ на другом таком же гипервизоре, создав машину и подменив образ... В понедельник займусь.