Die Frage kommt selten aus der Technik, sondern mit dem Verlängerungsangebot: Die Konditionen für die Virtualisierungsplattform sind andere als früher, und die Geschäftsführung möchte wissen, ob es dabei bleiben muss. Eine belastbare Antwort trennt drei Dinge, die im Gespräch schnell ineinanderlaufen: was über die Lizenzumstellung gesichert bekannt ist, was das eigene Haus technisch und personell leisten kann und welches Risiko es bewusst zu tragen bereit ist. Wer diese drei Ebenen vermischt, entscheidet am Ende nach Stimmung.
Was an der Lizenzumstellung gesichert ist
Die Umstellung wurde am 11. Dezember 2023 angekündigt und im Januar 2024 durch den Hersteller präzisiert. Kern der Ankündigung: Viele bisher einzeln erhältliche Produkte werden nicht mehr eigenständig verkauft, sondern nur noch als Bestandteil der Pakete VMware Cloud Foundation oder VMware vSphere Foundation. Die Mitteilung nennt ausdrücklich alle Lizenzarten – unbefristete Lizenzen, Support- und Subscription-Verträge sowie gehostete Angebote.
Für bestehende Verträge gilt nach derselben Mitteilung, dass bis zum Ende der laufenden Supportvereinbarung kein unmittelbarer Handlungsbedarf besteht; fällig wird die Umstellung zum Verlängerungstermin. Daraus folgt der einzige Termin, der für die eigene Planung zählt, und das ist nicht das Datum einer Pressemitteilung, sondern der eigene Verlängerungstermin. Wer ihn nicht kennt, kann die Frage nicht beantworten, weil er nicht weiß, wie viel Zeit ihm bleibt.
Über Mindestabnahmemengen, Paketzuschnitte und Preisentwicklungen wird seither viel berichtet, teils widersprüchlich. Für eine Entscheidung taugen solche Marktangaben nicht: Verbindlich ist allein das Angebot, das dem eigenen Unternehmen vorliegt, bezogen auf die Zahl der Prozessorkerne, die tatsächlich betrieben werden. Diese Zahl sollte vor dem Gespräch mit dem Anbieter feststehen, und zwar getrennt nach Wirten, die produktive Systeme tragen, und Wirten, die nur Test- oder Archivsysteme halten.
Drei Wege statt einer Gegenüberstellung
Die Diskussion verengt sich häufig auf „bleiben oder wechseln“. Praktisch stehen drei Wege offen. Der erste ist das Bleiben: Man akzeptiert die neue Lizenzform, verhandelt den Umfang und gewinnt dafür eine Plattform, die im Haus bereits beherrscht wird. Der zweite ist der Plattformwechsel mit eigener Mannschaft. Der dritte ist die Verlagerung des Betriebs – die virtuellen Maschinen laufen künftig in einer betreuten Umgebung, und die Plattformfrage wird Teil eines Dienstleistungsvertrags statt einer eigenen Lizenzentscheidung.
Diese drei Wege unterscheiden sich weniger im Ergebnis als in der Art des Aufwands. Bleiben kostet laufendes Geld, aber keine Projektzeit. Wechseln kostet Projektzeit, Lernaufwand und ein Risiko im Übergang, danach aber weniger laufende Bindung. Verlagern verschiebt den technischen Aufwand in einen Vertrag, was Prüfpflichten bei Datenschutz, Verfügbarkeit und Kündbarkeit nach sich zieht. Jeder Weg ist vertretbar; unvertretbar ist nur, sich nicht zu entscheiden und die Verlängerung stillschweigend laufen zu lassen.
Die Kandidaten und was sie voraussetzen
- Hyper-V: Die Virtualisierung ist Bestandteil von Windows Server und in den Editionen Standard und Datacenter enthalten, ebenso die Failover-Clusterfunktion. Wer Speicher aus den Servern selbst bilden will, braucht dafür Storage Spaces Direct – diese Funktion führt Microsoft ausschließlich für die Datacenter-Edition. Vorteil: kein zusätzlicher Hersteller, bekannte Werkzeuge. Nachteil: Die Verwaltung großer Verbünde ist weniger geschlossen als bei etablierten Plattformen, und der Umfang der Windows-Lizenzierung entscheidet über den Ausbau.
- Proxmox VE: eine Plattform auf Basis von Debian und KVM mit eigenem Clusterunterbau. Die Herstellerdokumentation nennt konkrete Voraussetzungen: Für ein verlässliches Quorum in Hochverfügbarkeitsaufbauten sind mindestens drei Knoten nötig, bei zwei Knoten tritt ein zusätzlicher Stimmgeber an die Stelle des dritten. Das Clusternetz muss Laufzeiten unter 5 Millisekunden einhalten, und für den Clusterverkehr wird eine eigene Netzwerkkarte empfohlen. Vorteil: offene Technik, keine Bindung an eine Hardwareliste. Nachteil: mehr Eigenverantwortung, andere Fehlerbilder, anderes Vokabular im Support.
- Nutanix und andere hyperkonvergente Systeme: Rechenleistung und Speicher kommen aus denselben Knoten, Hard- und Software werden als Einheit beschafft und gepflegt. Vorteil: wenige Schnittstellen, klare Zuständigkeit beim Hersteller, planbarer Ausbau in Knotenschritten. Nachteil: Die Bindung an einen Anbieter wird nicht aufgelöst, sondern verlagert, und der Einstieg lohnt meist erst ab einer gewissen Zahl von Knoten.
Eine Vorauswahl nach Gefühl führt hier regelmäßig in die Irre. Sinnvoll ist die umgekehrte Reihenfolge: zuerst die eigenen Randbedingungen festschreiben – Zahl der virtuellen Maschinen, geforderte Ausfalltoleranz, vorhandener Speicher, Kenntnisse im Team, Bereitschaft zu einem Hardwaretausch –, dann prüfen, welcher Kandidat diese Bedingungen ohne Sonderkonstruktion erfüllt.
Der Aufwand liegt nicht im Hypervisor
Das Verschieben einer virtuellen Maschine ist der einfachste Teil eines Plattformwechsels. Aufwendig ist alles, was an der Plattform hängt: Die Sicherungssoftware muss die neue Plattform unterstützen und nicht nur darauf laufen. Überwachungsagenten, Skripte für Wartungsaufgaben, Berechtigungskonzepte und die Anbindung an das Verzeichnisdienst-Anmeldeverfahren sind neu einzurichten. In den virtuellen Maschinen selbst werden die Gasttreiber ausgetauscht, was bei älteren Betriebssystemen der kritische Schritt ist.
Ein zweiter Block betrifft die Fachanwendungen. Manche Hersteller unterstützen bestimmte Plattformen ausdrücklich und andere nicht; technisch läuft die Software meist trotzdem, im Supportfall zählt aber die Freigabe. Das gehört vor der Entscheidung geklärt, schriftlich, mit Nennung der Version. Das BSI beschreibt im IT-Grundschutz-Kompendium einen eigenen Baustein für Virtualisierung, der auf jeden Virtualisierungsserver anzuwenden ist und ausdrücklich auch die Verwaltungssysteme einbezieht – eine brauchbare Gliederung für die eigene Prüfliste, auch ohne Zertifizierungsabsicht.
Können: Wer betreibt die Plattform am Sonntagabend
Die unterschätzte Größe ist nicht das Projekt, sondern der Betrieb danach. Eine Plattform, die im Projekt von einem externen Spezialisten aufgebaut wurde und die im eigenen Haus niemand im Detail kennt, ist eine Abhängigkeit mit anderem Namen. Prüfen lässt sich das mit einer unangenehmen Frage: Wer stellt in zwei Jahren nachts fest, warum eine Maschine nicht startet, und wer hat vorher geübt, sie zurückzuholen? Wenn die Antwort auf eine einzelne Person zeigt, ist der Wechsel nicht unmöglich, aber er braucht Schulung und eine zweite Person.
Ein Zeitgerüst mit angenommenen Werten
Zur Veranschaulichung ein Gerüst mit frei gewählten Beispielwerten, das jedes Haus mit eigenen Zahlen füllen sollte: 40 virtuelle Maschinen, davon 6 mit Fachanwendungen, die eine Herstellerfreigabe brauchen. Für Aufbau und Abnahme der neuen Plattform wird ein zusammenhängender Zeitraum angesetzt, für die Freigaben der Softwarehersteller ein deutlich längerer, weil er nicht in der eigenen Hand liegt. Danach werden die Maschinen in Gruppen verschoben – unkritische zuerst, Kernsysteme zuletzt, jede Gruppe in einem eigenen Wartungsfenster mit geprüfter Rückfallmöglichkeit.
Rechnet man in diesem Gerüst vom Verlängerungstermin zurück, zeigt sich schnell, ob der Termin realistisch erreichbar ist. Reicht die Zeit nicht, ist die sauberste Lösung häufig eine bewusst befristete Verlängerung: einmal zu den neuen Bedingungen verlängern, den Wechsel in Ruhe vorbereiten und zum folgenden Termin umstellen. Das ist teurer als ein sofortiger Wechsel, aber billiger als ein abgebrochener.
Prüffragen vor der Entscheidung
- Wann läuft unser Vertrag aus, und wie viele Prozessorkerne betreiben wir tatsächlich – getrennt nach produktiven und nicht produktiven Wirten?
- Welche Fachanwendungen brauchen eine Herstellerfreigabe für die neue Plattform, und liegt diese schriftlich vor?
- Unterstützt unsere Sicherungslösung die neue Plattform vollständig, einschließlich der Wiederherstellung einzelner Dateien aus einer Sicherung?
- Welche Hardware bleibt, welche muss ersetzt werden, und passt dieser Ersatz in den ohnehin geplanten Lebenszyklus?
- Wer im Haus beherrscht die neue Plattform nach dem Projekt, und wie viele Personen sind das?
- Welche Rückfallmöglichkeit haben wir während der Umstellung, und ist sie erprobt oder nur vorgesehen?
- Wenn wir bleiben: Welchen Umfang brauchen wir wirklich, und welche Bestandteile der Pakete nutzen wir nicht?
Ein Plattformwechsel ist ein Infrastrukturprojekt, kein Einkaufsvorgang. Er lohnt sich, wenn die eigene Umgebung ohnehin vor einem Hardwarewechsel steht, wenn die Bindung an einen Anbieter als strategisches Risiko bewertet wird und wenn das Können im Haus aufgebaut werden kann. Er lohnt sich nicht, wenn er allein aus Verärgerung über ein Angebot begonnen wird – dann wird aus einer Vertragsfrage ein Betriebsrisiko, und das ist der schlechtere Tausch.
Verwandte Themen: Wer hier weiterdenkt, liest bei Virtualisierung, Hyper-V Cluster und Snapshot weiter.
Quellen
- VMware End Of Availability of Perpetual Licensing and SaaS Services · Broadcom (VMware Cloud Foundation Blog)
- VMware End Of Availability of Perpetual Licensing and SaaS Services (Knowledge-Base-Artikel 309138) · Broadcom
- SYS.1.5 Virtualisierung, IT-Grundschutz-Kompendium · BSIamtlich
- Cluster Manager (Proxmox VE Administration Guide) · Proxmox Server Solutions
- Comparison of Windows Server editions · Microsoft Learn
