Vor einigen Jahren sorgte Red Hat für Unmut in der Linux-Gemeinde, weil das grafische Verwaltungstool für die eigene Virtualisierungslösung RHEV einen Windows-Rechner voraussetzte. Die Microsoft-Altlast rührte daher, dass Red Hat im Jahr 2008 nicht nur den vom israelischen KVM-Spezialisten Qumranet entwickelten KVM-Hypervisor übernommen, sondern gleich die ganze Firma gekauft hat, mitsamt eines zum damaligen Zeitpunkt fast fertigen Desktop-Virtualisierungs-Produkts, das auf Windows basierte.
Mit RHEV-Version 3.0 [1] haben die Red-Hat-Entwickler zwar alle Bestandteile der Management-Komponente "RHEV-M" von C# auf Java portiert, der Einsatz der Administrator Console erfordert bei RHEV aber offiziell immer noch eine Windows-Maschine mit Internet Explorer 7 oder größer, weil das auf oVirt basierende Frontend noch nicht alle Features des Vorgängers beherrscht. Seit Red Hat oVirt unter der Apache-Open-Source-Lizenz der Gemeinschaft übergeben hat und die Software unter dem Dach des gleichnamigen oVirt-Projektes von Suse, Canonical, Cisco, IBM, Intel und anderen gemeinsam weiterentwickelt wird, hat oVirt das Potenzial, den kommerziellen Lösungen von VMware, Citrix und Microsoft eine leistungsfähige, freie Cloud-Management-Plattform als Alternative gegenüberzustellen, die keineswegs nur Red-Hat-basierte Strukturen verwaltet.
Das oVirt-Projekt basiert auf zahlreichen von Red Hat entwickelten Technologien mit der Kernel-based Virtual Machine (KVM) und der Virtualisierungs-API Libvirt. Die erste finale und stabile oVirt-Version 3.0 ist als Technologie-Preview in Red Hats kommerzieller Virtualisierung-Lösung RHEV 3.0 [1] enthalten, die seit Januar diesen Jahres verfügbar ist.
Eine Installation von RHEV für Server besteht typischerweise aus einem (oder mehreren) Hypervisor-Hosts "RHEV-H", einem Management-Sytem "RHEV-M", das wahlweise auf RHEV oder RHEL basierende Hypervisor-Systeme verwaltet, sowie einem Host für die Administrationskonsole und einem PC (Windows oder Linux) für das Benutzer-Portal. Hinzu kommen ein oder mehrere Storage-Systeme (SAN, iSCSI).
Die jeweiligen minimalen und empfohlenen Hardware-Anforderungen zeigt Red Hats Promo-Seite [2] beim Herunterladen der Evaluierungs-Version von RHEV 3. Red Hat schlägt zum Testen auch ein Minimal-Setup vor. Das besteht aus einem Enterprise Virtualization Manager Server (RHEV-M) mit einer lokalen ISO-Domain und einem Hypervisor-Host. Ersterer soll laut Red Hat nach Möglichkeit ein RHEL6-System mit Quadcore-Prozessor, 16 GByte RAM, 50 GByte lokalem Festplattenspeicher und 1-GBit-Netzwerkkarte sein, der die erwähnte ISO-Domain zur Verfügung stellt.
Als Client für die Admin Console empfiehlt Red Hat ein Windows-7-System. Bleibt noch der Mini-Hypervisor RHEV-H für den Virtualisierungs-Host. Der lässt sich wahlweise als 172 MByte kleine Evaluierungs-Version von Red Hat herunterladen, darf aber laut Red Hat auch RHEL 6 (also auch CentOS 6) oder Fedora 17 sein. Als Hardware empfiehlt Red Hat einen Dual-Core-Server mit 16 GByte RAM, und 50 GByte Speicher sowie eine 1-GBit-Netzwerkkarte. Dessen CPU muss allerdings zwingend ein 64-Bit-System mit Virtualisierungs-Erweiterung AMD-V oder Intel VT sein.
RHEV 3 basiert im Gegensatz zu RHEV 2.2 nicht mehr auf RHEL 5, sondern auf RHEL 6, was KVM-seitig eine Reihe von Vorteilen mitbringt. Gastsysteme können damit beispielsweise bis zu 64 virtuelle CPU-Kerne und bis zu 2 TByte Arbeitsspeicher verwenden. Ferner unterstützt der RHEL6-Kernel alle aktuellen KVM-Techniken wie KSM (Kernel Shared Memory), Vhost-Net, Transparent Huge pages (THP) oder X2apic. Fehlt noch eine weitere Komponente im RHEV-Virtualisierungsbaukasten "RHEV für Desktops", ein Add-on für RHEV-Server, das eine Virtual Desktop Infrastructure (VDI) ermöglicht. Die Kommunikation zwischen einem Client oder Thin-Client und via RHEV virtualisiertem Desktop-Betriebssystem läuft dabei über das von Qumranet entwickelte Spice-Protokoll, das Red Hat ebenfalls inzwischen an zahlreichen Stellen verbessert hat, sodass Nutzer beispielsweise auch beliebige USB-1.1/2.0-Geräte an den Clients nutzen können, welche Spice an das entfernte virtualisierte Desktop-Betriebssystem weiterreicht.