Kernel-Log: Morton stellt Aufnahme des Xen-Dom0-Codes in Frage; Dateisysteme fĂĽr SSDs

Andrew Morton fragt bei der Veröffentlichung neuer Xen-Dom0-Patches kritisch, ob es überhaupt noch sinnvoll ist, die erweiterte Xen-Untersützung in den Kernel aufzunehmen. Theodore Tso verrät in seinen Blogs allerlei Details zu Ext-Dateisystemen und SSDs.

In Pocket speichern vorlesen Druckansicht
Lesezeit: 13 Min.
Von
  • Thorsten Leemhuis
Inhaltsverzeichnis

In einer Antwort auf kürzlich an die Linux-Kernel Mailing List (LKML) zur Begutachtung eingesandte Xen-Dom0-Patches fragt Andrew Morton, ob es überhaupt noch sinnvoll sei, die Kernel-Erweiterungen zum Betrieb als federführende Xen-Domäne (Dom0) in den Hauptentwicklungszweig von Linux aufzunehmen. So stellte er die Frage, ob Xen nicht immer noch der "alte" Weg zur Virtualisierung sei, während sich die Welt in eine "neue" Richtung zu KVM bewege; auch stellt er zur Diskussion, ob die Linux-Entwickler eine Aufnahme der Xen-Dom0-Unterstützung in drei Jahren vielleicht bereuen würden ("I hate to be the one to say it, but we should sit down and work out whether it is justifiable to merge any of this into Linux. I think it's still the case that the Xen technology is the "old" way and that the world is moving off in the "new" direction, KVM? In three years time, will we regret having merged this? ").

Daraus entstand eine Debatte um das Für und Wider sowie die verschiedenen Vor- und Nachteile von Xen und KVM. Der langjährige Xen-Entwickler Jeremy Fitzhardinge, der von ihm und anderen entwickelten Xen-Dom0-Patches an die LKML geschickt hatte , warb in dem Rahmen stark für Xen. Er bekam aber auch von anderen bekannten Linux-Entwicklern einiges an Gegenwind. Unter anderem von Nick Piggin und Ingo Molnar – letzterer dürfte als einer der Verwalter des Kernel-Codes zur Unterstützung der x86-Architektur bei der Entscheidung um die Aufnahme der Xen-Unterstützung ein gewichtiges Wörtchen mitzureden haben. Getroffen ist eine Entscheidung aber wohl noch nicht – trotz der von Morton angeregten Diskussion und den Einwürfen von anderen Kernel-Hackern ist es daher durchaus möglich, dass vielleicht schon die übernächste Linux-Version 2.6.30 Xen-Dom0-Code auf Basis dieser Patches bieten wird.

Wie es dazu kam

Beim Entwicklungsmodell des Linux-Kernels sind Prognosen ohnehin sehr schwierig, da viele Entwickler und nicht zuletzt Linus Torvalds eine Aufnahme von Patches erheblich beschleunigen oder verlangsamen können. Ursprünglich hatte Morton bereits vor vier Jahren eine baldige die Aufnahme der Xen-Unterstützung in den Linux-Kernel prophezeit. Die Kernel-Entwickler waren jedoch schon zu der Zeit mit einigen Eigenschaften an der Integration in den Kernel-Quellen unzufrieden und forderten Änderungen vor der Aufnahme.

Während die Xen-Entwickler daran arbeiteten, erschienen andere Linux-spezifische Virtualisierungslösungen wie KVM (Kernel Based Virtual Machine) und Lguest (anfangs Lhype). Die Kernel-Entwickler drängen daraufhin auf eine Schnittstelle, damit der Linux-Kernel als paravirtualisierter Gast unter all diesen und anderen Virtualisierungslösungen möglichst gut arbeitet, ohne für jeden der Hypervisor größere Mengen an speziellem Code in den Kernel mitzubringen. Maßgeblich unter der Leitung des Lguest-Entwickler entstand daraufhin die paravirt_ops genannte Abstraktionsschicht, die mit Linux 2.6.20 den Weg in den Hauptentwicklungszweig von Linux fand.

Mit eben dieser Version nahmen die Entwickler aber auch die Virtualisierungslösung KVM in Linux auf. Die war zu der Zeit erst wenige Monate alt, fügte sich aber deutlich besser als die Xen-Unterstützung in den Kernel ein und stellte nach Ansicht mancher Kernel-Hacker die technisch deutlich elegantere Lösung dar, da sie den Kernel selbst zum Hypervisor macht und dabei auf die Infrastruktur des Kernels (Scheduler, Speicherverwaltung, Treiber) zurückgreift, während bei der Xen-Hypervisor dem Linux-Kernel vorgeschaltet ist.

KVM erfordert allerdings für seine Arbeit CPUs mit Virtualisierungsfunktionen wie AMD-V oder Intel VT. Xen kann diese Funktionen ebenfalls nutzen, um unmodifizierte Gastsysteme zu virtualisieren. An Xen angepasste Betriebssysteme laufen unter dem Xen-Hypervisor allerdings mit Hilfe von Paravirtualisierung auch als Gast, wenn die CPU keine solchen Funktionen bietet. Diesen Unterschied führt Fitzhardinge jetzt als einen der Vorteile von Xen an – alle neueren x86-Server-Prozessoren sowie viele Desktop- und Notebooks-CPUs bieten heute allerdings Virtualisierungsfunktionen.