Die Anforderungen von VMware VCF 9.1 wirken auf kleinere Labs wie eine zugeschlagene Tür

Das Upgrade, das sich plötzlich zu schwer anfühlt

Es ist eine ganz eigene Frustration, wenn eine Plattform, in die man Zeit, Hardware und Geduld investiert hat, plötzlich entscheidet, dass die eigene Umgebung nicht mehr groß genug ist. Genau dieses Gefühl zieht sich durch die Reaktionen auf VCF 9.1. Dass eine neue Version mehr Ressourcen braucht, erwartet jeder, und ein gewisses Wachstum regt niemanden auf. Die Wut gilt dem Ausmaß. Eine kleinste VCF-Service-Runtime, die angeblich 40 vCPU und 82 GB RAM verlangt, wirkt weniger wie eine Steigerung und eher so, als hätte jemand eine zweite Plattform auf die erste gesetzt und das Fortschritt genannt.

Für Leute mit kompakten Umgebungen kommt diese Zahl schlecht an. Gegen neue Features haben sie nichts, sie befürchten aber, dass sich ihr Alltag nach dem Schlucken dieses ganzen Overheads kaum anders anfühlt. Jemand brachte es unverblümt auf den Punkt: „An der Oberfläche macht es nicht viel Neues.“ Genau das schmerzt. Hätte das Upgrade einen offensichtlichen, unverzichtbaren Sprung nach vorn gebracht, ließe sich der Preis vielleicht leichter rechtfertigen. So wirkt es wie eine massive Steuer auf die Management-Ebene, besonders für Labs und kleinere Produktivsetups, die ohnehin schon knapp am Limit laufen.

Wenn der Management-Stack anfängt, das Lab aufzufressen

Der eigentliche Bösewicht ist der Overhead. VCF war schon immer ernsthafte Infrastruktur und nie ein leichtgewichtiges Spielzeug, doch 9.1 treibt das für Homelabs offenbar ins Absurde. Die VCF Service Runtime mag Vorteile haben. Eine stärker serviceorientierte Architektur könnte Updates sauberer machen, Komponenten besser trennen und Teams einen Weg geben, Teile unabhängig zu skalieren. So lautet die optimistische Lesart. Optimismus fällt allerdings schwer, wenn schon das kleinste Deployment Ressourcen verlangt, die viele Leute für echte Workloads zurückgelegt hatten und nicht für die Maschinerie, die diese Workloads verwaltet.

Die Lizenzierung sorgt für zusätzliche Reibung. Einen neuen Lizenzserver mit 2 vCPU und 4 GB könnte man noch mit einem Achselzucken hinnehmen, nervig, aber überlebbar. Dann betritt vDefend den Raum, nach dem Upgrade offenbar unlizenziert und mit einem eigenen License Hub, für den 6 vCPU und 24 GB im Raum stehen. Spätestens da setzt der Unglaube ein. Ein Kommentator fragte sinngemäß, wie ein Lizenzserver überhaupt so viel Arbeitsspeicher brauchen könne, und scherzte, ein ganzer Linux-Desktop laufe mit deutlich weniger komfortabel. Technisch hinkt der Vergleich etwas, emotional trifft er.

Die Homelab-Community gerät stark unter Druck

Der Homelab-Aspekt ist wichtiger, als Hersteller manchmal zugeben. In Labs lernen, testen, zerstören und bauen Menschen Dinge wieder auf, und irgendwann empfehlen genau diese Leute Plattformen bei der Arbeit. Wenn ein Produkt zu schwer wird, um es ohne teure, laute Rack-Server zu betreiben, schneidet es sich von einer ganzen Schicht künftiger Expertise ab. Deshalb trifft die Beschwerde über „Pizzakarton-Server“ so hart. Niemand will einen kreischenden R640 unter dem Schreibtisch, nur um die Management-Ebene einer Plattform zu verstehen. Ab einem gewissen Punkt wird aus der Lernumgebung ein Infrastruktur-Beschaffungsprojekt.

Dazu kommt der praktische Hardware-Engpass. RAM ist nicht kostenlos, und selbst clevere Tricks wie NVMe-Tiering helfen nur begrenzt, wenn die Plattform riesige Brocken verlangt, bevor die eigentlich nützlichen Workloads überhaupt anfangen. Das ursprüngliche Setup war auch ein Homelab mit echten Heimdiensten und keine Wegwerf-Demobox, und alles herauszureißen wäre deshalb mehr als ein Wochenendexperiment. Der wahrscheinliche Rückfallplan klingt fast nach einem Rückzug: vSphere, vSAN, NSX, Ops und Supervisor, aber kein SDDC Manager und keine riesige Service Runtime. Das ist sicher weniger integriert, dafür vielleicht besser lebbar.

Manche sehen das Architekturproblem darunter

Nicht jede Reaktion war reine Wut. Ein paar Leute versuchten zu erklären, was hinter den Kulissen passieren könnte. Eine These war, Broadcom habe Teile duplizieren müssen, um sie in eine neuere Service-Plattform zu ziehen, und verschiedene Teams hätten ihre eigenen Microservices dimensioniert, ohne genug Gegendruck zu bekommen. Bei Enterprise-Software kennt man das: Jede Gruppe schützt ihren eigenen Dienst und polstert ihre eigenen Anforderungen, bis das kombinierte Produkt eine kleine Mondbasis braucht, um zu laufen. Den gesamten Schmerz spürt erst der Kunde, der es installieren will.

Man kann das Argument auch großzügiger lesen. Dienste in Container zu verschieben und Komponenten zu trennen, könnte die Plattform langfristig sauberer und flexibler machen. Vielleicht ist das erste Release überdimensioniert, weil sich die Architektur noch setzt, vielleicht werden einzelne Dienste später fein abgestimmt, und vielleicht schrumpft das Monster ja. Ein Kommentator brachte die politische Falle allerdings perfekt auf den Punkt: Es ist schwer, mit riesigen Anforderungen zu starten und später zu sagen: „Nur Spaß, wir haben verkleinert.“ Kunden planen um die erste Zahl herum, die sie sehen, und verlorenes Vertrauen lässt sich nicht so leicht zurückskalieren wie ein Container.

Die Enterprise-Verteidigung trägt nur begrenzt

Das stärkste Gegenargument ist einfach: VCF ist eigentlich nicht für winzige Umgebungen gedacht. Es ist ein Cloud-Foundation-Stack und kein minimalistischer Hypervisor. Wer ernsthafte Private-Cloud-Infrastruktur betreibt, rechnet Management-Overhead ohnehin ein. Größere Unternehmen absorbieren 40 vCPU und 82 GB vielleicht, ohne mit der Wimper zu zucken, besonders wenn sie Lifecycle-Management, Automatisierung, integriertes Networking, Sicherheit und einen unterstützten Upgrade-Pfad schätzen. Aus diesem Blickwinkel wirken Homelab-Beschwerden wie der Versuch, ein Schlachtschiff in eine Garage zu quetschen.

Selbst diese Verteidigung hat aber eine Grenze. Jemand sagte, er wisse nicht einmal, wo er es in der Produktion betreiben würde, ohne neue Hardware zu kaufen. Das ist ein Warnsignal. Wenn die Anforderungen auch arbeitende Admins schockieren und nicht bloß Hobbyisten, wirkt das Produkt schnell abgekoppelt von der Hardware, die tatsächlich in den Rechenzentren steht. Für große, frische Deployments mit Budget und Kapazität mag die Forderung akzeptabel sein. Für kleinere Shops, Edge-Standorte, Sandboxes und Umgebungen, in denen die Management-Domäne kein Fass ohne Boden sein darf, ist sie deutlich schwerer zu tragen. „Enterprise-tauglich“ sollte keine höfliche Umschreibung für „ressourcengleichgültig“ werden.

Eine Plattform kann die Architektur gewinnen und die Menschen verlieren

Hinter dem wütenden Thread über RAM steckt ein Vertrauensproblem. Für Kunden, die mit Lizenzänderungen, Paketierungsverschiebungen und der Unsicherheit der Broadcom-Ära kämpfen, war VMwares Welt schon vorher angespannt. Kommt VCF 9.1 dann mit Anforderungen, die sich extrem anfühlen, lesen die Leute das kaum als neutrale technische Änderung. Für sie ist es ein weiteres Zeichen, dass sich die Plattform von ihnen entfernt, ein weiteres verschobenes Ziel und eine weitere Erinnerung daran, dass sich der Schwerpunkt zu größeren Accounts und schwereren Stacks verschiebt.

Am traurigsten finde ich, dass offenbar niemand wütend ist, weil er VCF scheitern sehen will. Die Wut kommt von Leuten, denen es wichtig genug war, es zu betreiben, es zu lernen und ihre eigene Hardware daran anzupassen. Sie verlangen kein Wunder, nur eine Dimensionierung, die sich vernünftig anfühlt, Features, die die Kosten sichtbar rechtfertigen, und einen Pfad, der kleinere Umgebungen nicht dafür bestraft, aktuell zu bleiben. VCF 9.1 mag architektonisch ambitioniert sein, aber diese Ambition hat einen Preis, und gerade starren viele Nutzer darauf und fragen sich, ob das klügste Upgrade darin besteht, wegzugehen.