vielleicht mal mit einem hostnamen anstatt einer ipv6 addresse versuchen (entweder ins DNS eintragen, oder (wahrscheinlich robuster) in die /etc/hosts)?
ZFS over iSCSI - Fehler
- Thread starter Haithabu84
- Start date
Standard
Code:
-rw------- 1 root www-data 1675 Jan 13 15:00 10.1.1.100_id_rsa
-rw------- 1 root www-data 396 Jan 13 15:00 10.1.1.100_id_rsa.pub
Hier ist meine Deutsch Dokumentation zum Thema: https://deepdoc.at/dokuwiki/doku.ph...ox_debian_als_zfs-over-iscsi_server_verwenden
Hi, mir ist gerade aufgefallen, dass bei mir im System die block devices sowie die luns, die automatisch vom Proxmox iscsi initiator node angelegt werden, nach dem neustart des target iscsi Servers einfach verschwunden sind.
Kann es sein, dass die proxmox cli den save Befehl beim Anlegen des block sowie der luns nicht ausführt?
Kannst du das bei dir bestätigen?
Kann es sein, dass die proxmox cli den save Befehl beim Anlegen des block sowie der luns nicht ausführt?
Kannst du das bei dir bestätigen?
Kannst mir bitte Schritt für Schritt schreiben was ich tun soll damit ich das hier reproduzieren kann?
Hi, hab den Fehler schon gefunden. Liegt daran, dass mein storage server etwas länger braucht um die zfs devices zu laden (da ziemlich viel drauf ist) und deshalb beim start des rtslib-fb-targetctl.service diese noch nicht verfügbar sind.
Ein restart des Service, nachdem der Server hochgefahren und die devices verfügbar sind, löst das Problem.
Somit benötige ich irgendwie ein delay, welches auf die devices von zfs wartet.
Das dumme daran ist ja, wenn du dann "targetcli" ausführst, steht nichts in der config, und ein "exit" überschreibt die korrekte config und somit ist alles futsch.
Hier der Englische Post:
https://forum.proxmox.com/threads/iscsi-lio-targetcli-no-config-after-reboot.52966/
Ein restart des Service, nachdem der Server hochgefahren und die devices verfügbar sind, löst das Problem.
Code:
service rtslib-fb-targetctl restartSomit benötige ich irgendwie ein delay, welches auf die devices von zfs wartet.
Das dumme daran ist ja, wenn du dann "targetcli" ausführst, steht nichts in der config, und ein "exit" überschreibt die korrekte config und somit ist alles futsch.
Hier der Englische Post:
https://forum.proxmox.com/threads/iscsi-lio-targetcli-no-config-after-reboot.52966/
Das ist blöd. Als unschönen fix könnest du das ganze einfach in die rc.local packen, so mach ich das auch... oder du schreibst ein schönes File für systemd
Vorher das Scsiservice vom Autostart raus nehmen.
Code:
cat /etc/rc.local
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
sleep 20
systemctl start dein.service
exit0
Code:
systemctl edit --full deinserviceIst doch egal, hab einfach einen systemdstarter geschrieben. Wird die nächsten 2 Jahre auch noch gehen
Hallo zusammen!
Das Tutorial hat bei mir bisher prima funktioniert. Ich konnte damit zwei Storages teilen, einmal ein einfach zfs auf eine Einzelnen Platte und ein zfs mirror auf zwei platten, die all auf dem node "pve0" liegen. Seit kurzem habe ich nun aber Probleme und ich kann keine neuen VM disks mehr anlegen. Zwar wird die neue VM disk erstellt (sie ist sowohl lokal als auch auf allen anderen nodes sichtbar) aber die Erstellung (zB auf node "pve2" für VM "105") schlägt am Ende fehl mit der Meldung failed to update VM 105: Could not open /dev/local-zfs/vm-105-disk-0 (500)
auf dem host (pve0) findet sich unter /dev kein "local-zfs", sondern lediglich unter /dev/zvol/local-zfs.
Wenn ich nun manuell einen Symlink unter /dev /auf /dev/zvol erstelle, funktioniert die disk Erstellung.
Hat sich da mit den Updates ein Bug eingeschlichen, oder müsste ggf. nur das Tutorial ergänzt werden?
Das Tutorial hat bei mir bisher prima funktioniert. Ich konnte damit zwei Storages teilen, einmal ein einfach zfs auf eine Einzelnen Platte und ein zfs mirror auf zwei platten, die all auf dem node "pve0" liegen. Seit kurzem habe ich nun aber Probleme und ich kann keine neuen VM disks mehr anlegen. Zwar wird die neue VM disk erstellt (sie ist sowohl lokal als auch auf allen anderen nodes sichtbar) aber die Erstellung (zB auf node "pve2" für VM "105") schlägt am Ende fehl mit der Meldung failed to update VM 105: Could not open /dev/local-zfs/vm-105-disk-0 (500)
auf dem host (pve0) findet sich unter /dev kein "local-zfs", sondern lediglich unter /dev/zvol/local-zfs.
Wenn ich nun manuell einen Symlink unter /dev /auf /dev/zvol erstelle, funktioniert die disk Erstellung.
Hat sich da mit den Updates ein Bug eingeschlichen, oder müsste ggf. nur das Tutorial ergänzt werden?
Last edited:
Ich habe mein Tutorial und auch andere gerade mal durch getestet. Du hast Recht. Ich habe exakt das selbe Verhalten.
Danke für dein Feedback! Leider ist es mit den letzten Updates sogar noch schlechter geworden. Es funktioniert jetzt auch mit manuellem Eingriff bei mir nicht mehr. (Anm.: das gilt auch für eine reguläre HDD Freigabe via targetcli!) Ich habe leider den Fehler nicht zur Hand, konnte aber aber auf die Hosts zurückführen. Ich habe mir jetzt auf die Schnelle damit geholfen, eine kleine VM (mit OMV) aufzusetzen, die Festplatten dort physisch anzubinden und dort die iscsi targets einzurichten. Damit kann ich jetzt den Storage via iscsi (ggf mit iothread) im Cluster einbinden. (Nicht zfs over iscsi). Einen kleinen Vorteil hat dieser umständliche Weg auch: ich kann so die Platte(n) z.B. an pbs anbinden und dort den datastore als zfs konfigurieren.
Last edited:
Hab's mit PVE7 und PVE5 getestet. Gleicher Fehler. Nehme mal an deine Tragetcli läuft auch auf aktuellem Debian?
Auf einem der pve Hosts. Hat bis vor kurzem auch funktioniert. Seit einigen Wochen nicht mehr.
Getestet wurde:
PVE5, PVE7, PVE8 als Client --> Wenn Debian 12/PVE8 als Targetcli = keine Funktion
Getestet wurde bis Kernel 6.2 am Targetcli Server
PVE5, PVE7 als Targetcli Server --> funktioniert alles wie gehabt.
Ubuntu 24.04 LTS als Targetcli Server --> keine Funktion
Clientversion spielt in keinem Fall wirklich eine Rolle. Proxmox als Client funktioniert, sofern das Targetcli/ZFS Backend das tut was es soll ganz normal.
PVE5, PVE7, PVE8 als Client --> Wenn Debian 12/PVE8 als Targetcli = keine Funktion
Getestet wurde bis Kernel 6.2 am Targetcli Server
PVE5, PVE7 als Targetcli Server --> funktioniert alles wie gehabt.
Ubuntu 24.04 LTS als Targetcli Server --> keine Funktion
Clientversion spielt in keinem Fall wirklich eine Rolle. Proxmox als Client funktioniert, sofern das Targetcli/ZFS Backend das tut was es soll ganz normal.
Es scheint also ein Problem mit targetcli (mglw. auch tgtd) auf den neuesten Kerneln zu sein?Getestet wurde:
PVE5, PVE7, PVE8 als Client --> Wenn Debian 12/PVE8 als Targetcli = keine Funktion
Getestet wurde bis Kernel 6.2 am Targetcli Server
PVE5, PVE7 als Targetcli Server --> funktioniert alles wie gehabt.
Ubuntu 24.04 LTS als Targetcli Server --> keine Funktion
Clientversion spielt in keinem Fall wirklich eine Rolle. Proxmox als Client funktioniert, sofern das Targetcli/ZFS Backend das tut was es soll ganz normal.
Naja du schreibst for einigen Wochen ging es noch... mit Kernel 6.2 hab ich's getestet. Funktionierte auch nicht. Wahrscheinlich ein richtig blödes Zusammenspiel... vielleicht ja jemand bei Debian und Ubuntu einen Bugbericht erstellen.
Es ging, solange ich den symlink manuell erstellt hatte. Das war der erste „Fehler“.
Damit konnte man das wieder zum Laufen bekommen. Jetzt geht auch das nicht mehr. Insofern sind es eigentlich 2 Probleme, die nacheinander aufgetreten sind.