Nach Aussage der Ubuntu-Entwickler ist der neue Hypervisor Linux Container Daemon (LXD) eigentlich gar keiner (The new hypervisor isn’t a hypervisor, and it’s much, much faster“).

LXD wurde wie der Name nahelegt für die LXC-Container-Technologie entwickelt und soll sehr schnell sein, weil er einige der Nachteile traditioneller Virtualisierungstechnologien, wie den ausladenden Overhead vermeidet. Canonical arbeitet seit geraumer Zeit mit der LXC.Community zusammen. Im Zusammenhang mit dem  LXD- Hypervisor würde LXC quasi als reine Containertechnologie die Client-Seite abbilden, während sich LXD auf Server-Seite um die Virtualisierung kümmert.

Was ist LXD ?

Im Gegensatz zu Docker oder CoreOS-Rocket, die beide primär auf App-Container zielen, ist LXD auf das Erstellen von System-Containern angelegt, ähnlich wie es mit LXC oder OpenVZ bereits seit langem möglich ist. System-Container sind voneinander isolierte Linux-Laufzeitumgebungen, die entweder komplette Linux-Systeme mit oder ohne vorkonfigurierte Anwendungen enthalten.

Ähnlich wie es VMware gerade mit seinem Projekt Photon vormacht, können Docker- oder Rocket-App-Container aber problemlos in einem LXD-Container laufen, welche damit von den Sicherheitstechnologien in  LXD zu profitieren. Dies könnte genau jene Vertrauensebene schaffen, die viele Unternehmen gegenüber reiner Container-Umgebung wie LXC, bei der im Prinzip sämtliche Container in der gleichen Host-Umgebung laufen, derzeit noch haben. Hinzu kommt, dass LXD wie eine ausgewachsene Virtualisierungsumgebung Technologien wie  Live- Migration, Snapshots, Konfigurationsprofile und das Durchreichen von Geräten unterstützt.

Die Idee hinter LXD

Und die Idee dahinter? Canonical formuliert es so: man stelle sich die Geschwindigkeit und Effizienz von Docker mit dem Feeling vollständiger Virtualisierung vor. Man stelle sich weiter vor, man könnte eine neue virtuelle Maschine in weniger als einer Sekunde bereitstellen und zwar hunderte oder tausende davon auf einem Single-Server. Man stelle sich zudem vor, es gäbe eine Hardware-seitige Garantie, dass keine VM eine andere ausspionieren könne. Und man stelle sich vor, man könne jede VM mit einem eigenen isolierten virtuellen Netzwerk ausstatten. Ferner stelle man sich vor, das Ganze funktioniere gleichermaßen auf einem Single Node wie auf einer Millionen Nodes, zwischen denen sich virtuelle Maschinen nach Belieben zur Laufzeit migrieren liessen. Alles mit Hilfe einer sauberen und erweiterbare REST API? Dann habe man eine Vorstellung davon, wohin die Reise mit LXD ginge.

Das Ziel hinter LXD

Das ist das Ziel von Canonicals LXD-Initiative ist kein Geringeres, als den nächsten großen Hypervisor rein für Linux Container-Technologien zu schaffen. Der LX-Daemon auf dem Server soll sich dabei mithilfe der  LXC-Tools auf dem Client  steuern lassen. Optional klappt das aber auch mithilfe des OpenStack-Plugins „nova-compute-lxd“. Es sorgt dafür, das Orchestrieren von Containern über die o. e. REST-API in  OpenStack zu ermöglichen.

Noch nicht für den Produktiveinsatz

Die jetzt ins Repositorium von Ubuntu 15.04 aufgenommene Version 0.7 eignet sich nach Aussage eines der Entwickler allerdings noch nicht für den produktiven Einsatz. Die erste stabile Version  1.0 ist für Anfang 2016 angepeilt. Derweil arbeitet Canonical daran, Chip-Herstellern dazu zu bewegen,  Hardware-seitige Unterstützung für LSD zuzusichern, etwa in der Form, das gegenseitige Absichern und Isolieren von Container fest zu verdrahten. Die Entwicklung der in Go geschriebenen, unter der Apache2-Lizenz stehenden Open-Source-Software  ist momentan auf GitHub beheimatet.