Proxmox und Docker ohne ECC RAM

[kali-hi]

Warum VM in VM?

Ich betrachte docker container als VM.

Es hat sich nunmal gezeigt, dass der letzte Weg am besten ist.

Öhhhm Nein?! das ist deine subjektive Wahrnehmung.

Hier scheint Basiswissen zu Hypervisorn und Virtualisierungstechnologien zu fehlen!

Ja, dann nenne mir die Docker Docs, die besagen, man soll Docker in Proxmox installieren.

Ich weiß auch nicht, warum dieses Thema jetzt wiederhochkocht... Ich dachte, das wäre erledigt. Aber für einige anscheinend nicht.

 

[h00bi]

trau mich noch net aufn die 9er zu gehen

Letzte Woche 5 Hosts aktualisiert, nutze den "pve8to9" Guide mit dem offiziellen Test Tool.
Und mittlerweile gibt's ja schon 9.1

 

[Azghul0815]

Inwiefern ist Proxmox bitte Konkurrez zu docker?

Proxmox nicht, der LXC schon eher.
Sind ja beides Container-Formate. Mich würde ja K8s reizen da lernst man wirklich was fürs Business, aber die liebe Zeit und Lust

 

[gaym0r]

Ich betrachte docker container als VM.

Da fängt es schon an. Container und VMs sind technisch unterschiedliche Dinge.

Öhhhm Nein?! das ist deine subjektive Wahrnehmung.

Nein, das ist nicht meine subjektive Wahrnehmung, sondern die Erfahrung tausender User und Herstellerempfehlungen. Nennt sich Best-Practise.

Ja, dann nenne mir die Docker Docs, die besagen, man soll Docker in Proxmox installieren.

Hä? Docker selbst ist das relativ egal, wo man es installiert. Es funktioniert auch technisch direkt auf dem Hypervisor, keine Frage. Aber es bietet quasi keine Vorteile und nur Nachteile.
Wenn du Docker direkt auf einem Hypervisor laufen lassen willst - warum nicht auch alles andere? Wofür brauchst du überhaupt einen Hypervisor und verschiedene VMs? Man kann auch alles auf einem single-Host laufen lassen.
Bessere Verwaltung, Backups, Snapshots etc. hast du halt mit VMs bzw. Containern. Und dann ist nur die Frage: Lasse ich Docker als VM oder als LXC laufen - und da bietet VM nunmal vorteile.

Ich weiß auch nicht, warum dieses Thema jetzt wiederhochkocht... Ich dachte, das wäre erledigt. Aber für einige anscheinend nicht.

Ich möchte nur technische Falschaussagen korrigieren (z.B. dass Container und VM das gleiche seien)

@Azghul0815 Ich glaube mit Docker 9.1 kommt testweise die native Unterstützung von Docker-Containern. Dann bieten sie beides.

 

[kali-hi]

Dann ist Docker für dich keine Virtualisierungslösung? Ok, ich glaube, wir brauchen nicht mehr diskutieren.

Ergänzung (22. November 2025)

Ergänzung (22. November 2025)

Falschaussagen

Wo hab ich was falsches behauptet?

 

[Azghul0815]

Ich betrachte docker container als VM.

Docker ist wie eine VM ebenfalls eine Form von Virtualisierung, ab hier trennen sich die Konzepte aber deutlich.

Eine VM läuft mit einem komplett eigenen, virtualisierten Betriebssystem. Wenn du ihr 4 CPUs und 8 GB RAM zuweist, reserviert sie diese Ressourcen fix, sobald sie gestartet ist. Auch im Leerlauf bleiben diese 4 CPUs und 8 GB RAM blockiert.

Ein Docker-Container funktioniert anders. Wenn du ihn auf 4 CPUs und 8 GB RAM limitierst, bedeutet das nur, dass er maximal so viel nutzen darf. Benötigt er gerade wenig, werden die Ressourcen vom Host frei für andere Prozesse genutzt. Genau dadurch ist Containerisierung im Alltag deutlich effizienter als klassische VMs.

Für den Heimgebrauch ist das ein grosser Vorteil, vor allem wenn man mehrere Dienste parallel betreiben möchte, ohne ständig mit statisch reservierten Ressourcen zu kämpfen.

EDIT:
Insofern, ich unterscheide auch strikt zwischen VM (Virtuelle Maschine) und Container (LXC, Docker, K8s)

 

[gaym0r]

Dann ist Docker für dich keine Virtualisierungslösung? Ok, ich glaube, wir brauchen nicht mehr diskutieren.

Genau, wir brauchen nicht weiterdiskutieren, da:

• ich nie behauptet habe, dass Container keine Virtualisierung seien.
• Du offensichtlich nichtmal in der Lage bist mehr als einen Satz deiner KI-Antwort zu lesen. Direkt im Satz nach deinem markierten Satz wird beschrieben, dass und wie sich Container von VMs unterscheiden. Ist dir dein Verhalten eigentlich nicht peinlich?

 

[qiller]

Mich würde mal eher interessieren wie das mit der Performance so aussieht, wenn bei Proxmox empfohlen wird, einen Docker Host in einer VM zu betreiben. Desweiteren, wie siehts mit den Virtualisierungsfunktionen der CPUs aus. Gibts da evt. noch weitere Anforderungen wie z.B. Nested Virtualisation? Was ist mit CPUs, die das nicht können?

Ich geb @kali-hi da nämlich insofern recht, dass hier eine Virtualisierungstechnik verschachtelt in einer anderen Virtualisierungstechnik zum Einsatz kommt und das perfromancetechnisch in meinen Augen nach keiner so guten Idee klingt. So ein paar Single-Thread Benchmark- und IOPs-Vergleiche (VM Host vs. VM vs. Container in VM) wären mal nice.

 

[kali-hi]

Ich geb @kali-hi da nämlich insofern recht, dass hier eine Virtualisierungstechnik verschachtelt in einer anderen Virtualisierungstechnik zum Einsatz kommt und das perfromancetechnisch in meinen Augen nach keiner so guten Idee klingt. So ein paar Single-Thread Benchmark- und IOPs-Vergleiche (VM Host vs. VM vs. Container in VM) wären mal nice.

Ja, das meinte ich damit auch. Und ich habe nicht geschrieben, dass man das nicht machen kann/darf/sollte, sondern nur, dass sich für mich zwei geschachtelte Virtualisierungstechniken unlogisch anfühlen, und vermutlich auch mit geringen Performanceeinbußen einhergehen können. (1) Sicherheitsmäßig ist eine zusätzliche, vollständige Isolierung aber sicher nicht falsch - oder auch für das Anlegen von Snapshots oder dem "Herumexperimentieren". Für Daheim ist das sicherlich ein passabler Trade-off.

(1) Eigentlich war das auch nur eine kurze Rückfrage an den Fragesteller gewesen. Mea culpa

 

[gaym0r]

Mich würde mal eher interessieren wie das mit der Performance so aussieht, wenn bei Proxmox empfohlen wird, einen Docker Host in einer VM zu betreiben. Desweiteren, wie siehts mit den Virtualisierungsfunktionen der CPUs aus. Gibts da evt. noch weitere Anforderungen wie z.B. Nested Virtualisation? Was ist mit CPUs, die das nicht können?

Nested Virtualization braucht man nur, wenn man in einer VM nochmals Hardware virtualisieren will, das ist bei einer Docker-VM nicht der Fall.
CPU-Type der VM sollte man auf "Host" stellen.

Ich geb @kali-hi da nämlich insofern recht, dass hier eine Virtualisierungstechnik verschachtelt in einer anderen Virtualisierungstechnik zum Einsatz kommt und das perfromancetechnisch in meinen Augen nach keiner so guten Idee klingt. So ein paar Single-Thread Benchmark- und IOPs-Vergleiche (VM Host vs. VM vs. Container in VM) wären mal nice.

Das ist in fast allen Use-Cases zu vernachlässigen, das einzige was dazu kommt ist der Overhead der VM, Docker selbst performt in der VM normal.

Der Punkt Performance ist auch der einzige Vorteil, den ein bare-metal Docker auf Proxmox bietet. Aber für 2-3% weniger Overhead wirft man halt eine Menge Vorteile der VM weg.

 

[qiller]

das ist bei einer Docker-VM nicht der Fall.

Ah, alright. Find ich ne wichtige Info.

Aber für 2-3% weniger Overhead

Wenn das nur so wenig ist, wär das sicherlich kein Problem. Ich hab mal vor 6 Jahren unsere Zen1 basierte Server CPU durchgebencht. Windows Server 2019 als Hyper-V Host und in der VM auch nochmal Windows Server 2019. Und da waren im Cinebench ST gut 20% zwischen dem Host und der VM.

Edit: Also sind Containertechnologien gar keine wirklichen Virtualisierungen, sondern mehr so Prozess- und Ressourcenabschottungstechniken?

 

[kali-hi]

Edit: Also sind Containertechnologien gar keine wirklichen Virtualisierungen, sondern mehr so Prozess- und Ressourcenabschottungstechniken?

Bin gerade unterwegs und schreibe mit Smartphone, aber ich denke, es kommt darauf an. Zumindest bei Docker bekommen die Container eine Art geschützte Umgebung, in der die Prozesse laufen (eigenes Dateisystem usw.) - wie es bei bei LXC-Container gehandhabt wird, weiß ich gerade nicht.

 

[SavageSkull]

Du musst das so sehen: wenn bei dir Zuhause deine PDFs im paperlessnxg kaputt gehen, dann sind halt deine PDFs kaputt.

Wie oft tritt denn statistisch ein Bitflip bei einer Operation im RAM auf?
Wieviele Operationen im RAM laufen ab, bis eine PDF auf die Festplatte geschrieben wird?
Oder anders gesprochen, wieviele PDFs muß man denn am Stück über welchen Zeitraum schreiben, damit statistisch bei einer PDF ein Bitfehler vorliegt?
Und bei dem gepackten PDF Format finde da nicht auch eine Fehlerkorrektur/Plausibilitätsprüfung statt und der Bitfehler hat möglicherweise gar keine Auswirkung?

Bei der Überlegung finde ich noch den Gedankengang interessant, wie hoch im Vergleich die Wahrscheinlichkeit ist, dass der Bitflip durch einen non-ECC RAM steht, gegenüber dem Rechenprozess in der CPU oder dem Schreib-/Lesevorgang auf der Festplatte, die ja genauso eine Fehlerquelle darstellen?

Gibts dazu Statistiken?

 

[h00bi]

ECC RAM ist, volatile Endkundenpreise außen vor, bei DDR5 26% teurer als als non-ECC, denn du brauchst pro 32bit 1 Chip mehr.
Früher wars einer mehr pro 64bit.

Am Anfang kamen auch erste ECC x72 statt x80 auf, weil man da einen ECC Chip für 2x 32bit teilt und somit einen Chip spart. Hat sich nicht durchgesetzt, ist trotz 12,% Preisvorteil eine Nischenlösung.

Da macht sich - außer Endkunden - schlicht niemand ins Hemd und erstellt Statistiken. Das bezahlt man einfach oder man lässt es.

Bei Servern stellt sich die Frage sowieso nicht, denn RDIMMs ohne ECC gibt's seit Jahrzehnten nicht mehr, auch wenn die Jedec Spec das noch lange mit sich rumgeschleppt hat.

Was Endkunden daheim zusammen basteln und als Homeserver bezeichnen ist bei einer Risikobewertung sowieso eine Vollkatastrophe.

 

[SavageSkull]

Da macht sich - außer Endkunden - schlicht niemand ins Hemd und erstellt Statistiken.

Also ich erwarte durchaus von Datenzentren, dass diese wissenschaftlich prüfen, was mir ihren Daten und Dateisicherheit los ist. Das sollte selbstverständlich sein. Ich behaupte sogar, dass bei Datenzentren sogar Statistiken bezüglich dem Einfluß der Kühlung/Klimatisierung darauf erstellt werden. Das führt nämlich dazu, wie oft Backups notwendig sind, wieviel Backup Platz notwendig ist und wie stark die Klimatisierung ausgeführt sein muß und endet dann nämlich auch in Kosten, was sehr wohl wichtig ist.

Was Endkunden daheim zusammen basteln und als Homeserver bezeichnen ist bei einer Risikobewertung sowieso eine Vollkatastrophe.

Nach welchem Maßstab?
Für das, was in einer Firma steht und auf denen ihr System läuft? Für das was ein Microsoft bei Azure einsetzt?
Klar ist das nichtmal ansatzweise auf dem Level.
Allerdings ist deren Anwendung auch nichtmal ansatzweise vergleichbar, mit dem was auf einem Homeserver bei Otto Normal User daheim steht.
Wenn da ein PaperlessNGX- und ein PiHole-Docker auf einem NAS laufen, ist die Hardware schon fast wieder Overkill. Das machen genauso viele Anwender auf einem Raspberry Pi auf einer SD Speicherkarte ohne Backup.

Da macht es durchaus Sinn sich mal mit solchen Statistiken zu befassen und zu fragen, ist das für meine Anwendung relevant? Ich finde es auch interessant, ob ich nachher ein Fazit ableiten kann, ob es Sinn macht den Zyklus für Backups bei mir zu erhöhen oder zu lassen.

 

[Azghul0815]

Was Endkunden daheim zusammen basteln und als Homeserver bezeichnen ist bei einer Risikobewertung sowieso eine Vollkatastrophe.

Kommt drauf an, wie du die Risiko Bewertung ansetzt.
Wenn mein Paperless.ngx auf einmal weg ist, ist das maximal ärgerlich, führt dazu das ich bei der nächstens Steuererklärung in Stress komme, weil ich Dokumente neu beantragen muss aber mehr auch nicht.
Wenn da nun ein Bit Kippt...fällt das vermutlich nicht auf.

Und Backups sind vorhanden...
Ich kenne in meinem Bekanntenkreis keinen, der wie ich so viel digitalisiert hat. Die haben alle ihre Ordner aus Papier....wenns brennt ist das definitiv alles weg