Die Übernahme von VMware durch Broadcom im November 2023 führte zu großer Verunsicherung, da in absehbarer Zeit bekanntlich alle Partner- und Dienstleisterverträge gekündigt werden sollten. Die Kritik war so heftig, dass sich Broadcom sogar vor der Europäischen Kommission für die Preispolitik von VMware rechtfertigen musste. Viele Unternehmen sahen sich gezwungen, schnell eine Alternative zu implementieren.
So auch die qwertiko GmbH, Anbieter von maßgeschneiderten Plattform-as-a-Service-Lösungen. Das Unternehmen hat schnell gehandelt und innerhalb kürzester Zeit einen passenden Ersatz zu VMware gefunden. Im Interview berichtet Geschäftsführer Yannic Groß über den Migrationsprozess und die Herausforderungen, die es zu meistern galt.
Kannst Du uns einen Überblick über den Entscheidungsprozess geben, der zur Migration von VMware zu OLVM geführt hat?
Dass Broadcom VMware übernehmen würde, stand schon länger fest und als dann auch noch grünes Licht aus China kam, war klar, dass die Übernahme über die Bühne gehen würde. Am 24.12. erschien dann ein Artikel auf Heise und ich weiß noch genau, dass ich diesen Artikel noch am selben Abend gelesen habe. Inhalt des Artikels war die Kündigung aller Partnerverträge durch Broadcom. Ich habe den Artikel sofort an meinen Geschäftsführer-Kollegen weitergeleitet und unseren VMware-Distributor um mehr Infos gebeten. Bis Mitte Februar hörten wir nur, dass es eine Änderung bei der Lizenzierung geben würde: Weg von pro RAM, hin zu pro CPU-Core.
Wie ging es dann weiter?
Am 21. Februar habe ich mich ins Broadcom-Partnerportal eingeloggt und die neuen Preislisten gesehen. Die Preiserhöhungen waren so extrem, dass klar war, dass VMware für uns keine Option mehr ist. Die Lizenzkosten hätten sich mehr als verzehnfacht. Ich habe sofort mit meinem Kollegen gesprochen und wir haben überlegt, wie es für unser Unternehmen in der Hinsicht weitergehen kann.
Was habt ihr dann entschieden?
Noch am selben Abend war klar, dass wir eine Lösung brauchen, die nahtlos in unsere bestehende Infrastruktur passt. Das heißt, unser Storage-System NetApp mit NFS und unsere Backups mit Veeam sollten weiter funktionieren. Also mussten wir „nur“ den Hypervisor wechseln.
Wie seid Ihr dann auf OLVM gestoßen und warum habt ihr euch letztendlich dafür entschieden?
Wir haben kurz auf der Veeam-Website nachgeschaut und sind auf RHEV gestoßen, den KVM-basierten Hypervisor von Redhat. Unsere Begeisterung wurde gedämpft, als Redhat das Produkt für 2026 abkündigte. Im Veeam-Forum fanden wir dann den Hinweis auf OLVM von Oracle, das praktisch dasselbe wie RHEV ist und auch mit Veeam funktioniert. Aber die Zeit drängte, denn Broadcom hatte allen Partnern die Verträge gekündigt mit dem fixen Enddatum 31.03.2024. Wir hatten also nur 40 Arbeitstage Zeit, um alle unsere Anforderungen zu erfüllen.
Wie verlief die dann Migrationsphase von VMware zu OLVM, vor allem im Hinblick auf die knappe Zeitspanne?
Am nächsten Tag hatten wir ein Meeting und dabei einen unserer Mitarbeiter eingeweiht. Zwei Tage später informierten wir unseren dritten Geschäftsführer und alle anderen Mitarbeiter. Parallel dazu begann die Integration von OLVM in unsere bestehende VMware-Infrastruktur. Zu dritt haben wir uns dann in den nächsten Tagen an OLVM versucht und sind immer wieder an kryptischen Fehlermeldungen gescheitert.
Hattet Ihr mit Oracle auch direkten Kontakt?
Ja, als wir nicht weiterkamen, hatten wir ein Support-Ticket bei Oracle eröffnet. Im Meeting erfuhren wir, dass wir den kompliziertesten Weg gewählt hatten, und es wurde uns eine einfachere Möglichkeit aufgezeigt. Mit diesen Tipps haben wir dann die erste lauffähige Umgebung aufgesetzt, allerdings noch komplett virtualisiert in unserer alten VMware-Umgebung. Damit konnten wir dann unsere ersten Tests erfolgreich durchführen und hatten bereits Ende Februar nach nur einer Woche den Beweis, dass der eingeschlagene Weg der richtige war. Dann haben wir sofort mit der Planung der vollständigen Migration bis Ende März begonnen.
War diese Planung direkt erfolgreich?
Nein, zuerst nicht. Ein Blogeintrag von Oracle zeigte einen Migrationsweg, der zu langsam war. Eine Migration einer kleinen VM mit 20 GB Speicherplatz hätte dabei über zwei Stunden gedauert. So wären wir nicht bis Ende März fertig geworden und wir hätten unseren Kunden lange Ausfallzeiten zumuten müssen. Der ursächliche Grund für die lange Zeit war wohl der direkte Weg über die VMware API und damit das gleiche Verhalten, wie wenn man eine VM über das vCenter per OVA exportiert oder einfach nur herunterladen will.
Wie habt ihr an dieser Stelle weitergemacht?
Wir haben dann nach Möglichkeiten gesucht, die VM direkt über den Storage zu importieren und zu konvertieren.
Welche Möglichkeit habt Ihr gefunden?
Mit dem Tool virt-v2v, angepassten Shell-Skripten und einer Anpassung der migrierten VMs mit Ansible konnten wir unseren Migrationsprozess immer weiter optimieren. Am Ende lief die Migration fast automatisch und die Zeit schrumpfte von 2 Stunden für 20 GB auf nur 1,5 Minuten. Durch diesen automatischen Prozess konnten wir dann sehr viele VMs parallel migrieren und Mitte März war klar, dass wir es locker bis Ende März schaffen würden.
Wie lief die eigentliche Migration dann ab?
Die Migrationen folgten einem festgelegten Schema in angekündigten Wartungszeiträumen. Dank der Optimierung konnten wir die Ausfallzeiten minimieren. Selbst große Umgebungen waren in der Regel nicht länger als 30 Minuten offline.
Abschließend, welche Lehren hast Du aus diesem Migrationsprozess gezogen?
Wir haben gelernt, wie wichtig Flexibilität und schnelles Reagieren sind. Eine gründliche Planung und enge Zusammenarbeit mit den Anbietern sind entscheidend für den Erfolg solcher Projekte. Außerdem kam uns zugute, dass wir in der VMware-Umgebung ein NetApp mit NFS einsetzen und hauptsächlich Linux-VMs haben.