Oracle Linux Virtualization Manager (OLVM) für Hardpartitioning - SSO Authentication Fehler

Der Oracle Linux Virtualization Manager ist eine der wenigen verbliebenen Optionen, Hard Partitioning durchzuführen, um den Einsatz von Oracle-Lizenzen auf einem System zu beschränken.
Im vorliegenden Fall hatte ein Kunde bereits eine (veraltete) OLVM Umgebung mit drei Servern mit jeweils zwei CPU-Lizenzen für die Oracle-Datenbank, also insgesamt sechs CPU-Lizenzen, was dem Einsatz von zwölf Cores auf der Intel/AMD-Umgebung entspricht. Aufgrund von Hardware-Wechselzyklen wurde das vorhandene OLVM nicht upgegradet, sondern neu installiert.
Die Umgebung im neuen Umfeld besteht nun aus zwei Nodes mit jeweils 8 Cores, also insgesamt 16 und einer OLVM-Engine auf einer zusätzlichen VM (in VMWare). Um nun eine Nachlizenzierung der Oracle-Datenbank zu vermeiden und da bereits Expertisen im Haus sind, lautete die Anforderung, beim Umzug der virtuellen Maschinen (VMs) die CPU Cores bzw. Threads zu begrenzen.
Dies geht normalerweise relativ einfach, in dem man den wenigen Schritten im Dokument https://www.oracle.com/a/ocom/docs/linux/ol-kvm-hard-partitioning.pdf folgt. Es muss olvm-vmcontrol auf dem Engine-Host nachinstalliert werden und dann kann mittels des Einsatzes des olvm-vmcontrol mit einem Befehl das CPU-Pinning auf die Threads vorgenommen werden.
Leider lief der Kunde allerdings bei der Ausführung von olvm-vmcontrol in einen Fehler: Entweder hieß es, dass sich der Benutzer admin@internal wegen falscher Credentials nicht verbinden kann, oder dass der eigentlich auf der Oberfläche der Engine verwendete admin@ovirt überhaupt nicht existiert:

‘Error during SSO authentication "access_denied" : "Cannot authenticate user No valid profile found in credentials.."’

Das Problem war aber kein falsches Passwort, sondern, dass KeyCloak während der Installation (never change default values, if unsure ist nicht immer ein guter Ratgeber) als Standardinstallation vorgeschlagen wurde. KeyCloak ist noch “experimentell” und verantwortlich dafür, dass sich olvm-vmcontrol nicht mit der Engine verbinden kann.

Ob KeyCloak installiert ist, kann man auf dem Host, auf dem die Engine läuft, einfach prüfen:
grep KEYCLOAK_BUNDLED /etc/ovirt-engine/engine.conf.d/12-setup-keycloak.conf

Existiert hier der Wert “True”, läuft man definitiv in das Problem, dass sich olvm-vmcontrol nicht an der OLVM Engine anmelden kann. Glücklicherweise gibt es dafür einen Lösungsweg - KEYCLOAK muss disabled werden. Da das einige Schritte sind, die durchgeführt werden müssen, verweisen wir hier auf den entsprechenden Eintrag im Support-Portal von Oracle unter der Note KB495706 (einfach in support.oracle.com in der Suche eintragen).

Wurde das Disablen entsprechend durchgeführt, kann nachfolgend olvm-vmcontrol mit dem Benutzer admin@internal und das CPU/Thread-Binding an die VM wie gewünscht durchgeführt werden. Für nachfolgende Installationen weiß der Kunde jetzt, dass KeyCloak gleich bei der Konfiguration der Engine zu Beginn nicht mit verwendet werden sollte.

Um eine möglichst gleichmäßige Auslastung der CPU NUMAs zu erreichen, sollte übrigens beim Pinnen der Threads darauf geachtet werden, dass diese möglichst auf die Thread-Nummern gleichmäßig über die vorhandenen NUMAs (in diesem Fall 2) verteilt werden. Nicht für den Betrieb von Oracle-Lizenzen vorgesehene VMs können übrigens dann auf die übrigen Threads verteilt werden. 

Einen Nachteil hat das Pinnen der CPUs allerdings - Live Migrationen von einer VM von einem Node auf einen anderen wird nicht mehr unterstützt. Es muss also die VM gestoppt, die Definition bearbeitet (Hosts) und die VM neu gestartet werden. Ein (kleiner) Tribut, der da im Gegenzug zu den Lizenzersparnissen gezollt werden muss.