# Linux - Proxmox # Proxmox VE 9 auf verschlüsseltem Debian 13 mit Dropbear-Remote-Unlock installieren Diese Anleitung beschreibt die Installation von Proxmox VE 9 auf einem bereits installierten Debian 13 System mit verschlüsseltem Root-Dateisystem via LUKS. Das System wird vor dem Boot per `dropbear-initramfs` über SSH entsperrt. Zusätzlich wird ein zweiter verschlüsselter lokaler Storage für VM-Disks und ISO-Dateien eingerichtet. **Ausgangslage in diesem Beispiel:**

- Debian 13 Trixie ist bereits installiert. - Root liegt auf LUKS + LVM. - `/boot` und `/boot/efi` sind unverschlüsselt. - `dropbear-initramfs` funktioniert bereits. - Der Server wird als `root` administriert. - Hostname: `byte-me` - Management-IP: `10.100.3.13`

--- ## 1. Bestehende Partitionierung prüfen ``` lsblk df -h uname -r ``` Beispielhafte Zielstruktur für das Systemlaufwerk: ``` nvme0n1 ├─nvme0n1p1 /boot/efi ├─nvme0n1p2 /boot └─nvme0n1p3 crypto_LUKS └─nvme0n1p3_crypt ├─broken--vg-root / └─broken--vg-swap_1 [SWAP] ``` **Wichtig:** `/boot` ist bei verschlüsselten Debian-Installationen oft klein. Proxmox-Kernel und Initramfs-Dateien können sehr groß werden. Vor der Installation sollte ausreichend Platz geschaffen werden. --- ## 2. Alten Debian-Kernel bereinigen Aktuell laufenden Kernel prüfen: ``` uname -r ``` Installierte Kerneldateien prüfen: ``` ls -lh /boot dpkg -l 'linux-image*' 'linux-headers*' | awk '/^ii|^rc/ {print $1, $2, $3}' ``` Wenn mehrere alte Kernel vorhanden sind, zuerst in den neuesten Debian-Kernel booten und danach alte Kernel entfernen. Beispiel: ``` apt purge linux-image-6.12.85+deb13-amd64 apt autoremove update-grub df -h /boot ``` Falls das Paket anders heißt, den Besitzer der Kerneldatei ermitteln: ``` dpkg -S /boot/vmlinuz-6.12.85+deb13-amd64 ``` Dann das exakt passende Paket entfernen, zum Beispiel: ``` apt purge linux-image-6.12.85+deb13-amd64-unsigned ``` --- ## 3. Proxmox Repository einrichten Benötigte Werkzeuge installieren: ``` apt install -y wget ca-certificates ``` Proxmox-Keyring für Debian 13 / Trixie herunterladen: ``` wget https://enterprise.proxmox.com/debian/proxmox-archive-keyring-trixie.gpg -O /usr/share/keyrings/proxmox-archive-keyring.gpg ``` Hash prüfen: ``` sha256sum /usr/share/keyrings/proxmox-archive-keyring.gpg ``` Erwarteter Hash: ``` 136673be77aba35dcce385b28737689ad64fd785a797e57897589aed08db6e45 /usr/share/keyrings/proxmox-archive-keyring.gpg ``` Repository-Datei anlegen: ``` cat > /etc/apt/sources.list.d/proxmox.sources <<'EOF' Types: deb URIs: http://download.proxmox.com/debian/pve Suites: trixie Components: pve-no-subscription Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg EOF ``` Paketlisten aktualisieren: ``` apt update ``` --- ## 4. Proxmox-Kernel installieren Zuerst nur den Proxmox-Kernel installieren, noch nicht das komplette Proxmox-Paket: ``` apt install proxmox-default-kernel ``` Danach GRUB prüfen: ``` update-grub ``` Erwartet wird ein Eintrag ähnlich zu: ``` Found linux image: /boot/vmlinuz-7.0.2-2-pve Found initrd image: /boot/initrd.img-7.0.2-2-pve ``` --- ## 5. Initramfs-Größe bei kleinem /boot reduzieren Bei kleinem `/boot` kann der Proxmox-Initramfs zu groß werden. In diesem Setup wurde die Kompression von `zstd` auf `xz` geändert. Datei öffnen: ``` nano /etc/initramfs-tools/initramfs.conf ``` Diese Zeile ändern: ``` COMPRESS=zstd ``` zu: ``` COMPRESS=xz ``` `MODULES=most` wurde bewusst beibehalten, damit Netzwerk- und Storage-Treiber für Dropbear/LUKS möglichst robust im Initramfs enthalten bleiben. Proxmox-Initramfs neu bauen: ``` update-initramfs -c -k 7.0.2-2-pve ``` Prüfen: ``` df -h /boot ls -lh /boot/initrd.img-7.0.2-2-pve ``` --- ## 6. In den Proxmox-Kernel booten ``` reboot ``` Nach dem Reboot wie gewohnt per Dropbear entsperren. Danach prüfen: ``` uname -r ``` Erwartet: ``` 7.0.2-2-pve ``` --- ## 7. Debian-Kernel entfernen Nachdem der Proxmox-Kernel erfolgreich gebootet wurde, können die Debian-Kernel entfernt werden. Das schafft Platz in `/boot` und verhindert spätere Initramfs-Probleme. Paketnamen ermitteln: ``` dpkg -S /boot/vmlinuz-6.12.86+deb13-amd64 ``` Falls Debian-Headers den Kernel wieder installieren wollen, Kernel und Headers zusammen entfernen: ``` apt purge linux-image-6.12.86+deb13-amd64-unsigned linux-headers-6.12.86+deb13-amd64 linux-headers-6.12.86+deb13-common linux-headers-amd64 ``` Danach Proxmox-Initramfs erneut bauen: ``` update-initramfs -c -k 7.0.2-2-pve update-grub df -h /boot ``` --- ## 8. ZFS-DKMS entfernen und Proxmox-ZFS verwenden Falls Debian-ZFS bereits installiert war, insbesondere `zfs-dkms`, sollte `zfs-dkms` entfernt werden. Proxmox nutzt eigene Kernel und passende ZFS-Pakete. ZFS-Pakete prüfen: ``` dpkg -l 'zfs*' 'spl*' | awk '/^ii|^rc/ {print $1, $2, $3}' ``` `zfs-dkms` entfernen: ``` apt purge zfs-dkms ``` Falls dabei `zfsutils-linux` und `zfs-zed` entfernt wurden, diese aus dem Proxmox-Repository wieder installieren: ``` apt install zfsutils-linux zfs-zed ``` Prüfen: ``` dpkg -l 'zfs*' 'proxmox*' 'pve*' | awk '/^ii|^rc/ {print $1, $2, $3}' ``` Gewünscht: ``` ii proxmox-default-kernel ... ii proxmox-kernel-7.0 ... ii pve-firmware ... ii zfs-zed ... ii zfsutils-linux ... ``` Nicht gewünscht: ``` ii zfs-dkms ... ``` --- ## 9. Proxmox VE installieren ``` apt install proxmox-ve postfix open-iscsi chrony ``` Bei der Postfix-Abfrage kann für einen normalen Proxmox-Host gewählt werden: ``` Local only ``` Entfernungen während der Installation sind normal: - `exim4-*` wird durch `postfix` ersetzt. - `ifupdown` wird durch `ifupdown2` ersetzt. - `systemd-timesyncd` wird durch `chrony` ersetzt. --- ## 10. Hostname-Auflösung für Proxmox korrigieren Proxmox benötigt, dass der Hostname auf eine echte Nicht-Loopback-IP zeigt. Wenn `pve-cluster` nicht startet und im Journal steht: ``` Unable to resolve node name 'byte-me' to a non-loopback IP address ``` dann muss `/etc/hosts` angepasst werden. Datei öffnen: ``` nano /etc/hosts ``` Beispiel: ``` 127.0.0.1 localhost 10.100.3.13 byte-me.localdomain byte-me # The following lines are desirable for IPv6 capable hosts ::1 localhost ip6-localhost ip6-loopback ff02::1 ip6-allnodes ff02::2 ip6-allrouters ``` **Wichtig:** Der Hostname `byte-me` darf nicht auf `127.0.0.1` oder `127.0.1.1` zeigen. Prüfen: ``` hostname hostname -f getent hosts byte-me ``` Erwartung: ``` byte-me byte-me.localdomain 10.100.3.13 byte-me.localdomain byte-me ``` Proxmox-Dienste neu starten: ``` systemctl reset-failed pve-cluster systemctl restart pve-cluster systemctl restart pvedaemon pveproxy pvestatd ``` Status prüfen: ``` systemctl status pve-cluster pvedaemon pveproxy pvestatd --no-pager ``` Erwartung: ``` pve-cluster active pvedaemon active pveproxy active pvestatd active ``` Weboberfläche: ``` https://10.100.3.13:8006/ ``` --- # Verschlüsselten lokalen VM-Storage einrichten Zusätzlich wurde eine zweite NVMe als verschlüsselter Storage für VMs und ISO-Dateien eingerichtet. In diesem Beispiel: ``` /dev/nvme1n1 ``` **Achtung:** Die folgenden Schritte löschen die Zielplatte. Nicht auf dem Systemlaufwerk ausführen. --- ## 11. Zielplatte prüfen ``` lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS,MODEL wipefs -n /dev/nvme1n1 ``` Beispiel: ``` nvme1n1 953,9G disk SKHynix_HFS001TEJ9X162N ``` --- ## 12. Partition erstellen ``` fdisk /dev/nvme1n1 ``` In `fdisk`: ``` g n 1 y w ``` Danach prüfen: ``` lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS,MODEL /dev/nvme1n1 ``` Erwartung: ``` nvme1n1 953,9G disk └─nvme1n1p1 953,9G part ``` --- ## 13. LUKS2 sicher formatieren ``` cryptsetup luksFormat \ --type luks2 \ --label crypt-vmstore \ --cipher aes-xts-plain64 \ --key-size 512 \ --hash sha512 \ --pbkdf argon2id \ --iter-time 5000 \ --verify-passphrase \ /dev/nvme1n1p1 ``` Eine lange Passphrase verwenden. Keine kurzen Passwörter, keine Projektnamen, keine Tastaturmuster. --- ## 14. LUKS öffnen In diesem Beispiel wurde der Mapper `exploding_disk` genannt. ``` cryptsetup open /dev/nvme1n1p1 exploding_disk ``` Prüfen: ``` lsblk /dev/nvme1n1p1 ``` Erwartung: ``` nvme1n1p1 └─exploding_disk ``` --- ## 15. LUKS-Header sichern Ein LUKS-Header-Backup ist wichtig. Wenn der Header beschädigt wird, sind die Daten sonst praktisch verloren. ``` mkdir -p /root/luks-header-backups chmod 700 /root/luks-header-backups cryptsetup luksHeaderBackup /dev/nvme1n1p1 \ --header-backup-file /root/luks-header-backups/nvme1n1p1-crypt-vmstore-header.img chmod 400 /root/luks-header-backups/nvme1n1p1-crypt-vmstore-header.img ``` Dieses Header-Backup sollte zusätzlich extern und sicher verschlüsselt gesichert werden. Ohne passenden Header und ohne Passphrase sind die Daten nicht wiederherstellbar. --- ## 16. LVM auf dem entschlüsselten Device erstellen ``` pvcreate /dev/mapper/exploding_disk vgcreate vg_vmstore /dev/mapper/exploding_disk ``` Prüfen: ``` vgs pvs ``` Erwartung: ``` VG VSize VFree vg_vmstore 953,85g 953,85g ``` --- ## 17. LVM-thin für VM-Disks erstellen ``` lvcreate -L 850G -T vg_vmstore/vmdata ``` Prüfen: ``` lvs ``` Beispiel: ``` LV VG Attr LSize vmdata vg_vmstore twi-a-tz-- 850,00g ``` --- ## 18. ISO-Storage erstellen ``` lvcreate -L 60G -n iso vg_vmstore mkfs.ext4 -L pve-iso /dev/vg_vmstore/iso mkdir -p /mnt/pve/iso-store ``` UUID anzeigen: ``` blkid /dev/vg_vmstore/iso ``` Beispiel: ``` /dev/vg_vmstore/iso: LABEL="pve-iso" UUID="0f1496f7-d7ad-4e97-9243-cff799d44e5e" BLOCK_SIZE="4096" TYPE="ext4" ``` --- ## 19. ISO-Storage in /etc/fstab eintragen ``` nano /etc/fstab ``` Eintrag ergänzen: ``` UUID=0f1496f7-d7ad-4e97-9243-cff799d44e5e /mnt/pve/iso-store ext4 defaults,noatime 0 2 ``` Systemd neu laden und Mount testen: ``` systemctl daemon-reload mount -a df -h /mnt/pve/iso-store ``` --- ## 20. Storage in Proxmox eintragen LVM-thin für VM- und Container-Disks: ``` pvesm add lvmthin vmstore \ --vgname vg_vmstore \ --thinpool vmdata \ --content images,rootdir ``` Directory-Storage für ISOs und Container-Templates: ``` pvesm add dir iso-store \ --path /mnt/pve/iso-store \ --content iso,vztmpl ``` Status prüfen: ``` pvesm status ``` Beispiel: ``` Name Type Status Total (KiB) Used (KiB) Available (KiB) % iso-store dir active 61611820 2084 58447624 0.00% local dir active 477545328 154494456 298719404 32.35% vmstore lvmthin active 891289600 0 891289600 0.00% ``` --- # Optional: Automatisches Entsperren des zweiten LUKS-Storage Ein Keyfile auf dem verschlüsselten Root-Dateisystem ist komfortabel, reduziert aber die Trennung der Sicherheitsstufen. Ohne Keyfile braucht ein Angreifer bei Diebstahl beider Platten Root-Passphrase und Storage-Passphrase. Mit Keyfile reicht die Root-Passphrase, weil danach das Keyfile verfügbar ist. ## Variante A: Maximale Trennung Kein Keyfile verwenden. Nach jedem Boot manuell entsperren: ``` cryptsetup open /dev/nvme1n1p1 exploding_disk vgchange -ay vg_vmstore mount -a ``` VM-Autostart für VMs auf diesem Storage sollte dann deaktiviert werden, weil der Storage nach dem Boot zunächst fehlt. ## Variante B: Komfortabler Auto-Unlock nach Root-Unlock Keyfile auf verschlüsseltem Root-Dateisystem erstellen: ``` mkdir -p /root/luks-keys chmod 700 /root/luks-keys dd if=/dev/random of=/root/luks-keys/exploding_disk.key bs=64 count=1 chmod 400 /root/luks-keys/exploding_disk.key ``` Keyfile zu LUKS hinzufügen: ``` cryptsetup luksAddKey /dev/nvme1n1p1 /root/luks-keys/exploding_disk.key ``` LUKS-UUID anzeigen: ``` blkid /dev/nvme1n1p1 ``` `/etc/crypttab` bearbeiten: ``` nano /etc/crypttab ``` Eintrag ergänzen: ``` exploding_disk UUID=DEINE-LUKS-UUID-HIER /root/luks-keys/exploding_disk.key luks ``` Systemd neu laden: ``` systemctl daemon-reload ``` --- # Ceph-Zukunftsplanung Für später geplante drei Proxmox-Nodes mit Ceph gilt: - Die aktuell lokal genutzte NVMe muss später für Ceph gelöscht werden. - VMs müssen vorher vom lokalen Storage auf Ceph migriert werden. - Ceph-OSDs sollten später direkt über Proxmox/Ceph mit Encryption erstellt werden. - Nicht vorher manuell LUKS + LVM bauen und dann Ceph darüberlegen. Geplanter späterer Ablauf: ``` 1. PVE 2 und PVE 3 installieren 2. Cluster erstellen 3. Dediziertes 10G-Netz für Ceph konfigurieren 4. Ceph installieren 5. Auf allen Nodes freie NVMe als verschlüsselte Ceph-OSD einrichten 6. Ceph-Pool erstellen 7. VM-Storage auf Ceph RBD anlegen 8. VMs vom lokalen vmstore auf Ceph migrieren 9. Lokalen LUKS/LVM-Storage auf nvme1n1 entfernen 10. nvme1n1 als Ceph-OSD neu verwenden ``` Mit nur einem Node ist Ceph nicht sinnvoll redundant. Für produktive Ceph-Nutzung sollten mindestens drei Proxmox-Nodes vorhanden sein. --- # Wichtige Checks nach der Einrichtung ``` dpkg --audit df -h /boot uname -r pvesm status lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS vgs lvs systemctl status pve-cluster pvedaemon pveproxy pvestatd --no-pager ``` Erwartung: ``` Kernel: 7.0.2-2-pve /boot nicht voll pve-cluster active pvedaemon active pveproxy active pvestatd active vmstore active iso-store active ``` --- # Zusammenfassung - Debian 13 mit LUKS-Root und Dropbear-Remote-Unlock wurde als Basis verwendet. - Proxmox VE 9 wurde auf Debian installiert. - Der Proxmox-Kernel wurde zuerst einzeln installiert und getestet. - `/boot`-Probleme wurden durch Entfernen alter Debian-Kernel und `COMPRESS=xz` behoben. - `zfs-dkms` wurde entfernt und Proxmox-ZFS verwendet. - Hostname-Auflösung wurde für `pve-cluster` korrigiert. - Eine zweite NVMe wurde mit LUKS2 verschlüsselt. - Darauf wurde LVM-thin für VM-Disks eingerichtet. - Ein ext4-LV wurde als ISO-/Template-Storage eingebunden. - Späterer Ceph-Betrieb ist möglich, erfordert aber Migration und Neuanlage der Disk als Ceph-OSD. # Neue Seite # Proxmox iSCSI SAN mit tgt und LVM Diese Dokumentation beschreibt die bisher eingerichtete iSCSI-SAN-Konfiguration mit **tgt** auf der SAN-Seite und dem ersten Proxmox-Node **pve\_1**. --- ## 1. Ziel der Konfiguration Es wurde ein iSCSI-Target auf der SAN-Seite bereitgestellt und auf dem ersten Proxmox-Node als Shared-LVM-Storage eingebunden. Der Aufbau ist: ``` tgt SAN └─ iSCSI Target: iqn.2026-02-25.linux.proxmox.pve:cleopatra └─ LUN: /dev/mapper/cleopatra └─ pve_1 sieht LUN als /dev/sda └─ /dev/sda1 als LVM Physical Volume └─ VG: vg_vmstore └─ Proxmox Storage: lvm-cleopatra ``` --- ## 2. Namensschema

Objekt	Name	Beschreibung
SAN-Host	`big-bunda`	Server mit `tgt` als iSCSI-Target-Dienst
Erster Proxmox-Node	`pve_1` / `byte-me`	Erster Proxmox-VE-Node, der das iSCSI-LUN nutzt
iSCSI Portal	`10.99.255.1:3260`	IP-Adresse und Port des iSCSI-Targets
iSCSI Target IQN	`iqn.2026-02-25.linux.proxmox.pve:cleopatra`	Eindeutiger iSCSI-Targetname für den Storage Cleopatra
tgt Backing Store	`/dev/mapper/cleopatra`	Blockdevice, das vom tgt-Target als LUN exportiert wird
Proxmox iSCSI Storage-ID	`iscsi-cleopatra`	Proxmox-Eintrag für die reine iSCSI-Verbindung
LVM Volume Group	`vg_vmstore`	LVM-VG auf der iSCSI-LUN
Proxmox LVM Storage-ID	`lvm-cleopatra`	Nutzbarer VM-Storage in Proxmox

--- ## 3. Wichtige Entscheidung: Warum zwei Proxmox-Storage-Einträge? In Proxmox gibt es zwei Einträge, weil iSCSI und LVM zwei verschiedene Schichten sind. ``` iscsi-cleopatra = Verbindung zum iSCSI-Target lvm-cleopatra = eigentlicher VM-Storage auf der LVM Volume Group ``` Der iSCSI-Eintrag selbst hat `content none`, weil Proxmox dort keine VM-Disks direkt ablegt. Die eigentlichen VM-Disks werden später auf `lvm-cleopatra` erstellt. --- ## 4. tgt SAN-Konfiguration Auf dem SAN-Host `big-bunda` wird `tgt` als iSCSI-Target-Daemon genutzt. Das exportierte Blockdevice ist: ``` /dev/mapper/cleopatra ``` Beispiel für die tgt-Konfiguration: ``` driver iscsi lun 1 device-type disk vendor_id "linux" product_id "iscsi disk" product_rev "0001" scsi_sn "cleopatra-lun1" write-cache off # zugriff nur für erlaubte proxmox-nodes initiator-address 10.99.255.X # initiator-iqn von pve_1 / byte-me # prüfen auf dem pve-node mit: # cat /etc/iscsi/initiatorname.iscsi initiator-name iqn.1993-08.org.debian:01:1ebae4d041e # mutual chap # incominguser = initiator authentifiziert sich beim target # outgoinguser = target authentifiziert sich beim initiator incominguser pve-byteme "SECRET_NICHT_IN_DOKU_EINTRAGEN" outgoinguser tgt-cleopatra "ANDERES_SECRET_NICHT_IN_DOKU_EINTRAGEN" ``` **Wichtig:** Die CHAP-Secrets dürfen nicht identisch sein. Für `incominguser` und `outgoinguser` müssen unterschiedliche Passwörter verwendet werden. Für dieses Setup wurden kurze, kompatible CHAP-Secrets verwendet, da längere Secrets im konkreten tgt/Open-iSCSI-Stack Probleme verursachen können. Empfohlen sind zufällige Secrets mit 12 bis 16 Zeichen. ``` openssl rand -hex 8 ``` --- ## 5. Proxmox pve\_1 / byte-me: iSCSI-Verbindung Auf dem ersten Proxmox-Node wurde das Target über das Portal `10.99.255.1` eingebunden. Proxmox-Storage-Eintrag: ``` iscsi: iscsi-cleopatra portal 10.99.255.1 target iqn.2026-02-25.linux.proxmox.pve:cleopatra content none ``` Das iSCSI-LUN ist auf `pve_1` sichtbar als: ``` /dev/sda ``` Der stabile Gerätepfad lautet: ``` /dev/disk/by-path/ip-10.99.255.1:3260-iscsi-iqn.2026-02-25.linux.proxmox.pve:cleopatra-lun-1 ``` --- ## 6. Entfernen des alten VMFS-Datastores Auf dem iSCSI-LUN befand sich vorher ein VMware VMFS6-Dateisystem. Dieses wurde entfernt, da die Daten nicht mehr benötigt wurden. Vorheriger Zustand: ``` sda └─sda1 VMFS_volume_member 6 ``` Verwendete Befehle: ``` lun="/dev/disk/by-path/ip-10.99.255.1:3260-iscsi-iqn.2026-02-25.linux.proxmox.pve:cleopatra-lun-1" findmnt "$lun" findmnt "${lun}-part1" wipefs -a "${lun}-part1" wipefs -a "$lun" partprobe "$lun" udevadm settle ``` **Achtung:** Diese Befehle löschen Dateisystem- und Partitionssignaturen. Sie dürfen nur verwendet werden, wenn die Daten auf der LUN wirklich gelöscht werden dürfen. --- ## 7. Neue GPT-Partition für LVM Nach dem Entfernen der VMFS-Signaturen wurde eine neue GPT-Partitionstabelle mit einer LVM-Partition erstellt. ``` parted -s "$lun" mklabel gpt parted -s "$lun" mkpart primary 1MiB 100% parted -s "$lun" set 1 lvm on partprobe "$lun" udevadm settle ``` Danach war die LUN sauber vorbereitet: ``` NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS sda └─sda1 ``` --- ## 8. LVM auf iSCSI erstellen Auf der neuen Partition wurde ein LVM Physical Volume und danach eine Volume Group erstellt. ``` pvcreate "${lun}-part1" vgcreate vg_vmstore "${lun}-part1" ``` Ergebnis: ``` PV VG Fmt Attr PSize PFree /dev/sda1 vg_vmstore lvm2 a-- <6,99t <6,99t VG #PV #LV #SN Attr VSize VFree vg_vmstore 1 0 0 wz--n- <6,99t <6,99t ``` **Wichtig für weitere Nodes:** `pvcreate` und `vgcreate` wurden nur einmal auf `pve_1` ausgeführt. Auf weiteren Proxmox-Nodes darf das nicht erneut ausgeführt werden. Weitere Nodes sollen die bestehende VG nur erkennen. --- ## 9. Proxmox LVM Storage Der Proxmox-LVM-Storage wurde als shared Storage angelegt. ``` pvesm add lvm lvm-cleopatra \ --vgname vg_vmstore \ --content images,rootdir \ --shared 1 ``` Finaler Proxmox-Storage-Eintrag: ``` lvm: lvm-cleopatra vgname vg_vmstore content images,rootdir shared 1 ``` Damit ist `lvm-cleopatra` der nutzbare Storage für VM-Disks und Container-Rootdisks. --- ## 10. Aktueller Proxmox-Status Aktueller Status auf `pve_1`: ``` Name Type Status Total (KiB) Used (KiB) Available (KiB) % iscsi-cleopatra iscsi active 0 0 0 0.00% lvm-cleopatra lvm active 7503060992 0 7503060992 0.00% ``` Dass `iscsi-cleopatra` eine Größe von `0` zeigt, ist normal. Dieser Eintrag ist nur die Verbindung zum iSCSI-Target. Die nutzbare Kapazität wird bei `lvm-cleopatra` angezeigt. --- ## 11. Finaler Aufbau in Proxmox ``` iscsi: iscsi-cleopatra portal 10.99.255.1 target iqn.2026-02-25.linux.proxmox.pve:cleopatra content none lvm: lvm-cleopatra vgname vg_vmstore content images,rootdir shared 1 ``` --- ## 12. Hinweise für spätere Proxmox-Nodes Bei weiteren Proxmox-Nodes muss nur die iSCSI-Verbindung eingerichtet werden. Die LVM-Struktur existiert bereits. Auf jedem weiteren Node prüfen: ``` cat /etc/iscsi/initiatorname.iscsi pvesm status pvs vgs ``` Jeder Node braucht einen eigenen eindeutigen Initiator-IQN. Dieser muss auf der SAN-Seite in der tgt-Konfiguration als `initiator-name` erlaubt werden. Nicht erneut ausführen: ``` pvcreate vgcreate wipefs parted mklabel ``` Diese Befehle würden die bestehende LVM-Struktur beziehungsweise die Daten auf dem Shared Storage beschädigen. Storage verzeiht so etwas nicht, es merkt sich das nur in Form von Datenverlust. --- ## 13. Sicherheitsregeln - iSCSI nur über das dedizierte Storage-Netz betreiben. - Port `3260/tcp` nur für autorisierte Proxmox-Nodes erlauben. - Pro Node einen eigenen Initiator-IQN verwenden. - Auf dem tgt-Target sowohl `initiator-address` als auch `initiator-name` setzen. - Mutual CHAP verwenden. - `incominguser` und `outgoinguser` mit unterschiedlichen Secrets konfigurieren. - Keine echten CHAP-Secrets in BookStack dokumentieren. - Für mehrere Nodes klassisches `lvm` verwenden, nicht `lvmthin`. --- ## 14. Optionales späteres Cleanup Aktuell heißt die LVM Volume Group noch: ``` vg_vmstore ``` Für ein konsequentes Namensschema könnte sie später optional umbenannt werden: ``` vgrename vg_vmstore vg_cleopatra pvesm set lvm-cleopatra --vgname vg_cleopatra ``` Danach wäre das Schema vollständig konsistent: ``` iscsi-cleopatra lvm-cleopatra vg_cleopatra ``` Dieser Schritt ist optional. Der Storage funktioniert bereits mit `vg_vmstore`. --- ## 15. Kurzfassung ``` SAN big-bunda: Target: iqn.2026-02-25.linux.proxmox.pve:cleopatra Backing Store: /dev/mapper/cleopatra Portal: 10.99.255.1:3260 Auth: Mutual CHAP ACL: initiator-address + initiator-name Proxmox pve_1 / byte-me: iSCSI Storage: iscsi-cleopatra LVM VG: vg_vmstore Proxmox VM Storage: lvm-cleopatra Shared: ja Content: images,rootdir ``` # Proxmox - VMs von einem ausgefallenen Proxmox-Host übernehmen Wenn ein Proxmox-Host im Cluster ausgefallen bzw. offline ist, können die darauf registrierten VMs einem anderen Host zugeordnet und dort gestartet werden, sofern deren Storage weiterhin erreichbar ist. **Wichtig:** Der ausgefallene Host muss wirklich ausgeschaltet bzw. vom Cluster getrennt sein. Er darf nicht gleichzeitig wieder starten, während seine VMs bereits auf einem anderen Host laufen. Andernfalls besteht die Gefahr von gleichzeitig laufenden VMs und beschädigten Dateisystemen. **Storage beachten:** Liegen die VM-Festplatten ausschließlich auf dem lokalen Storage des ausgefallenen Hosts, können die VMs nicht einfach auf einem anderen Host gestartet werden. Die folgende Vorgehensweise setzt voraus, dass die benötigten VM-Datenträger vom Ziel-Host erreichbar sind, beispielsweise über Ceph, NFS oder anderes Shared Storage. ## VMs des ausgefallenen Hosts anzeigen Die VM-Konfigurationen des ausgefallenen Hosts befinden sich im Proxmox Cluster Filesystem und können direkt angezeigt werden: ``` ls -1 /etc/pve/nodes//qemu-server/ ``` Beispiel: ``` ls -1 /etc/pve/nodes/pve01/qemu-server/ ``` Die Ausgabe enthält die VM-Konfigurationen anhand ihrer VM-ID: ``` 101.conf 102.conf 103.conf 104.conf ``` ## Alle VMs auf einen anderen Host übernehmen Um alle VMs des ausgefallenen Hosts dem Ziel-Host zuzuordnen, werden deren Konfigurationsdateien in das Verzeichnis des Ziel-Hosts verschoben: ``` mv /etc/pve/nodes//qemu-server/*.conf /etc/pve/nodes//qemu-server/ ``` Beispiel: ``` mv /etc/pve/nodes/pve01/qemu-server/*.conf /etc/pve/nodes/pve02/qemu-server/ ``` Die VMs erscheinen anschließend in Proxmox unter dem neuen Host. Dabei werden nur die VM-Konfigurationen verschoben. Die eigentlichen VM-Datenträger bleiben auf dem vorhandenen Storage. ## Einzelne VM übernehmen Soll nur eine bestimmte VM übernommen werden, kann deren Konfigurationsdatei einzeln verschoben werden: ``` mv /etc/pve/nodes//qemu-server/.conf /etc/pve/nodes//qemu-server/ ``` Beispiel: ``` mv /etc/pve/nodes/pve01/qemu-server/101.conf /etc/pve/nodes/pve02/qemu-server/ ``` ## VMs starten Nach der Übernahme können die benötigten VMs über die Proxmox-Weboberfläche oder über die Shell gestartet werden: ``` qm start ``` Beispiel: ``` qm start 101 ``` ## Bei HA-verwalteten VMs VMs, die durch Proxmox HA verwaltet werden, sollten nicht manuell über das Cluster-Dateisystem verschoben werden. In diesem Fall übernimmt Proxmox HA die Wiederherstellung und den Neustart der VM auf einem verfügbaren Cluster-Node. ## Nach der Übernahme prüfen Vor dem Start größerer VM-Mengen sollte geprüft werden, ob Storage und Netzwerk auf dem Ziel-Host korrekt verfügbar sind. ``` qm status ``` Zusätzlich sollte kontrolliert werden, ob alle in der VM-Konfiguration verwendeten Storages auf dem Ziel-Host verfügbar sind. # Proxmox VE ohne Subscription: kostenlose Repositories nutzen und Subscription-Hinweis ausblenden # Proxmox VE 9: No-Subscription-Popup deaktivieren ## Fix Betroffene Datei: ``` /usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js ``` Datei öffnen: ``` nano /usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js ``` Mit **Strg + W** nach folgendem Text suchen: ``` checked_command: function (orig_cmd) ``` Den **vollständigen** `checked_command`-Block löschen und an exakt derselben Position durch diesen Block ersetzen. Die vorhandene Einrückung beibehalten: ``` checked_command: function (orig_cmd) { orig_cmd(); }, ``` **Wichtig:** Der komplette bisherige Inhalt der Funktion wird entfernt. Es bleibt kein alter Subscription-Code unterhalb von `orig_cmd()` stehen. Danach speichern, Nano schließen und `pveproxy` neu starten: ``` systemctl restart pveproxy ``` Anschließend die Proxmox-Weboberfläche mit **Strg + F5** neu laden. ## Quick-Befehl Wenn du die Datei nicht manuell bearbeiten willst, als `root` direkt in der Terminal-Session ausführen: ``` python3 -c ' from pathlib import Path import re, shutil p = Path("/usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js") s = p.read_text() m = re.search(r"^([ \t]*)checked_command:\s*function\s*$orig_cmd$\s*\{", s, re.M) if not m: raise SystemExit("FEHLER: checked_command wurde nicht gefunden") indent = m.group(1) start = m.start() brace = s.find("{", m.start()) depth = 0 end = None for i in range(brace, len(s)): if s[i] == "{": depth += 1 elif s[i] == "}": depth -= 1 if depth == 0: end = i + 1 break if end is None: raise SystemExit("FEHLER: Ende von checked_command wurde nicht gefunden") if end >= len(s) or s[end] != ",": raise SystemExit("FEHLER: Abschließendes Komma von checked_command wurde nicht gefunden") end += 1 replacement = ( f"{indent}checked_command: function (orig_cmd) {{\n" f"{indent} orig_cmd();\n" f"{indent}}}," ) if s[start:end] == replacement: print("Patch ist bereits sauber gesetzt") else: shutil.copy2(p, str(p) + ".bak") p.write_text(s[:start] + replacement + s[end:]) print("Patch angewendet; Backup: " + str(p) + ".bak") ' && systemctl restart pveproxy && systemctl is-active pveproxy ``` Der Befehl übernimmt die **vorhandene Einrückung** der `checked_command`-Zeile und ersetzt den vollständigen Funktionsblock. Danach steht der Block an derselben Position wie vorher und ist sauber wie folgt eingerückt: ``` checked_command: function (orig_cmd) { orig_cmd(); }, ``` Der alte Subscription-Code wird vollständig entfernt. Wenn tatsächlich eine Änderung vorgenommen wird, wird die vorherige Datei als `proxmoxlib.js.bak` gesichert. Wenn am Ende `active` ausgegeben wird, läuft `pveproxy` wieder. ## Änderung rückgängig machen ``` cp -a /usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js.bak /usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js && systemctl restart pveproxy && systemctl is-active pveproxy ``` ## Nach Updates Ein Update von `proxmox-widget-toolkit` kann `proxmoxlib.js` ersetzen. Wenn das Popup danach wieder erscheint, den Quick-Befehl erneut ausführen. Vor einem erneuten tatsächlichen Patch wird die dann aktuelle Paketversion wieder als `.bak` gesichert.