Speicher von TrueNAS Scale VM in Proxmox nutzen

[CoMo]

Hallo,

ich betreibe hier eine TrueNAS VM auf meinem Proxmox. Darauf ist ein RAIDZ1 konfiguriert.

Den Speicher möchte ich auch in Proxmox nutzen. Da hier noch Temperaturprobleme vorherrschen, würde ich das JBOD-Array, in dem die Platten stecken, erst mal nicht dauerhaft laufen lassen. Ebenso die TrueNAS VM

Das scheint ein Problem für NFS zu sein. Ich werde mit Fehlemeldungen zugespammt, wenn TrueNAS nicht verfügbar ist, auch wenn ich den Storage vorher deaktiviere.

Nach ein paar Reboots ist der gesamte NFS-Share jetzt plötzlich Read-Only in Proxmox gewesen.

Also neuer Versuch: ZFS over iSCSI. zvol angelegt, SSH-Key erstellt und auf dem TrueNAS konfiguriert, iSCSI-Freigabe erstellt und in Proxmox konfiguriert.

Jetzt kann ich auf dem Storage VM-Disks erstellen. Aber ich benötige auch und vor allem Mountpoints in meine LXC-Container und Backup-Storage.

So sieht die Konfiguration in meinr storage.cfg aus:

zfs: truenas
        blocksize 4k
        iscsiprovider LIO
        pool tank
        portal truenas.pve.internal
        target iqn.2005-10.org.freenas.ctl
        content images
        lio_tpg 1
        nodes pve
        nowritecache 1
        sparse 0

Wie ist hier der richtige Weg?

 

[redjack1000]

Verständnisfrage:

Du möchtest ein ISCSI-Target, das auf dem Truenas läuft, dauerhaft als "Storage" in Proxmox einbinden, ohne dass das Truenas dauerhaft verfügbar ist?

Ich halte das für eine "sehr" schlechte Idee.

Speicher/Storage, die in deinem Hypervisor eingebunden sind, müssen dauerhaft und bei start, verfügbar sein. Wie soll man das mit einer VM realisieren, die auf dem Hypervisor läuft?

Cu
redjack

 

[T3Kila]

Ich stehe heute vielleicht ein bisschen auf dem Schlauch...

Du willst den Speicher, den Proxmox an die VM durchreicht und die VM zur Verfügung stellt wieder in Proxmox einbinden? Reden wir hier von Single-Host?
Wenn Du den Host neu startest steht der Speicher ja zwangsweise nicht zur Verfügung, weil die VM logischerweise noch nicht gestartet sein kann?

Weshalb nicht anders herum? Den Speicher in Proxmox einbinden und zusätzlich an die VM durchreichen?

 

[VDC]

Wie ist hier der richtige Weg?

Du gehst die Sache schlichtweg falsch herum an. Wenn dann vom Truenas auf Proxmox zugreifen, dann klappt das auch mit Platten schlafen legen.

Da hier noch Temperaturprobleme vorherrschen, würde ich das JBOD-Array, in dem die Platten stecken, erst mal nicht dauerhaft laufen lassen.

Werte bitte.

 

[CoMo]

Es geht mir darum, dass TrueNAS vollen Zugriff auf die Platten hat, deshalb habe ich den kompletten Controller an die VMs durchgereicht.

Ich möchte nicht alles auf der CLI konfigurieren, aber eine GUI-Verwaltung für verschlüsselte Datasets etc haben. Das kann Proxmox so scheinbar alles nicht.

Ergänzung (25. Mai 2025)

Werte bitte.

Keine Ahnung. Wenn ich die Tür meines Racks schließe, fängt das JBOD-Gehäuse an zu piepen. Was laut Handbuch bedeutet, dass die Temperatur von 65°C überschritten wurde. Die Platten selbst reporten keine Temperatur an TrueNAS. Habe ich zumindest nicht gefunden.

Ergänzung (25. Mai 2025)

Du willst den Speicher, den Proxmox an die VM durchreicht und die VM zur Verfügung stellt wieder in Proxmox einbinden? Reden wir hier von Single-Host?
Wenn Du den Host neu startest steht der Speicher ja zwangsweise nicht zur Verfügung, weil die VM logischerweise noch nicht gestartet sein kann?

Richtig. Ich habe einen Cluster aus 2 Nodes, aber der Controller hängt nur an einem Node, wird auch nur dort benötigt und per PCIe-Passthrough an TrueNAS Scale durchgereicht. Dass der nicht sofort beim Boot zur Verfügung steht, ist klar.

 

[redjack1000]

Es geht mir darum, dass TrueNAS vollen Zugriff auf die Platten hat, deshalb habe ich den kompletten Controller an die VMs durchgereicht.

Wird nicht auf Dauer funktionieren.


Was spricht dagagen, für das ganze, nur Truenas zu nutzen?

Cu
redjack

 

[CoMo]

Ich verstehe die Frage nicht. Was heißt "nur Truenas zu nutzen"?

 

[redjack1000]

Proxmox weg, Truenas direkt auf der Hardware installieren.

Cu
redjack

 

[CoMo]

Ich betreibe hier einen Cluster aus 2 Nodes, mit mehr als 30 LXC-Containern. Ich habe nicht vor, das alles wegzuwerfen. Wie sollte ich das mit Truenas überhaupt machen?

 

[Don_2020]

TrueNAS kann doch Docker. Die LXC nach Docker umziehen/anlegen.
Normalerweise macht man alles in Proxmox. TrueNAS bekommt dann eine Freigabe für den Storage.
Was machst Du denn mit TrueNAS, das mit Proxmox nicht geht?
Unter Proxmox kann man auch einen Backupserver laufen lassen. In TrusNAS eine Vm laufen lassen macht keinen Sinn, da Proxmox vorgeschaltet ist. Das kostet viel Performance und führt zu nicht vorhersehbaren Seiteneffekten.

 

[CoMo]

Was machst Du denn mit TrueNAS, das mit Proxmox nicht geht?

Zum Beispiel verschlüsselte Datasets mit Entsperrung über die GUI oder einen KMIP Server.

Die LXC nach Docker umziehen/anlegen.

Das kommt nicht in Frage und geht auch gar nicht.

Unter Proxmox kann man auch einen Backupserver laufen lassen. In TrusNAS eine Vm laufen lassen macht keinen Sinn, da Proxmox vorgeschaltet ist. Das kostet viel Performance und führt zu nicht vorhersehbaren Seiteneffekten.

Ich habe nicht vor, in TrueNAS irgendwelche VMs laufen zu lassen. Ebensowenig wie irgendwelche Container.

 

[CoMo]

Ich glaube ich habe jetzt erst mal eine Lösung gefunden. Ich habe den Storage jetzt wieder per NFS eingebunden.

Zunächst mal habe ich die Boot-Order der TrueNAS VM auf 1 gestellt. Die startet also immer als erstes und wird als letztes heruntergefahren.

Zusätzlich habe ich ein Startup Delay von 2 Minuten konfiguriert. Also starten die anderen Container und VMs erst, nachdem der QEMU Guest Agent den volsltändigen Boot gemeldet hat.

Zusätzlich habe ich ein Hook-Skript erstellt und an die VM gehängt:

#!/bin/bash

VMID="$1"
PHASE="$2"
STORAGE="truenas_nfs"
NFS_HOST="truenas.pve.internal"
MAX_WAIT_SEC=180
INTERVAL=5

log() {
    logger -t "hookscript-vm${VMID}[$PHASE]" "$1"
}

case "$PHASE" in
  post-start)
    log "Waiting up to ${MAX_WAIT_SEC}s for NFS server '${NFS_HOST}'..."
    SECONDS=0
    while [ $SECONDS -lt $MAX_WAIT_SEC ]; do
      if showmount -e "$NFS_HOST" >/dev/null 2>&1; then
        log "NFS available, enabling storage '${STORAGE}'..."
        pvesm set "$STORAGE" --disable 0 && log "Storage '${STORAGE}' enabled successfully."
        exit 0
      fi
      sleep "$INTERVAL"
    done
    log "Timeout: NFS server not reachable after ${MAX_WAIT_SEC}s. Storage not enabled."
    exit 0
    ;;

  pre-stop)
    log "Disabling storage '${STORAGE}' before VM stops..."
     pvesm set "$STORAGE" --disable 1 && log "Storage '${STORAGE}' disabled successfully."
    ;;
esac

Das prüft nach dem VM-Boot drei Minuten lang, ob der NFS-Share verfügbar ist und aktiviert dann den Storage. Vor dem Herunterfahren der VM wird der Storage deaktiviert. Nach ersten Tests scheint das zu funktionieren.

 

[CoMo]

Da der deaktivierte Storage trotzdem im System gemounted bleibt und mich mit Meldungen wie

pve kernel: nfs: server truenas.pve.internal not responding, timed out

vollspammt, hier das verfeinerte Skript, das auch den Mountpoint entfernt:

#!/bin/bash

# VM hookscript to manage delayed NFS mount/unmount via Proxmox storage interface and systemd

VMID="$1"
PHASE="$2"
STORAGE="truenas_nfs"
NFS_HOST="truenas.pve.internal"
MAX_WAIT_SEC=180
INTERVAL=5
MOUNT_UNIT="mnt-pve-${STORAGE}.mount"

log() {
    logger -t "hookscript-vm${VMID}[$PHASE]" "$1"
}

case "$PHASE" in
  post-start)
    log "Waiting up to ${MAX_WAIT_SEC}s for NFS server '${NFS_HOST}'..."
    SECONDS=0
    while [ $SECONDS -lt $MAX_WAIT_SEC ]; do
      if showmount -e "$NFS_HOST" >/dev/null 2>&1; then
        log "NFS available, enabling storage '${STORAGE}'..."
        if pvesm set "$STORAGE" --disable 0; then
          log "Storage '${STORAGE}' enabled successfully."
        else
          log "Failed to enable storage '${STORAGE}'."
        fi
        exit 0
      fi
      sleep "$INTERVAL"
    done
    log "Timeout: NFS server not reachable after ${MAX_WAIT_SEC}s. Storage not enabled."
    exit 0
    ;;

  pre-stop)
    log "Disabling storage '${STORAGE}' before VM stops..."
    if pvesm set "$STORAGE" --disable 1; then
      log "Storage '${STORAGE}' disabled successfully."

      # Wait to ensure Proxmox has time to release the mount
      sleep 10

      if systemctl is-active --quiet "$MOUNT_UNIT"; then
        if systemctl stop "$MOUNT_UNIT"; then
          log "Unmounted systemd unit '$MOUNT_UNIT' successfully."
        else
          log "Failed to unmount systemd unit '$MOUNT_UNIT'."
        fi
      else
        log "Systemd unit '$MOUNT_UNIT' was already inactive."
      fi

    else
      log "Failed to disable storage '${STORAGE}'."
    fi
    ;;
esac

Wie immer natürlich mit bestem Dank an ChatGPT.