Der OVM Manager wurde komplett überarbeitet und basiert nun auf dem Oracle Application Development Framework (ADF), einer Fusion Middleware Komponente. Dies bedeutet, dass neben der XE Datenbank auch der Oracle WebLogic Application Server installiert wird und somit ein deutlicher Anstieg der Installationsgröße (das DVD Image ist mit 2,4 GB 4 mal so groß wie das CD-Image bei OVM 2) und des Ressourcenbedarf (4 GB Hauptspeicher) zu verzeichnen ist. Allerdings bietet die Oberfläche auch mehr Funktionalität: So gibt es - das wird ehemalige Java Enterprise Manager Benutzer freuen - eine interaktive Baumstruktur, trotzdem bleibt die Oberfläche weiterhin komplett HTML basierend und damit über jeden aktuellen Browser bedienbar. Außerdem erlaubt die Verwendung der neuen Technologie zukünftig die einfache Integration in den kommenden Enterprise Manager, womit die schwierige entweder- oder Entscheidung (Entweder Enterprise Manager oder Oracle VM Manager) zur Verwaltung von OracleVM der Vergangenheit angehört.

Für produktive Umgebungen wird übrigens dringend empfohlen, nicht die bereitgestellte XE Version der Datenbank zu verwenden, sondern eine Standard oder Enterprise Edition der Datenbank zu installieren. Wichtig: Wird diese Datenbank nur als Repository für den OVM Manager verwendet, ist sie (wie beim Enterprise Manager auch) im Rahmen des sogenannten "Restricted Use" kostenlos.

Aber nicht nur am Look & Feel des neuen OVM Managers erkennt man die Verbesserungen, sondern auch beim Hinzufügen der eigentlichen OVM Server. Es reicht aus, dem OVM Manager den IP Bereich bekannt zu geben, in dem die OVM Server stehen. Der OVM Manager sucht sich die bestehenden VM Server selbstständig und zeigt diese an. Jede weitere Konfiguration geschieht dann über die graphische Oberfläche. Zu dieser Konfiguration gehört auch die Netzwerkkonfiguration: So kann nun das Bonding (d.h. die Verwendung mehrerer Netzwerkkarten für Loadbalancing und Failover) genauso eingestellt werden, wie sogenannte VLANs (virtuelle Netzwerke zur besseren Trennung/Verwaltung, zum Beispiel aufgrund von Security Richtlinien). Einzig die physikalischen Voraussetzungen wie Switches und Kabel müssen noch "per Hand" am Server installiert werden ;)

Genauso verhält es sich mit dem Zugriff auf das Storage. Auch diese Konfiguration wird komplett im Manager erledigt. Damit sich dies aber nicht nur auf die Einbindung bestehender Storages, NFS Filer und bestehender LUNs beschränkt, hat Oracle das "Storage Connect Framework" eingeführt. Dieses erlaubt dem Oracle VM Manager direkten Zugriff auf die Funktionalität bestehender Storages. Es ermöglicht damit, Storage nicht nur anzulegen, zu löschen und zu erweitern, sondern auch weitgehende Funktionalitäten (wie zum Beispiel) Snapshot Technologien zu verwenden, wenn der Storage Hersteller dies zulässt. Hiermit lässt sich auch physikalisches Storage direkt an eine VM durchreichen, wie es zum Beispiel im RAC benötigt wird, oder die passenden LUNs auf dem Storage System direkt anzulegen. Aber auch wenn der Storage Hersteller kein Plugin für das Storage Connect Framework liefert, so liefert das sogenannte "generische Storage Plugin" die Basis Funktionen zum Anbinden von Storage.

Durch diese neuartige Architektur hat sich aber auch an der Anbindung der OVM Server einiges geändert. Dies hat zur Folge, dass mit dem OVM 3.0 Manager nur Systeme mit Oracle VM 3.0 Server oder höher administriert werden können.

Genau wie den OVM Manager gibt es auch den OVM Server nur noch in der 64-bit Variante. Dies bezieht sich aber nur auf den Hypervisor und dessen Verwaltungssystem der sogenannten Dom0, nicht auf die zu betreibenden Gast Systeme, den DomU. Alle bisherigen VM Gast Systeme werden auch nach einer Übernahme auf einen OVM 3.0 Server unverändert betrieben werden können.

Die Dom0 wurde mit OVM 3.0 nochmals optimiert und weitere unnötige Packages wurden entfernt, was der Security und Performance des Systems zugute kommt. Auch wurden alle Packages auf den aktuellen Stand des Unbreakable Enterprise Kernel (UEK) aktualisiert, entsprechen also in etwa dem OL6 Pendant, allerdings mit einigen Anpassungen. Dadurch wird nun auch die aktuelle Hardware Generation ohne Anpassungen der Dom0 supported. Die aktuelle Version des integrierten XEN Hypervisors ist 4.0 und enthält die damit verbundenen Verbesserungen im Bereich Performance, Sicherheit und Stromsparfunktionen.

Durch diese Verbesserungen erreicht OVM 3.0 beeindruckende Zahlen: Ein einzelner OVM Server kann bis zu 160 CPUs und 2TB an Memory verwenden, und ein einzelnes Gast System kann 1TB an Memory und 128CPUs adressieren.

Die mit Abstand interessanteste Neuerung beim OVM Server ist die Integration des OCFS2 1.8 Dateisystems. Insbesondere da OCFS2 1.8 noch nicht auf normalen Linux Plattformen verfügbar ist (die aktuelle Version ist 1.6), aber auch aus funktionaler Sicht: So gibt es mit OCFS2 1.8 das sogenannte "Instant Cloning". Diese Snapshot ähnliche Funktionalität erlaubt es, Kopien von angehaltenen und laufenden Gast Systemen in Sekundenbruchteilen zu erstellen und somit auch mehrere Systeme gleichzeitig bereitzustellen. Allerdings eignet sich diese Funktionalität nicht als Backup für laufende VMs mit Datenbanken.

Ein Vorteil von Virtualisierung ist die einfache Konsolidierung mehrerer Systeme auf ein System, um Kosten zu sparen. Allerdings gibt es wie häufig eine 2. Seite zu dieser Medaille: Erstens sollten trotz Konsolidierung wichtige Systeme nicht durch andere Systeme ausgebremst werden, andererseits sollte die Virtualisierung so leistungsfähig sein, so viele Systeme wie möglich zu konsolidieren, um vielleicht sogar nicht benötigte Hardware abschalten und somit Stromkosten sparen zu können. Genau aus diesem Grund hat Oracle die regelbasierte dynamische Ressourcenverteilung in OVM 3.0 unter Zuhilfenahme der sogenannten Life Migration eingeführt. Dabei gibt es zwei zusammenarbeitende Mechanismen: Distributed Resource Scheduling (DRS) und Distributed Power Management (DPM). DRS optimiert das System hinsichtlich konstanter Performance, indem die Auslastung der VM Server in Echtzeit überwacht wird und bei Bedarf Gast Systeme von stark verwendeten VM Servern verlagert werden. DPM hingegen versucht, möglichst viele Systeme zu konsolidieren, wenn diese gerade wenig gebraucht werden und kann sogar VM Server "abschalten", um Strom zu sparen. Jederzeit kann DPM aber auf diese Kapazitäten wieder zugreifen, wenn mehr Ressourcen benötigt werden.