VMwares VCF-9.1-Anforderungen fühlen sich an wie eine Tür, die kleineren Labs vor der Nase zuschlägt

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

Es gibt eine ganz spezielle Art von 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 durchzieht die Reaktionen auf VCF 9.1. Die Beschwerde lautet nicht bloß „neue Version braucht mehr Ressourcen". Ein gewisses Wachstum erwartet jeder. Die Wut dreht sich um das Ausmaß. Eine kleinste VCF-Service-Runtime, die angeblich 40 vCPU und 82 GB RAM verlangt, fühlt sich nicht wie eine Steigerung an. Es fühlt sich an, 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. Nicht weil sie neue Features hassen, sondern weil sich der Alltag der Nutzer nach dem Schlucken dieses ganzen Overheads vielleicht gar nicht dramatisch 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. Stattdessen 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 hier ist der Overhead. VCF war immer ernsthafte Infrastruktur, kein Leichtgewicht-Spielzeug, aber 9.1 scheint diese Realität für Homelabs in absurdes Terrain zu treiben. Die VCF Service Runtime mag Vorteile haben. Eine servicorientiertere Architektur könnte Updates sauberer machen, Komponenten besser trennen und Teams einen Weg geben, Teile unabhängig zu skalieren. Das ist die optimistische Lesart. Aber Optimismus fällt schwerer, wenn schon das kleinste Deployment Ressourcen verlangt, die viele Leute eigentlich für echte Workloads gespart hatten, nicht für die Maschinerie, die diese Workloads verwaltet.

Die Lizenzierungsteile fügen eine weitere Reibungsebene hinzu. Ein neuer Lizenzserver mit 2 vCPU und 4 GB ließe sich noch abschütteln. Nervig, aber überlebbar. Dann betritt vDefend den Raum, offenbar nach dem Upgrade unlizenziert und mit einem eigenen License Hub, wobei 6 vCPU und 24 GB im Raum stehen. An dieser Stelle setzt der Unglaube ein. Ein Kommentator fragte im Grunde, wie ein Lizenzserver überhaupt so viel Arbeitsspeicher brauchen könne, und scherzte, ein ganzer Linux-Desktop laufe mit deutlich weniger komfortabel. Es ist kein perfekter technischer Vergleich, aber emotional trifft er.

Die Homelab-Community gerät stark unter Druck

Der Homelab-Aspekt ist wichtiger, als Hersteller manchmal zugeben. Labs sind der Ort, an dem Menschen lernen, testen, Dinge kaputtmachen, wieder aufbauen und schließlich zu den Leuten werden, die Plattformen bei der Arbeit empfehlen. Wenn ein Produkt zu schwer wird, um es ohne teure, laute Rack-Server zu betreiben, kappt es still und leise eine ganze Schicht künftiger Expertise. 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. An 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 keine Wegwerf-Demobox. Es war ein Homelab, das echte Heimdienste betrieb. Das macht es zu mehr als einem Wochenendexperiment, alles herauszureißen. Der wahrscheinliche Rückfallplan klingt fast nach einem Rückzug: vSphere, vSAN, NSX, Ops, Supervisor, aber kein SDDC Manager und keine riesige Service Runtime. Weniger integriert, sicher. Lebbarer? Vielleicht.

Manche sehen das Architekturproblem darunter

Nicht jede Reaktion war reine Wut. Ein paar 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. Das ist ein vertrauter Geruch bei Enterprise-Software: Jede Gruppe schützt ihren eigenen Dienst, polstert ihre eigenen Anforderungen, und plötzlich braucht das kombinierte Produkt eine kleine Mondbasis, um zu laufen. Niemand trägt den gesamten Schmerz, bis Kunden versuchen, es zu installieren.

Es gibt eine großzügigere Version dieses Arguments. 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. Vielleicht schrumpft das Monster. Aber ein Kommentator brachte die politische Falle 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. Vertrauen schrumpft nicht so leicht wie ein Container.

Die Enterprise-Verteidigung trägt nur begrenzt

Das stärkste Argument ist einfach: VCF ist eigentlich nicht für winzige Umgebungen gedacht. Es ist ein Cloud-Foundation-Stack, kein minimalistischer Hypervisor. Wer ernsthafte Private-Cloud-Infrastruktur betreibt, für den ist Management-Overhead Teil der Rechnung. 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 könnten Homelab-Beschwerden aussehen wie der Versuch, ein Schlachtschiff in eine Garage zu quetschen.

Aber selbst diese Verteidigung hat eine Grenze. Jemand sagte, er wisse nicht sicher, wo er es überhaupt in der Produktion betreiben würde, ohne neue Hardware zu kaufen. Das ist das Warnsignal. Wenn die Anforderungen nicht nur Hobbyisten schockieren, sondern arbeitende Admins, riskiert das Produkt, sich vom realen Bestand abgekoppelt anzufühlen. Die Forderung mag für große, frische Deployments mit Budget und Kapazität akzeptabel sein. Für kleinere Shops, Edge-Standorte, Sandboxes und Umgebungen, in denen die Management-Domäne kein Fass ohne Boden ist, 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

Was hier passiert, ist größer als ein wütender Thread über RAM. Es ist ein Vertrauensproblem. VMwares Welt war für Kunden schon angespannt, die mit Lizenzänderungen, Paketierungsverschiebungen und Unsicherheit der Broadcom-Ära kämpfen. Kommt VCF 9.1 also mit Anforderungen, die sich extrem anfühlen, lesen die Leute das nicht als neutrale technische Änderung. Sie lesen es als ein weiteres Zeichen, dass sich die Plattform von ihnen entfernt. Ein weiteres verschobenes Ziel. Eine weitere Erinnerung daran, dass sich der Schwerpunkt zu größeren Accounts und schwereren Stacks verschiebt.

Der traurigste Teil ist, dass niemand wütend zu sein scheint, weil er wollte, dass VCF scheitert. Die Wut kommt von Leuten, denen es wichtig genug war, es zu betreiben, es zu lernen und ihre eigene Hardware daran anzupassen. Sie fordern kein Wunder. Sie fordern 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 Ambition hat einen Preis. Gerade jetzt starren viele Nutzer auf diesen Preis und fragen sich, ob das klügste Upgrade darin besteht, wegzugehen.