5. Mai 2007Eigenes Projekt · ContainerEigener Beitrag

Container im Jahr 2007: bk99.de mit OpenVZ

Zusammenfassung

Im Mai 2007 lief bk99.de mit OpenVZ, der freien Fassung von Virtuozzo, und am 5. Mai legte ich für die Nutzer der Container eine FAQ zu den typischen Fragen an, von der Uhrzeit bis zum Speicherhunger von Apache. Das war sechs Jahre vor Docker und elf Jahre vor Podman. Dieser Beitrag aus meinem alten Blog zeigt, wie Container damals im Alltag funktionierten, und vergleicht OpenVZ mit LXC, auf das Proxmox VE 2015 umgestiegen ist.

OpenVZ und Virtuozzo

Container waren 2007 unter Linux nichts Neues mehr, nur noch wenig bekannt. Unix kennt seit 1979 chroot, das einem Prozess ein eigenes Wurzelverzeichnis vorspielt. FreeBSD brachte 2000 die Jails, unter Linux folgten Linux-VServer und das kommerzielle Virtuozzo der Firma SWsoft, das 2000 als erste kommerzielle Container-Technik auf Betriebssystemebene auf den Markt kam.

Den Kern von Virtuozzo gab SWsoft 2005 als OpenVZ frei. Schon im April 2006 konnte OpenVZ laufende Container im Betrieb auf einen anderen Server verschieben. 2006 gab es auch einen ersten Anlauf, OpenVZ in den offiziellen Linux-Kernel zu bringen, über den Golem damals berichtete.

bk99.de als Container

Schon beim Serverumzug im Oktober 2006 hatte ich Teamspeak- und Counter-Strike-Server in eigene chroot-Umgebungen gesperrt. Kurz darauf lief mein Server selbst als OpenVZ-Gastgeber: Dienste und Nutzer arbeiteten in Containern, die damals meist VPS hießen, jeder mit eigenem Root-Zugang, eigenen Prozessen und eigener IP-Adresse, aber alle mit dem Kernel meines Servers.

Belegt ist das durch meine OpenVZ-FAQ, die ich am 5. Mai 2007 für die Nutzer des Servers angelegt habe. Sie sammelte die Fragen, die im Alltag auftauchten:

Wie starte ich einen VPS neu?
Warum stimmt die Zeit auf meinem VPS nicht?
Brauche ich einen NTP-Server?
Gibt es ein initiales iptables-Skript für den VPS?
Warum verbraucht der Apache2-Webserver so viel RAM?
Wie bekomme ich aktuelle Antivirensoftware?
Wie bekomme ich lighttpd in eine chroot?
Wie kann ich vorkompilierte 32-Bit-Programme starten?

Von den Antworten ist im Webarchiv nur eine erhalten. Die Fragen zeigen trotzdem, wo OpenVZ im Alltag anders war als ein eigener Rechner.

Ein Kernel für alle

Alle Container auf einem OpenVZ-Server teilen sich einen Kernel. Daraus folgten mehrere der Fragen. Die Uhrzeit gehört dem Kernel, ein Container kann sie nicht selbst stellen; ein eigener NTP-Dienst im Container ist deshalb sinnlos, die Zeit muss der Gastgeber richtig halten. Kernelmodule lädt ebenfalls nur der Gastgeber, und für iptables standen im Container nur die Module zur Verfügung, die der Gastgeber freigegeben hatte. Eine Firewall im Container war deshalb immer ein Kompromiss aus dem, was man wollte, und dem, was erlaubt war.

Die Speicherfalle mit Apache

Die einzige erhaltene Antwort der FAQ handelt von einem Fehler, der im Mai 2007 im Log meines Webservers stand (Archivfassung):

/var/log/apache2/error.log
[alert] (12)Cannot allocate memory: apr_thread_create: unable to create worker thread
[alert] (12)Cannot allocate memory: apr_thread_create: unable to create worker thread

Die Erklärung damals: Der Apache-Worker reserviert für jeden Thread 8 MB Stack, bei den standardmäßig 25 Threads also 200 MB virtuellen Speicher. Ich riet, StartServers und die Spare-Werte zu senken oder gleich den sparsamen Webserver thttpd zu nehmen.

Warum das ausgerechnet unter OpenVZ zum Problem wurde, steckt in den User Beancounters, mit denen OpenVZ die Ressourcen jedes Containers begrenzte. Eine der Grenzen, privvmpages, zählte den reservierten virtuellen Speicher, nicht den tatsächlich genutzten. Ein Programm, das viel Speicher reserviert, aber wenig belegt, scheiterte also an der Grenze, obwohl der Server genug freies RAM hatte. Gezielter als weniger Threads hilft deshalb ein kleinerer Stack, etwa mit der Apache-Direktive ThreadStackSize oder ulimit -s vor dem Start. Spätere OpenVZ-Kernel haben die Begrenzung mit VSwap auf RAM und Swap vereinfacht.

Was sich seitdem geändert hat: OpenVZ und LXC

Docker erschien erst im März 2013 und nutzte anfangs LXC, Podman folgte 2018 und erreichte im Januar 2019 Version 1.0. Bis dahin war unter der Haube viel passiert. OpenVZ brauchte einen eigens angepassten Kernel, der meist auf dem Kernel von Red Hat Enterprise Linux beruhte und damit dem aktuellen Linux hinterherlief. Parallel wanderten die Bausteine für Container in den offiziellen Kernel: Google begann 2006 mit den „Process Containers“, die als cgroups Anfang 2008 mit Linux 2.6.24 erschienen, und Namespaces isolieren Prozesse, Netzwerk und Dateisysteme. LXC setzte diese Bausteine im August 2008 zu Containern zusammen. An den Namespaces und am Werkzeug CRIU, das laufende Prozesse einfrieren und wiederherstellen kann, haben die Entwickler von OpenVZ und Virtuozzo selbst kräftig mitgearbeitet.

	OpenVZ	LXC
Kernel	eigener, angepasster Kernel (meist RHEL-basiert)	unveränderter Linux-Kernel
Isolation	eigene Kernel-Erweiterungen	Namespaces des Kernels
Ressourcen	User Beancounters, später VSwap	cgroups
Live-Migration	eingebaut, seit 2006	über CRIU
Verwaltung	vzctl, Vorlagen (Templates)	lxc-Werkzeuge, in Proxmox pct
In Proxmox VE	bis Version 3.4	ab Version 4.0 (Oktober 2015)

Genau deshalb ist Proxmox VE umgestiegen. Proxmox entstand ab 2005, weil OpenVZ weder Sicherungswerkzeug noch Verwaltungsoberfläche hatte; die erste Version vom April 2008 verband OpenVZ-Container mit KVM-Maschinen. Mit Version 4.0 im Oktober 2015 ersetzte LXC das OpenVZ, und Proxmox konnte endlich aktuelle Kernel verwenden. Bestehende OpenVZ-Container ließen sich beim Upgrade zu LXC umwandeln.

Systemcontainer und Anwendungscontainer

OpenVZ und LXC verfolgen dieselbe Idee: Ein Container ist ein vollständiges Linux-System mit Init, Diensten, Benutzern und Paketverwaltung, nur ohne eigenen Kernel. Man nennt das Systemcontainer. Docker und Podman setzen dagegen auf Anwendungscontainer: ein Abbild pro Anwendung, unveränderlich, in Schichten gebaut und schnell ersetzt statt gepflegt.

Beides hat seinen Platz. Für einen kleinen Server, der wie ein eigener Rechner wirken soll, ist ein Systemcontainer bis heute die einfachere Wahl; heute läuft bei mir Proxmox VE, das virtuelle Maschinen und LXC-Container nebeneinander verwaltet. Die Fragen aus meiner FAQ von 2007 stellen sich dort übrigens fast unverändert: Auch ein LXC-Container stellt seine Uhr nicht selbst, lädt keine Kernelmodule und lebt mit Grenzen, die ihm der Gastgeber setzt.

Zahlen im Überblick

Virtuozzo von SWsoft kam 2000 auf den Markt, 2005 wurde der Kern als OpenVZ freigegeben.
Meine OpenVZ-FAQ für bk99.de stammt vom 5. Mai 2007, sechs Jahre vor dem ersten Docker-Release im März 2013.
cgroups erschienen Anfang 2008 mit Linux 2.6.24, LXC im August 2008, Proxmox VE im April 2008.
Proxmox VE nutzte OpenVZ bis Version 3.4 und wechselte mit Version 4.0 im Oktober 2015 auf LXC.
Podman erschien 2018, Version 1.0 im Januar 2019.

Referenzen

Bemerkungen

Dieser Beitrag beruht auf meiner OpenVZ-FAQ vom 5. Mai 2007 aus dem alten Plone-Blog; 2026 habe ich ihn aus dem Webarchiv geholt, ausformuliert und um die spätere Entwicklung ergänzt. Die FAQ ist dort nur als Fragenliste erhalten, die Antworten bis auf die zu Apache nicht. Die Erklärungen zu Uhrzeit, Kernelmodulen und Speichergrenzen in diesem Beitrag sind meine heutige Einordnung, nicht der Text von damals.
SWsoft benannte sich Ende 2007 in Parallels um; Virtuozzo ist seit Dezember 2015 wieder ein eigenständiges Unternehmen.

OpenVZ-FAQ von 2007 im Webarchiv