Nicht genug. Einfach das ganze TN sparen. 🤯
Zuletzt bearbeitet:
[Sammelthread] Proxmox Stammtisch
- Ersteller GrafikTreiber
- Erstellt am
Ich glaub du machst es dir zu kompliziert.
Bevor ich jetzt ratschlage, meine 2 Eurocent. Gibt 2 Dinge die ich nicht mehr virtualisieren würde: Primäre Firewall und primäres Backupziel. Beide will ich auch dann laufend haben, wenn der Virtualisierer nicht läuft. So, nu gehts mir besser, zu dir:
Einach machen! Ich hab damals einfach geschaut welcher meiner Sata-Controller frei ist. Hab dann ne VM angelegt, hab der den Controller durchgereicht und war glücklich. Für die Einstellungen der VM hab ich damals das hier benutzt:
www.truenas.com
Und als VM hab ich einfach alles auf default gelassen in PVE. Und das lief wunderbar so.
Bevor ich jetzt ratschlage, meine 2 Eurocent. Gibt 2 Dinge die ich nicht mehr virtualisieren würde: Primäre Firewall und primäres Backupziel. Beide will ich auch dann laufend haben, wenn der Virtualisierer nicht läuft. So, nu gehts mir besser, zu dir:
Einach machen! Ich hab damals einfach geschaut welcher meiner Sata-Controller frei ist. Hab dann ne VM angelegt, hab der den Controller durchgereicht und war glücklich. Für die Einstellungen der VM hab ich damals das hier benutzt:
Resource - "Absolutely must virtualize TrueNAS!" ... a guide to not completely losing your data.
[---- 2024/01/16: Still relevant. Virtualization really doesn't change much. Updates made as appropriate. ----] [---- 2018/02/27: This is still as relevant as ever. As PCIe-Passthru has matured, fewer problems are reported. I've updated some...
www.truenas.com
pwnbert
Legende
- Mitglied seit
- 30.10.2014
- Beiträge
- 9.620
Mit ZFS oder Ext4/LVM?
Und zum Thema Passthrough, ich muss den Controller nicht durchreichen (müsste schauen, ob das einzeln geht, bzw. will ich das eigentlich nicht, bin mir nicht sicher, inwiefern der Controller am B550 druchreichbar ist, imho ist das direkt vom PCH, die haben keinen extra Controller der auf einer Lane hängt.
Ob man nun die 4 nativen Ports des PCH isoliert durchreichen kann, kein Plan. Ist mir aber auch egal, ist nicht mein Ziel, den 9400-16i hab ich ja und der läuft auch als Passthrough Device.
Die Frage ist eigetnlich ausschließlich, ob ich davon booten kann (wenn ich das will).
ZFS on ZFS ist halt meh.
Und zum Thema Passthrough, ich muss den Controller nicht durchreichen (müsste schauen, ob das einzeln geht, bzw. will ich das eigentlich nicht, bin mir nicht sicher, inwiefern der Controller am B550 druchreichbar ist, imho ist das direkt vom PCH, die haben keinen extra Controller der auf einer Lane hängt.
Ob man nun die 4 nativen Ports des PCH isoliert durchreichen kann, kein Plan. Ist mir aber auch egal, ist nicht mein Ziel, den 9400-16i hab ich ja und der läuft auch als Passthrough Device.
Die Frage ist eigetnlich ausschließlich, ob ich davon booten kann (wenn ich das will).
ZFS on ZFS ist halt meh.
Mein Proxmox ist auf nem ZFS mirror installiert. Meine VMs liegen auf einem weiteren ZFS mirror. Auf diesem Mirror habe ich einfach eine TrueNAS VM mit VirtIO SCSI Disk als Bootmedium angelegt, die hatte ich mit ext4 formatiert. Machs dir doch nicht so kompliziert?
asm@s24
Profi
Hab nicht so genau drüber nachgedacht.
Ja. Also ... einfach machen.
drunkenmaster
Urgestein
Moin, ich bin leider absoluter Noob. Ich versuche gerade proxmox auf einem HP Elitedesk 800 G2 mit einer SATA SSD zu installieren aber ich bekomme die Meldung "no hard disk found". BIOS erkennt die SSD jedenfalls. Woran könnte das noch liegen, einer ne Idee?
@drunkenmaster Irgend ein wilder SATA Mode im BIOS aktiviert, oder Secure Boot aktiv?
Dann mach doch einfach ZFS - stört dich später null.
Aber blocks werden doch vonKVM durchgereicht... Mach dir da doch einfach nicht so einen Kopf, was soll denn schief gehen? Wovor hast du Angst? So wie sich das für mich anfühlt solltest du für dein NAS vielleicht aufs Metall gehen...
pwnbert
Legende
- Mitglied seit
- 30.10.2014
- Beiträge
- 9.620
Das NAS ist am Metall und soll weg davon. 
Hab ich nicht am ZFS einfach ne große Datei, in welcher dann die VM wieder ein ZFS macht? Tja und wenn der Block in der VM nicht direkt "auf" dem Block vom Host "liegt" sondern die Daten anders "verteilt" sind, dann werden beim Schreiben von 1 Block in der VM mehrere Blöcke am Host geschrieben, so blasen sich kleine Schreibvorgänge massiv auf.
Das ist ja das Ding hinter der Write Amplification.
Erzähl mir was neues, läuft das irgendwie anders?
Wie meinst du?
Hab ich nicht am ZFS einfach ne große Datei, in welcher dann die VM wieder ein ZFS macht? Tja und wenn der Block in der VM nicht direkt "auf" dem Block vom Host "liegt" sondern die Daten anders "verteilt" sind, dann werden beim Schreiben von 1 Block in der VM mehrere Blöcke am Host geschrieben, so blasen sich kleine Schreibvorgänge massiv auf.
Das ist ja das Ding hinter der Write Amplification.
Erzähl mir was neues, läuft das irgendwie anders?
drunkenmaster
Urgestein
Secure Boot ist aus, SATA Mode kann ich nichts einstellen, da scheint HP sehr restriktiv zu sein.
Ich sehe die Write Amplification von ZFS als kritisch, erst recht hier. Aber, wenn es nur um das OS geht, dann denk ich vernachlässigbar. Versuche außerdem, die selben Settings für beides zu nehmen, Sync-Writes aus, braucht eh keiner zuhause und dann wäre das ok. Besser wäre, gleich auf TN zu verzichten ^^
Beitrag automatisch zusammengeführt:
Kannst Du Windows installieren?
asm@s24
Profi
Steggi
Enthusiast
- Mitglied seit
- 31.12.2010
- Beiträge
- 3.513
Nabend, ich schmeiß mal folgendes Szenario in den Raum, dass ich grade versuche zu optimieren, und würde mich über Meinungen / Anregungen freuen.
Ausgangslage:
Zwei standalone Proxmox 9.2 Hosts, aktuelle Frequency Optimized EPYC CPU, jeweils über 1TB RAM, nicht mal zu einem Drittel ausgelastet.
Jeweils 2 NVMe SSDs, 3 SAS SSDs und 6 HDDs.
Host 1:
Host 2:
Problem: VMs auf dem Daten-Pool von Host 1 haben teils extreme (schreib) Latenzen. Bei einer Windows VM mit etwa 4TB an MSSQL Datenbanken liegt die Länge der Datenträgerwarteschlange teils im vierstelligen Bereich. Interessanterweise spiegelt sich dies im IO Pressure Stall der VM nicht immer wieder.
Die Umgebung muss optimiert werden, für den Moment muss ich allerdings erstmal mit der Hardware klarkommen, die vorhanden ist. Optimierungen innerhalb der Datenbank übernimmt jemand anderes.
Folgende Ideen hätte ich nun. Diese sind erstmal nur für Host 1 vorgesehen. Host 2 soll später auch optimiert werden, dient im Moment aber erstmal dazu, die VMs von Host 1 temporär weiterzubetreiben, sollte eine komplette Neuinstallation / Neuerstellung des Pools erforderlich sein bzw. sich die Arbeiten nicht im laufenden Betreb umsetzen lassen (wovon ich aktuell leider ausgehe):
Ausgangslage:
Zwei standalone Proxmox 9.2 Hosts, aktuelle Frequency Optimized EPYC CPU, jeweils über 1TB RAM, nicht mal zu einem Drittel ausgelastet.
Jeweils 2 NVMe SSDs, 3 SAS SSDs und 6 HDDs.
Host 1:
- 2x 1.92TB NVMe (1 DWPD) --> Boot-Pool, Rest für VMs
- 6x 16TB HDD --> Daten-Pool mit 3x Mirror
- 3x 3.2TB 24G SAS (3 DWPD) --> Partitioniert in jeweils 3 Partitionen
- Partition 1 --> Mirror aus 2x 1.2TB Special vDEV (nur Metadaten) für Daten-Pool
- Partition 2 --> Mirror aus 2x 70GB SLOG für Daten-Pool
- Partition 3 --> L2ARC für Daten-Pool (ca 3x 1.9TB)
- Bei SSD Nr. 3 sind Partition 1 und 2 jeweils nicht in Nutzung (Speicherplatz wird verschwendet)
- ARC wurde via Konfigurationsdatei auf 24-48GB GB eingestellt
Host 2:
- NVMe's und HDDs identisch zu Host 1 konfiguriert
- Kein Special vDEV
- 3.2TB großes SLOG aus SAS SSD 1 & 2
- 800GB L2ARC Partition auf SAS SSD 3, der restliche Speicherplatz wird verschwendet
Problem: VMs auf dem Daten-Pool von Host 1 haben teils extreme (schreib) Latenzen. Bei einer Windows VM mit etwa 4TB an MSSQL Datenbanken liegt die Länge der Datenträgerwarteschlange teils im vierstelligen Bereich. Interessanterweise spiegelt sich dies im IO Pressure Stall der VM nicht immer wieder.
Die Umgebung muss optimiert werden, für den Moment muss ich allerdings erstmal mit der Hardware klarkommen, die vorhanden ist. Optimierungen innerhalb der Datenbank übernimmt jemand anderes.
Folgende Ideen hätte ich nun. Diese sind erstmal nur für Host 1 vorgesehen. Host 2 soll später auch optimiert werden, dient im Moment aber erstmal dazu, die VMs von Host 1 temporär weiterzubetreiben, sollte eine komplette Neuinstallation / Neuerstellung des Pools erforderlich sein bzw. sich die Arbeiten nicht im laufenden Betreb umsetzen lassen (wovon ich aktuell leider ausgehe):
- Laut zpool iostat liegt die Belegung des Special vDev aktuell bei 230GB (nur Metadaten), L2ARC bei 3x 700GB bei weniger als 20% Cache Hit)
- ARC vergrößern, 200-300GB für den Anfang
- Auflösung der Partitionierung der SAS SSDs wegen IO / Workload-Konflikten --> Überall wird davon abgeraten
- 2x 3.2TB Special vDev Mirror, inkl. special_small_blocks <= 64K, da MSSQL 64K schreibt
- Die Recordsize des Pools sowie die volblocksize der VM liegen aktuell bei 16K --> Rewrite erforderlich.
- Die dritte SAS SSD als L2ARC nutzen? Oder ggf. mit einer weiteren SSD (evtl. aus Host 2) das Special vDev vergrößern? Habe die genaue Größe noch nicht ausrechnen können.
- Wird noch ein seperates SLOG Device benötigt? Ab OpenZFS 2.4 soll man ja das Special vDev dafür mitnutzen können.
- Wäre sync=disabled ansonsten eine Option, wenn man dieser Aussage zu single Nodes glauben kann? https://blog.stylite.de/blog/zfs-slog-best-practices/
Es ist wie so häufig eine Abwägung zwischen Kosten, Performance und Risikobereitschaft.
Insgesamt sehe ich das so.
Die größte Verbesserung bei ZFS im letzten Jahr sind Hybrid Pools mit Special Vdev. Die können neuerdings sync write aufnehmen, dedup Tabellen und auch zvols. Man kann damit Pools aufbauen bei denen man flexibel per dataset entscheiden kann, ob Daten auf hd oder Flash landen. Zur Wahl stehen dabei nur Metadaten, kleine Files <= Special Block Size oder alle Daten mit recsize <= Small Blocksize z.B. für VMs. Nachträglich kann man Daten mit zfs rewrite oder replikation verschieben.Aber auch das automatisch Tiering "over time nach Reconfiguration der special blocksize" ist meist ok.
L2Arc ist damit ziemlich obsolet. Ich sehe fast keinen Nutzen mehr für L2Arc bei denen nicht Special Vdev die viel bessere Alternative wäre. Ich würde ganz klar bei einer dritten SSD eine vierte für 2 x Special Vdev Mirror kaufen. Special Vdev als Z1 wird auch kommen dann ist das eine Option mit drei SSD.
ZFS ist auch bei Absturz beim Schreiben durch CoW sicher und konsistent, ganz im Gegensatz zu "alten" Dateisystemen wie ext4 oder ntfs. Für einen ZFS Filer braucht man daher kein sync write das die letzten Sekunden Schreibaktion in den RAM Schreibcache schützt. Auch eine VM mit ZFS als OS und Daten Dateisystem ist ziemlich sicher, zumindest von der Filesystem Konsistenz. Man muss halt eine Anwendung haben der es egal ist wenn die letzten Sekunden bestätigter Writes verloren gehen können. Anders sieht es aus wenn die VM "alte" Dateisysteme hat. Da sind atomare Schrebvorgänge wie "Schreibe Datenblock und aktualisiere anschließend Metadaten" trotz ZFS darunter nicht geschützt. Ein Absturz beim Schreiben kann eine virtuelle VM Platte beschädigen. Unangenehm weil man dazu keine Warnungen erhält. Auch transktionale Datenbanken sollte man immer durch sync write absichern. Sync weglassen bei einem Hypervisor isr daher fast immer eine schlechte Option. Eine USV kann das Risiko verringern.
Insgesamt sehe ich das so.
Die größte Verbesserung bei ZFS im letzten Jahr sind Hybrid Pools mit Special Vdev. Die können neuerdings sync write aufnehmen, dedup Tabellen und auch zvols. Man kann damit Pools aufbauen bei denen man flexibel per dataset entscheiden kann, ob Daten auf hd oder Flash landen. Zur Wahl stehen dabei nur Metadaten, kleine Files <= Special Block Size oder alle Daten mit recsize <= Small Blocksize z.B. für VMs. Nachträglich kann man Daten mit zfs rewrite oder replikation verschieben.Aber auch das automatisch Tiering "over time nach Reconfiguration der special blocksize" ist meist ok.
L2Arc ist damit ziemlich obsolet. Ich sehe fast keinen Nutzen mehr für L2Arc bei denen nicht Special Vdev die viel bessere Alternative wäre. Ich würde ganz klar bei einer dritten SSD eine vierte für 2 x Special Vdev Mirror kaufen. Special Vdev als Z1 wird auch kommen dann ist das eine Option mit drei SSD.
ZFS ist auch bei Absturz beim Schreiben durch CoW sicher und konsistent, ganz im Gegensatz zu "alten" Dateisystemen wie ext4 oder ntfs. Für einen ZFS Filer braucht man daher kein sync write das die letzten Sekunden Schreibaktion in den RAM Schreibcache schützt. Auch eine VM mit ZFS als OS und Daten Dateisystem ist ziemlich sicher, zumindest von der Filesystem Konsistenz. Man muss halt eine Anwendung haben der es egal ist wenn die letzten Sekunden bestätigter Writes verloren gehen können. Anders sieht es aus wenn die VM "alte" Dateisysteme hat. Da sind atomare Schrebvorgänge wie "Schreibe Datenblock und aktualisiere anschließend Metadaten" trotz ZFS darunter nicht geschützt. Ein Absturz beim Schreiben kann eine virtuelle VM Platte beschädigen. Unangenehm weil man dazu keine Warnungen erhält. Auch transktionale Datenbanken sollte man immer durch sync write absichern. Sync weglassen bei einem Hypervisor isr daher fast immer eine schlechte Option. Eine USV kann das Risiko verringern.