VMware-klanten moeten extra licentie afnemen voor cpu's met meer dan 32 cores

VMware past zijn licentiemodel aan. Per 2 april moeten klanten voor cpu's met meer dan 32 cores een 2CPU-licentie afnemen. Momenteel is dat een 1CPU-licentie ongeacht het aantal cpu-kernen. Voor bestaande klanten geldt de regel nog niet.

VMware past de nieuwe licentieregels toe op zijn gehele softwareaanbod waarvoor licenties op cpu-basis beschikbaar zijn. Voor processors met maximaal 32 cores is één licentie voldoende, maar bij meer cores moet er een tweede licentie afgenomen worden.

Vooralsnog laat VMware voorbeelden zien van processors met 64 cores, waarvoor twee licenties nodig zijn. Er zijn nog geen x86-processors met meer cores, maar het lijkt erop dat VMware met de nieuwe regels in de toekomst bijvoorbeeld vier licenties zal vereisen voor een processor met 128 cores.

Volgens VMware gebruikte het overgrote deel van zijn klanten momenteel bestaande Intel- en AMD-processors met minder dan 32 cores. Beide fabrikanten hebben cpu's met meer dan 32 cores uitgebracht. Intels Xeon-lijn gaat momenteel tot 56 cores per cpu en bij AMD's Epyc-serverprocessors is dat maximaal 64 cores.

Klanten die al een licentie hebben en nieuwe hardware willen installeren met meer dan 32 cores per cpu, komen in aanmerking voor een gratis tweede licentie als ze voor 30 april daar een aanvraag voor doen. VMware zegt met de aanpassing te komen naar aanleiding van de 'verwachte veranderingen' in de hardwaremarkt.

Reacties (139)

Tja niet zo heel gek, want mensen proppen gewoon 1 zwaardere cpu in een vmware host ipv zoals vroeger 2 keer een dualcore oid.

Alleen de manier waarop ze dit dan weer verpakken alsof het beter is voor de klant tja..

[Reactie gewijzigd door DDX op 4 februari 2020 20:52]

Totdat 64 core CPU's gemeengoed zijn, dan betaal je je in verhouding weer scheel. Het is gewoon een lange termijn tactiek.

Het is zeer zeker geen lange termijn tactiek, dit is korte termijn. Het issue is dat bijna elk bedrijf naar de 'cloud' gaat en de grote cloud aanbieders hebben geen VMware draaien. Daarnaast zijn de bedrijven die nog wel lokaal een (aantal) servers hebben draaien de boel aan het consolideren naar zo weinig mogelijk machines. Afhankelijk van wat men nodig heeft vaak zelfs geen multi CPU bakken meer. Dus VMware is aan het bloeden aan alle kanten en wat ze dan doen, zoals al eerder, is de prijzen effectief verhogen voor bepaalde setups.

Dat gecombineer met dat virtualisatie gewoon commodity is geworden (opensource varianten, Windows doet het goedkoop) is het logisch dat je, met een duur product, niet echt meer hard groeit.

Microsoft geeft Hyper-V praktisch gratis weg (gemakkelijker migreren naar Azure later). En ik weet dat het nog lang niet in de buurt komt van VMWare maar als je de prijsverschillen ziet wordt het toch wel heel overtuigend.

Voor de meeste omgevingen is VMWare overkill. Ik heb al voldoende klanten overgezet op Proxmox (betaald). Alleen als je denkt 24/7 een VMWare engineer nodig te hebben zou ik er voor betalen. Verder is het duur, soms instabiel (netwerkkaarten die er 2x per jaar uitknallen en niemand snapt het) en teveel tunables waardoor je een horde specialisten nodig hebt om het te tweaken. En de grap is dat je als bedrijf geen cent meer gaat verdienen als je VMware gebruikt. Je IT kosten gaan omlaag, maar je omzet als bedrijf verandert er niet door.

Dit deel van je betoog kan ik niet volgen:

En de grap is dat je als bedrijf geen cent meer gaat verdienen als je VMware gebruikt. Je IT kosten gaan omlaag, maar je omzet als bedrijf verandert er niet door.

Dat is toch het doel van interne optimalisatie? Bij gelijkblijvende inkomsten minder kosten maken?

Ja, maar als je je business case aan het opstellen bent en VMWare naast de alternatieven legt is het moeilijk uit te leggen dat je meer wilt betalen dan voor de concurrerende producten. Want welke je ook kiest: ze doen allemaal ongeveer hetzelfde, maar de een is duur en de ander niet.

Ik heb diezelfde business case gemaakt, men wilde proxmox maar dan niet betalend. Gezien er ook een specifieke vraag was naar ondersteuning van non-tcp ip netwerk verkeer (zeer exotisch protocol) dat ze dan ook nog in high availability wilden zijn alle hypervisors meerdere keren in de problemen gekomen.

Proxmox had 2 grote nadelen:
- Van het moment het fout gaat is de GUI nutteloos, je bent verplicht op command prompt te werken wat niet bepaald bevorderlijk is om geen dure engineers nodig te hebben.
- Cluster issues, als je een node verwijderd mag die nooit nog online komen maar ook het IP en de hostname mogen nooit meer gebruikt worden. Als de cluster zelf de mist in gaat, wat ook gebeurd is om een andere reden, dan weet ik niet welke expert je nodig hebt maar ik kreeg er nog 0,0 leven in, het is een format op alle nodes geworden.

VMWare was overigens de enigste die nooit echt tilt geslagen heeft in de testen waardoor management deze gekozen heeft. Ik snap best dat een vaag issue dat niet opgelost geraakt behoorlijk frustrerend is maar ik zie behalve dat je er ooit een issue mee had geen motivatie in je betoog.

Proxmox had 2 grote nadelen:
- Van het moment het fout gaat is de GUI nutteloos, je bent verplicht op command prompt te werken wat niet bepaald bevorderlijk is om geen dure engineers nodig te hebben.

Niet per se. Maar wees gerust. het is gewoon een Debian bak. Niet een propriatary software pakket. Je schetst alsof de CLI een slecht iets is. Een beetje IT'er die werkt met virtualisatie, krijgt ook met linux te maken.

Ik begrijp je punt hier ook niet. Want als je GUI niet meer werkt in vmWarez dan zal je ook naar de KB moeten gaan, of zelfs een support ticket indienen. Voor Proxmox ga je naar de CLI, en daar kan je dan nog je VMs starten en aanpassen zonder tussenkomst van de GUI. Heel de KVM, LXC stack en de Clustertooling hebben CLI tools (pct, pvecm etc)

- Cluster issues, als je een node verwijderd mag die nooit nog online komen maar ook het IP en de hostname mogen nooit meer gebruikt worden. Als de cluster zelf de mist in gaat, wat ook gebeurd is om een andere reden, dan weet ik niet welke expert je nodig hebt maar ik kreeg er nog 0,0 leven in, het is een format op alle nodes geworden.

Proxmox is er heel duidelijk over. Het gaat over de SSH fingerprint blijft op de server staan:
"""After removal of the node, its SSH fingerprint will still reside in the known_hosts of the other nodes. If you receive an SSH error after rejoining a node with the same IP or hostname, run pvecm updatecerts once on the re-added node to update its fingerprint cluster wide."""

Ik schets dat problem solving/shooting via CLI minder instap vriendelijk is dan via een GUI. Gezien, althans bij de testen die ik gedaan heb, de GUI bij het minste issue ofwel stopte met werken of niet toe liet het op te lossen, stel ik dat je net meer expertise nodig hebt.

Uiteraard zal je bij Vmware ook naar een CLI moeten grijpen als de GUI niet werkt, echter tot hier toe, is die noodzaak hiervoor er hier nog niet geweest waar Proxmox bij het minste issue de GUI nutteloos was.

Als ik even je bron mag gebruiken, Proxmox is ook heel duidelijk dat een cluster die fout is gegaan moeilijk tot niet te herstellen is. Ik weet de details niet meer hoe het hier juist fout is gegaan maar het had niets te maken met een node te verwijderen of SSH fingerprint, maar het punt dat ik maak is dat als ze zelf al aangeven dat een clusterprobleem nauwelijks op te lossen valt dan is dat voor mij een rode vlag. Het SSH fingerprint verhaal volgt diezelfde lijn dat de cluster techniek niet bepaald bulletproof is.

"As said above, it is critical to power off the node before removal, and make sure that it will never power on again (in the existing cluster network) as it is. If you power on the node as it is, your cluster will be screwed up and it could be difficult to restore a clean cluster state."

[Reactie gewijzigd door sprankel op 5 februari 2020 11:52]

... and make sure that it will never power on again (in the existing cluster network) as it is.

Lezen meneer: "As it is."
Na een re-install kan je die host prima draaien los van het bestaande cluser. Of opnieuw toevoegen wanneer je de ssh fingerprints verwijderd van het bestaande cluster.

[Reactie gewijzigd door D0phoofd op 5 februari 2020 13:11]

Wij hebben uiteindelijk gekozen voor HyperV omdat deze 90+% bied van wat VMWare bied, maar dan zonder extra kosten. Die 10% extra functionaliteit (van Entprise Plus) gebruiken wij niet, daarmee besparen wij ruim 4000 euro (ex btw) per server. Wij hebben inmiddels ruim 30 dual Epyc (7742 - 64 core) servers staan. Onder het nieuwe model zouden wij dan 4 licenties moeten afnemen. Dan praat je over bijna 17.000 euro. de Epyc 7742 processor zit rond de 8000 euro per stuk..

Tenzij je echt die features nodig hebt welke VMWare bied ten opzichte van Hyperv (of andere hypervisors), kun je het geld beter besparen en besteden voor hardware..

Optimalisatie komt na innovatie.

Ik denk dat @latka bedoeld, dat VMware te weinig unieke/innovatieve "killer" features heeft om zijn meerwaarde t.o.v. open-source of goedkopere pakketten te verantwoorden. Als het product gemeengoed is geworden en daardoor onderhevig is aan veel concurrentie, dan kunnen license kosten al gauw naar kopje "overhead" schuiven ipv kostprijs.

In geval van VMware ga je er niet meer omzet mee draaien, dus kan je er net zo op besparen. Het kan dan zomaar logischer zijn om een eenmalige migratie/ontwikkeling kosten te dragen, dan steeds hoger worden license kosten te betalen.

Nu snap ik je, @latka bedoelt het tegenovergestelde van wat hij lijkt te zeggen. Ofwel ‘Je gaat geen cent meer verdienen als je VMWare gebruikt en je kosten gaan omhoog’, of ‘Je gaat geen cent meer verdienen als je VMWare gebruikt maar bij het alternatief gaan je kosten omlaag.

Ik draai ook proxmox en VMware, VMware is toch nog wel iets beter maar het hangt er inderdaad vanaf waar je het voor nodig hebt.

Instabiel zou ik het niet noemen, ik hoef echt niks te tunen en er knalt echt niks uit. Draai je misschien je VMware op unsupported hardware?

Nope, HP hardware. Broadcom NICs.

Nope, HP hardware. Broadcom NICs.

Ik troubleshoot esx networking stacks voor werk, broadcom is vaker lastig let op je driver/fw combos en ga mee.

[Reactie gewijzigd door analog_ op 5 februari 2020 00:03]

Broadcom kan echt een probleem zijn. Zeker met die 10 Gb/s adapters als module (Proliant G8 en later) i.p.v. PICe kaart. En in combinatie met Cisco switches.
Ik heb er meerdere gehad die na een reboot tussen de 10 en 50 minuten nodig hadden om netwerk-link te detecteren. Of keihard naar 100 Mb/s gingen terwijl de switch alleen 1 en 10 Gb/s doet.
Da's erg leuk bij een failover scenario....
Gek genoeg gingen de PCIE kaarten met exact dezelfde chipset (en dezelfde ESX drivers) dan weer wel goed, maar die hadden het probleem met HP Aruba switches.
Uiteindelijk er maar Intel NICs in gestopt en alle problemen weg.

Die staan nu niet echt bekend om hun stabiliteit en kwaliteit van hun drivers.

Hmm, dan ben je de enige met deze problemen denk ik.
Wij draaien al VMware ESX vanaf versie 2.5.1 (2005: destijds Proliant DL585) nu dan op Synergy. En nog nooit issues gehad. Meer dan 200 VM's waarvan echt alles gevirtualiseerd is. Ook PBX. Elke nacht met VEEAM keurig replicatie gemaakt naar andere vestiging.

Wat een raar verhaal. Ik werk bij een bedrijf waar we een paar duizend werkplekken en een paar honderd servers over verschillende sites allemaal beheren via VMWare, en we hebben geen "hordes specialisten nodig" want we doen dat met 6 man.

Zie andere reactie met peak-load van een interactieve applicatie voor eindejaar verwerking met SLA erop. Die drukte de rest weg. Als het batch was was het geen issue. Dedicated hardware ook geen issue. Maar omdat het interactief was en de responsetijd naar de gebruikers cruciaal moesten er eigenlijk teveel resources heen. wat de rest van de omgeving teveel in de weg zat. Extra hardware had een optie geweest, maar het was maar voor 2 maanden, dus dat gingen we niet redden. Horde was in dit geval 3 specialisten die het geheel tweakten tot de meest optimale situatie voor die periode.

Daar heb je DRS voor en een goed geschaalde omgeving. Niks spannends aan met VMware. Volgens mij is er wat anders aan de hand, bijvoorbeeld een verkeerde opzet/design van de ESX omgeving. Een ESX farm is zo goed als de ontwerper er van en de gekozen hardware.

Daarnaast zijn er een aantal mitigations geweest voor Intel CPUs die performance onder load behoorlijk negatief beïnvloeden bij veel IO en Hyperthreading scenario's waardoor AMD waarschijnlijk een betere optie was geweest, maar zonder kennis van de omgeving en de applicatie is dat ook gissen.

En misschien is er wel iemand die heeft geroepen dat meer cores in een VM beter is zonder na te denken over andere factoren zoals Disk, Netwerk en geheugen en de configuratie hiervan op host niveau.

[Reactie gewijzigd door Wim-Bart op 4 februari 2020 23:33]

DRS op manual staan? VMware is rock solid in cluster omgevingen. Vooral als je FC gebruikt.

Ik ben als hobbyist wel eens in virtuele machines gedoken. Ik had daarbij een enigszins bizarre set-up, waarbij ik zelfs richting professionele hardware moest gaan. Alsnog was VMWare zwaar overkill. Open source spul zoals KVM/QEMU was goed genoeg. En wanneer je eenmaal doorhebt wat je doet, niet eens zo moeilijk om op te zetten.

Om wat specifieker te zijn, ik had een tweede videokaart die ik aan een virtuele machine koppelde. Deze VM had volledige zeggenschap over deze videokaart. Later stopte ik er nog wat extra hardware bij. Destijds was AMD ruk, en als je het echt goed wilde doen moest je IOMMU separatie (ofwel ACS support) in je hardware hebben. Dit werd alleen ondersteund door Intel op de meeste (niet eens alle) HEDT CPU's en op de Xeon E5 en E7 lijnen. Verder was wat extra PCIe lanes ook niet onwenselijk. Verder had Nvidia een subroutine in zijn drivers die checkt of je niet een consumentenkaart in een VM gebruikt. Overigens kan je de hypervisor met een simpele instelling verbergen, maar ik meen dat hierdoor wel iets van performance werd ingeleverd. AMD had dit probleem niet

Tegenwoordig zie je hobbyisten niet snel meer dit soort dingen doen. Het was vooral populair onder bepaalde Linux gebruikers die niet hun hele computer opnieuw wilden opstarten om te gamen. Tegenwoordig lijkt bijna alles wel te werken op WINE. Wellicht ga ik het nog ooit gebruiken, maar dan alleen omdat ik toch een server ergens ga verstoppen. Die mag dan best wel een videokaart erbij in hebben, en dan laat ik Steam In-Home Streaming wel regelen dat het op mijn beeldscherm komt.

Maar heb je als hobbyist ook al eens geprobeerd om iets zoals een HA cluster op te zetten? Machines verhuizen in die cluster? Gewoon eens de stekker uit trekken zonder dat iemand downtime merkt op ook maar 1 machine?

Er is veel mogeljk met open source software, maar de eenvoud waarmee je zulke dingen doet in VMWare kom je niet snel tegen.

Snap jr betoog niet: als je IT kosten dalen bij gelijkblijvende inkomsten/omzet dan verdien je toch juist meer als bedrijf?
En als je alleen standaard (basis) virtualisatie nodig hebt voor een handvol vms dan kan vmware overkill zijn maar bij dat soort gebruik zelden of nooit gezien dat "het eruit knalt" agv fouten in vmware imho zeer stabiel produkt. Maar als je bepaalde functies wenst die (veel) verder gaan, zoals op grote schaal meerdere organisaties (afdelingen of zelf bedrijven/klanten) op dezelfde hw clusters draaien of je wil de power van micro-segmentatie gebruiken dan heeft vmware voor mij nog heel vaak de voorkeur. Ook als je hosts heel soepel van het ene datacenter naar het andere wil kunnen overzetten zonder ip adres te wijzigen (terwijl je geen groot stretched l2/broadcast domain wil hebben) dan kom je ook weer terecht bij vmware en mogelijk andere betaalde paketten.
En vsan, vxrail/vblock of private vcloud met open source paketten kunnen flinke uitdaging zijn.
Blijf erbij dat er vast veel voorbeelden te bedenken zijn waar vmware mogelijk overkill is; maar in de grotere enterprise omgevingen is er nog veel markt.
En publieke cloud is ook niet voor iedereen zaligmakend en kan bovendien ook zwaar in de papieren gaan lopen.

[Reactie gewijzigd door tonkie_67 op 5 februari 2020 01:01]

Promox is prima qua features en prestaties. Bovendien verloopt de ontwikkeling daar ook vlot. Ik ben er erg tevreden over.

hyper-v zelf is gratis. je betaald alleen voor de hosts die je er virtueel op draait.
en is dat Linux, dan betaal je zelfs helemaal niets.

En als je groot inkoopt, dan kost een (embedded) serverlicentie ook praktisch gezien, bijna niets meer.

Hyper-V is gratis, met server standaard kun je gratis 2 Windows VM's draaien, met server datacenter ongelimiteerd Windows. Linux is sowieso gratis.

Dan zou ik toch nog eerder proxmox prefereren tov hyper-v.

Ik heb jaren HyperV gedraaid en nu drie jaar over op Proxmox. Nooit meer omgekeken!

hyper-v zelf is gratis. je betaald alleen voor de hosts die je er virtueel op draait.

Wat hij zegt klopt; het staat er wellicht wat vreemd.
De Hyper-V host is gratis. De VM's die je er op zet hebben een licentie nodig, als ze dat nodig hebben.
Dus is je guest een Linux distro, of bijvoorbeeld Windows IOT, of een Windows-variant die je voor testdoeleinden inzet dan kost dat niets.

Voorzie je een guest van Windows Server of zelfs Windows 10 dan moet je voor dat guest-OS betalen, net als dat je dat zou moeten als je dat OS op blik en welke andere hypervisor dan ook zou installeren.

helaas moet je voor WIndows 10 IoT ook een licentie hebben om deze virtueel te mogen draaien.
laatst hebben wij die licenties moeten kopen. Dat zijn Windows 10 IoT High-End LTSC licenties.
Dat High-End slaat op virtueel draaien en kost een paar tientjes per licentie.

Ik vermoed ook niet dat ze kunnen groeien omdat imho de gehele Virtual Machine markt eerder aan het krimpen is dan aan het groeien. Een product is in mijn ervaring alleen maar duur als het veel werk kost in onderhoud en gebruik...

VMware heeft juist nauwelijks onderhoud .
Goede hardware/software combo en je hebt nauwelijks omkijken.

en VMware ondersteund als 1 van de weinige aanbieders OSX functionaliteit.

Alleen mag je macOS alleen virtualiseren op Apple Hardware (volgens de license agreement van Apple). Uiteraard werkt VMWare Fusion perfect op een Mac, maar zul je wel wel wat uitdagingen hebben om ESXi te draaien op elke Mac (er staan wel een aantal Macs op de Hardware Compatibility List van VMWare).

Zie: https://www.vmware.com/re...umn=Partner&sortOrder=Asc

Mijn ervaring is toch anders. Load (flinke) op 1 VM en het tunen om zo optimaal mogelijk te werken zonder de rest van de VMs al teveel in de weg te zitten heeft toch enkele dagen voor wat VMWare specialisten gekost. De applicatie had eigenlijk op dedicated hardware of in de cloud gemoeten, want het was een peakload die 2 maanden per jaar optrad (einde jaar verwerking).

Hmm dat klinkt toch meer als een ontwerpfout dan een resource probleem?

Over wat voor gigantische load hebben we het dan dat die per se in 2 maanden tijd moet plaatsvinden en niet verspreid kan worden over het hele jaar? En is dat echt voldoende geoptimaliseerd?

De load zat bij de jaarafsluiting (belastingtechnisch). Dus die kun je niet uitsmeren want dat is hoe de wetgever werkt. Slecht ontwerp van de software: zeker weten. Maar dat trek je ook niet 1-2-3 recht. Het was een suboptimale oplossing voor een probleem wat niet had hoeven bestaan als men de juiste keuzes op tijd aan het begin gemaakt had. Het virtualiseren van deze oplossing (want alles is virtueel) maakte dit probleem eigenlijk zichtbaarder. Op een hele bak dedicated hardware had het niet zoveel uitgemaakt.

Inderdaad, dit is gewoon een ontwerpfout. Men heeft gewoon vergeten hier rekening mee te houden.
Dit is het hoofdmoot van de problemen trouwens, men gooit alles maar in VM's maar houd er geen rekening mee dat het een shared omgeving wordt of dat virtualisatie ook een 'overhead' heeft.

Een bekend issue met oa. de jaar afsluiting. Erg fijn met 'cloud' oplossingen om dan even voor een maand (of twee) even wat extra resources erbij te kunnen prikken. Een dedicated server zou de rest van het jaar staan te niksen...

Yup. Cloud zou nice zijn voor de capaciteit, maar in dit geval was dat eigenlijk ook geen oplossing, om dat de eindejaar afsluiting bestond uit een aantal systemen over meerdere organisaties die samen werkten (eigenlijk een batch verwerkten met online requests). Als een van de partners de cloud in gaat dan was het nog geen oplossing. Iedereen in dezelfde cloud zou wellicht helpen, maar Oracle (duur), legacy, teveel poppetjes en tegengestelde belangen blokkereerden die route.

Helemaal mee eens en dat bedoel ik met 'duur', ook al moeten sommigen straks voor VMware meer gaan betalen, dat betekend nog niet dat het duur is of duurder is dan de concurrentie. Veel issues met VMware komen door niet voldoende resources en/of slechte inrichting/ontwerp.

De virtualisatie markt krimpt. Niet voor niets dat vmware niuwe markten probeert aan te boren. Ze komen binnenkort (maart/april)met native kubernetes integratie in esx. Ook richten ze zich in toenemende mate op hybrid clouds. Zo is nsx inmiddels multicloud zodat naadloos clouds kunt integreren en centraal kunt managen.

Ik weet niet waar je al deze aannames vandaan haalt, maar vorig jaar zijn ze 14% gegroeid. Vmware is een hele grote speler in de cloud markt en zal dat ook zeker nog wel even blijven. Vmware doet niet alleen maar vm’s

https://www.macrotrends.net/stocks/charts/VMW/vmware/revenue

grote cloud aanbieders hebben geen VMware draaien.

Enkel de 3 grootste:
Amazon: https://aws.amazon.com/vmware/
Microsoft: https://azure.microsoft.com/en-us/overview/azure-vmware/
Google: https://cloud.google.com/vmware/

[Reactie gewijzigd door IStealYourGun op 4 februari 2020 22:38]

Dat is even iets anders dan waar in die quote over gesproken wordt. Dit is VMWare op Azure, AWS en GCE draaien. Die drie gebruiken zelf geen VMware om hun cloud te draaien. Wezenlijk verschil. Meer bedoeld om het overstappen makkelijker te maken

VMware draait bv binnen AWS niet óp de AWS omgeving maar erin, gewoon op bare-metal.
Die bare-metal is wel van AWS en is direct gekoppeld aan AWS zodat je "best of both worlds" hebt.

Correct, maar het is niet zo dat AWS EC2 op VMWare draait wat wel geinsinueerd werd met die reactie van IStealYourGun

Oehh een cloud in de cloud, cloudception

The cloud is just sombody else's computer.
In dit geval is het VMware op een computer van AWS.
Geen "cloud in een cloud" zoals jij zegt, maar een VMware omgeving direct op de hardware van AWS met een directe koppeling naar de AWS Cloud.

Als de cloud slechts iemand anders zijn computer is, is het toch nog steeds 'de cloud'.

Je spreekt jezelf een beetje tegen

En DELL EMC zelf tegenwoordig.

Ze bieden het aan voor hun klanten, maar hebben het niet nodig voor hun eigen infrastructuur. Dat is wat er bedoeld wordt.

Klopt, VMware is voor de grote aanbieders te duur. Daarin tegen on-premise of private cloud zie je wel vmware volop worden gebruikt (althans in mijn omgevingen). Super grote organisaties leunen niet op 1 oplossing en hebben meerdere varianten om business continuïteit te garanderen. Recent voorbeeld Citrix, zeer grote organisaties hebben ook andere oplossing klaarstaan. Nooit op 1 paard wedden.

[Reactie gewijzigd door sokolum01 op 4 februari 2020 21:53]

Tsja beetje appels met peren vergelijking. De grote cloud providers zijn zo groot dat ze geen standaard tools gebruiken. Dus geen standaard vmware, hyper v of kvm. Ze hebben de schaalgrootte om eigen hyper visors, os en zelfs hardware te ontwikkelen. Alles om efficientie te verhogen

Er zijn genoeg grote organisaties die op VMware one draaien. Daarbij heb je van begin tot eind alles op VMware. Grote organisaties zijn ook niet gek en kijken ook naar kosten, ondersteuning en compatibiliteit.

Iedere business case is anders. Er is geen uniforme beste oplossing.

In die lange termijn tactiek zou het mij niets verbazen als vmware op ARM publiekelijk aangeboden wordt. Dan wordt betalen per 32 cores (maar dan wellicht ook een prijs per cpu type) bij nu al beschikbare 128 core cpu's "normaal".

vSphere / ESXi 7
(ESXi on ARM is al in beta)

Ik vraag me af of Amazon aws op vmware draait eigenlijk. Of andere grote datacenters/cloud provider. Zal toch niet alleen kubernetes oid zijn? Ik ben er teveel uit eigenlijk. In die gevallen zou fysieke ruimte ook we meespelen als je een hele grote aanbieder bent. Zou denken, kosten/bate.

Ik kan me niet echt vinden in dit verhaal. Sowieso hebben Cloud aanbieders op basis van VMware een ander licentie model als dat in dit artikel is omschreven. Daarnaast zijn er nog genoeg Cloud aanbieders op basis van VMware, echter kijk jij naar partijen die jou waarschijnlijk bekent zijn? Waarschijnlijk public cloud, of partijen als TransIP maybe?

Het is gewoon meer dan logisch dat VMware dit toepast, net zoals alle andere licentie boeren dit doen -> Microsoft -> core-licenties ipv socket licenties. VEEAM van sockets licenties naar VM licenties, ga zo maar door.

Als 1 CPU straks de capaciteit heeft van 4 CPU's, dan moet je wel iets doen indien het verdienmodel op basis van socket's is ingeregeld. Zo gek is dat niet, en heeft zeker niets met bloeden te maken, wat een onzin.

[Reactie gewijzigd door Marchel op 5 februari 2020 14:03]

Daarom zij ik ook 'grote cloud aanbieders', TransIP is er daar imho niet een van. Ik had het meer over het formaat van MS, Amazon en Google. En voor elke TransIP is er een 2tcloud (Copaco) die weer geen VMware gebruikt.

Ik heb niet echt het idee dat je begrijpt dat je 2 totaal verschillende markten met elkaar vergelijkt.

Jij vergelijkt het MKB met Enterprise. Omdat servers minder vaak een meerdere CPU socket gaan hebben, is de VMware markt bijna dood? Terwijl omgevingen waar veel sockets aanwezig zijn VMware een heel ander afrekenmodel heeft dan dat hier is besproken.

Daarnaast richt VMware zich op de Private Cloud en niet op Public Cloud. Ik werk voor één van de grootste Private Cloud aanbieders van Nederland op basis van VMware, ik heb nog nooit zo'n succesvol jaar gehad dan 2019 en 2020, en dat allemaal op VMware. Natuurlijk niet representatief voor de markt, maar je mening strookt gewoon totaal niet met het geen dat ik weet en ervaar.

Dit is mijn mening

[Reactie gewijzigd door Marchel op 5 februari 2020 14:41]

VMware is ook beschikbaar op AWS, Azure en Google Cloud. Dat van AWS is behoorlijk geavanceerd.

Multi CPU is toch altijd sneller dan multi core in verband met shared cache of dedicated cache? Of heeft iedere core tegenwoordig wel dedicated cache?

Moderne x86 cores hebben eigen L1 en L2 caches en een gedeelde L3 cache.

Alle cores op 1 CPU hebben heeft ook voordelen, de latency tussen cores is bijvoorbeeld lager.

Het is veel belangrijker om te kijken naar NUMA nodes dan je blind te staren op cache.

In essentie is goed NUMA management eigenlijk cache management

Absoluut maar niet elke cpu architectuur is hetzelfde. Hoe het opgedeeld is ligt aan veel meer dan enkel het cache.

[Reactie gewijzigd door Caelestis op 5 februari 2020 22:44]

howto NUMA op VMware...

https://itnext.io/vmware-...so-important-9764c16a7e73

Een zeer goed artikel voor Multi Socket ESX omgevingen.

Er is niks mis met het artikel. Het gaat meer om het "howto" opmerking en de ... Aan het eind van de zin.

Jammer dat het gewoon mijn werk jat en alleen een simpele referentie plaatst.
http://frankdenneman.nl (of http://numa.af)

De link naar je site is opgeslagen

Tja, dan zijn die mensen niet slim bezig, kan je maar de helft van de PCI lanes gebruiken, helft van de DIMM slots, maar 1 set cache memory, etc..

Dual EPIC 64 core

Maar dan betaal je wel suf met die nieuwe prijzen van vmware

En je hebt een single-thread snelheid van 2.25Ghz. Er zijn nog erg veel applicaties die meer baat hebben bij een hogere kloksnelheid dan meer threads/cores.

Hoe dan ook, dit zal op dit moment maar een beperkte impact hebben, gezien het feit dat de meeste Enterprises (nog) geen CPU's hebben met zoveel cores.
Voor gebruikers die het VMware SDDC-portofolio gebruiken (ESX/NSX/vSAN) gaat dit helemaal ernstig in de papieren lopen, dat kost momenteel al snel 25k+ per socket, dus als je dat 'ineens' moet verdubbelen ben je met 2x64cores gewoon ruim 100k kwijt.

Net 2 server met 1x Epyc per stuk voor een klant aangeschaft. Draaien S2D en Hyper-V failover cluster. Met 128GB en 13TB ben je ongeveer 25K kwijt, dan is de licentie een schijntje als je kijkt wat 2x Windows Server Datacenter kost.
Ik kom maar heel weinig scenarios tegen waar ik VMware nodig heb, moet ik wel zeggen dat ik System Center ook wel erg fijn vindt maar kost ook vanaf 4K.

Bij WSD lees ik "unlimited virtual machines, plus one Hyper-V host per license"
Hoezo geen VM nodig?
https://docs.microsoft.co...19/editions-comparison-19

128GB is tegenwoordig niks voor een virtualisatieserver, voor enterprises is 768GB nu normaal. Wij draaien al 1,5 jaar met 1,5TB per node. Ook 13TB storage zegt niks. Op 7k2 Sata is dat peanuts. Op Intel Optane NVMe een ander verhaal qua kosten. De waarde van een totaaloplossing is niet alleen in kosten voor hardware uit te drukken, het zit ook in beheerkosten, snelheid van wijzigingen maken, schaalbaarheid, en nog meer factoren.

Met zo'n portfolio zijn kortingen boven de 50% heel normaal bij cisco en vmware. Oracle en BMC hebben een ander business model: eerst een goedkoop klein touwtje, duurder uitrollen, knoopje leggen en dan maar aandraaien....

Ja, maar de grap met dit soort onzin licenties is wel er geen extra kosten zijn aan het hosten van 32 cores of 64 cores. Problemen met de software doen zich voor bij de stap van single naar multi-core (race condities e.d.). Dit soort pricing past bij melken, niet bij het toevoegen van extra waarde als ik meer cores gebruik. Doe dan gewoon een prijs die zoveel % van de jaaromzet is dan ben je gewoon eerlijk in hoe je je klanten ziet.

Zeker een onderhands dealtje met intel gemaakt?

Vmware is van Dell en doet weinig aan amd

Zeker een onderhands dealtje met intel gemaakt?

toch was t ook mijn 1e gedachte...

intel 32+ cores zijn al n tijdje op de markt, voor t 10voudige bedrag van de nieuwe amd tegenhangers. Die hebben al vm-contracten en zullen niet gedwongen kunnen worden t dubbele gaan te betalen. maar de nieuwe amd's worden toch echt gehinderd door dit soort onzin.

intel heeft op dit moment(net als in hun vorige wanpraktijktijd) niets om te kunnen concurreren met amd. en we weten hoe intel daar in t verleden mee om is gegaan...daardoor acht ik de kans juist zeer groot dat intel hierbij een dikke vinger in de pap heeft...

macht en geld en vooral de angst om dat te verliezen kan t ergste uit iemand halen...

Welke Intel 32+ cores zijn er? Bij mijn weten steken ze nog vast op 28 core Xeons.

Edit: Never mind, gevonden. 400w monsters met prijs op aanvraag en levertijd onbekend. Nice

[Reactie gewijzigd door Khrome op 5 februari 2020 01:18]

Ga eens even kijken. Ze hebben tegenwoordig een mooi AMD Epyc aanbod bij Dell.

De AMD Epyc is sowieso een fantastische CPU in datacenters. Veel cores, snel en een stuk betaalbaarder dan Intel.

Eerste waar ik aan dacht toen ik dit zag. Intel heeft het geld om dit af te dwingen, en ik zie ze dit wel doen ondanks de problemen die dit plannetje alsnog heeft

Intel heeft ook 32 core CPU's. Zelfs 48 en 56 Cores. Gros van die CPU's worden alleen gebruikt in de VMware on AWS cloud diensten of andere cloud hosting partijen. Daarnaast is core count vs beschikbare ram vs overcommit erop altijd een balans en afhankelijk van de workloads. Lange termijn strategie is meer dat ze willen dat je de het als dienst afneemt uit b.v. VMware on AWS waar je hardware, services en licenties in een package deal hebt. Platform zelf heb je geen omkijken meer naar en alleen maar hoeft na te denken je eigen services.

Denk dat uberhaupt een groot deel van de klanten geen enkele cent extra betaald nog. Beetje mainstream CPU op moment is maar 14 / 24 / 28 core. 1.5TB+ ram in een host is al te prijzig en laat staan die exotische 32+ core CPU's. En meeste klanten hebben wel een ELA/huur licenties i.p.v. perpetual licenties...

[Reactie gewijzigd door Qualixo op 4 februari 2020 21:35]

Wij zijn overgestapt van VMware naar Proxmox. Een clustertje van een tiental nodes en het bevalt goed! Eigenlijk mis ik niets. Alleen het netwerkbeheer is wat minder volwassen maar verder werkt het prachtig. Live migrations en de hele mikmak voor nop.

Hoezo, daar betaal je toch ook support voor? En dat support is ook met dit soort licentie modellen.

Daar kan je voor kiezen ja. Zo hebben wij een aantal licenties zodat we van de enterprise repositories gebruik kunnen maken (echter zonder support)
Support kan je indien nodig ook per ticket afnemen maar via forum werkt ook prima.

Is er ondertussen al "support "for stretched metroclusters ??.

Sales zegt altijd wel , wij kunnen alles wat de concurrrentie kan, de realiteit is toch vaak net wat anders en al zeker als het om de meer advanced feat. gaat.

Ook integratie en support met vendors als Rubrik of Veeam kun je meestal wel op je buik schrijven .
Of simpelere dingens als , is mijn SQL2014 wel supported op dit platform.

[Reactie gewijzigd door klakkie.57th op 4 februari 2020 22:23]

Proxmox is ook gewoon goed. In veel situaties heb je VMWare niet nodig en kan KVM met Proxmox precies het zelfde.

De KVM hypervisor is ook gewoon erg goed.

Klinkt alsof ze hebben gekeken hoe Oracle hun licentiemodel hebben tegenwoordig en zijn daar langzaam naar toe aan het bewegen.

Volgens mij is Oracle aan het kijken naar kosten per query model om de revenue nog wat hoger te krijgen

Oh maar bij cloud databases is dat al vrij normaal hoor, betalen per transactie.

En dat komt dan weer uit de mainframe tijd waar je per cpu-tik betaald(e).

Ja, maar dat dan on-premise met je eigen HW. There is no cloud, only some else's computer.

[Reactie gewijzigd door latka op 4 februari 2020 21:47]

Maar daar moet je geen rekening meer houden met de overhead zoals een (24/7) operationeel infrastructure team, licentie, backup, DR, HA, hardware, hardware support, ... dat zit normaal allemaal in die enkele transactie kost

Daar vergis je toch in. Veel bedrijven hanteren een licentie model per core en eigenlijk was VMware één van de weinige die per socket werkte zonder enige beperking. Met het uitkomen van AMD Ryzen, was het maar een kwestie van tijd tot er iets van een beperking zou komen en eigenlijk zijn ze er nog vrij laat mee.

Bovendien is het een pay-what-you-use-model en moet je enkel betalen voor de sockets die je echt gebruikt. Je kan perfect een cluster maken van 10 hosts en maar 2 hosts een licentie toekennen. Uiteraard kan je enkel op die 2 hosts ook VM's draaien en bedienen vanuit vCenter.

Bij Oracle moet je heel je cluster van de nodige licenties voorzien, zelfs als je maar een guest hebt die één enkele core gebruikt met daarop een oracle db

[Reactie gewijzigd door IStealYourGun op 4 februari 2020 22:57]

Maar je krijgt bij oracle en checkpoint wel een gratis ROI calculator zodat inkopers zich goed kunnen profileren bij de baas, bonus vangen want de roi calculator geeft een happy face...

Ben ik blij dat we overstappen op proxmox

Erm... Ik denk dat je baas ook Enterprise support wil en daar betaal je ook gewoon per CPU voor (op het moment), dat kan in de toekomst natuurlijk ook veranderen.

https://www.proxmox.com/en/proxmox-ve/pricing

Ik ken de prijzen, echter ben ik niet verplicht om een licentie nemen en werken alle toeters en bellen bij elke versie out-of-the-box.

En nee ... mijn baas interesseert dat niet, echter ik wel. Ik vindt het belangrijk dat er een support model achter zit.

[Reactie gewijzigd door powerboat op 4 februari 2020 21:24]

die kon ik nog niet:) bedankt
Gebruik je deze in een zakelijke omgeving ?

zo ja wat is je setup ?

Yes! Ik heb Promox draaien bij verschillende bedrijven vanuit mijn eigen bedrijfje.

Bij mijn primaire werkgever zijn we nu bezig met een POC met 3 nodes i.c.m. ceph storage.

Overigens ben ik aan het kijken of heb mogelijk is om een trainer hier te krijgen om training (certificering) te kunnen geven aan een een groep mensen

Kunstmatige limieten. Nergens voor nodig dit en hevig anti-consumer.

+32 cores is niet bepaald gemiddelde consumer ...

Ergens klinkt dit niet als eerlijke handel. VMware heeft een businessmodel om producten te verkopen dat zich op een markt richt waarbij gebruikers de vrijheid hebben om cpu's met steeds meer cores te kopen. Dat VMware nu zegt dat je bij een cpu met meer dan 32 cores extra moet gaan betalen of anders de software niet kan gebruiken lijkt mij het kapen van de vrijheid van de klant door die vrijheid eenzijdig te beperken. Als ze nu zouden stellen dat de software met 1 licentie tot maximaal 32 cores zal gebruiken zou ik nog redelijk vinden. Dan legt VMware namelijk geen beperkingen aan de vrijheid van de klant op, enkel op de vrijheid om VMware te gebruiken.

edit:
Hoezo off-topic irrelevant en zelfs niet gewenst? Als je het niet eens bent, komt dan met tegenargumenten. Ik ben benieuwd waarom we maar zouden moeten accepteren dat een bedrijf zou dicteren wat je wel of niet aan hardware mag gebruiken terwijl ze ook met minder vergaande acties het zelfde kunnen bereiken.

[Reactie gewijzigd door kodak op 4 februari 2020 23:17]

Het is juist zeer relevant en gewenst. Ik zou dit soort gedrag zelf niet accepteren. Maar je kunt ervan uitgaan dat een aantal van de modders een carrière heeft opgebouwd op basis van VMware producten en jouw reactie ziet als een aanval op de broodwinning.

Ook heb ik elders te horen gekregen dat Proxmox niet kan tippen aan de features van VMware Vsphere. Dat zou inderdaad het geval kunnen zijn en dat zou betekenen dat er in het Linux/KVM project nog flink wat te verbeteren valt. Daarnaast bestaat Hyper-V ook nog, maar daar kan ik niet veel over vertellen.

Ik weet nog goed dat ik in 2012 voor ESXi heb gekozen, omdat een oplossing op basis van KVM nog lang niet volwassen was. Maar we zijn nu 8 jaar verder en er zijn meerdere hypervisors. Containers beheerd via Kubernetes beginnen ook steeds populairder te worden.

Een broodwinning gebaseerd op het dwingen dat (nieuwe)klanten onredelijke belemmeringen op legt lijkt me geen eerlijke broodwinning. Helaas lees ik nog geen tegenargument waarom het wel redelijk zou zijn hoe VMware het licentiemodel wil toepassen door klanten te belemmeren in hun vrijheid in hardwarekeuze als ze niet meer licenties willen afnemen. Ik vraag me zelfs af of dit wel legaal is als ze het in de EU zo gaan toepassen.

[Reactie gewijzigd door kodak op 5 februari 2020 19:16]

Klanten pikten destijds hun gelijkaardige aanpassing van licentie IVM RAM niet en toen hebben ze moeten terugkrabbelen. Ik ben benieuwd hoe het nu gaat aflopen.

Het is een verdienmodel wat in de herfst van zn leven zit IMO...

Intels Xeon-lijn gaat momenteel tot 56 cores per cpu

in ZEER beperkte oplagen, als ze al echt beschikbaar zijn en niet enkel bestaan om mee genomen te worden in reviews, en met een in de meeste gevallen onbruikbaar hoog verbruik.

Nee, deze maatregel treft in de praktijk enkel en alleen AMD.

Linkje naar de prijzen: vanaf 1473€

https://www.altaro.com/vm...e-editions-and-licensing/

Dit zijn list prijzen. In software land zijn voor grote omgevingen kortingen boven de 50% gebruikelijk.

wel eens 90% korting gehad bij een vendor.( Dat was overigens niet vmware)