Infos dazu gibt es in Marc Hamiltons Weblog oder bei ITpro.

Der bloggende CEO sah sich dadurch wohl genötigt etwas Licht ins Dunkel zu bringen. Neben den Bemühungen den Kurs von Sun im X64-Markt darzustellen gab es dann noch vage Neuigkeiten zu verkünden.

In Kürze wird eine neue Hypervisor-Plattform namens “Project Virginia” von Sun vorgestellt Sun wird dabei neben Solaris und Linux auch die Virtualisierung von Windows unterstützen. Dies wird durch das Abkommen mit Microsoft möglich. Im Gegenzug kann Microsoft Solaris in den Virtual Server offiziell mit aufnehmen. Weiterhin tritt Sun als OEM-Partner von M$ auf.

Schwartz nimmt das Blade6000-System als Beispiel, in dem zukünftig Sparc, Intel und AMD mit Solaris, Windows und Linux als Betriebssysteme versammelt sein können. Kernpunkt soll dabei das einheitliche Management sein. Sowohl Project Virginia als auch VMware werden als Virtualisierungslösung unterstützt.

Wie LDOMs und Xen hierzu passen darf gerätselt werden. Aber harren wir der Dinge, vielleicht kann ich den Sunnies am 26. beim Besuch in München/Heimstetten ein paar Infos entlocken…

Nachtrag:

The register schreibt heute etwas mehr zu Project Virginia.

Nachtrag2:

Nach meinem Besuch in München bleibt diese Geschichte weiterhin nebulös. Es sieht wohl danach aus, daß hier vorhandene und neue Managementfunktionen unter einer Oberfläche zusammenfinden sollen. An der eingesetzten Basistechnologie wie LDOMs ändert dies nichts…

Der Sun-Mitarbeiter Narayan Venka, der an der Entwicklung von LDOMs beteiligt ist, stellt in seinem Blog Technologien vor, die in eine zukünftige LDOM-Version Einzug halten werden und momentan noch als experimentell bezeichnet werden dürfen.

Service Domain / Virtual I/O – Failover

Um die Verfügbarkeit von Guest Domains zu erhöhen wäre ein Failover zwischen 2 Service Domains wünschenswert. Prinzipiell läßt sich das folgendermaßen realisieren:

• Auf den momentanen LDOM-fähigen Servern Sun Fire T1000/T2000 gibt es 2 seperate PCI-Busse, allerdings hängen nur die NICs gleichmäßig auf beiden Bussen verteilt, die lokalen Disks nicht.
• D.h. es werden 2 bootfähige Disk-Controller benötigt, die jeweils in einem Slot eines Busses stecken und auf ein Storage Zugriff haben. Das könnten z.B. FC-HBAs an einem externem SAN-Storage sein. iSCSI- und SCSI-Storage funktionieren auch.
• Zunächst wird also die Firmware mit Hypervisor und im Anschluß die erste Service Domain installiert, die dann alle Hardware besitzt.
• Danach wird der zweite Bus der Service Domain entzogen.
• Nun wird die nächste Service Domain installiert, die nun den zweiten Bus nutzen kann.
• Nun wird für die Guest Domain ein virtueller NIC und eine virtuelle Disk in jeder Service Domain erstellt.
• Jetzt wird die Guest Domain erstellt und ihr die virtuellle Disk und der NIC aus jeder Service Domain zugewiesen. Man beachte: Die Konfiguration der LDOMs hält der Hypervisor, nicht die Service-Domain!
• Nach der Installation der Guest Domain mit einer Disk und einem NIC wird das Failover eingerichtet. Für das LAN-Failover wird IPMP verwendet. Die Verfügbarkeit der Disks wird über Software RAID-1 erreicht (SDS/SVM).
• Nach dem Einrichten der Failover Mechanismen kann eine Service Domain durchgestartet werden und das Guest OS überlebt den Ausfall einer Hälfte der Resourcen. Natürlich ist die Guest Domain kurzzeitig nicht erreichbar (Timeout für IPMP default 10s).

Hier ist das detailierte Konfigurationsbeispiel von Hr. Venka. Ebenfalls gibt es dazu eine bebilderte Erklärung: Teil1 und Teil2.

Alexandre Chartre hat einen weiteren Artikel zum Thema verfaßt, der dabei die Hardwarebesonderheiten der T1000/2000 erklärt.

Erste Infos zur Performance klingen vielversprechend. Allerdings gilt wie immer das Motto: Glaube keinem Benchmark, den du nicht selbst getürkt hast…

Hier noch ein interessantes Video, das demonstriert was Martial Arts mit dem Niagara II zu tun hat. Ausserdem erklärt AliG die enorme Leistungsfähigkeit der CPU.