OLVM

OLVM ist eine zentrale Management-Plattform für die KVM-Virtualisierung. Anders als das masterfreie Proxmox-Modell setzt OLVM auf eine zentrale Engine (eine Java-Anwendung auf oVirt-Basis), die Hosts, VMs, Netzwerke und Storage verwaltet und Web-Konsole sowie REST-API bereitstellt.

Die virtuellen Maschinen laufen auf Oracle-Linux-KVM-Hosts mit VDSM-Agent und libvirt. Organisiert wird alles in der Hierarchie Data Center → Cluster → Host: Eine Engine kann mehrere Rechenzentren und Cluster zentral steuern.

Diese Funktionen heben OLVM über einen reinen Hypervisor-Manager hinaus und sind seine eigentlichen Alleinstellungsmerkmale:

Die Self-Hosted Engine macht den zentralen Verwaltungspunkt selbst hochverfügbar: Sie läuft als VM, und HA-Agenten auf den Hosts überwachen sie über ein Shared-Storage-Metadaten-Volume. Fällt der Host der Engine aus, startet ein anderer Host sie neu.

Für die VMs greift HA über Fencing: Verliert ein Host die Verbindung zum Manager (non-responsive), wird er über sein Power-Management (IPMI, iDRAC, iLO und weitere Agenten) sauber abgeschaltet und seine HA-VMs starten auf anderen Hosts neu. VM-Leases (Sanlock-basiert) sichern zusätzlich ab, dass eine VM nicht doppelt läuft.

OLVM bringt fünf eingebaute Cluster-Scheduling-Policies mit (u. a. gleichmäßige Verteilung und Power Saving) sowie Affinitäts- und Anti-Affinitätsgruppen mit harter oder weicher Durchsetzung. So lassen sich VMs gezielt zusammen- oder auseinanderhalten, etwa für Lizenz- oder Ausfallsicherheitsgründe.

Für leistungskritische Workloads gibt es vollständige NUMA-Unterstützung: vCPUs und Speicher lassen sich an physische NUMA-Knoten binden (Pinning), eine virtuelle NUMA-Topologie an das Gastsystem durchreichen und beim Migrieren automatisch an den Ziel-Host anpassen.

Das granulare QoS wirkt auf drei Ebenen: CPU-Limit, Netzwerk-Shaping pro vNIC und Storage-QoS mit IOPS- und Durchsatz-Limits pro virtueller Disk. Damit bremst ein einzelner Gast nicht die geteilte Infrastruktur aus.

Das RBAC vergibt Rechte als Tripel aus Benutzer, Objekt und Rolle und vererbt sie entlang der Hierarchie Data Center → Cluster → VM. Benutzer kommen über das AAA-Modul aus Active Directory, LDAP oder FreeIPA. Zusammen ergibt das eine feingranulare, mandantenähnliche Verwaltung.

Über Ressourcen-Quotas pro Data Center lassen sich zusätzlich CPU-, Speicher- und Storage-Kontingente an Benutzer und Gruppen vergeben (kein Cloud-Multi-Tenancy, aber wirksame Kontingentierung mit Soft- und Hard-Limits).

OLVM bringt eine inkrementelle Backup-API mit Changed Block Tracking mit (produktiv nutzbar ab OLVM 4.5). Sie sichert nur geänderte Datenblöcke und ist die Schnittstelle, über die Enterprise-Backup-Lösungen wie Veeam, Storware oder Commvault OLVM einbinden. Ein eigenes Backup-Werkzeug für den Produktivbetrieb ist es nicht; die Sicherung übernimmt das angebundene Backup-Produkt.

Für die VMware-Ablösung gibt es einen VMware-Import (über einen vCenter-/ESXi-Provider im Portal) auf Basis von virt-v2v, dazu OVA-Import und -Export. Neue VMs entstehen aus Templates mit Cloud-init (Linux) oder Sysprep (Windows); Disks laufender VMs lassen sich per Live Storage Migration zwischen Storage-Domains verschieben.

Neben klassischen logischen Netzen, VLANs und Bonding (LACP) bietet OLVM ein optionales softwaredefiniertes Netzwerk über den OVN-Provider (Open Virtual Network). Damit gibt es logische L2-/L3-Overlays, Security Groups (Firewall-Regeln pro VM), DHCP und IPv6, optional mit IPSec-verschlüsselten Tunneln zwischen den Hosts.

Für latenzarme Netz-Workloads unterstützt OLVM SR-IOV: Eine VM bindet ihre virtuelle Netzwerkkarte direkt an eine Virtual Function der physischen NIC und spart so CPU-Last und Latenz.

OLVM ist vollständig automatisierbar. Jede Funktion der Weboberfläche steht auch über die REST-API bereit, ergänzt um SDKs für Python, Java und Ruby.

Für Infrastructure as Code gibt es eine gepflegte Ansible-Collection (ovirt.ovirt) mit über 60 Modulen sowie einen offiziellen Terraform-Provider. Damit lassen sich Cluster, VMs, Netze und Storage reproduzierbar ausrollen, ein klares Plus für planbaren Betrieb.

Für leistungskritische Workloads gibt es den VM-Typ High Performance, der per Klick CPU-Pass-Through, IO-Threads, Headless-Betrieb und das Pinning von IO- und Emulator-Threads setzt, ergänzt um Hugepages und NUMA-Pinning. Wegen des Pinnings ist die Live-Migration solcher VMs eingeschränkt.

Für GPU-Workloads unterstützt OLVM PCI-Passthrough und vGPU über Mediated Devices (z. B. NVIDIA); auch hier schränken durchgereichte Geräte die Live-Migration ein. Für hohe Dichte sorgen KSM (Speicher-Deduplizierung), Memory-Ballooning sowie CPU- und Memory-Hotplug.

OLVM bringt Monitoring ab Werk mit: Ein Data Warehouse sammelt und aggregiert die Metriken, und Grafana ist als Monitoring-Portal integriert, mit rund zwei Dutzend vorkonfigurierten Dashboards für Data Center, Cluster, Hosts und VMs. Für den Einstieg ist kein separates Monitoring-Tool nötig.

Als Storage-Domains sind NFS, iSCSI (mit Multipath über iSCSI-Bonding) und Fibre Channel (mit Multipath) sowie lokaler Storage offiziell dokumentiert. iSCSI- und FC-Pfade sind also redundant auslegbar.

Auch Ceph lässt sich anbinden, und zwar auf dem dokumentierten Pfad: Ceph bringt ein NFS-Gateway mit (CephFS über nfs-ganesha, optional Objektspeicher über RGW). Da NFS eine unterstützte OLVM-Storage-Domain ist, kommt verteilter Ceph-Speicher so direkt über die Engine in OLVM, je nach Setup samt NFS-Stärken wie pNFS und NFS over RDMA. Die Engine muss Ceph dafür nicht nativ sprechen.

Ein echter Sonderfall: Oracle erkennt Oracle Linux KVM (mit OLVM) als Hard-Partitioning-Technologie an. Über CPU-Pinning lassen sich Oracle-Datenbank-Lizenzen damit auf die gepinnten Kerne statt auf den ganzen Host begrenzen, ein potenziell erheblicher Kostenvorteil.

OLVM unterstützt zwei DR-Modelle. Beim Active-Active (Stretch Cluster) spannt sich ein Cluster über zwei Standorte; VMs ziehen bei Ausfall automatisch um. Voraussetzung sind synchron replizierter, beidseitig beschreibbarer Storage, L2-Konnektivität und niedrige Latenz (Richtwert bis 7 ms bei Self-Hosted Engine).

Beim Active-Passive stehen zwei getrennte OLVM-Umgebungen, das Failover läuft per Ansible-Playbook. Eine Einschränkung des Stretch-Modells: Kann beim Site-Ausfall der Storage-Pool-Manager nicht gefenced werden, sind bestimmte Storage-Operationen blockiert. Das gehört in die DR-Planung.

Oracle Linux ist vollständig kostenfrei nutzbar, inklusive Sicherheits-Updates aus den öffentlichen Repos. OLVM wird ohne separaten Kauf direkt darüber installiert: ein Release-Meta-Paket (z. B. oracle-ovirt-release-45-el8) aktiviert die nötigen Repos, danach folgt die Engine per dnf.

Kostenpflichtig ist nur der optionale Oracle-Linux-Support (mit Ksplice für Kernel-Patching ohne Neustart). Für den Betrieb von OLVM ist er nicht zwingend. Host-Provisionierung lässt sich zusätzlich über Foreman/Katello (als External Provider) automatisieren.