Proxmox VE

ZFS over ISCSI

Quorum with an External QDevice

Having only two nodes in my Proxmox cluster, I wanted to add a third external device to keep quorum during reboots or other outages. To do so I added an external qdevice as a node which works as a voting only member of the cluster. The qdevice has to be debian based, so I set mine up on a raspberry pi.

First you’ll need to install the following packages on your external server.

sudo apt install corosync-qnetd corosync-qdevice

Once the install is complete, use this command to install a package on each of your existing Proxmox nodes.

apt install corosync-qdevice

Now you can run the following on one of your Proxmox nodes.

pvecm qdevice setup <QDEVICE-IP>

You will need to have a root password available for the setup. In my case I temporarily allowed root login with password and then reverted it back to prohibit-password after. That configuration is found in:

sudo nano /etc/ssh/sshd_config

Once you’ve run the setup command, you’ll be able to run the following to view the status and nodes.

pvecm status
pvecm nodes

For additional information, check out the documentation here.

Debian Cloud-Init

Debian Cloud-Init

Proxmox · Debian-VM-Strategie

Proxmox · Debian-VM-Strategie

abstract: Zweck Debian-13-VMs auf Proxmox reproduzierbar aus einem Cloud-Init-Template bereitstellen. Dieses Dokument beschreibt den aktuellen CORESTREAM-Standard und verweist für den ausführbaren Stand auf das zentrale OneDev-Repo.

Gültig für: Debian 13 (trixie), Proxmox VE, UEFI/OVMF, qcow2-Images

Inhaltsverzeichnis

  1. 1 · Standard und Entscheidung
  2. 2 · Skripte installieren
  3. 3 · Voraussetzungen vorbereiten
  4. 4 · Template bauen
  5. 5 · VM klonen
  6. 6 · Verifikation
  7. 7 · User und SSH-Zugriff
  8. 8 · Goldene Regeln
  9. 9 · Troubleshooting
  10. 10 · Source of Truth

1 · Standard und Entscheidung

Modus Image Einsatz
cloudinit debian-13-generic-amd64.qcow2 CORESTREAM-Standard; User, Key, Hostname und IP pro VM
bake debian-13-nocloud-amd64.qcow2 Sonderfall für bewusst fest gebackene Images

tip: Empfehlung Für neue Kunden-, Staging- und Infrastruktur-VMs immer cloudinit mit --img genericcloud verwenden.

warning: Image-Falle nocloud enthält kein Cloud-Init. Der Skriptparameter --img genericcloud verwendet im aktuellen CORESTREAM-Workflow die Datei debian-13-generic-amd64.qcow2.

2 · Skripte installieren

Auf jedem neuen Proxmox-Host als root:

curl -fsSL https://git.corestream.ch/corestream/proxmox-debian-cloudinit-scripts/~raw/master/install-on-proxmox.sh | bash

Fester Installationspfad:

Kommandos über Symlinks:

note: > Der OneDev-Raw-Zugriff ist anonym als Code Reader freigegeben. Der Installer kann deshalb ohne Token ausgeführt werden.

3 · Voraussetzungen vorbereiten

3.1 Pakete auf Proxmox

apt update
apt install -y libguestfs-tools wget curl

qemu-guest-agent wird nicht für den Proxmox-Host benötigt. Das Build-Skript installiert und verifiziert das Paket innerhalb des Debian-Images.

3.2 Storage und Debian-Image

pvesm status --enabled
mkdir -p /mnt/pve/<STORE>/import
cd /mnt/pve/<STORE>/import
wget -O debian-13-generic-amd64.qcow2 https://cloud.debian.org/images/cloud/trixie/latest/debian-13-generic-amd64.qcow2
wget -O SHA512SUMS https://cloud.debian.org/images/cloud/trixie/latest/SHA512SUMS
sha512sum -c --ignore-missing SHA512SUMS

Das Build-Skript trennt zwei Rollen:

Die VM-Disk, EFI-Disk und Cloud-Init-Disk liegen immer auf dem gewählten Zielstorage. NFS wird automatisch nicht als VM-Ziel angeboten.

3.3 Admin-Public-Key

Standardpfad:

test -s /root/.ssh/id_csgadmin.pub

Fehlt die Datei, einen vorhandenen Public-Key beim Build explizit übergeben:

build-debian-template -t 9000 -n debian13-init -m cloudinit --img genericcloud --user-key /root/.ssh/authorized_keys

warning: > Bei --user-key /root/.ssh/authorized_keys werden alle dort enthaltenen Keys in die VM übernommen. Für genau einen Admin-Key eine dedizierte Public-Key-Datei verwenden.

4 · Template bauen

Standard:

build-debian-template -t 9000 -n debian13-init -m cloudinit --img genericcloud

Mit expliziter Key-Datei:

build-debian-template -t 9000 -n debian13-init -m cloudinit --img genericcloud --user-key /pfad/admin.pub

Hermes-Zugriff nur auf ausdrücklichen Wunsch:

build-debian-template -t 9000 -n debian13-init -m cloudinit --img genericcloud --hermes --hermes-key /pfad/hermes.pub

Das Skript:

Template-Konfiguration prüfen:

qm config 9000 | grep -E 'agent|scsi1|cloudinit|ciuser|boot'

Erwartet:

important: > Template niemals booten. Immer einen Clone zum Testen verwenden.

5 · VM klonen

Test-VM mit DHCP:

clone-vm 9000 901 test-debian dhcp

VM mit statischer IPv4-Adresse:

clone-vm 9000 121 app-staging 10.10.10.121/24 10.10.10.1

Der Clone-Helper:

Für Throwaway-Tests kann bei Bedarf manuell ein Linked Clone erstellt werden. Kunden-, Staging-, Produktions- und Infrastruktur-VMs bleiben Full Clones.

6 · Verifikation

6.1 Im Gast

cloud-init status --long
id csgadmin
hostname
ip -4 a
ls -l /dev/disk/by-label/cidata
dpkg-query -W qemu-guest-agent
systemctl is-active qemu-guest-agent
sysctl net.ipv6.conf.all.disable_ipv6
cat /proc/cmdline
ip -6 addr

Erwartet:

6.2 Auf Proxmox

qm agent <VMID> ping

SSH-Test:

ssh csgadmin@<IPv4>

7 · User und SSH-Zugriff

User Standard Key Rechte
csgadmin immer im Cloud-Init-Modus --user-key, standardmässig /root/.ssh/id_csgadmin.pub Admin-Zugang gemäss Cloud-Image/Cloud-Init
hermes nur mit --hermes --hermes-key, standardmässig /root/.ssh/id_ed25519.pub NOPASSWD:ALL, Passwort gesperrt
root kein SSH-Login keiner PermitRootLogin no

Zusätzlich gilt PasswordAuthentication no; SSH-Zugriff erfolgt per Key.

important: > Hermes ist opt-in. Der User wird nie automatisch angelegt.

8 · Goldene Regeln

  1. Für Cloud-Init debian-13-generic-amd64.qcow2 verwenden.
  2. Template nie booten.
  3. Cloud-Init-Drive muss vorhanden sein, bei OVMF auf scsi1.
  4. Nach Änderungen an ci* immer qm cloudinit update <VMID>.
  5. Kunden-/Staging-/Prod-/Infra-VMs als Full Clone erstellen.
  6. Admin-Key vor dem Build verifizieren; der Build bricht bei fehlender oder leerer Key-Datei ab.
  7. Nach dem ersten Clone Cloud-Init, Guest Agent, IPv4, SSH und deaktiviertes IPv6 prüfen.
  8. Skripte nicht aus Obsidian kopieren; immer den aktuellen OneDev-Stand installieren.

9 · Troubleshooting

Symptom Ursache Fix
user pubkey missing Default-Key-Datei fehlt dedizierte Datei bereitstellen oder --user-key <datei> verwenden
storage ... does not support vm images Quell-NFS fälschlich als VM-Ziel verwendet oder alter Skriptstand Installer erneut ausführen; lokalen Zielstorage wählen oder --target-store <STORE> setzen
VM-ID existiert nach fehlgeschlagenem Import alter Build hat die VM vor dem Storage-Fehler angelegt qm config <VMID> prüfen, unbrauchbaren Teilbau gezielt löschen oder neue ID wählen
Basis-qcow2 stimmt nicht mehr mit SHA512 überein alter Skriptstand hat das NFS-Image direkt verändert Original erneut von Debian laden; aktueller Skriptstand arbeitet mit /var/tmp-Kopie
Kein SSH-Login Key nicht im Cloud-Init-Seed qm config, sshkeys, Key-Datei und qm cloudinit update prüfen
cloud-init: command not found nocloud-Image verwendet Template mit generic-amd64 neu bauen
cidata fehlt Cloud-Init-Drive fehlt/falscher Bus scsi1 und qm cloudinit update prüfen
Cloud-Init überspringt Template wurde gebootet Template sauber neu bauen; künftig nur Clones booten
qemu-guest-agent fehlt altes/fehlerhaftes Template aktuelles Build-Skript installieren und Template neu bauen
qm agent <VMID> ping scheitert Paket/Dienst/Agent-Flag fehlt Gastpaket, Dienst, /dev/virtio-ports/ und qm config prüfen
IPv6 noch aktiv alter Template-Stand oder kein Neustart aktuelles Template bauen; Sysctl, Kernelparameter und Cold Boot prüfen
DHCP wartet kein DHCP im Zielnetz statische IPv4 beim Clone übergeben

10 · Source of Truth

important: > Ausführbarer Source of Truth ist OneDev, nicht ein eingebetteter Skriptblock in Obsidian.

Die früher eingebetteten Vollkopien der Skripte wurden bewusst entfernt, damit Dokumentation und ausführbarer Code nicht erneut auseinanderlaufen.

Verwandt: Staging- und Produktionskonzept

Quelle: Obsidian Knowledge Base/Proxmox/Proxmox Debian Cloud-Init Strategie.md · Stand: 2026-09-13 · Automatisiert publiziert durch Hermes.

Knowledge Base

Aktive technische Knowledge-Base-Einträge aus Obsidian.

Knowledge Base

NTP Proxmox Cluster

Umstellung – Schritt für Schritt

1️⃣ Datei anpassen:

nano /etc/chrony/chrony.conf

2️⃣ Dienst neu starten:

systemctl restart chrony

3️⃣ Prüfen:

chronyc sources -v

Erwartung:

^* 192.168.10.1
^+ ch.pool.ntp.org

Konfig

## Welcome to the chrony configuration file. See chrony.conf(5) for more
## information about usable directives.

## Include configuration files found in /etc/chrony/conf.d.
confdir /etc/chrony/conf.d

## === Proxmox Cluster NTP Configuration ===

## Primary NTP – Firewall (LAN / MGMT)
server 10.0.0.1 iburst prefer

## Fallback – Swiss NTP Pool
server ch.pool.ntp.org iburst

## --- Disabled defaults for deterministic cluster time ---
## pool 2.debian.pool.ntp.org iburst
## sourcedir /run/chrony-dhcp
## sourcedir /etc/chrony/sources.d

/

Quelle: Obsidian Knowledge Base/Proxmox/NTP Proxmox Cluster.md · Stand: 2026-09-20 · Automatisiert publiziert durch Hermes.

Knowledge Base

UEFI Secure Boot Zertifikate 2023

Problem

EFI-Disk ohne ms-cert=2023k-Option: nicht alle UEFI-2023-Zertifikate von Microsoft sind eingespielt.

Wichtig: Die UEFI-2011-Zertifikate laufen im Juni 2026 ab. Die neuen Zertifikate werden für Secure-Boot-Updates von Windows und gängigen Linux-Distributionen benötigt.

Lösung

qm enroll-efi-keys 100

(VM-ID 100 entsprechend anpassen.)

Quelle: aus Untitled.md (Wurzelverzeichnis) überführt am 2026-07-26.

Quelle: Obsidian Knowledge Base/Proxmox/UEFI Secure Boot Zertifikate 2023.md · Stand: 2026-09-20 · Automatisiert publiziert durch Hermes.