[English]Neuer Ärger für Nutzer von VMWare by Broadcom, die Produkte wie VMware vSphere Enterprise Plus, VMware vSphere Standard (VVS), VMware vSphere Foundation (VVF) und VMware Cloud Foundation (VCF) im Einsatz haben. In zwei Wochen sind Lizenzen für mindestens "72 Cores für eine Lizensierung" erforderlich. Anmerkung: In der Erstfassung stand "72 Cores per CPU", was geändert wurde.
Anzeige
Gestern hatte ich im Beitrag VMware klagt gegen Siemens wegen fehlender Lizenzen über den Zoff zwischen VMware und die Siemens AG berichtet. VMware hat die Firma Siemens wegen unlizenzierter Produkte verklagt. Heute schiebe ich mal den nächsten VMWare by Broadcom Lizenz-Hammer nach: Im April 2025 wird die Vorgabe für die "Mindestmenge von Cores, die zu lizenzieren ist" drastisch angehoben. Und es gibt noch ein paar weitere "Schmerzpunkte".
Rückblick auf einen Fall vor einem Jahr
Bei VMware ist seit der Broadcom-Übernahme die Hölle los, und im Artikel Der Fluch der neuen Broadcom/VMware VCF-Lizenzierung in der Praxis vom 12.02.2024 heißt es noch von einem IT-Dienstleister, der einen Kunden mit "sehr vielen VMs" betreut: "Durch die Vorgabe jede CPU mit mindestens 16 Cores zu lizenzieren, müssten nochmal ca. 2.500 Cores mehr lizenziert werden, als der Kunde tatsächlich im Bestand hat."
Hat dazu geführt, dass die Rechnung einen etwas größeren Betrag aufwies. Anstatt der vorher ausgewiesenen ca. 40.000 USD für den Support der Lizenzen standen dann 270.000 USD pro Monat bzw. 3,1 Millionen USD pro Jahr, zu bezahlen an VMware by Broadcom, auf dem Papier.
Mindestens 72 Cores pro CPU oder Produkt?
Gestern hat IT-Dienstleister Friedel S. mich per Mail kontaktiert und schrieb "zu VMWare heißt es im Artikel "Der Fluch der neuen …" vom 12.02.2024 "Durch die Vorgabe jede CPU mit mindestens 16 Cores zu lizenzieren entstünden erhebliche Mehrkosten". Nun habe er eben beim Software-Distributor SFC gelesen, dass VMware by Broadcom die Mindestabnahmemenge der 'Cores pro CPU' ab dem 10. April 2025 nach oben schraubt. Ich habe die betreffende Seite nachfolgend per Screenshot dokumentiert.
Anzeige
Das Bild aus obigem Screenshot passt schon. Denn im Text heißt es, dass für die Produkte VMware vSphere Enterprise Plus, VMware vSphere Standard (VVS), VMware vSphere Foundation (VVF) und VMware Cloud Foundation (VCF) ab dem 10. April 2025 dann mindestens 72 Lizenzen anstatt der bisherigen 16 [bei einer Neulizenzierung] benötigt werden.
Mindestbestellwert 25.000 Euro
Weiterhin sollen Prepaid- und Multiyear-Payment-Angebote zukünftig erst ab einem Mindestwert von zur Zeit 25.000 € erstellt werden. Offene Angebote müssen, laut dieser SFC-Meldung in dieser Hinsicht neu erstellt werden und haben daher keine Gültigkeit mehr. Neue Anfragen können dann gegebenenfalls seitens des Herstellers abgelehnt werden, heißt es weiter. Wann und in welchem Umfang diese Änderung in Kraft tritt, sei derzeit noch nicht bekannt, schreibt der Software-Distributor SFC.
Der Software-Distributor SFC empfiehlt Kunden die Bedarf an einem der obigen Produkte haben, nicht bis zur nächsten Hiobsbotschaft zu warten und zügig beim betreffenden Ansprechpartner bezüglich eines Angebots anzufragen. Wann und zu welchen Bedingungen das Angebot seitens des Herstellers erstellt wird, ist jedoch unklar – die Hoffnung stirbt aber zuletzt.
Eine weitere Quelle und eine Diskrepanz
Wer glaubt, dass dies eine irre Fake-News ist, mit dem Software-Distributor SFC die Kasse füllen möchte, ich bin die Nacht fast zeitgleich bei The Register auf den Beitrag VMware distributor Arrow says minimum software subs set to jump from 16 to 72 cores gestoßen. Dort kommt die gleiche Nachricht zu den 72 Cores Mindestabnahmemenge vom VMware-Distributor Arrows. The Register hat die E-Mail dieses Distributors an Kunden aus nachfolgendem Screenshot einsehen können. Hier gibt es aber Diskrepanzen zur obigen (deutschen) Meldung eines Distributors (es wird von "72 Cores per command line" statt pro CPU geschrieben).
Das wird vor allem für Kleinstkunden ein Problem, die nur eine oder zwei CPUs lizenzieren, da immer die Mindestmenge von 72 Cores für die Lizenzierung anfallen. Wer fünf Dual-Prozessor-Systeme mit 16 Cores hat, komme bei der alten und neuen Lizenzierung auf 160 Cores, heißt es in obigem Screenshot – wobei ich diese Rechnung nicht ganz stimmig finde, da ich auf 5 * 72 = 360 Lizenzen komme, weiß nur noch nicht, wo mein Denkfehler liegt.
Ergänzung: Habe nochmals die obigen Meldungen des deutschen und englischen Distributors verglichen und die Leserkommentare berücksichtigt. Der Text des deutschen Distributors spricht von "72 Cores pro CPU", während der Distributor Arrows von einer Mindestlizenzierung von "72 Cores per command line" schreibt. Dies ist formal etwas gänzlich unterschiedliches.
Sprich: Bei 5 Dual-Prozessoren mit je 8 Cores komme ich auf 160 Cores. Die Schwelle von 72 Cores (pro Lizenz) ist überschritten und es müssen nur die 160 Cores lizenziert werden.
Ich gehe daher davon aus, dass der Text des Software-Distributors SFC mit den '72 Cores pro CPU' ungenau bzw. missverständlich interpretiert und dann so formuliert wurde.
Auf Facebook hat ein Leser ausgeführt, dass man "ab sofort 72 Cores – gilt pro Produkt-Edition – lizenzieren muss". Ich habe von diesem Leser auch gehört, dass die 16 Cores pro CPU weiter gelten, da ändert sich nichts. Ich habe daher den Titel des Beitrags und einige Textstellen angepasst und das "pro CPU" gelöscht.
Strafe für "zögerliche" Endkunden
Die E-Mail von Arrows enthält noch einen zweiten Hammer für "säumige" VMware by Broadcom-Kunden. Broadcom hat wohl "Strafen für Endkunden eingeführt, die ihre (bereits bestehenden) Abonnementlizenzen nicht zum Jahrestag erneuert haben." Wer also die Frist versäumt, für den erhöht sich der Preis eines erneuerten Abonnements im ersten Jahr um 20 Prozent.
The Register hat diese Information auch in mehreren Social-Media- und Blog-Beiträgen gesehen. Auf eine Nachfrage bei VMware by Broadcom von letzter Woche habe man aber keine Antwort bekommen, heißt es.
Kleinkunden ade?
Es sieht so aus, dass VMware by Broadcom nun endgültig die kleinen Kunden los werden möchte und sich auf Großkunden mit einer entsprechenden Anzahl an Lizenzen fokussiert. Bei unerwünschten Kunden wird dann nochmals ein wenig an der Preisschraube gedreht.
Ähnliche Artikel:
VMware OEM-Portal offline, Kunden können VMware-Lizenzen nicht aktivieren
Bestell-/Lizenz-Chaos bei VMware-Produkten nach Broadcom-Übernahme (Jan. 2024)
Broadcom beerdigt VMware-Produkte mit Perpetual-Lizenzen – Ende des kostenlosen ESXi-Servers?
VMware-Nachlese: PAC funktioniert wieder; Dell macht den Exit
Der Fluch der neuen Broadcom/VMware VCF-Lizenzierung in der Praxis
VMware by Broadcom: Erkenntnis "es läuft nicht rund, mit den Broadcom-Plänen"
Analysen: VMware agiert bei Lizenzen geplant; Wechsel zu Alternativen ein Problem
VMware-News: Nur noch Mehrjahres-Subscriptions? End-User-Produkte Vertrieb unter
VMware by Broadcom: Portal-Umzüge, Achtung: Schlüssel ohne Supportvertrag werden gelöscht
Kundenschwund bei VMware; Holpriger Portalwechsel; Kunden wechseln zu Nutanix AHV
VMware-Übernahme durch Broadcom, geht die Wette auf?
Broadcoms VMware-Umsatz Q3 2024 schießt nach oben und Eindrücke von der VMware Explore
VMware ein Jahr nach der Broadcom-Übernahme: Erfolg oder Kundenschwund? Was geht?
Österreichischer Cloud Provider Anexia kickt VMware wegen Kosten
Erfahrungen mit Hypervisor XCP-NG als VMWare Alternative
Zäher und teurer Abschied von VMware? Rackspace vor dem Exit?
VMWare by Broadcom: Nächster Fail mit Schulungs-Credits
Broadcoms VMware-Wette aufgegangen? Kunden buchen größtes Paket
VMware vCenter: Update-Tokens ab 23. April 2025 erforderlich
VMware klagt gegen Siemens wegen fehlender Lizenzen
Anzeige
ich glaube es werden hier CPU und Bestellung verwechselt. So weit ich es verstanden habe sind pro Bestellung jetzt 72 cores und nicht mehr nur 16 cores notwendig.
Kann gut sein, dass Bestellung gemeint ist – wie in anderen Kommentaren angemerkt. Kleinnutzer sind dann aber definitiv raus. Goldene Zeiten für Proxmox?
Raus (oder teurer) wären dann auch die sogenannten "hyperconvergenten Infrastrukturen", bei denen man dem Kunden ein komplettes Paket mit Hardware (Computing, Storage), Virtualisierung (eben VMware), Betriebssystem (Windows) und oft auch noch Backup aus einer Hand und in einer Wartung hinstellt. Beispielsweise Dell VXrail.
Das sind oft Kleinkunden ohne eigene IT (z.B. eine Steuerkanzlei oder Arztpraxis).
Dann lässt man die Virtualisierung eben weg?
Proxmox bietet alles aus einer Hand, auch hyperkonvergent
Thomas Krenn baut gerade entsprechende Produktlinien auf – und sie sind bei Weitem nicht die Einzigen:
https://www.thomas-krenn.com/de/produkte/einsatzzweck/virtualisierung.html
Wenn ich es richtig verstanden habe, sind die 72 Cores pro Bestellung und nicht pro CPU. Die Rechnung oben von Arrow geht wie folgt:
Hat man nur ein Server mit 16 CPU, muss man 72 Cores kaufen.
Hat man 5 Server mit 2 CPUs (Dual-processors) und 16 Kerne jeweils, sieht die Rechnung so aus:
5 Server x 10 CPUs x 16 Kerne = 160 Cores muss gekauft werden.
Software Express schreibt dazu:
Mindestlizenzierung: Jede CPU muss mit mindestens 16 Kernen lizenziert werden. Für jede 8-Core-CPU (oder 4-Core-CPU) müssen Sie also auch 16 Cores lizenzieren.
Mindestbestellung: Bei jeder Bestellung müssen Sie mindestens 72 Cores bestellen, auch wenn Sie weniger benötigen. Das gilt für Neukunden und für Bestandskunden.
autsch….
Bei allem Haß auf Broadcom: Der Titel "Mindestens 72 Cores pro CPU erforderlich" kommt mir ein wenig mißverständlich vor.
Vermutlich ist "Mindestens 72 Cores pro Kunde erforderlich" gemeint.
Der englische Screenshot beleuchtet das im Kasten "Example" m.E. ganz gut, bei "5 dual-processor servers" wären ja sonst 10 × 72, also 720 Cores zu lizensieren.
Zum Hintergrund:
Bis VMware 6 wurde ausschließlich nach Sockeln lizensiert.
Der Kunde hatte einen Server mit 2 CPU, also 2 Lizensen.
In diese Zeit waren Dual- und Quadcore-Prozessoren üblich, mit Hyperthreading kam man auf 8 Rechenwerke pro Sockel.
Dann führte Intel schrittweise "fettere" CPUs ein, mit 8, 12, oder 16 Cores pro CPU.
Hat VMware noch mitgemacht.
Aber zu dieser Zeit bog dann AMD mit CPUs um die Ecke, die bis zu 48 Cores beinhalten können.
Da schwante es auch VMware, daß man da was ändern muß, las seine bisherigen Lizenzbedingungen und stellte klar, daß eine Sockel-Lizenz nur bis zu 16 Cores umfaßt.
Für den o.g. 48-Core-Epyc braucht es dann also 3 Sockellizenzen, obwohl physisch nur eine CPU vorhanden ist.
Mit VMware ab 8 hat man dann die Zählerei von Sockeln ganz aufgegeben und nur noch Cores lizensiert (wobei allerdings die 16 Cores pro Sockel als Minimum beibehalten wurden).
Das war keine alleinige Erfindung von VMware, ich habe hier genauso alte Windows-Server-Lizenzen herumliegen, auf denen "1-2 CPU" steht, damit sind dann auch Sockel gemeint. Mit neueren Versionen (19, 22) hat dann auch Microsoft auf die Core-Lizensierung umgestellt.
Veeam übrigens auch.
das ist übrigens nicht ganz richtig dargelegt.
Die Sockel Lizenzen früher waren unlimitiert, ich müsste jetzt schauen wann, aber mit dem Aufkommen größerer CPUs und vor allem durch den Nutzen von mehr als einem CPU Die in einer CPU haben manche Hersteller harte Core Count Limits eingeführt. Bei VMware waren das 32C pro Sockel, bis zum Wegfall dieser unlimitiert zeitlich nutzbaren Lizenzen. Seit Broadcom gibt es nur noch Abo Nutzungsrechte, also pro Core, Sockel Count effektiv egal. Alternativ gab es ggü. den pro Sockel Lizenzen noch Lizenzen nach Core Count, das waren die von dir genannten 16C mindestens. Allerdings war das eher untypisch, weil häufig laufende Subscriptions eben weiter verlängert wurden und damit die Lizenzen mit 32C pro Sockel vorhanden waren respektive man weiter hat nachgekauft anstatt das zu ändern. Für die meisten Paarungen war das idR. auch günstiger.
Bei Microsoft lief das damals ähnlich, es wurde von unlimitiertem Core Count auf ein pro Core Modell umgestellt. Wobei bei Microsoft seit Anfang an verschiedene Bundles angeboten wurden. Initial gab es mal 16C Modelle, für 2x8C oder 1x16C, mehr wurde pro 2 Cores dazu gebucht in bspw. Volumenlizenzverträgen. Du hast letztlich dort beliebig verteilt, wenn die Summe stimmte. Anders als eben VMware damals, wo immer jeder Sockel 32C Cores hatte, bei nur einem physischen Kern mehr brauchte es die zweite Lizenz, egal ob eben 36, 40, 48, … oder 64C.
Aus Gründen der Weitsicht war es nicht schlauf auf die 32C pro Sockellizenzen zu verzichten, spätestens mit dem nächsten Server brauchte man dann auch mehr Cores pro Sockel und rechnerisch ging das wieder auf…
Ja, Du hast Recht, bei den 16c habe ich mich falsch erinnert.
In diesem 5 Jahre alten Artikel ist es mal schön beschrieben:
https://www.windowspro.de/news/vmware-beschraenkt-lizenzen-maximal-32-kerne-pro-cpu/04445.html
die zerlegen sich munter selbst, bin gespannt wie lang es noch dauert
ein Monopolist kann seinen Preis beliebig erhöhen. Irgendwann aber fangen die Kunden an, Alternativen zu suchen, gar zu bauen und zu verwenden. Die suchen diesen Punkt…
Microsoft geht da sensibler vor.
MS packt den Frosch ins kalte Wasser und dreht erst dann den Herd an.
Das war der Plan von Anfang an, Kleinkunden abschütteln, Preise erhöhen, von Großkunden so lange es geht kassieren, da diese nicht von heute auf morgen wechseln können.
So viel Geld wie möglich extrahieren und dann verkaufen.
Ich lese das Beispiel im Screenshot so:
Es geht da scheinbar um die Gesamtzahl an Lizenzen.
Bleibe ich unter den 72 Lizenzen, sprich 1 CPU 8 Kerne = 72 zu kaufen
Habe ich 5x 2Cpus a 16Kerne = 160 Kerne zu kaufen
Gruß
Benjamin
Entwicklungen wie diese zeigen vor allem eines auf: Die Produktentwicklung ist am Ende, neue und überzeugende Features werden nicht mehr entwickelt werden. Es ist Schicht im Schacht.
Und im Zuge dessen, versucht man die "bestehenden Kühe" bestmöglich zu melken. Diese Gebaren tritt gegenwärtig in so vielen Bereichen (auch branchenfremden) auf, daß es nicht mehr überrascht.
Ein Narr ist, wer sich immer nur auf einen Anbieter festlegt und keinerlei Alternativen hat.
Da merkt man doch dass da Profit auf Teufel komm raus erzeugt werden soll. Wer setzt schon in großem Maße CPUs mit 72 Kernen oder mehr ein. Die Durchschnitts-CPU dürfte weit darunter sein. Für viele Einsatzzwecke genügen auch deutlich weniger Kerne. Wenn ein KMU einen Server zur Virtualisierung für die wichtigen VMs hinstellt werden da wohl deutliche Weniger Kerne gebraucht. DC, Fileserver, Warenwirtschaftsystem, Emailserver, Backup und evtl. Firewall-VM viel mehr wird da nicht laufen da braucht man keine 72 Kerne pro CPU. Wenn man mal davon ausgeht dass zwei Server mit je 2 CPU aus Redundanzgründen laufen ist die Masse an Lizenzen da rausgeschmissen Geld.
Ich denke das mit dem "per command line" ist irgendwie falsch und soll wohl eher pro Auftrag / Kunde heißen.
72 pCores pro CPU kann ich mir beim besten willen nicht vorstellen: davon gibt es schlicht zu wenige (Intel hat glaube ich aktuell keine…nur als Blaupause oder so. AMD hat welche). Das würde dann auch deren Rechenbeispiel widersprechen.
Grüße und schönes Wochenende. :)
Ich denke auch, dass da vielleicht "per batch" oder so gemeint war und das dann durch ne KI verschlimmbessert wurde
Ich lese da auch nichts von "pro CPU", sondern nur eine Mindestmenge von 72 Lizenzen.
Dennoch eine sehr drastische Maßnahme.
Danke für die zahlreichen Kommentare – habe nach dem Frühstück nochmals beide Meldungen verglichen und oben im Text einen erklärenden Nachtrag verfasst. Der Text des deutschen Distributors dürfte mit "pro CPU" falsch sein es gilt "72 Cores pro Produkt" als Minimum für die Lizenzierung.
Wie war das nach Marx doch gleich.
"Ab einem bestimmten Satz an Profit geht der Kapitalist über Leichen oder ist sich für keine Schandtat zu Schade."
Erinnert mich irgendwie an das Gebaren der derzeitigen US-Regierung.
Bestehen da Verbindungen?
Back to the roots, kleinere Betriebe brauchen keine Virtualisierung und zig Cores für ihr Alltagsgeschäft? Handelsübliche PC Arbeitsplätze von der Stange mit z.B. einem simplen i5 reichen doch völlig aus?
Oder sie setzen auf andere Virtualisierungslösungen – es wurde ja der Fall "Fertiger Server mit Virtualisierung von der Stange" für Autohäuser, Arztpraxen, Steuerberater oder Rechtsanwälte genannt. Da scheinen die verwendeten "Lösungen" oft eine VM vorzugeben.
Leider nicht so einfach. Man hat jahrelang in kleinen Umgebungen die strikte Rollenseparierung gefördert wie das in grösseren Umgebungen üblich ist. Das ganze jetzt auf physisch umstellen? Schwierig und eigentlich unsinnig.
Das ganze war gut finanzierbar, mittlerweile verkommt das Kosten/Nutzen Verhältnis aber zu einem Desaster für kleine Umgebungen.
Umstellung auf HyperV oder ein anderer HyperVisor ist gar nicht immer so einfach. Es gibt zahlreiche Appliances die nicht oder nicht so einfach auf etwas anderem wie VmWare laufen. Auch im KMU-Umfeld. Gibt enorme Investitionen. :(
So ist es. Die Erkenntnis, dass die jahrelangen Fehlleitungen zu einem Desaster führen, kam bei einigen eher und kommt bei anderen jetzt später an.
Und ja, Investitionen sind jetzt dringend erforderlich, für viele falsch Beratene kaum mehr stemmbar, denn alles kostet jetzt letztendlich doppelt und dreifach, damit man überhaupt wieder zurück auf Start ohne den ganzen überflüssigen Ballast gehen kann.
Warum laufen die Applikationen nur auf VMware? Das sollte höchstens bei fertigen Images set Fall sein, die dafür ausgeliefert wurden. Und selbst die lassen sich recht einfach migrieren, zumindest auf Proxmox VE.
Und wenn es eine Zertifizierungsnummer ist fordere den Hersteller auf diese um die gewünschte Lösung zu erweitern. Die Softwarehersteller sollten auch gemerkt haben, dass viele Kunden sich von VMware verabschieden.
Einen Cisco WLAN-Controller bekomme ich im Moment nur für VMware oder Hyper-V. Oder als – sehr teure – Hardware-Appliance. Genauso etwa ein Barco XMS zur Verwaltung der Clickshares.
Das sind opaque Appliances, in die ich mich nicht als root hineinhacke, nur um die passenden Virtualisierungstreiber zu installieren – schließlich will ich im Problemfall Support.
Genau.
Eine der DATEV-Musterlösungen für Mandanten einer bestimmten Größe sieht zum Beispiel so aus, daß man einen Terminalserver hat, auf dem die Mitarbeiter arbeiten und einen Datenbankserver, auf dem die Dienste laufen. Zusätzlich Backup.
Virtualisiert stellt man genau ein Blech hin, ohne Virtualisierung einen ganzen Haufen.
Umstellung aug auf HyperV heißt den Teufel mit dem Belzebuben austreiben. Was für eine Idee?
Die Mehrkosten der Virtualisierung machen sich doch spätestens bei der migration auf neue Hardware bezahlt. Die Arbeitszeit ist mit sicherheit teurer.
Kühe muss man melken solange sie Milch geben, weis sogar der dümmste Bauer!
Unbegrenzter Wachstum gibt es nunmal nicht, will man dann seinen Profit noch steigern muss man eben kreativ werden… Aber heh wo ist das Problem? Zum Abzocken gehören immer 2: einer der abzockt und einer der sich abzocken lässt!
Hallo zusammen,
ich schreibe für Software-Express und möchte Euch kompakte und verlässliche Informationen zur VMware-Lizenzierung geben. Auch wenn es allgemein nicht gerne gesehen wird, verlinke ich auf unsere Seite mit dem Abschnitt über die Lizenzierung. Ich denke, das ergibt Sinn und Günter Born wird es sicher freischalten oder die Links vielleicht noch im Post einbauen.
https://www.software-express.de/hersteller/vmware/#vmware-lizenzierung
und
https://www.software-express.de/blog/vmware-vsphere-lizenzdschungel/#lizenzmodell
Ich habe mir nicht alle Eure Kommentare durchgelesen und fasse einfach einmal alles, was gilt, zusammen. Das sollte die allgemeine Verwirrung beseitigen.
Core-License: VMware vSphere wird pro Prozessorkern lizenziert. Eine solche Lizenz wird als Core-Lizenz bezeichnet.
Mindestlizenzierung: Jede CPU muss mit mindestens 16 Kernen lizenziert werden. Für jede 8-Core-CPU (oder 4-Core-CPU) müssen Sie also auch 16 Cores lizenzieren.
Mindestbestellung: Bei jeder Bestellung müssen Sie mindestens 72 Cores bestellen, auch wenn Sie weniger benötigen. Das gilt für Neukunden und für Bestandskunden.
Mindestlizenzierung und Mindestbestellung sind zwei Paar Schuhe. Ihr könnt weiterhin Nodes im Cluster ab theoretisch 16 Cores lizenzieren, jedoch müsst Ihr immer (auch bei Nachbestellungen) 72 Cores bestellen. Darunter bucht Broadcom einfach nicht und liefert keine Lizenzen aus.
Die Regelung mit der Mindestbestellung tritt ab dem 1. April in Kraft, ist de facto aber schon heute aktiv.
Ich möchte Euch noch einen persönlichen, strategischen Rat mitgeben. Vielleicht hilft er der einen oder dem anderen. Broadcoms Zielgruppe sind große Organisationen, ja, sehr große Organisationen. Das ist schade. Wir alle haben uns an die erschwinglichen und hervorragenden Lösungen aus den Zeiten "VMware allein zu Hause" gewöhnt. Ist man nicht auch richtig groß (und selbst dann), würde ich heute auf Alternativen hinarbeiten. Das Problem Broadcom geht nicht mehr weg. Aussitzen ist keine Option. Ihr müsst handeln. Es gibt bspw. Vates (unser Favorit) oder ihr stellt einfach auf pure Windows Server um, falls möglich. Jeder hat eigene Anforderungen und die eierlegende Wollmilchsau haben auch wir nicht im Stall stehen. Aber Ihr solltet handeln und zumindest auf eine Loslösung von VMware hin arbeiten, wenn Ihr nicht gaaaanz groß seid! Broadcom geht nicht mehr weg.
Don, ich habe keine Probleme mit deiner Verlinkung zu Software-Express – hab euch im Zusammenhang mit Windows ESU-Lizenzen ja häufiger verlinkt.
Japp, danke. Ich verlinke auch nur, wenn es für die Mitlesenden wirklich hilfreich ist. In diesem Sinne, ein schönes Wochenende.
Der Besuch eines guten Englischkurses dürfte wohl bestimmten Personen helfen …. die in englischer Sprache klar und deutlich abgefassten Original-Vertragsbedingungen ! richtig verstehen zu können.
Broadcom fügt sogar noch ein Beispiel an, um die neue Regelung zu veranschaulichen!
Was ich mich ernsthaft frage: Wie können Leute mit beschränkten oder sogar komplett fehlenden Englischkenntnissen überhaupt als Administratoren von virtuellen Maschinen professionell tätig sein?
Hast Du den Original Broadcom Text, den Du mir zur Verfügung stellen könntest? Ich bin aktuell auf die beiden verlinkten Quellen angewiesen.
Ich habe als Deutscher sogar Probleme mit manchem deutschen Kleingedruckten, dennoch kann ich mit dem PC und englischsprachiger Technik gut umgehen, dabei hatte ich Englisch nicht mal als erste Fremdsprache.
Mit VMware vSphere ist es sehr einfach in kleinen Umgebungen ein SAN via FC mit den Hosts zu verbinden und darauf ein Shared Datastore mit Snapshot-Fähigkeit einzurichten. Dürfte im KMU-Umfeld ein oft angewendetes Szenario sein. Nicht alle brauchen dafür 72 Cores.
Mit Proxmox kann eine solches Cluster mit FcSAN nicht 1:1 abgelöst werden. Der Shared Datastore funktioniert, wenn man im Debian die Multiplath-Konfiguration mit der vorhandenen Hardware zum Laufen bringt. Das Datastore wird dann als LVM erstellt. Mit LVM sind dann jedoch keine VM-Disk-Snapshots mehr möglich. Vielleicht habe ich aber auch was übersehen?
Schade macht Broadcom VMware „kaputt". ESXi und vSphere war bisher ein gutes, brauchbares Produkt. Mit VMware GSX-Server und später VMware Server, für den es auch Free-Lizenzen gab, hat die Firma in den letzten 25 Jahren sicher viel zur Verbreitung der Virtualisierungstechnologie beigetragen und viele ITler ihr halbes Berufsleben lang begleitet.
Nun aber, Schraubendreher ausfassen, ISO eines anderen Herstellers einlegen und auf geht's zu neuen Horizonten. Auf Virtualisierung zu verzichten ist keine Option!
Dieselbe Erkenntnis hat uns bei der Umstellung auf Proxmox auch getroffen. Im Grunde bleiben folgende Möglichkeiten: Ceph Storage (also der HCI Gedanke, Vorsicht vor zu langsamen inter-host-connections, die lassen die Performance leiden) lokaler zfs storage und dann mit Replikaten arbeiten oder ein zentrales storage das aber immer compute braucht. Also zum Beispiel ein blockbridge. Die Preise sind aber dort absurd hoch für KMU nicht zu stemmen und auch nur was für die ganz großen…
Wir haben uns da primär Test Umgebung für local zfs entschieden und gute Performance raus geholt.
Aber das hängt halt immer vom usecase ab.
Vor dem gleichen Problem stehen wir auch. Letztes Jahr noch ein neues All-Flash Cluster für einen 6-Stelleigen Betrag gekauft, das könnten wir mit Proxmox nun nicht mehr sinnvoll und mit Support nutzen.
Finde es sehr schade, dass Proxmox in dem Punkt stur bleibt und keine wirkliche Alternative anbietet. Mir ist bewusst, dass HCI (CEPH) und SDS (z.B. Blockbridge) die moderneren Lösungen sind, als eine Storage Anbindung über FC oder ISCSI. Für die Migrationsphase ist das natürlich, wie z.B. in unserem Fall, der absolute Killer.
Zumal ja oft auch andere Systeme (z.B. ein WSFC) an das Storage angebunden ist, was mit CEPH in der Form auch nicht möglich wäre.
Wir haben ocfs2 (unsupported) getestet und das wäre prinzipiell okay. Aber mit Quorum etc. Auch kein Ersatz für die lockmechnismen von vmfs in kleinen Umgebungen.
72 cores was soll das den für ein Geschäft sein, die das nicht erreichen?
Eigentlich will man heute doch alles virtualisieren um bei Hardwareausfällen schnell reagieren zu können. Da würde ich erwarten dass alle etwas technikaffinen Gewerke mit mehr als 15-20 Mann schnell auf die 72 cores kommen.
Runter fallen doch nur Bastler und Einmannshows, aber da gab es doch wieder die Desktop-Variante.
Ganz generell finde ich Broadcoms Umgang mit Kunden, die Kommunikation und Preise abartig. Schon aus dem Grund würde ich mich nach Alternativen umsehen.
Die 72 Cores sind doch einfach eine praxisferne, willkürliche Grenze um die kleinen zu vergraulen, bzw. zu melken. Mit 2 Nodes, 2 CPUs/Node und 8 Cores/CPU brauchte man bisher Lizenzen für 64 Cores (weil min. 16 Cores per CPU). Wählt man Server mit leistungsfähigen CPUs kann man damit für kleinere KMU schon was brauchbares machen.
Ja, definitiv Zeit für alternative Hersteller. Diese arbeiten auch daran noch fehlende Features einzubauen, denn die Kundschaft steht Schlange vor der Türe.
"Da würde ich erwarten dass alle etwas technikaffinen Gewerke mit mehr als 15-20 Mann schnell auf die 72 cores kommen."
Nein, definitiv nicht. Ich kenne auch viel größere Unternehmen (ca 200 User) die mit deutlich(!) weniger Cores auskommen. Oder sprichst du von einem Voll-virtualisiertem Unternehmen, in denen es nur noch Terminal-Clients gibt? Mit fetten Terminalservern sieht es natürlich anders aus. Aber überall dort, wo lediglich auf Anwendungen zugegriffen wird, kommt man mit um viele Größenordnungen kleineren Servern aus. Ich habe die Doku gerade nicht vor Augen, nach meiner Erinnerung sind es zwei Server mit jeweils <16 Cores.
Das Problem ist doch viel mehr, dass die Grenze von 72 Cores auch bei einer Lizenzerweiterung gilt. Also wenn z.B. ein zusätzlicher Server mit Beispielsweise 32 Cores Lizenziert werden muss.
VMware bieten wir zwar noch an, aber nicht mehr lange. Bei ehemaligen VMware-Kunden migrieren wir auf Hyper-V, wenn eine Lizenzverlängerung ansteht. Ist dank Veeam Backup Restore kein Problem. Neue Kunden nehmen immer öfter Proxmox. Broadcom macht hier das gleich wie damals schon bei Symantec, den letzten Rest noch ausquetschen mit minimalem Einsatz
72 Kerne sind bei einem modernen Rackserver schnell erreicht.
Dell PowerEdge R6725, Rackserver mit 2 HE, mit zwei AMD AMD EPYC 5gen 9365 Kacheln mit 36 Kernen und man hat 72 Kerne. Der Chip findet sich in folgender Tabelle im unteren Drittel, man kann den Chip auch als 9965 mit sage und schreibe 192 Kernen haben, macht 768 Threads bei einer 2 Sockel Maschine.
https://www.amd.com/de/products/processors/server/epyc/9005-series.html
Dell PowerEdge R760, Rackserver mit 2 HE, mit zwei Intel XEON 6. Generation, 6736p hat auch 36 Kerne, und man bekommt auch hier bis zu 144 Kerne pro Kachel, macht 576 Threads bei einer Zweisockel-Maschine.
https://www.intel.de/content/www/de/de/ark/products/series/240357/intel-xeon-6.html
Auf so einen 72-Kern-Server bekommt man 18 Vierkern-VMs drauf, ohne die Mühle zu überprovisionieren, sprich jede dieser VMs hat die je 4 Kerne für sich alleine. Nacht man natürlich nicht, da laufen auch locker 36 solcher VMs drauf. Das ist durchaus realistisch und 36 virtualisierte Server hat eine kleine Firma sicher schnell zusammen. Natürlich braucht man zwei von den Blechen, wegen Redundanz, man will ja nicht die zahlreichen VMs runterfahren, wenn man mal wieder notgedrungen Vmware-Sicherheits-Updates installieren muss…
Ob man die ganz dicken Brocken von AMD und Intel in die 1 HE-Maschine auch reingesteckt bekommt, weiß ich nicht, aber die 36-Kerner bestimmt. In den oben genannten 2 HE Maschinen geht Dank größerer Netzteile sicher mehr.
Aus Vmware-Sicht verhält sich das so: Je mehr Kerne eine CPU hat, um so mehr VMs kann man da drauf packen. Also mit fortschreitender Entwicklung würde Vmware immer weniger Sockel-Lizenzen verkaufen, ohne dass die Anzahl virtualisierter Server sinkt, im Gegenteil, wie man sieht, geht der Trend ja zu immer mehr Servern ("Eine Anwendung, ein Dienst, ein Server".)
Natürlich will VMware weiterhin sein Stück vom Kuchen haben.
ohne Overprovisioning….
Wirtschaftlich selten sinnvoll.
es geht ja im Artikel weniger um die Sockel-lizenzierung als um die mindestabnahmemenge. 72 physikalische Kerne sind für uns zu viel. auch wenn wir das mit der Sockellizenz schon im Einsatz hatten aber nicht weil es notwendig war.
Kommt auf den Einzelfall an, ob das wirtschaflich sinnvoll ist. Es gibt durchaus Anwendungen, welche dauerhaft diese Leistung brauchen. Gerade jetzt auch, wo laut Dell-Server-Spezifikationen diese ganzen Server für KI "gebraucht" werden. Ne KI die nicht unter Dauerlast läuft, wird nicht "gebraucht". "gebraucht" ist absichtlich in Anführungszeichen, falls hier jemand auf dieses Buzz-Thema anspringt, nach dem Motto: Wer zwischen den Zeilen lesen kann, ist ganz klar im Vorteil!
Alles hat seine Zeit. Und die Zeit von VMeare ist jetzt abgelaufen. Der Stern ist am Ende. Jetzt noch kurz vor der Implosion maximal viel Geld aus den Kunden ziehen, bevor VMware gänzlich der Vergangenheit angehört. Ich habe noch kein Produkt gesehn, das nach der Übernahme durch einen Konzern aufgeblüht ist. Letzendlich macht deren Gier einfach alles kaputt. Und genau deshalb halte ich mich von diesen fern. Ich kann auch nicht verstehen, wie erfolgreiche KMUs sich an diese Heuschrecken verkaufen. Gier essen Hirn auf.
Milk-License: Milch wird pro 1Liter lizenziert. Eine solche Lizenz wird als Milk-Lizenz bezeichnet.
Mindestmilkisierung: Jede Milchpackung muss mit mindestens 16 Litern gekauft werden. Für jede 8 Liter Packung (oder 4 Liter Packung) müssen Sie also auch 16 Liter bezahlen.
Mindestbestellung: Bei jeder Bestellung müssen Sie mindestens 72 Liter Milch bestellen, auch wenn Sie weniger benötigen. Das gilt für Neukunden und für Bestandskunden.
Mindestlizenzierung und Mindestbestellung sind zwei Paar Schuhe. Ihr könnt weiterhin Milch im Gebinde ab theoretisch 16 Liter kaufen, jedoch müsst Ihr immer (auch bei Nachbestellungen) insgesamt 72 Liter bestellen. Darunter läßt der Marktleiter Euch nicht mehr aus dem Laden.
lasst Euch melken !