24. Mai 2024

Von RHV/oVirt zu Proxmox

Per Ende August 2024 wird Red Hat den Support für RHV einstellen. Die Zukunft des oVirt Projekts ist damit zwar noch nicht besiegelt, sieht aber sicher nicht mehr gleich rosig aus, wie mit IBM im Rücken. Als ich am Wochenende wieder einmal meine oVirt Engine verschossen hatte, war es für mich an der Zeit, RHV/oVirt hinter mir zu lassen und mit Proxmox etwas Neues auszuprobieren.

Allgemein
Digital Transformation
Managed Services & Operations
Von oVirt zu Proxmox

Da einige Systemengineers in unserem Team bereits Proxmox zu Hause erfolgreich einsetzen, haben auch wir uns entschlossen, dieses Jahr im Sommer unsere RHV Umgebung im Keller durch Proxmox zu ersetzen. Nun kam für mich die Migration etwas schneller als erhofft. Wie einfach das Ganze geht, möchte ich euch in diesem Blog aufzeigen. Eventuell könnte dies auch für von Broadcom geplagte VMWare User interessant sein.

Rant aka how i killed my oVirt

Man sollte nicht gleichzeitig die Engine VM patchen und auch den Hypervisor, auf dem die Engine gerade läuft. Eventuell ist es so oder so nicht das beste Konzept, den Manager in einer VM drehen zu lassen, welche auf dem Hypervisor läuft, der von der Engine verwaltet wird.

Was nun?

Für mich war bereits klar, dass ich früher oder später von RHV/oVirt auf Proxmox migrieren will. Da meine Engine wieder einmal nicht mehr bootete (bzw. ich auf jeden Fall nicht mehr zugreifen konnte, da der Konsole-Zugang via virsh bei oVirt schon immer eher Glücksache war), war für mich der Moment gekommen, zu migrieren.

Mein Setup besteht aus zwei NUCs als Hypervisor. Als Storage dient ein NAS, welches via nfs angebunden ist. Am Wochenende bin ich eher der Typ, der «einfach mal probiert», statt stundenlang Dokumentationen liest. (Vor allem, wenn es um mein Heimlab geht. Darum geht das auch immer wieder mal hops, aber so lernt man ja auch, wie man das Ganze wieder zusammen schustert…). Also entschied ich mich, ein NUC mit Proxmox neu zu installieren und das andere Mal mit oVirt zu belassen. So könnte ich jederzeit darauf zurückgreifen, um dort die Engine wieder neu aufzubauen.

Also Proxmox ISO herunterladen, auf meinen Ventoy-USB-Stick pappen und los gehts. Oder auch nicht, mein Ventoy war zu alt, aber ein Update half zum Glück. Im zweiten Anlauf bootete der Installer dann auch und mit etwas «Weiter… Weiter… Fertigstellen» ist der Hypervisor installiert.

Anschliessend konnte ich mich via Webinterface verbinden. Ich brauchte zwei bis drei Minuten Geklicke, um mich zurechtzufinden. Danach konfigurierte ich dann als Erstes das NAS als nfs-Storage ( man muss diesen auch aktivieren, das ging mir beim ersten Konfigurieren unter. Einfach die Checkbox activate anklicken). Natürlich erkannte Proxmox die Storage-Domain von oVirt nicht. Kurz gegoogelt, stosse ich schnell auf einen hilfreichen Kommentar.

Das ist bereits alles, was für die Migration nötig ist:

qm create 100  --name mymigratetvm
qm disk import 100 /path/to/oVirt/image $storage 

Das ganze Sizing von Memory und CPU nahm ich im Anschluss im Webgui vor.

Troubles

Welche Disk gehört wozu?

oVirt/RHV macht es einem ja zum Glück ganz einfach, herauszufinden, welche Disk zu welcher VM gehört, wenn man mal die Engine verloren hat. Jede VM trägt eine 37-stellige UID. Jede Disk trägt ebenfalls eine 37-stellige UID und zusätzlich ein .meta und ein .lease File. Also alles easy, im .meta-File steht ja ganz sicher der Name der VM.

root@proxmox02:~# cat /mnt/pve/NAS/97c358d4-bb9d-4d1f-a2ad-1bcf6595c669/images/54b1b742-2180-414b-a163-3fe3ee8bc36d/2b30250a-2e59-4c2b-ad25-beb226750a7a.meta CAP=21474836480 CTIME=1563029277 DESCRIPTION={"DiskAlias":"GlanceDisk-fe03ebf","DiskDescription":"CentOS 7 Generic Cloud Image v1901 for x86_64 (fe03ebf)"} DISKTYPE=DATA DOMAIN=97c358d4-bb9d-4d1f-a2ad-1bcf6595c669 FORMAT=COW GEN=0 IMAGE=54b1b742-2180-414b-a163-3fe3ee8bc36d LEGALITY=LEGAL PUUID=00000000-0000-0000-0000-000000000000 TYPE=SPARSE VOLTYPE=SHARED EOF

 

Na toll, danke . Das war wohl nichts. Also einfach mal alle Disks importieren, an eine VM anhängen und schauen, ob man da was gemountet kriegt. Dann /etc/hostname ausgeben, so kann man das ganze wieder zusammen puzzeln.UEFI und Co.Alle meine VMs wollten dann immer noch nicht booten, bei gewissen blieb der Bootprozess einfach bei booting from Disk stehen. Was nun? Hurtig das Hirn anwerfen und überlegen … Ah, das sind alles Rocky 9 VMs, die haben per default EFI aktiviert und ich will mit SeaBIOS ran, geht wohl nicht … Also umstellen auf OVMF, booten und voilà, Grub rast vorbei und … …Kernelpanik! glibc CPU does not support x86-64-v2 ! Was nun, CPU Settings im Webgui aufmachen, aha, da gibt es einen Typ x86-64-v2 . Und schon bootet das Ganze. Stay tuned for more…