[SOLVED] fstrim vor Backup-Job

[Detlef Paschke]

Hallo,

in den Optionen der VMs gibt es unter QEMU Guest Agent ja die Möglichkeit, "guest-trim nach Disk-klonen ausführen" zu aktivieren.
Ob das viel Sinn hat, kann ich mir im Moment nicht so recht vorstellen, wo es aber Sinn machen würde ist, wenn vor den Backup-Jobs ein fstrim ausgeführt würde.

Aktuell mache ich es so, dass ich in der jeweiligen VM, fstrim per Cron-Job einige Minuten vor dem in Proxmox geplanten Backup-Job ausführe.
Eleganter wäre es, wenn von Proxmox vor vzdump ein "qm agent VMID fstrim" ausgeführt werden würde.
Ich könnte ebenso einen extra Cron-Job in Proxmox einrichten der vor dem geplanten Backup-Job ein "qm agent VMID fstrim" ausführt aber das bleibt sich gleich, ob ich den extra Cron-Job nun in der VM oder in Proxmox starte.
Den Befehl in die /etc/pve/vzdump.cron zu schreiben ist sicher auch nicht das wahre, zumal er bei jeder Veränderung wieder verschwunden wäre aber könnte man den Befehl nicht irgendwo als Standard vor dem ausführen von vzdump festlegen?

Viele Grüße
Detlef Paschke

 

[Alwin]

in den Optionen der VMs gibt es unter QEMU Guest Agent ja die Möglichkeit, "guest-trim nach Disk-klonen ausführen" zu aktivieren.
Ob das viel Sinn hat, kann ich mir im Moment nicht so recht vorstellen, wo es aber Sinn machen würde ist, wenn vor den Backup-Jobs ein fstrim ausgeführt würde.

Ein Disk-Klon, ist ein voller Klon.

Den Befehl in die /etc/pve/vzdump.cron zu schreiben ist sicher auch nicht das wahre, zumal er bei jeder Veränderung wieder verschwunden wäre aber könnte man den Befehl nicht irgendwo als Standard vor dem ausführen von vzdump festlegen?

Mittels den Hook-Scripts kann sich ein eigener Backup-Workflow zusammengestellt werden.
https://pve.proxmox.com/pve-docs/chapter-vzdump.html#_hook_scripts

 

[Detlef Paschke]

Hallo Alwin,

Ein Disk-Klon, ist ein voller Klon.

Aha, dann erklärt es sich mir.

Mittels den Hook-Scripts kann sich ein eigener Backup-Workflow zusammengestellt werden.
https://pve.proxmox.com/pve-docs/chapter-vzdump.html#_hook_scripts

Das ist genau das, was mich weiter bringt. Nun habe ich nur ein kleines Timingproblem?
QEMU-Guest-fstrim endet bei einer VM, das ist sozusagen mein Hauptserver, mit "failed - got timeout".
Das liegt ganz schlicht und einfach daran, dass zu dieser VM unter anderem ein 8TB Raid5 durchgereicht wird den guest-fstrim auch "bearbeitet" und das dauert dann ein paar Sekunden. Wenn ich kurze Zeit später guest-fstrim für diese VM erneut aufrufe, läuft es ohne Probleme durch, weil der Raid5 ja nichts mehr zu Trimmen hätte. Das geht aber nicht für einen Backup-Job.

Der Raid ist im Backup-Job nicht enthalten und müsste somit auch nicht von guest-fstrim "bearbeitet" werden nur scheint es keine entsprechende Option zu geben, nur definierte Partitionen zu trimmen. Oder doch?
Ich habe bis jetzt zumindest nichts gefunden, "qm agent VMID fstrim" macht das selbe als wenn ich in der VM "fstrim -av" eingebe.
Für meinen Backup-Job würde aber "fstrim /boot && fstrim /" genügen.

Viele Grüße
Detlef Paschke

 

[Detlef Paschke]

Das liegt ganz schlicht und einfach daran, dass zu dieser VM unter anderem ein 8TB Raid5 durchgereicht wird den guest-fstrim auch "bearbeitet" und das dauert dann ein paar Sekunden.

Noch als Nachtrag, die Option Discard ist für dieses Laufwerk in den Einstellungen deaktiviert.

 

[Alwin]

Noch als Nachtrag, die Option Discard ist für dieses Laufwerk in den Einstellungen deaktiviert.

Dann werden auf dem Storage keine Blöcke freigegeben.

 

[Detlef Paschke]

Hallo Alwin,

Dann werden auf dem Storage keine Blöcke freigegeben.

also doch lieber aktivieren?
Ich nahm an, wenn ich Discard nicht aktiviere, wird auch guest-fstrim auf dem Storage nicht ausgeführt doch das ist ja nicht so, wie ich feststellen musste.

Viele Grüße
Detlef Paschke

 

[Detlef Paschke]

Doch die Frage ist immer noch, wie bekomme guest-trim dazu nur bestimmte Storages zu trimmen?

Ich habe es gerade noch mal getestet aber es klappt so nicht.

root@Proxmox:~# qm agent 100 fstrim
VM 100 qmp command 'guest-fstrim' failed - got timeout

Ein paar sek. später ist es kein Problem mehr.

Nur die Timeout-Zeit verlängern möchte ich nicht unbedingt.
Ich möchte nicht, wenn nicht unumgänglich, jeden Tag ein trim über den 8TB Hardware-Raid5 laufen lassen der gar nicht nötig wäre sondern eigentlich nur das Storage trimmen welches auch für das Backup bestimmt ist.

Viele Grüße
Detlef Paschke

 

[Alwin]

Ich nahm an, wenn ich Discard nicht aktiviere, wird auch guest-fstrim auf dem Storage nicht ausgeführt doch das ist ja nicht so, wie ich feststellen musste.

Das fstrim wird ausgeführt, aber es werden keine Blöcke freigegeben. Damit wiederholt sich das Spiel bei jedem fstrim.

root@Proxmox:~# qm agent 100 fstrim
VM 100 qmp command 'guest-fstrim' failed - got timeout

Das geht über alle Filesysteme. Für eine gezielte Steuerung ist es besser den Befehl per exec (qm guest exec) laufen zu lassen.

Nur die Timeout-Zeit verlängern möchte ich nicht unbedingt.
Ich möchte nicht, wenn nicht unumgänglich, jeden Tag ein trim über den 8TB Hardware-Raid5 laufen lassen der gar nicht nötig wäre sondern eigentlich nur das Storage trimmen welches auch für das Backup bestimmt ist.

Generell sollte das Zeitfenster kleiner werden, wenn der fstrim periodisch ausgeführt wird.

 

[Detlef Paschke]

Für eine gezielte Steuerung ist es besser den Befehl per exec (qm guest exec) laufen zu lassen.

Das scheint zu gehen aber wie verdammt bekomme ich den hier zu Testzwecken Optionen übergeben?

So scheint es ja zu gehen:

root@Proxmox:~# qm guest exec 101 fstrim /
{
   "exitcode" : 0,
   "exited" : 1
}
root@Proxmox:~#

Nun wollte ich das mal mit Output testen um zu sehen dass was passiert aber:

root@Proxmox:~# qm guest exec 101 fstrim -av
Unknown option: av
400 unable to parse option
qm guest exec <vmid> [<extra-args>] [OPTIONS]
root@Proxmox:~#

Auch nur mit -v und Angabe eines Storage geht es nicht, da scheint nach "-v" Schluss zu sein:

root@Proxmox:~# qm guest exec 101 fstrim -v /
{
   "err-data" : "fstrim: no mountpoint specified\n",
   "exitcode" : 1,
   "exited" : 1
}
root@Proxmox:~#

In " " oder ' ' habe ich auch schon probiert aber noch ohne Erfolg.

Viele Grüße
Detlef Paschke

 

[fabian]

qm gust exec 101 -- fstrim -v / should work.

 

[Detlef Paschke]

Hallo Fabian,

qm gust exec 101 -- fstrim -v / should work.

nach Copy and Paste habe ich mich erst gewundert aber ein kleiner Typo macht viel aus. ;-)
Aber funktioniert so, warum stehen solche Sachen blos in keiner Hilfe und Doku...???

Danke an alle für die Hilfe.

Viele Grüße
Detlef Paschke

 

[tom]

Aber funktioniert so, warum stehen solche Sachen blos in keiner Hilfe und Doku...???

qm guest exec ist im admin guide beschrieben, siehe https://pve.proxmox.com/pve-docs/

 

[Ingo S]

Was ich an dieser Stelle noch nicht verstanden habe ist:
Warum nicht einfach virtio-SCSI für die Disks nutzen und das discard flag setzen? Dann braucht man eigentlich keinen fstrim zu machen, weil der disk Treiber den Discard vom OS an den Storage weiter reicht.

 

[Alwin]

Dann braucht man eigentlich keinen fstrim zu machen, weil der disk Treiber den Discard vom OS an den Storage weiter reicht.

Das kommt auf das OS an. Auch kann ein autom. TRIM bei jedem Löschen zu erhöhtem IO führen. Und ob man das zur Kernzeit haben will ist fraglich. Ein gesteuertes TRIM gibt hier mehr Kontrolle, ob das jetzt bei jedem nächtlichen Backup oder einmal pro Woche passiert.

 

[Detlef Paschke]

Hallo Ingo,

Was ich an dieser Stelle noch nicht verstanden habe ist:
Warum nicht einfach virtio-SCSI für die Disks nutzen und das discard flag setzen? Dann braucht man eigentlich keinen fstrim zu machen, weil der disk Treiber den Discard vom OS an den Storage weiter reicht.

Das habe ich hier von Anfang an genau so Konfiguriert, hatte aber feststellen müssen, dass trotzdem von Tag zu Tag die Backups etwas größer geworden sind. Eine kurze Suche brachte mich dann auf Trim, weil dieses Verhalten wohl nicht so selten ist.
Zunächst lief Trim als Cronjob in der VM, jetzt schon einige Tage zuverlässig über den Backup-Job selbst.

Viele Grüße
Detlef Paschke

 

[Ingo S]

Ah, das ist interessant. So ein Verhalten ist bei uns bislang noch nicht aufgefallen, aber wir haben auch nicht explizit danach geguckt.

Hab da gerade mal nachgesehen und tatsächlich sind die nachfolgenden Backups meist ein wenig größer (0,5-3GB) Allerdings bewahren wir nur 2-3 tägliche Jobs auf, weil die nur als Zwischenlager für die Bandsicherung dienen. Da sieht man sowas nicht.

Ich werde auf jeden Fall mal die ein oder andere Maschine mit fstrim "behandeln" und sehen ob das Backup danach deutlich kleiner ist.

 

[Detlef Paschke]

Hallo,
nach einiger Zeit, in der alles zufriedenstellend lief muss ich mich doch mal wieder melden.

In meinem vzdump-hook-script.pl sind für das trimmen nun folgende Zeilen:

# fstrim vor backup
    if ($phase eq 'backup-start') {
    system ("/usr/sbin/qm guest exec $vmid -- fstrim -v /boot ; /usr/sbin/qm guest exec $vmid -- fstrim -v /") == 0 ||
    die "Fehler bei fstrim von $hostname auf VM-$vmid";
    }

Nun wollte ich zum einen, eine Sicherung von VMs machen, welche nicht in Betrieb waren, zum anderen von einer VM auf der kein Gast Agent ist. In beiden Fällen ist das Backup mit Fehlermeldung abgebrochen.
Zunächst dachte ich, man müsste im vzdump-hook-script.pl prüfen, ob die VM läuft und ob der Gast Agend in der Config aktiviert ist aber letztendlich genügt es ja auch, wenn trotz Fehler an dieser Stelle das Backup fortgeführt wird.

Wie ließe sich das machen?

Viele Grüße
Detlef Paschke

 

[Alwin]

die "Fehler bei fstrim von $hostname auf VM-$vmid";

Am besten das 'die' durch ein 'warn' ersetzen. Damit bricht das Script nicht gleich ab, sondern schreibt eine Warnung aus.

 

[Detlef Paschke]

Ich danke Dir Alwin, es kann manchmal so einfach sein.

Viele Grüße
Detlef Paschke