VMware maakt Fusion 12 Player voor macOS gratis voor persoonlijk gebruik

VMware heeft Workstation 16 en Fusion 12 aangekondigd. De Player-versie van Fusion 12 voor macOS is gratis voor persoonlijk gebruik. Daarmee brengt VMware zijn licentieplan voor Fusion in lijn met dat van Workstation.

Nieuw bij VMware Fusion 12 is de ondersteuning voor macOS 11.0 Big Sur als host en guest. Bij zowel Fusion als Workstation is ondersteuning voor DirectX 11 en OpenGL 4.1 en externe gpu's toegevoegd. Ook bevatten beide programma's voortaan een donkere modus.

VMware heeft daarnaast de ondersteuning voor 'kind' toegevoegd, waarmee lokale Kubernetes-clusters te draaien zijn, door containers als nodes in te zetten. Kubernetes is een opensourcesysteem om containers van apps te distribueren en te beheren.

Ten slotte voegt VMware ondersteuning voor VMware vSphere 7 toe en Workstation 16 kan voortaan overweg met virtuele machines, containers en Kubernetes-clusters op pc's met Windows 10 May 2020 Update met de Hyper-V-modus geactiveerd.

Over de ondersteuning van Fusion voor de komende op ARM gebaseerde Macs meldt VMware nog niets. Een commerciële licentie voor VMware Fusion Player 12 Player en Workstation 16 Player kost 149 dollar en een upgrade is voor bestaande klanten voor 79 dollar mogelijk, maar voor consumenten is gebruik dus gratis. De Pro-versies komen later dit kwartaal voor 199 dollar en 99 dollar voor een upgrade.

Fusion is VMwares software waarmee Mac-gebruikers een ander besturingssysteem binnen macOS kunnen draaien. Met Workstation kan dat op een Windows- of Linux-pc en met de Pro-versies zijn verschillende OS'en te draaien.

Reacties (50)

Waarom zou je in vredesnaam nog Kind (Kubernetes-in-Docker) gebruiken van VMWare (betaald) Als je dit standaard met Docker-desktop (gratis) meegeleverd krijgt en je daarmee een stabielere versie hebt?

Dat ze het doen snap ik wel, maar waarom je het zou moeten willen niet. VMware pakt volgens mij best wel wat overhead op de container nodes als ik het zo bekijk door de Node als Fysieke container te draaien. Hierdoor krijg je dus Containers die in containers draaien, met alle overhead van dien.

Dus of Tweakers heeft het net niet helemaal goed verwoord, of VMware is best raar bezig met hun implementatie, maar ik heb dan liever een single-node cluster, waar minder overhead op zit. Zeker op 16GB machines is het anders niet te doen.

Waarom zou je in vredesnaam nog Kind (Kubernetes-in-Docker) gebruiken van VMWare (betaald) Als je dit standaard met Docker-desktop (gratis) meegeleverd krijgt en je daarmee een stabielere versie hebt?

Dat ze het doen snap ik wel, maar waarom je het zou moeten willen niet. VMware pakt volgens mij best wel wat overhead op de container nodes als ik het zo bekijk door de Node als Fysieke container te draaien. Hierdoor krijg je dus Containers die in containers draaien, met alle overhead van dien.

Ik denk dat je je even moet verdiepen in de producten alvorens daar een hele sterke mening over te hebben. Docker is een Linux tool die de Linux kernel vereist. Docker kun je dus niet op een niet-Linux systeem zoals een Mac draaien. Docker for Mac doet dat dan ook niet. Ze maken slim gebruik van de ingebouwde hypervisor van macOS en draaien daar een virtuele machine op waarin docker draait. Middels allerlei additionele software lijkt het er dan op alsof het native in macOS draait. Voor Windows hanteren ze exact dezelfde werkwijze (uiteraard dan met de tools die Windows biedt).

VMware doet niet anders dan wat Docker for Mac ook al doet: onderwater is het een vm die draait met daarin docker en eromheen nog een laagje zodat het een native tool lijkt. Dit is iets wat ze met Fusion 11.5.5 hebben geïntroduceerd. Dat systeem van hun heeft als codenaam Nautilus (het is opensource en staat op github trouwens).

Het lijkt er nu op dat ze dit hebben uitgebreid met Kubernetes mogelijkheden (dat is niet helemaal zo als je kijkt wat Nautilus is en doet). Hierbij moet je echter even stilstaan bij de doelgroepen van VMware. Dat is veelal de enterprise waar men nu ook meer naar containers gaan en dan ook al snel tegen Kubernetes aanlopen. Het is lang niet alleen maar hippe startups die van cloudplatformen van Amazon of Microsoft gebruik maken.
De wensen en eisen van die doelgroep is anders. Het grote voordeel hier is het kunnen maken van een mix tussen virtuele machines en containers. Dat is iets wat je steeds vaker ziet en wat Docker for Mac absoluut niet kan. Docker for Mac is namelijk alleen maar containers (hetzij via hun eigen oplossing, hetzij via Kubernetes). Je kunt nu dus 1 specifiek product gebruiken en daarop standaardiseren. Voor veel bedrijven is dat een heel belangrijk punt.

Dus of Tweakers heeft het net niet helemaal goed verwoord, of VMware is best raar bezig met hun implementatie, maar ik heb dan liever een single-node cluster, waar minder overhead op zit. Zeker op 16GB machines is het anders niet te doen.

De verwoording is prima maar je hebt hier wel inhoudelijke kennis van de producten nodig om het te kunnen plaatsen.

Om een idee te geven wat de bedoeling is: met de huidige VMware Fusion heb je dat Nautilus. Op de commandline kun je met het vctl commando datgene doen wat je normaliter met het docker commando doet. Een bekend commando is het exec commando om iets in een container te doen. Vctl heeft er echter nog eentje:

exec Execute a command within a running container.
execvm Execute a command within a running virtual machine that hosts container.

Ze springen dus duidelijk in op de vervaging van waar en hoe je dingen draait. Virtuele machines en containers kun je nu dus door elkaar gebruiken ipv strikt gescheiden naast elkaar. Fusion 11.5.5 was stap 1, Fusion 12 stap 1,5 of 2 (hoe je het bekijkt). Er zullen ongetwijfeld nog wel meer stappen komen.

En om het nog duidelijker te maken zet ik hieronder de visie van Nautilus die ze op het Fusion blog hebben gezet voor de aankondiging van de 1e technology preview (wat we nu kennen als Fusion 12, simpel gezegd):

The vision for Nautilus: A single development platform on the desktop that can bring together VMs, Containers and Kubernetes clusters, for building and testing modern applications.

[Reactie gewijzigd door ppl op 21 augustus 2020 16:18]

Ik denk dat je je even moet verdiepen in de producten alvorens daar een hele sterke mening over te hebben. Docker is een Linux tool die de Linux kernel vereist. Docker kun je dus niet op een niet-Linux systeem zoals een Mac draaien. Docker for Mac doet dat dan ook niet. Ze maken slim gebruik van de ingebouwde hypervisor van macOS en draaien daar een virtuele machine op waarin docker draait. Middels allerlei additionele software lijkt het er dan op alsof het native in macOS draait. Voor Windows hanteren ze exact dezelfde werkwijze (uiteraard dan met de tools die Windows biedt).

Het ging mij dan ook vooral om het stukje betaald. Wat is het voordeel van fusion kind dan nog ten opzichte van standaard kubernetes node?

Onder windows heb je met wsl2 geen virtuele machine meer nodig overigens. Mac is nu nog de enige die dat heeft (en derhalve dus ook geen fatsoenlijke host network support).

De verwoording is prima maar je hebt hier wel inhoudelijke kennis van de producten nodig om het te kunnen plaatsen.

Voor mij komt het over alsof men een VM heeft en daarin een container virtualiseert waarin je dan weer je node hebt draaien. Dat is een extra laag in de implementatie of mis ik iets?

Het is lang niet alleen maar hippe startups die van cloudplatformen van Amazon of Microsoft gebruik maken.

Ik denk juist dat dit een move is omdat specifieke de niet hippe start-ups, maar juist de grote jongens als de belastingdienst overgaan naar die cloud platformen. Die raakt vmware anders kwijt.

execvm Execute a command within a running virtual machine that hosts container

En hoe zit die hosting dan? Voor zover ik het nu begrijp vanuit de documentatie is dat dus twee lagen diep.

Ik denk dat je je even moet verdiepen in de producten alvorens daar een hele sterke mening over te hebben.

Meh, andere bewoording denk ik. Ik vraag me gewoon af waarom je dit nog zou moeten willen anders dan binnen gecontracteerde on-premise omgeving waar je nog een paar jaar mee moet doen. Dan snap ik hem ook wel.

Een belangrijke horde in dit soort systemen is scaling. Als je hard moet kunnen schalen loop je vaak tegen limieten aan in dergelijke omgevingen. Soms alleen al doordat je gewoon geen machines meer hebt en soms doordat men fysieke servers moet reserveren voor memory intensieve taken en dat is duur, cq soms niet eens mogelijk.

[Reactie gewijzigd door supersnathan94 op 21 augustus 2020 19:35]

Het ging mij dan ook vooral om het stukje betaald. Wat is het voordeel van fusion kind dan nog ten opzichte van standaard kubernetes node?

Die vraag kun je ook stellen voor hetgeen er standaard met Docker wordt meegeleverd. Dat Kubernetes is niet louter alleen maar iets voor containers, je kunt er veel meer mee doen (dat is ook het hele idee). Het probleem is echter dat het nou niet bepaald een klein stukje software is. Wat velen, waaronder Docker, VMware maar ook Rancher Labs, doen is een uitgedunde versie gebruiken die grotendeels wel compatible is met de gewone vanilla Kubernetes versie. Rancher Labs heeft de hare zo ver uitgekleed dat je het op een kassasysteem in de winkel kunt draaien, ze noemen het k3s (ipv k8s).

Zoals ik al heb uitgelegd kiest VMware er voor om niet alleen maar containers of virtuele machines te doen. De markt bewoog eerst naar hybride cloud oplossingen en nu naar een hybride wat betreft virtualisatie en containerisatie. VMware beweegt gewoon met de markt mee. Waarschijnlijk is er dan ook een technische reden om te kiezen voor Kind die deze strategie beter ondersteund dan dat bijv. Kubernetes dat zou doen.

Het grootste voordeel van de implementatie van Kubernetes in Docker en in Fusion zit hem in het feit dat je niet alles zelf hoeft uit te vinden. Je hoeft geen vm te maken, niet op te snorren welke Linux distro je het beste kunt gebruiken (en die ook te onderhouden!) en ook niet helemaal zelf de installatie van Kubernetes te doorlopen. Het is veelal de optie voor Kubernetes aanvinken en gaan. Doordat je het makkelijk in en uit kunt schakelen kun je op resource besparen wanneer je het niet nodig hebt. Het laat ook zien dat dit echt puur voor testing, training, etc. is. Houdt er rekening mee dat consultants, docenten en beheerders ook gebruik maken van dit soort dingen om een ander wat aan te leren of een bepaald idee te pitchen. Zoals je op de website van Kind kunt lezen helpt Kind hierbij door te fungeren als een Kubernetes installatie tool.

Onder windows heb je met wsl2 geen virtuele machine meer nodig overigens.

Je haalt WSL1 en 2 door elkaar. WSL1 heeft geen virtuele machine, WSL2 is een virtuele machine. Beiden kun je prima naast elkaar draaien; er zijn namelijk redenen waarom je voor WSL1 zou willen gaan (WSL2 kan niet bij allerlei devices waar WSL1 wel bij kan). In de officiële documentatie staat het volgende:

WSL 2 is a major overhaul of the underlying architecture and uses virtualization technology and a Linux kernel to enable its new features.

Btw, wil je WSL2 in een virtuele machine met Windows draaien dan kan dat wanneer je hypervisor nested virtualization ondersteund (moet je het alleen ook nog wel even aan zetten natuurlijk).

Mac is nu nog de enige die dat heeft (en derhalve dus ook geen fatsoenlijke host network support).

Neen. Docker for Windows werkt exact zoals die voor de Mac dat ook doet: met een vm. Het enige wat ze nu hebben aangepast is dat ze gebruik maken van dezelfde technologie als waar WSL2 gebruik van maakt. Ze hebben in Windows namelijk niet alleen maar Hyper-V als virtualisatie optie, er zijn nog een stuk of 2 anderen (Hypervisor Platform, Virtual Machine Platform, naast de standaard Hyper-V rol die je op Windows Pro hebt). Dit zijn, zoals ik het heb begrepen, API's om Hyper-V heen. Applicaties kunnen van 1 van deze API's gebruik maken en dat is exact wat zowel WSL2 als Docker for Windows doen. Bij deze laatste is het wel een vinkje die je moet aan zetten als je het installeert (weet niet meer of dat achteraf ook nog aan te passen is).

De reden waarom WSL2 hiervan gebruik maakt zit hem in een aantal voordelen zoals het kunnen gebruiken van een echte Linux kernel, betere performance en betere compatibiliteit van de Linux tooling (ze praten immers met een echte Linux kernel, niet met een of ander vertaallaagje zoals bij WSL1). De verschillen tussen WSL1 en 2 staan bij Microsoft op een rijtje: https://docs.microsoft.co...dows/wsl/compare-versions

Die host network support is ook al niet Mac specifiek maar komt doordat Docker allerlei proxies moet gebruiken zodat de vm beter integreert met het host OS. Ik verwacht dan ook niet dat Docker for Windows hier ook maar enigszins anders in zal zijn.

Daarnaast is het ook goed om te weten dat er ook nog een Docker versie is met specifieke Windows containers. Deze containers maken gebruik van de Windows kernel ipv Linux kernel. Dat komt in containerwereld niet zo veel voor dus dat heb ik bewust even buiten beschouwing gelaten.

Ik denk juist dat dit een move is omdat specifieke de niet hippe start-ups, maar juist de grote jongens als de belastingdienst overgaan naar die cloud platformen. Die raakt vmware anders kwijt.

Dat zeg ik. De hippe startups gooien alles al in containers bij AWS o.i.d. en hebben dus niets anders dan containers. Het gros van de bedrijven is niet zo. Die zullen nog zitten met bare metal, virtuele machines, lokale cloud, externe cloud en nu ook containers. VMware richt zich juist op dit soort bedrijven en geeft ze tools waardoor hybride cloudoplossingen mogelijk zijn en je zowel containers als virtuele machines kunt draaien.

Wat cloudoplossingen a la AWS betreft is die markt eigenlijk wel vol. IBM heeft niet voor niets Red Hat overgenomen. Het heeft dan ook geen zin om je hier alsnog in te lopen mengen dus kiest VMware voor wat anders.

Het bedrijf waar ik werk zit ook een beetje aan de hybride oplossing. We zetten onze eigen virtuele machines op in de cloud en op die machines rollen we onze microservices uit. Dit zijn containers die we middels Docker draaien. Niet een manier die heel raar is, zo doen velen het. Je kunt echter ook van cloudplatformen de container service afnemen. Dan elimineer je je eigen virtuele machines. In werkelijkheid doe je dat niet. Al die platformen draaien gewoon op bare metal dat met hypervisors aan elkaar geknoopt is en waarop uiteindelijk virtuele machines draaien die weer iets als Docker (of een andere containerd service zoals Podman) of Kubernetes + Docker draaien. Dat deel krijg je als klant niet te zien en hoef je je ook niet druk over te maken. Dat is waar het voordeel zit: uitbesteding van een deel van je beheer.

Voor mij komt het over alsof men een VM heeft en daarin een container virtualiseert waarin je dan weer je node hebt draaien. Dat is een extra laag in de implementatie of mis ik iets?

8<

En hoe zit die hosting dan? Voor zover ik het nu begrijp vanuit de documentatie is dat dus twee lagen diep.

Ik heb deze twee even bij elkaar gezet. Het is eigenlijk vrij makkelijk: VMware Fusion is desktop virtualisatie software. Het meest makkelijke is om dan te doen wat Docker for Mac ook doet: een super kale vm met daarin alleen maar een OS dat maar 1 ding kan: het draaien van containers. Met dat laatste heeft VMware ook al ruime ervaring, ze hebben namelijk al een tijdje hun eigen CoreOS concurrent genaamd Photon OS. Hoef je zelf niet een complete vm aan te maken en alles in te richten. Je tikt "vctl system start" in en als je op enter drukt dan wordt alles voor je opgezet.

Kort gezegd is het gewoon een ingebouwde Docker for Mac die meelift op de virtualisatietechnologie die al in VMware Fusion zit. Het grote voordeel voor VMware is dat ze hiermee vctl voor zowel virtuele machines als containers kunnen gebruiken.

Als je echt wil weten waar het grote voordeel zit dan moet je maar eens hypervisor.framework en Docker for Mac naast elkaar gebruiken. Of Docker for Mac en iets als Parallels, Virtualbox of Fusion. Je hebt nu twee totaal aparte tools die niet met elkaar integreren. Container volumes worden met Nautilus gewoon op je desktop gemount (het zit onder ~/.vctl/storage/containerd, met het "vctl describe" commando kun je zien waar exact, idem voor de vm) en kun je dan ook via Finder benaderen. Dat is met Docker for Mac een stuk lastiger om te doen (met Finder kan het volgens mij niet, je zult dan met het docker cp commando op de cli moeten gaan werken).

Overigens zie je de container vm niet in Fusion zelf (je ziet alleen je eigen vm's) dus die kun je niet eenvoudig bewerken (en dat moet je ook helemaal niet willen).

Meh, andere bewoording denk ik. Ik vraag me gewoon af waarom je dit nog zou moeten willen anders dan binnen gecontracteerde on-premise omgeving waar je nog een paar jaar mee moet doen. Dan snap ik hem ook wel.

Voor een ontwikkelaar of een consultant bij een bedrijf waar zowel met bare metal/virtuele machines wordt gewerkt als met containers is het handig om 1 tool te hebben waarmee je beide kunt. Steeds meer software wordt als microservice ontwikkelt waarbij componenten in een container worden gestopt. Dit is echter niet voor alles de oplossing. Bare metal en virtuele machines kunnen een betere oplossing zijn.

Een belangrijke horde in dit soort systemen is scaling. Als je hard moet kunnen schalen loop je vaak tegen limieten aan in dergelijke omgevingen.

Daar heb je hier geen last van. Dit is vooral bedoeld voor demo's, trainingen, pitchen van ideetjes, lokaal development, etc. Het echte werk zal op een serverpark gebeuren waar bijv. VMware vSphere draait of iets wat een combinatie is van vSphere en bijv. AWS.

Het allerbelangrijkste is realiseren dat er eigenlijk niet zoiets is als een Docker container. Het hele gebeuren maakt veel gebruik van open standaarden. Dat zorgt er voor dat iedereen zo zijn eigen containerd variatie kan maken die het beste met hun eigen producten integreert. Doordat het op open standaarden drijft is er ook meer compatibiliteit onderling. Dat is wat VMware hier ook gedaan heeft. Daardoor kun je dus ook prima images van Docker Hub plukken en die met VMware Fusion draaien (de Nautilus documentatie doet exact dit trouwens).
Hier kleeft echter ook een groot nadeel aan: er zijn zo vreselijk veel tools die op elkaar lijken dat het echt moeilijk is om door de bomen het bos nog te zien.

Edit: net even gekeken met "vctl execvm" (je kunt via "vctl describe" achterhalen wat het exacte commando is om een shell in de vm die de container draait te krijgen). Als je na inloggen op de vm een "uname -a" doet dan zie je het volgende: "Linux 4.19.84-1.ph3-esx #1-photon SMP Tue Nov 19 00:39:50 UTC 2019 x86_64". Er wordt dus inderdaad gebruik gemaakt van VMware's Photon OS.

Er draait geen docker daemon in de vm, wel iets met de naam spherelet en crxrun (er wordt dus CRX ipv Docker gebruikt). Voor beiden heeft VMware documentatie: vSphere 7 – Introduction to the vSphere Pod Service. Daarin staat, denk ik, een ander antwoord op je vraag "waarom niet gewoon Kubernetes?":

vSphere Pods provide unique security and operational advantages such as leveraging the proven ESXi isolation techniques that may, at this time, be interesting to some unique/particular workloads. vSphere Pods don’t allow direct access to hardware, another security advantage.

Die laatste zin is een belangrijk punt. Doordat er een virtualisatielaag tussen zit heb je geen directe hardware toegang vanuit de pod/container.

[Reactie gewijzigd door ppl op 23 augustus 2020 22:43]

Docker Desktop voor Mac start onderwater alsnog een VM op, de prestaties hiervan wisselen echt sterk per apparaat. Soms tot bedroevend aan toe. Docker rechtstreeks vanuit een VM op een Mac draait een stuk prettiger, maar dat zijn mijn persoonlijke bevindingen.

Hmm apart. Bij mij is het precies andersom door de overhead van de VM die je zelf maakt. Die is namelijk niet per se gebouwd om dit allemaal te draaien en bevat vaak veel meer dan je nodig hebt.

Docker for Mac heeft allerlei additionele tools nodig die als proxy dienen. Om de een of andere reden is er een issue met het gedeelte dat voor file systems verantwoordelijk is. Die zorgt ervoor dat dingen die je middels de bind mounts aan een container koppelt nogal traag worden. Daarover is op het officiële forum genoeg te vinden maar je komt ook blogposts als deze tegen:
Docker for Mac file system performance summary.
Beating some performance into Docker for Mac
Improve the Performance of Docker on MacOS With Docker-Sync
Revisiting Docker for Mac's performance with NFS volumes

Met networking loop je ook nog wel eens tegen dit soort issues aan op gebied van DNS, routing en VPN's. Daarbij kan het ook zijn dat dingen gewoonweg helemaal niet werken. Docker draaien in een Linux vm op je Mac is dan vaak een beter plan. De vm software weet zich beter te gedragen dan Docker for Mac.

En zie hier nog een reden om voor de container implementatie van Fusion te kiezen ipv Docker for Mac.

Heb ook nog geen echte high-perf zaken gedraaid op Docker moet ik zeggen.

Sws is het een beter idee om gewoon bare linux te draaien als je met Docker en K8s aan de slag gaat. Dat scheelt een hoop gezeur met networking en lijkt ook meer op je Productie omgeving. Docker implementaties voor zowel mac als Windows zijn relatief meh in dat opzicht alhoewel WSL2 wel een enorme verbetering is onder windows.

Edit: Ik heb nog even je posts doorgelezen om een en ander even uit te zoeken en wat mij opviel dat het veelal gaat om development zaken icm frontend Development (die vrij heftig leunen op IO). Iets wat mij opviel was dit:

Keep in mind that if you are developing a fully 12-factor-compliant microservice, be it Symfony or anything else, your codebase should be performant on D4M as it is already properly chunked and easy to containerise. When talking about old-school monoliths, distributed monoliths and bigBallsOfMud or Wordpress, all of which are hard to split up, you will experience difficulties. This is what this post is about.

Ik heb tot op heden voornamelijk gewerkt met software die dus 12Factor compliment was en veelal uit backend microservices bestond. Derhalve was disk perofmance waarschijnlijk vrij zelden een issue, Ja het was niet per se native speeds, maar voor API's is dat ook niet direct nodig. Zoveel data gaat er niet over de lijn.

Ik kan me dan ook best voorstellen dat een CRM kompleet systeem als Wordpress wel problemen geeft. Aangezien je met meerdere Filesystem conversies moet werken (Mac draait standaard APFS tegenwoordig en de Docker interne standaard is EXT4).

[Reactie gewijzigd door supersnathan94 op 21 augustus 2020 19:31]

Heb ook nog geen echte high-perf zaken gedraaid op Docker moet ik zeggen.

Dit heeft ook niet met high performance te maken (en ook niet met web development trouwens). Dit is gewoon lokale ontwikkeling en dan willen mensen soms nog wel het nodige aan data kopiëren of aan een container koppelen. Ik heb een keer een container met Oracle DB opgezet voor 1 van onze ontwikkelaars zodat we een oude applicatie nog konden ondersteunen. Ik had daarbij een datadump die geïmporteerd moest worden en dan loop je tegen dit soort issues aan.

Laat ik duidelijk zijn: dit soort zaken moet je niet in productie doen, dit is echt alleen voor lokaal ontwikkelwerk waarbij je tijdelijk een Oracle databaseserver nodig hebt. In een productie (of acceptatie of test) omgeving kun je veel beter van een aparte databaseserver (of cluster) gebruik maken. Containers zijn er alleen voor microservices. Dit vanuit het oogpunt dat je zonder meer een container af kunt schieten of kunt vervangen. Met een database kan dat niet want dat levert dataloss op.

Sws is het een beter idee om gewoon bare linux te draaien als je met Docker en K8s aan de slag gaat. Dat scheelt een hoop gezeur met networking en lijkt ook meer op je Productie omgeving.

Er is niemand die dat nog doet, een hypervisor wordt nog bare metal gedraaid maar de rest is toch echt een virtuele machine. Dat werkt prima en levert geen gezeur met networking op. Het zijn juist het gebruik van de proxies bij Docker for Windows en Docker for Mac die het probleem zijn. Draai je het in een lokale virtuele machine dan is er niks aan de hand. Het ontwikkelt alleen niet zo makkelijk omdat ontwikkeltools nou niet lekker integreren met een virtuele machine.

Aangezien je met meerdere Filesystem conversies moet werken (Mac draait standaard APFS tegenwoordig en de Docker interne standaard is EXT4).

Docker heeft UnionFS en die zijn er ook weer in diverse smaakjes (zie link). Daarnaast heb je dan ook nog weer eens storage drivers. Dit alles is op Windows, Linux en macOS allemaal weer net even anders omdat ieder OS weer net even anders werkt.

Docker Desktop voor Mac start onderwater alsnog een VM op, de prestaties hiervan wisselen echt sterk per apparaat. Soms tot bedroevend aan toe. Docker rechtstreeks vanuit een VM op een Mac draait een stuk prettiger, maar dat zijn mijn persoonlijke bevindingen.

Oh? Op mijn mid-2015 MacBook Pro draait docker vooralsnog als een tierelier. Dat was eerst minder goed, maar dat hebben ze sterk verbeterd. Volgens mij sloeg die vm in het verleden gewoon heel structureel op hol door een foutje of een bug, en dat maakte dat ik regelmatig docker afschoot als ik hem niet nodig had. Tegenwoordig kan hij gewoon blijven draaien.

Als test-setup, VM weg alles weg geen troep die achterblijft, snapshots, instant-restore ... teveel redenen om op te noemen

Daar heb ik een knopje voor: reset cluster.

En wat bedoel je met instant-restore? Snapshot maken van je hele cluster? Dergelijke dingen wil je absoluut niet hoeven doen. Enige wat je op cluster niveau wil kunnen snapshotten is persistente data. De rest is toch allemaal stateless en kan per node iedere minuut weer anders zijn.

Kind is gemaakt om Kubernetes zelf te testen en kan gebruikt worden als Lokale test-eetup, maar is hier totaal niet voor bedoelt. Single node setups als Minikube en Docker-desktop-k8s wel. Die hebben veel minder overhead.

Reset-cluster dan staat het alsnog op je computer geinstalleerd en dat wil ik niet.

Alle test draait altijd in een VM, folder weg = alles weg niks appdata, dll, registry whatever.
Snapshot idd van je persistente data, of je vm die de client simuleert

Binnen docker desktop is dat ook een vinkje.

Ik weet niet wat je bedoelt met “staat het alsnog op je computer geïnstalleerd”, maar dat is met vmware an sich dan toch ook het geval?

Mbt snapshot persistent data kan het voordelen hebben om bepaalde VM’s te kunnen snapshotten ja.

Dan staat er alleen vmware en niet de 10-tallen die ik installeer/test/package ...
Dus geen docker, choco, php, iis, sql, customapps ... whatever.
Ook al dan niet gevoelige data is foetsie

VM weggooien en mijn computer heeft niets van dat alles nog op zijn schijf staan, enkel nog vmware ..

Mijn computer moet altijd zijn. Alsof hij net geïnstalleerd werd.

En dan nog herinstalleer ik mijn laptop minstens 2keer per jaar omdat ik zo nu en dan me toch niet heb gehouden aan mijn eigen regels

[Reactie gewijzigd door klakkie.57th op 21 augustus 2020 19:40]

Mijn computer moet altijd zijn. Alsof hij net geïnstalleerd werd.

Ok, prima, maar dan kun je dat toch ook zeggen van je VMware installatie?

Dit is dan niet per se gerelateerd aan iets functioneels. Je kan net zo goed Virtualbox draaien en daarin je spul zetten dan. Deze K8s functionaliteit voegt daar niet iets aan toe wat je eerst niet kon en nu wel of begrijp ik het nu verkeerd?

Precies dat deed ik voorheen ook al

[Reactie gewijzigd door klakkie.57th op 21 augustus 2020 19:40]

Volgends mij is het eerder bedoeld voor vcenter intergratie. Zodat er makkelijk van test/dev naar productie gezet kan worden. Dit zal voor een consument niet heel interesant zijn maar ik denk voor wat grotere vmware clusters is het wel makkelijker om een Kind (Kubernetis-in-docker) te ontwikkelen

Hier onder de quote van vmware news
“Developers can now slipstream Kubernetes applications from test/dev into production,” said Lee Caswell, vice president, marketing, Cloud Platform Business Unit, VMware. “We’ve built a consistent CI/CD operational model that—with our free Player version—is available for all developers.”

Bron: https://www.vmware.com/co...4a-9052-8db04c0f58dc.html

Interessant om het een keer te lezen ja.

Ik ben zelf niet zo van de custom implementaties. Deze werkwijze is ontzettend lastig te porteren naar een cloud provider op zo’n manier.


Daarnaast willen veel bedrijven niet dat je lokaal ff images bouwt en naar productie knalt. Opzich logisch wat daar heb je buildservers en CI processen voor.

Kan me wel voorstellen dat het handige tools zijn als je voorlopig nog in VMware land zit.

Tweakers heeft het prima verwoord.

Waarom zou je in vredesnaam nog Kind (Kubernetes-in-Docker) gebruiken van VMWare (betaald) Als je dit standaard met Docker-desktop (gratis) meegeleverd krijgt en je daarmee een stabielere versie hebt?

1) Zodat je networking e.d. gemakkelijk op kan zetten tussen je containers en VM's?
2) Snapshots

Dat ze het doen snap ik wel, maar waarom je het zou moeten willen niet. VMware pakt volgens mij best wel wat overhead op de container nodes als ik het zo bekijk door de Node als Fysieke container te draaien.

Wat is een fysieke container in deze context? De enige fysieke container waarmee ik bekend ben staan in de regel op vrachtschepen. Ik ga verderop in op je argument m.b.t. overhead.

Hierdoor krijg je dus Containers die in containers draaien, met alle overhead van dien.

Dit is letterlijk de standaard implementatie van Kubernetes. Je Kubernetes containers draaien altijd als containers onder 'system' namespace. Dit is ook letterlijk 100% gelijk aan de implementatie op Docker.
Voor de duidelijkheid, het argument m.b.t. "overhead" is bijna verwaarloosbaar. Containers draaien in een kernel namespace en hebben niet dezelfde isolatie als een VM. Bij Docker Desktop heb je de optie 'Show system containers' om deze zichtbaar te maken.

Dus of Tweakers heeft het net niet helemaal goed verwoord, of VMware is best raar bezig met hun implementatie, maar ik heb dan liever een single-node cluster, waar minder overhead op zit. Zeker op 16GB machines is het anders niet te doen.

Ik wil je graag even uitleggen waarvoor dit product bedoeld is. Dit product is bedoeld voor virtualisatie/containerisation op een (1) laptop of desktop. Dit is dus een ander product dan een bare-metal hypervisor van VMware dat bedoeld is voor virtualisatie op datacenters.
Een ontwikkelaar gebruikt dit product dus om op zijn lokale laptopje een container te ontwikkelen, en deze te pushen naar een test/acceptatie/productie cluster waar je natuurlijk performance tests draait.
Wat maakt die performance op het lokale laptopje dan uit? Wil je ook even inzichtelijk maken hoeveel performance verlies dat dan is, ik heb hier echt andere ervaringen mee?

1) Zodat je networking e.d. gemakkelijk op kan zetten tussen je containers en VM's?

Wil je dat niet liever via loadbalancer laten draaien en niet rechtstreeks naar je VM? Anders kun je die VM niet zomaar even vervangen voor een nieuwe/andere.

Wat is een fysieke container in deze context? De enige fysieke container waarmee ik bekend ben staan in de regel op vrachtschepen

Ha fair enough . Ik zie em, had natuurlijk virtueel moeten zijn.

Dit is letterlijk de standaard implementatie van Kubernetes. Je Kubernetes containers draaien altijd als containers onder 'system' namespace. Dit is ook letterlijk 100% gelijk aan de implementatie op Docker.
Voor de duidelijkheid, het argument m.b.t. "overhead" is bijna verwaarloosbaar. Containers draaien in een kernel namespace en hebben niet dezelfde isolatie als een VM. Bij Docker Desktop heb je de optie 'Show system containers' om deze zichtbaar te maken.

Euhm nee? Op Docker K8s worden je alle containers als container gedraaid in doceer zelf en niet container in container zoals uit het bericht wel het geval lijkt (voor mij iig). Juist doordat Fusion de boel dus nog een keer in een VM draait heb je toch juist wel die isolatie? Bij Docker for mac heb je al het gezeur met Host networking omdat het geheel al in een VM draait.

Ik wil je graag even uitleggen waarvoor dit product bedoeld is. Dit product is bedoeld voor virtualisatie/containerisation op een (1) laptop of desktop. Dit is dus een ander product dan een bare-metal hypervisor van VMware dat bedoeld is voor virtualisatie op datacenters.

Mja I know. Docker-desktop toch ook?

Wat maakt die performance op het lokale laptopje dan uit?

Overhead op resources. RAM kun je maar 1 keer besteden, 16GB is al niet zoveel aangezien reserveringen soms best hard gaan. Heeft dan ook niks te maken met het feit dat je echt een performance hit hebt, maar meer met het feit dat je nog een virtueel laagje (lijkt) te hebben wat dan dus ook resource reserveringen doet.

Weet iemand of VMWare (ongeveer) net zo snel is als Parallels? Mijn ervaring met in ieder geval VirtualBox is dat die écht heel traag is op macOS, waar Parallels dan weer bijna-native snelheden heeft.

Zo traag bedoel je met muis input? Dat ervaar ik verder wel, daarom zit ik alleen maar via de CLI te werken.
Andere vraag: is parallels een ander programma waarbij de GUI wel snel werkt?

Zie mijn comment hieronder. Parallels werkt veeeel beter dan VirtualBox.

Ik had VirtualBox draaien op m'n mbp, maar dat was onwerkbaar traag en met een enorme lag. Daarna Parallels eenmalig gekocht en draai Windows 10 als een zonnetje. Voor ontwikkelwerk met Visual Studio perfect. Ik heb destijds vergeleken en las dat dat Parallels vergelijkbaar is met wmware, misschien iets soepeler.

Parallels is met bootcamp-partitie alvast sneller, tenzij deze nieuwe versie dat natuurlijk aanpakt.

[Reactie gewijzigd door klakkie.57th op 21 augustus 2020 13:05]

Parallels richt zich vrijwel uitsluitend op Windows (en hebben nu dus een heel groot probleem aangezien er vooralsnog geen officiële consumer versie is van een ARM versie van Windows). Als je echt performancewinst ziet dan is dat vooral in Windows. Beide producten doen de afgelopen 5 jaar aan haasje-over. De verschillen zijn veelal erg klein dus ik denk dat je beter naar de feature set en prijs kunt kijken dan naar performance alleen.

VMware is zich de laatste jaren wel meer aan het richten op professionals en ontwikkelaars. Parallels doet dat in wat mindere mate.

Mag je formeel eigenlijk wel macOS draaien als een virtuele machine, zoals dat als ik het goed begrijp mogelijk is met Workstation, op Windows / Linux / PC hardware?

Formeel is het volgens mij 'nee'. Je mag OSX Server gebruiken als VM op een Mac. Dat impliceert dat je geen client versie mag gebruiken en geen Windows/Linux host mag gebruiken. VMWare draait ook op OSX dus het zal dus wel officieel ondersteund zijn door VMWare. De ondersteuning onder Windows/Linux met VMWare is dan waarschijnlijk een grijs gebied, je mag het vast qua software ondersteunen maar het gebruiken mag dan weer niet.
Hoe dit in praktijk zit weet ik niet. Meeste mensen die ik ken die apps gebruiken hebben al een Apple computer privé of omdat die ook nodig is om de app te ontwikkelen.

10.6 Server license aggreement
"You may also install and use other copies of Mac OS X Server Software on the same Apple-branded computer, provided that you acquire an individual and valid license from Apple for each of of these other copies of Mac OS X Server Software."

Server is sinds Lion (10.7) een losse app en geen OSX versie meer. We zitten nu bovendien op macOS Catalina (10.15). Dus de licentievoorwaarden van Snow Leopard Server (10.6) zijn niet erg relevant meer.

In de licentievoorwaarden van Catalina staat het volgende over virtualisatie (specifiek m.b.t.de App Store versie van Catalina):

2. Toegestaan gebruik en beperkingen.
[...]
B. Licentie voor de Mac App Store.
[...]
(iii) twee (2) of meer extra kopieën of exemplaren van de Apple software te installeren, te gebruiken en uit te voeren in omgevingen met een virtueel besturingssysteem op elke Mac- computer die je in eigendom of beheer hebt en waarop de Apple software al is geïnstalleerd, zulks met de volgende doeleinden: (a) het ontwikkelen van software; (b) het uitvoeren van tests tijdens de ontwikkeling van software; (c) het gebruik van macOS Server; of (d) persoonlijke, niet- commerciële doeleinden.

Het recht dat je wordt verleend krachtens paragraaf 2 B (iii) hierboven staat je niet toe om de
gevirtualiseerde kopieën of exemplaren van de Apple software te gebruiken in verband met een servicebureau, timesharing, terminalsharing of vergelijkbare diensten.

En over het niet mogen gebruiken op niet-Apple hardware:

J Overige gebruiksbeperkingen. De rechten die je door middel van deze licentie worden verleend, omvatten niet het recht om Apple software te installeren, te gebruiken of uit te voeren op een computer van een andere fabrikant dan Apple, en je stemt erin toe dit niet te doen noch anderen in staat te stellen dit te doen.
[...]

Wat TonnyTonny hierboven zegt klopt dus: op een Mac mag je macOS virtualiseren zoveel je wilt, op andere hardware mag je Apple software niet gebruiken.

[Reactie gewijzigd door Herko_ter_Horst op 21 augustus 2020 13:15]

Kortom, het mag van Apple alleen op Mac hardware en zelfs dan nog alleen voor eigen gebruik.

Jammer want ik hoopte op een soort van virtuele #hackintosh route.

Een virtuele macOS / Hackintosh is natuurlijk geen echte hackintosh, maar als hij snel genoeg is, heb je dan toch macOS zonder een complete, aparte machine te hoeven kopen of bouwen. Nu hackintoshes dreigen uit te sterven vanwege Apple Silicon, zou dit interessant(er) kunnen worden.

cc @tedades @TonnyTonny

[Reactie gewijzigd door laptopleon op 21 augustus 2020 13:15]

Dat gaat prima, heb op mijn Threadripper ook gewoon een OSX VM draaien. Omdat mijn Mac Pro te oud is heb ik hier helemaal geen problemen mee, heb de hardware wel aangeschaft.

Ik heb al enige tijd geprutst met macos op virtualbox op een Windows machine.
Ja, het is werkend te krijgen, maar er zijn wel enige haken en ogen.
Soms is de performance aardig, soms compleet bagger.
En een aantal specifieke dingen heb ik nooit (goed) aan de praat gekregen.
iMessage bijvoorbeeld en apple maps. Nooit werkend gekregen. Daarvoor moet je echt diep in de settings gaan prutsen. Maar dat is me nooit gelukt.
Andere apps wel aardig om wat mee te spelen.

Al met al leuk om de look en feel van macos mee te proeven. Handig om die paar dingen vanuit iCloud te kunnen doen die met een Mac toch net wat makkelijker gaan (agenda, contacten etc. Op een groter scherm wat makkelijker te overzien).
Iedere update is echter weer een uitdaging om het aan de praat te krijgen.

Wat dat betreft lijkt het dan wel weer op een hackintosh

Maar goed, Virtualbox is dan ook gratis.

Klopt, het is zelfs zo dat als je ESXi op een Mac installeert, hij automatisch macOS guests toe laat!

Ik draai al jaren zo'n ESXi op een oude Mac Mini. Kan zelfs macOS versies draaien die de mini zelf niet support.

Overigens is "macOS Server" sinds de laatste versies niet meer dan een flauwe grap geworden. Ze hebben letterlijk alles dat nuttig was er uit gepulkt. Je hebt nog steeds dezelfde instellingen app maar die is nu bijna leeg omdat alles er uit gehaald is De laatste echte "Server" was 10.6. Helaas. In het begin ondersteunde de app nog wel wat goede functies zoals email server, VPN, web enz. Maar met de overgang naar de losse app waren de uitgebreide instellingenschermen al weggehaald en vervangen door domme on/off sliders. Vervolgens is bij elke nieuwe versie wel een nuttige functie weggeknipt tot het zielige overblijfsel wat het nu is.

Het is wel zo dat het nu ook niks meer kost, tot 10.7 was macOS server een 500 euro licentie! De losse app was in het begin 20 en later naar 0 gegaan omdat ze er met droge ogen geen geld meer voor konden vragen.

[Reactie gewijzigd door GekkePrutser op 21 augustus 2020 15:29]

Ja, volgens de Apple licentievoorwaarden voor MacOS mag je net zoveel kopien, al dan niet virtueel, draaien als je wilt, zolang het draait op Apple hardware.

Maar op een niet Apple is tegen de licentie voorwaarden.

Of die licentievoorwaarden juridisch houdbaar zijn is een ander verhaal. Daar zijn de meningen over verdeeld.

Zoals anderen al aangeven mag je macOS alleen op Apple hardware draaien. Dit wordt tegenwoordig ook door de 3 bekendste desktopvirtualisatieproducten technisch afgedwongen. Zowel Virtualbox, VMware Workstation als Parallels Desktop zullen weigeren om macOS te draaien op niet-Apple hardware.

Overigens is macOS draaien in een vm lang niet zo'n fijne ervaring als bijv. Linux. Hardwareacceleratie voor het hele video gebeuren kun je vergeten. Voor wat testwerk is het werkbaar.

Overigens is macOS draaien in een vm lang niet zo'n fijne ervaring als bijv. Linux. Hardwareacceleratie voor het hele video gebeuren kun je vergeten.

Daar was ik al bang voor. Jammer. Niet echt een alternatief voor een hackintosh dus.

Volgens mij moet je bij vmware inderdaad eea aanpassen in wat configuratie files.
Virtualbox draait nog steeds standaard een macos cliënt.
Goed, het is wat prutsen om het (grotendeels) draaiend te krijgen, maar het werkt wel

zou je player ook in een container kunnen draaien? Dan kan je de pro versie omzeilen

Nee je kunt maar beperkt virtualiseren. Standaard is het meestal maar 1 laag diep en anders moet je hypervisor passthrough gaan doen waarbij de derde laag weer inprikt op de hypervisor laag van de eerste.

Dat is de vraag. VMware Fusion heeft, net als Workstation en ESXi, wel de mogelijkheid voor hypervisor passthrough zaken. Dat zit er overigens voornamelijk in omdat je dan iets als ESXi kunt testen of demonstreren en omdat je dan bepaalde applicaties (denk hier even aan Docker for Windows die werkt middels wat Hyper-V API's) kunt draaien. Deze laatste is vooral iets wat developers doen.

De vraag in deze is niet of Fusion het kan maar welke versie van Fusion. De Player versie was ooit bedoeld als een gestripte versie die alleen maar een virtuele machine kan draaien. Het heeft dan ook meer weg van een mediaplayer, vandaar ook de naam. In de loop der jaren is Player wat verder uitgebreid maar het heeft nog steeds niet de volledige feature set van bijv. Workstation. Dat moet je dus ook hier niet verwachten. De kans dat zaken als Nautilus (het draaien van containers) in Player zitten acht ik niet heel hoog. Temeer ook omdat dit nog een hele nieuwe feature is, ze zijn er pas dit jaar mee begonnen.

De volgende link is een vergelijking tussen de gewone Fusion 11.5 versie en de Fusion Pro 11.5 versie: https://www.vmware.com/products/fusion.html#compare Dat zou je een idee moeten geven wat je niet in Player moet verwachten.

Your Fusion 12 Pro key will unlock Workstation 16 Pro on Windows or Linux.

Oehhh... Dat maakt het wel een stuk interessanter. De iets hoge prijs voor de licentie maakt het alsnog een stuk goedkoper dan wanneer je die twee producten los moet aanschaffen. Nice! Mooi ook dat het tot 3 machines is, dan kan je dus cross-platform tussen alle drie de operating systems je VM's gebruiken met dezelfde featureset en compatibiliteit. Goed nieuws!

Inderdaad dat is wel ern lekker feature

Moeten wij helemaal wachten tot de release 30 October om het te kunnen testen (zoals in Press release) of kan je het al ergens downloaden?

Ben benieuwd of het te gebruiken is voor Windows gaming op mijn oude beest van een MacPro 2011 Die heeft nog steeds redelijk specs, maar ik krijg er maar voor geen meter Windows op geboot. (Bootcamp met Windows 10 gaat niet)

Ik acht die kans erg klein, het is al een paar fusion versies geleden dat ik Oblivion probeerde te spelen op een Windows VM op een Mac Pro 2013, maar daar werd je niet echt vrolijk van... misschien zijn ze wat efficenter gaan virtualiseren van grafisch geweld... het kan wel, maar dan moet je niet hechten aan framerates

Er is een tech preview beschikbaar op deze pagina, die je kunt downloaden zonder een account:
https://blogs.vmware.com/...big-sur-tech-preview.html
(beetje late reactie, maar had zelf ook moeite om het te vinden, dus dacht laat ik het maar even toevoegen)

Hmmm nice, eindelijk.

Ik ben zelf overgegaan naar VirtualBox omdat ik het geforceerd betalen van VMWare elk jaar te duur vond worden. Want elke macOS update was er wel een reden waarom de oude Fusion niet meer werkte. Het was altijd raar dat player wel gratis was op PC maar niet op Mac. Maar dat wordt nu dus eindelijk opgelost.

Dat klopt niet. VMware Fusion hoef je niet ieder jaar te upgraden. Je kunt prima versies overslaan zonder dat dit echt problemen geeft. Bovendien zijn er ook gratis upgrades (11.5 is een nieuwe versie maar je kon vanaf 11 gratis naar 11.5 upgraden) en zit je niet aan een licentie waar je beperkt bent tot welgeteld 1 Mac (voor wie het weten wil, bij VMware mag het op 3 Macs). Als je echter braaf naar ieder nieuwe versie wil upgraden dan heb je 2 opties: steeds weer een licentie kopen of overgaan op het abonnement.

Voor mij was het juist een van de redenen om sinds versie 1.0 gewoon bij Fusion te blijven, dit soort opties zie je bij de concurrentie niet. Een ander probleem is ondersteuning van niet-Windows systemen en performance. Parallels zet hoofdzakelijk in op Windows en dat is te merken, zowel de performance als het kunnen draaien van een Linux distro naar keuze kent veel meer haken en ogen bij hun. Virtualbox heeft voornamelijk forse performance issues met vrijwel alles. Met alleen maar text-only Linux vm's merk je daar dan weinig van; als dit het enige is wat je draait dan biedt dat nog wel een uitkomst.

Misschien bij de laatste versies niet, maar ik heb rond de tijd van Yosemite/Mavericks een paar keer achter elkaar moeten upgraden. Of op zijn minst elke 2 jaar (waarbij ik ook geen gebruik meer kon maken van de goedkopere upgrade versie). Toen was ik er gewoon helemaal klaar mee. Volgens mij was versie 5 of 6 de laatste die ik gehad heb.

Braaf naar de nieuwe versie was er niet bij, want vanaf versie 3.0 toen ze met de Pro uitbreiding kwamen, had het al meer dan zat functies voor me Als ik die nog steeds had kunnen gebruiken, had ik dat gedaan. Ik had de Pro nodig vanwege de extra netwerk functionaliteit.

Een abonnement was er toen nog niet, trouwens. Maar ik heb sowieso een hekel aan abonnementen op software.

Ik draaide inderdaad alleen maar Linux VM's met voornamelijk tekst. Nu gebruik ik overigens helemaal geen Desktop virtualisatie meer (behalve KVM op Linux), ik heb nu zat ESXi servers die ik kan gebruiken (dat is al die tijd gratis gebleven). Maar nu het gratis wordt kan ik er wel weer over denken, het is immers makkelijk om een VM even te transporteren vanaf ESXi naar Player.

[Reactie gewijzigd door GekkePrutser op 21 augustus 2020 17:12]