VK keurt miljardenovername VMware door Broadcom goed

De Britse Consumer and Market Authority heeft toestemming gegeven voor de VMware-overname door Broadcom. De toezichthouder concludeert dat de deal geen grote gevolgen zal hebben voor de concurrentie op de Britse markt voor serverhardware.

De Britse CMA komt tot die conclusie na een uitgebreid 'phase 2'-onderzoek. De beslissing betekent het einde van het Britse onderzoek naar de overname. De CMA is van mening dat de concurrentie op de serverhardwaremarkt niet aanzienlijk beperkt zal worden nadat de overname door Broadcom is voltooid. Daarom mag de deal doorgaan in het Verenigd Koninkrijk.

De CMA onderzocht onder meer of Broadcom ervoor kan zorgen dat hardware van concurrenten minder goed wordt ondersteund door de software van VMware. Volgens de toezichthouder zou dat niet opwegen tegen het omzetverlies dat Broadcom daarmee zou lijden.

De CMA onderzocht ook of de overname 'innovatie kan remmen'. De toezichthouder bekeek of concurrenten van Broadcom gevoelige informatie moeten delen met VMware om hun hardware goed te laten werken met VMware en of er zorgen bestaan dat Broadcom die kan inzien. Volgens de CMA hoeft die info pas relatief laat gedeeld te worden met VMware, in een stadium 'waarin het te laat is om commercieel voordeel op te leveren voor Broadcom'.

Broadcom kondigde vorig jaar aan dat het VMware wil overnemen voor 61 miljard dollar. Het is daarmee de grootste overname die het bedrijf tot op heden heeft gedaan. Onlangs werd de overname al goedgekeurd door de Europese Commissie. De EU deed dat nadat Broadcom verschillende concessies en beloftes had gedaan. De overname wordt momenteel nog onderzocht door de Amerikaanse Federal Trade Commission.

Reacties (134)

[Laurens84]

Ben heel benieuwd wat voor gevolgen dit gaat hebben. Ik maak intensief gebruik van producten van VMWare. Met name hun Hypervisor gebruik ik veel. Mijn complete home lab draait op ESXi. Het zal uiteraart wel een flike tijd duren voordat er iets merkbaar veranderd maar toch. Ben altijd wel tevreden geweest en weet niet hele goede alternatieven. Red Hat Virualization is mij veel te complex voor wat ik nodig heb. Dan ben ik al een aardig deel van mijn server hardware kwijt voordat ik ook maar iets draai.
Proxmox ziet er op zich aardig uit. Maar weet niet of dat alles kan wat ik nu doe met ESXi. Mijn router heb ik bijvoorbeeld als virtual machine in ESXi staan. Om dat voor elkaar te krijgen heb ik toch wel wat trukjes uit de kast moeten halen.

Achja, we gaan zien hoe het allemaal loopt.

[eltweako]

We zijn een jaar geleden gestart met de migratie van VMWare naar Proxmox. En eerlijk gezegd was het grotendeels een verademing.

Zowel het uitvoeren van updates als de ingebouwde tools voor back-up, migratie en beheer bevallen uitstekend.
Mijn homelab draait momenteel ook nog op ESXi maar binnenkort gaat dat ook naar Proxmox.

Natuurlijk weet ik niet welke functionaliteit je van ESXi gebruikt, maar het uitproberen van Proxmox kan zeer de moeite waard zijn.

[EXCalibur_EeK]

Je klinkt erg positief, Nu ben ik wel benieuwd naar je backup ervaringen.

Dus je gebruikt ingebouwde backup functionaliteit (intuitieve GUI?)? Hoe kan ik dit vergelijken met een Acronis of Veeam Backup & Recovery? Kun je bijvoorbeeld individuele mails terughalen bij een Exchange backup of individuele objecten van Active Directory?

[eltweako]

Ah, goede en terechte vraag.

Laten we vooropstellen dat ik zeer te spreken ben over VEAAM, en ik het erg jammer vind dat er geen versie voor Proxmox is. Dat gezegd hebbende, snap ik dat die ondersteuning er niet is, omdat de markt door de ingebouwde backup functionaliteit van Proxmox waarschijnlijk beperkt is.

Goed, de backup in Proxmox.
Je kunt je backup binnen de server zelf wegschrijven, of naar een externe locatie.
Hiervoor is er ook de Proxmox backup server, die kun je op een (extern) systeem installeren waarna je deze aan je servers hangt. Vervolgens kun je deze server als backup lokatie kiezen.

In tegenstelling tot ESXi initialiseer je de backup vanuit de cluster zelf, je geeft op je proxmox cluster aan welke machines je wanneer waarheen wilt backuppen, en de cluster regelt dit vervolgens. Het is dus niet zo dat een externe server of applicatie (zoals bijv. de proxmox backupserver) de backup maakt. De Proxmox backupserver dient puur als repository voor je backups.

Dan het herstellen. Als je VEEAM gewend bent dan zijn je herstelopties simpelweg karig. Proxmox kan geen losse Exchange items herstellen of losse active directory objecten. Heel erg jammer, en ik kan me goed voorstellen dat het een dealbreaker voor je kan zijn.
De opties die je hebt zijn: het herstellen van een complete VM, of het herstellen van individuele bestanden.

In ons geval hebben we de verschillende opties afgewogen, en bij ons is het de moeite waard om wat frequenter backups te maken. Tevens is het in onze omgeving zo dat er zoveel procedures zijn om ook maar 1 ding in de AD te wijzigen, er altijd eerst een backup gemaakt zal worden en het in een maintanance window zal plaatsvinden. De kans dat wij de opties van VEEAM zouden gaan gebruiken is nul.

Voor ons is de flexibiliteit van proxmox, vooral op het gebied van clustering en hardware support zo veel belangrijker. Zo ondersteunde onze ESXi installaties onze nieuwe 100gbit fiber netwerkkaarten niet en hadden we problemen met NVME drives. Met proxmox is alle hardware die we tot nu toe gebruiken plug and play.
Ook is de netwerkperformance tussen de verschillende VM's aanzienlijk sneller en geven onze gebruikers aan dat de applicaties "vlotter" reageren. Al is dat laatste subjectief.

[EXCalibur_EeK]

Bedankt voor je uitgebreide reactie!

De mogelijkheid om individuele objecten terug te zetten is een toegevoegde waarde. Blijft idd de vraag of dit de voldoende voordeel is om bij Veeam te blijven zeker als je kijkt hoe vaak zoiets nu echt in je omgeving voor komt dat je zo'n restore dient uit te voeren.

Zo te lezen moet ik binnenkort eens een testomgeving gaan optuigen

[GoBieN-Be]

Enkele voordelen van Veeam, die mij ervan weerhouden om Proxmox in te zetten voor serieuze zaken op professioneel vlak.
- AD Domain Controller restore met Veeam logica die de nodige flags zet etc
- Item restore voor AD, SQL, Exchange, ...
- Back-up (copy) naar Object storage in de cloud (AWS, Azure, Backblaze, ...)
- Immutability mogelijkheden op repo's en object storage
- Block cloning op GFS copies met XFS of ReFS

En niet te vergeten, redelijke goede support van Veeam.

In mijn Homelab gebruik ik trouwens beide, ESXi en Proxmox.
Proxmox is een zeer mooi product, maar ESXi is rock solid.

[Reactie gewijzigd door GoBieN-Be op 22 juli 2024 14:15]

[vali]

Ik zou eerder kijken of je vele zaken in code kan stoppen zodat je zo min mogelijk Veeam hoeft in te zetten. Hierdoor kan je jobs aanzienlijk verkleinen gezien je vele servers vanuit automation weer terug kan krijgen. Al helpt het als je storage omgeving op ZFS draait en daarmee je data veilig houdt.

Grootste probleem met Veeam is dat het zeer MKB aanvoelt en niet in de buurt komt qua mogelijkheden die andere backup oplossingen bieden.

[Reactie gewijzigd door vali op 22 juli 2024 14:15]

[goarilla]

Toch niet IBM Tivoli Storage Manager of ... Symantec Netbackup ?

[vali]

IBM Tivoli Storage Manager is aanzienlijk robuuster en beter schaalbaar dan Veeam en biedt veel meer mogelijkheden qua automation.. Vooral back-up retentie heb ik in het verleden bugs gezien die nog steeds niet (zover ik weet) opgelost zijn. Een andere voorbeeld is bv Rubrik. Veeam is naar mijn mening leuk voor een kleine omgeving van paar honderd servers.

[Reactie gewijzigd door vali op 22 juli 2024 14:15]

[goarilla]

Absoluut maar mijn ervaring is met een hele oude versie op RHEL 4 (Nahant) en om dan op een kritiek moment (ransomware anno 2015) het bizarre dsmc (leren) gebruiken gaf me toen wel stress en schrik.
Ik heb dan ook verschillende wrappers erom geschreven om mij minder snel in de voet te schieten.

[vali]

Dat waren de mooie tijden!

[eborn]

Het grote voordeel van PBS (Proxmox Backup Server) is wel dat daar de periodieke verificatie en garbage collection plaatsvindt. Dit gebeurt dus niet op je host. De snapshots worden weggeschreven in blocks, waarbij Proxmox op basis van een dirty map enkel de gewijzigde blocks hoeft over te zetten. Elke backup is qua opslag daardoor wel een soort van incrementele backup. Het is daarnaast wel heel eenvoudig om een offsite replica server te maken. Doordat de replica geen toegang naar boven nodig heeft, is dit een mooie extra laag van beveiliging tegen malware en cryptolockers.

[Inktvisje]

Alles wat je hier noemt doet vsphere + veeam ook al standaard hoor. Neemt overigens niet weg dat proxmox backup server prima werkt!

[DVBNL]

Klinkt goed, en stel de hypervisor is compromised, zijn back-ups dan vanuit daar wel te deleten aangezien dit je console is voor het maken en beheren van back-ups? Of kun je je repository nog beschermen door een extra encryptie/check voordat back-ups delete mogen worden?

[Verwijderd]

Mag ik je vraag beantwoorden met een wedervraag?
Zijn de kosten van een zeer dure oplossing als Veeam nog wel de moeite waard?

Ik kom bij veel organisaties en vaak 'snapt' men niet hoe 'backup' werkt... Neem Exchange Online als voorbeeld, daar worden alle verwijderde items naar de prullenbak verplaatst, na 14 dagen worden ze verwijderd en komen ze in de 'recoverable items' waarna ze pas na 14 dagen permanent verwijderd worden. Microsoft staat garant voor de integriteit van de data met drie individuele kopieën...
Dus hoe krijg je dan nog de business case (als in, kosten verantwoording) rond?

Veelal komt men aanzetten met wetgeving of iets in die trant terwijl die wetgeving helemaal niet bestaat (bijvoorbeeld dat je een backup 7 jaar moet bewaren).

De grap is dat VMware hier hetzelfde probleem heeft. Mooie software maar alternatieve goedkope (zelfs open-source) oplossingen zitten vrijwel op hetzelfde niveau. VMware biedt vrijwel geen voordeel maar heeft wel hoge kosten.

[Bor]

Ik kom bij veel organisaties en vaak 'snapt' men niet hoe 'backup' werkt

Begrijp je het zelf wel? Een 'prullenbak' (die je kan legen, welke corrupt kan raken etc) heeft echt niets met een backup te maken. Microsoft legt die verantwoordelijk ook bij de klant neer. Wat als je langer dan die 2x14 dagen terug wilt (of erger; moet)? Hoe voldoet dit aan de retentie wensen en eisen van de klant? Kan je het indien nodig ook elders terugzetten in het geval van een calamiteit? Ik hoop niet dat je dit soort adviezen geeft bij de vele organisaties waar jij komt.

In een "Shared responsibility model' zoals Microsoft het noemt is de klant altijd verantwoordelijk voor informatie en data. En ja, wet en regelgeving kan ook meespelen.

[Reactie gewijzigd door Bor op 22 juli 2024 14:15]

[Verwijderd]

Begrijp je het zelf wel?
Ja.

Een 'prullenbak' (die je kan legen, welke corrupt kan raken etc) heeft echt niets met een backup te maken. Microsoft legt die verantwoordelijk ook bij de klant neer.
Nee, je begrijpt blijkbaar niet hoe cloud omgevingen werken. Microsoft maakt geen backups want zij werken met redundancy en resiliency:
https://learn.microsoft.c...-data-resiliency-overview
We have moved beyond the traditional strategy of relying on complex physical infrastructure, and we have built redundancy directly into our cloud services.

Ik snap dat dit moeilijk is voor 'traditionele' denkwijzen maar op een gegeven ogenblik zul je over moeten naar een andere denkwijze. De hoeveelheid data die je traditioneel kan backuppen heeft simpelweg een maximum.

Wat als je langer dan die 2x14 dagen terug wilt (of erger; moet)?
Geef even een scenario waar dat het geval is? En maak trouwens ook even in je hoofd een businesscase wat backup kost tegenwoordig en hoe vaak er gebruik van gemaakt wordt. Dan zie je dat dit zeer 'scheef' is.

Hoe voldoet dit aan de retentie wensen en eisen van de klant?
Ik neem aan dat je 'de klant' bent en dat je dat weet....

Kan je het indien nodig ook elders terugzetten in het geval van een calamiteit?
Dat is een goede vraag voor jou: hoe ga je je Exchange Online 'elders' terugzetten?
Daar sta je dan met je mooie dure backup.... En je kan er niets mee....

Ik hoop niet dat je dit soort adviezen geeft bij de vele organisaties waar jij komt.
Mijn taak is om mensen te laten nadenken in plaats van maar leveranciers oplossingen door de strot van klanten te drukken die helemaal niets toevoegen anders dan flinke marges maken...

In een "Shared responsibility model' zoals Microsoft het noemt is de klant altijd verantwoordelijk voor informatie en data. En ja, wet en regelgeving kan ook meespelen.
Je verdraait de feiten.. Microsoft's 'Shared responsibility model' gaat helemaal niet over backups maar over security... Hier, leer de 'fundamentials':
https://learn.microsoft.c...als/shared-responsibility

Hier is de volledige datasheet. Kijk maar hoe vaak daar 'backup' in voor komt...

[Question Mark]

Kijk even naar de Microsoft Service Agreement:

We strive to keep the Services up and running; however, all online services suffer occasional disruptions and outages, and Microsoft is not liable for any disruption or loss you may suffer as a result. In the event of an outage, you may not be able to retrieve Your Content or Data that you’ve stored. We recommend that you regularly backup Your Content and Data that you store on the Services or store using Third-Party Apps and Services.

Ik heb het afgelopen jaar veel gesproken met Accountmanagers en technical sales van Microsoft voor de onboarding van een grote partij. Daarbij werd duidelijk aangegeven dat een klant toch echt zelf backups moet maken, als onderdeel van het shared responsibility model.

[BytePhantomX]

Daarbij werd duidelijk aangegeven dat een klant toch echt zelf backups moet maken, als onderdeel van het shared responsibility model.

Hoe kun je dan backups maken van Teams (en die restoren) en Planner, PowerBi, To-Do (misschien in Exchange), Bookings, To-Do etc. Volgens mij kan dat allemaal niet.

Daarnaast is het Shared Responsibility model meer dan security en hier is een duidelijk stuk documentatie van Microsoft: https://learn.microsoft.c...ner-ebcm-responsibilities

En hier een stuk over resiliency van Exchange Online: https://learn.microsoft.c...-exchange-data-resiliency

Ik zie in beide stukken echt niet terug dat Microsoft zegt dat een klant verantwoordelijkheid heeft voor deze onderdelen.

In het geval van Azure is het trouwens compleet anders. Maar ik heb het hier alleen over SaaS diensten.

[Reactie gewijzigd door BytePhantomX op 22 juli 2024 14:15]

[Question Mark]

De aanbeveling om zelf backups te maken staat letterlijk in de Service Agreement van alle MS cloud diensten, zie quote die ik daar al eerder van gepost heb.

Technisch heeft MS allemaal api's beschikbaar waarmee backups gemaakt kunnen worden. Dit zijn dezelfde api's die 3rd-party leveranciers ook gebruiken bij hun tooling. Zie bijvoorbeeld: https://learn.microsoft.c...eams/export-teams-content

Ik weet verder hoe de resiliency van de cloud diensten werken, en het is ook niet aan mij om te bepalen of élke organisatie een backup moet gaan maken. Dat mag de betreffende organisatie lekker zelf bepalen. Voor de klant waar ik nu voor bezig ben, is het echter een verplichting dat er geen dataverlies kan optreden (hoe klein de kans ook), vandaar dat daar gekeken wordt naar een 3rd-party oplossing voor het backuppen van M365.

[Bor]

Dat is dan ook precies hoe de vork in de steel zit en wat er actief wordt geadviseerd. "Microsoft's 'Shared responsibility model' gaat helemaal niet over backups maar over security" is dan ook onjuist zoals eerder aangegeven. De eerdere genoemde zaken redundancy en resiliency hebben een heel andere insteek. Microsoft legt de verantwoordelijkheid voor data op dit punt echt bij de klant neer.

[Reactie gewijzigd door Bor op 22 juli 2024 14:15]

[Bor]

redundancy en resiliency:

Man, man, man... Over klok en klepel gesproken. Dit zijn technieken die je tegen heel andere risico's beschermen. Dit heeft echt niets met backup te maken. Het stuk wat je aanhaalt gaat ook over totaal andere zaken.

Ik snap dat dit moeilijk is voor 'traditionele' denkwijzen maar op een gegeven ogenblik zul je over moeten naar een andere denkwijze.

Dit heeft echt helemaal niets van doen met een traditionele denkwijze? Redundancy en resiliency beschermen je simpelweg niet tegen alle risico's die tot data verlies kunnen leiden. Ook in een "andere manier van denken" dien je de risico's goed te overwegen.

Ik neem aan dat je 'de klant' bent en dat je dat weet....

Dat is toch veel te kort door de bocht? Sommige mensen hebben bedrijven of bv een interne afdeling als klant waar ze diensten voor leveren, ontwerpen of implementeren waarbij de afnemer de daadwerkelijke klant van bijvoorbeeld Microsoft is?

Microsoft's 'Shared responsibility model' gaat helemaal niet over backups maar over security...

Backups zijn een security maatregel

[Reactie gewijzigd door Bor op 22 juli 2024 14:15]

[Verwijderd]

Ik geef je de links en de onderbouwing die je jouw 'argumenten' tegenspreken.
Je reageert zonder onderbouwing met 'ik weet het beter'.
Je moet eens leren je zaken te onderbouwen. Maak eens een business case, dan kom je jezelf wel tegen...

[BytePhantomX]

Een 'prullenbak' (die je kan legen, welke corrupt kan raken etc) heeft echt niets met een backup te maken.

Klopt, maar een gemiddelde gebruiker doet dat niet. En corrupt raken zal vast voorkomen, maar is in mijn ervaring een uitzondering. Voor beide is het dan m.i. een risicoafweging. Hoeveel risico wil je accepteren, wat zijn de kosten als het risico zich manifesteert en wat kost het om dat te mitigeren. Ik denk dat voor veel organisaties een backup van Exchange online dan niet de moeite waard is.

Hoe voldoet dit aan de retentie wensen en eisen van de klant?

Kun je ook anders oplossen door retentieregels te gebruiken in Exchange online. Afgezien van het feit dat veel organisaties geen retentieregels hebben (niet iedereen werkt bij een multinational, of in een sterk gereguleerde omgeving).

Kan je het indien nodig ook elders terugzetten in het geval van een calamiteit?

Daar neem je toch een SaaS dienst voor af, juist omdat de ander verantwoordelijk is voor beschikbaarheid en disaster recovery. Als je daar dan alsnog zelf zaken omheen gaat bouwen omdat je die derde partij niet vertrouwd op dat vlak, kun je jezelf afvragen of je wel een SaaS product moet afnemen.

In een "Shared responsibility model' zoals Microsoft het noemt is de klant altijd verantwoordelijk voor informatie en data.

In een SaaS model ben je niet verantwoordelijk voor disaster recovery en beschikbaarheid. Daarvoor zou je m.i. echt geen extra backup moeten afnemen bij Microsoft 365.

En als je dat principe hanteert, dien je ook Teams te backuppen, aangezien er veel communicatie is verplaatst van mail naar Teams. Nu kun je de chats wel in een backup meenemen (zit in je Exchange mailbox) maar restore naar Teams kan niet. En de rest van je Teams kun je volgens mij niet backuppen (afgezien van documenten, maar geen chats).

Als je jouw principe hanteert, ben je meer dan onvolledig en kun je niet anders dan Teams niet gebruiken. Als je teams wel gebruikt, dan begrijp ik niet waarom je voor Exchange online ineens een ander backup principe zou willen hanteren. Idem voor alle anders SaaS diensten. Het is dat Microsoft überhaupt de optie biedt, maar dat is naar mijn idee een uitzondering.

Andere argumenten voor een backup:

• Juridisch: Vooral gericht op de VS. Kun je eventueel ook retentielabels of legal hold voor gebruiken
• Exit plan: Dat is voor mij bij uistek wel de reden om voor een backup te kiezen. Alleen moet je dit ook doen op basis van aan risicoafweging en bepalen op het de kosten waard is.

[Reactie gewijzigd door BytePhantomX op 22 juli 2024 14:15]

[Bor]

Een retentielabel of legal hold heeft echt helemaal niets met backup te maken

[BytePhantomX]

Klopt zeker, maar als je backup inzet met als argument bewaartermijnen of een juridisch perspectief, dan kun je dat ook oplossen met retentielabels en legal hold. Het gaat er om dat documenten beschikbaar blijven, en dat kun je met beide oplossingen.

In een onpremises situatie gebruik je backups voor meerdere doelen. Waaronder disaster recovery en in sommige gevallen voor juridische verplichtingen. Als je dan naar Exchange Online gaat, is het te kort door de bocht om standaard backup in te richten. Voor disaster recovery is het niet nodig. En voor juridische redenen zijn er alternatieven.

Ik hoop niet dat je dit soort adviezen geeft bij de vele organisaties waar jij komt.

Wat ik vooral aan wil geven is dat die adviezen m.i. met Exchange Online zeer genuanceerd zijn en dat de backup die je onpremises had, niet 1-op-1 vertaald moeten worden naar Exchange online. Standaard zeggen dat iedereen met Exchange online een backup nodig heeft, is m.i. ook een verkeerd advies.

[Reactie gewijzigd door BytePhantomX op 22 juli 2024 14:15]

[Bor]

Klopt zeker, maar als je backup inzet met als argument bewaartermijnen of een juridisch perspectief, dan kun je dat ook oplossen met retentielabels en legal hold. Het gaat er om dat documenten beschikbaar blijven, en dat kun je met beide oplossingen.

Niet geheel. Een legal hold of retentielabel houdt jouw data in het geval van een calamiteit niet beschikbaar. Je beschermt je daar op een heel ander niveau tegen heel andere risico's. Het is echt appels met peren vergelijken.

[BytePhantomX]

Ik ben oprecht benieuwd aan welke calamiteiten jij denkt in het geval van Exchange online?

[Blokker_1999]

Heb jij echt zo een blind vertrouwen in de cloud? Dat volgens jouw nooit ook maar iets verloren kan gaan? Dat is durven.

Bijkomend zijn retentielabels en legal hold nog altijd geen backup. Ja, ze voorkomen het verwijderen van data, maar je kuint nog altijd niet zonder slag of stoot terug naar een weergave van hoe het er uit zag op datum X. Daarvoor heb je effectief backups nodig.

[BytePhantomX]

Nee, zeker geen blind vertrouwen, maar met alles is het een risico en kostenafweging. 100% zekerheid kun je in geen enkel geval bereiken. En veel organisaties zijn nu eenmaal afhankelijk van cloud dienstverlening.

Het enige dat ik wil aangeven dat ik moeite heb met iedereen die standaard een backup van Exchange online adviseert omdat je dat onpremises ook had. Dat is een afweging die je moet maken.

Ja, ze voorkomen het verwijderen van data, maar je kuint nog altijd niet zonder slag of stoot terug naar een weergave van hoe het er uit zag op datum X

Maar kun je exchange online dan ook restoren naar Exchange online? En kun je Teams restoren? Dan kun je toch ook niet terug naar een weergaven van hoe het was? En voor juridische redenen is dat waarschijnlijk niet eens nodig. Daar is legal hold juist voor bedoeld.

Ik ben oprecht benieuwd aan welke calamiteiten jij denkt in het geval van Exchange online?

Maar ik ben echt benieuwd. Wat zouden concrete calamiteiten kunnen zijn? Of welke hebben zich al voorgedaan?

[Reactie gewijzigd door BytePhantomX op 22 juli 2024 14:15]

[Bor]

In een SaaS model ben je niet verantwoordelijk voor disaster recovery en beschikbaarheid.

Kijk even naar deze reactie rond specifiek backup; Question Mark in 'VK keurt miljardenovername VMware door Broadcom goed'

[Reactie gewijzigd door Bor op 22 juli 2024 14:15]

[RockmanX]

"Veelal komt men aanzetten met wetgeving of iets in die trant terwijl die wetgeving helemaal niet bestaat (bijvoorbeeld dat je een backup 7 jaar moet bewaren)." Is echt te kort door de bocht.
Het ligt er aan of je moet voldoen aan de archiefwet. Bijvoorbeeld het bewaren van persoonsgegevens of bijzondere persoonsgegevens door bepaalde instanties en ziekenhuizen is wel degelijk onderhevig aan bewaartermijnen. Er zijn zelfs zaken die je eeuwig dient te bewaren. wellicht niet van toepassing op de bedrijven waar jij mee in contact bent; maar zeker wel voor overheidsonderdelen, ziekenhuizen en dergelijke. Dus eerst goed uitzoeken en dan je Back-up of archiefoplossing inrichten naar de eisen waar je wel of niet aan dient te voldoen.

Succes!

[Blokker_1999]

Ik kom bij veel organisaties en vaak 'snapt' men niet hoe 'backup' werkt.

En dan geef je een voorbeeld van EXO waaruit blijkt dat jij niet eens het verschil kent tussen redundantie en backups.

Vooreerst is de flow van een verwijderd item in EXO geen enkele vorm van backup. Het is gewoon een deletion flow in de hoop dat als iets per ongeluk wordt verwijderd, dit te herstellen is. Het is ook maar half geimplementeerd door Microsoft want in de recovery wordt voor gebruikers veel te weinig informatie weergegeven en het is voor een gebruiker niet zomaar mogelijk om een item naar de originele plaats te herstellen.

Maar van zodra ik toegang heb tot een mailbox en ik ga verwijderen met slechte bedoelingen, kan ik heel die flow overslaan, of ik kan op het einde naar mijn recoverable items gaan en op de purge knop duwen. En al je recoverable items zijn weg. Daar komen backups van pas. Het kan ook zijn dat je vereisten hebt om data langer te kunnen herstellen dan wat MS toelaat, ook daar komen backups van pas. Microsoft staat niet zomaar garant voor de integriteit van de data, en de dag dat het misloopt, sta jij in voor de backups.

En wetgeving bestaat niet? Wanneer heb jij voor het laatst met legal in je onderneming gepraat? Er zijn voor heel wat data wel degelijk een hoop bewaringstermijnen. Zo hebben wij nog financiele systemen draaien op een verouderd OS terwijl we die software al heel wat jaren niet meer gebruiken. Maar omdat de bewaringstermijn van die data 10 jaar is, blijft het systeem draaien en blijven we backups houden.

En noem eens een alternatief voor VMware dat dezelfde functionaliteit heeft EN dezelfde support? Mensen vergeten wel eens dat er een reden is dat bedrijven willen betalen voor een product. Namelijk de garantie dat alles wat ze kopen compatibel is met elkaar, dat er 24/7 ondersteuning geboden kan worden voor mission critical taken en de enorme hoeveelheid aan documentatie die gewoon bestaat en klaar staat voor iedereen.

[EXCalibur_EeK]

Backup is één van de belangrijkste zaken in een omgeving. Daar wil ik niet op bezuinigen. Als het goedkoper kan met dezelfde betrouwbaarheid dan is een switch zeker het overwegen waard. Daarom ben ik benieuwd naar de Proxmox oplossing.

Ik kijk dan alleen naar on prem backups van servers. M365 is een ander verhaal en dat is, zeker bij Veeam, belachelijk duur door hun per gebruiker per maand abbo's.

Het voorbeeld dat je aanhaalt staat los van een backup. Daarnaast zijn deze zaken zo te verwijderen. Je wilt je gegevens op minimaal twee plekken hebben staan, het liefst drie.

Op zich vallen de kosten van VMware wel mee,zeker als je een redelijk kleine omgeving hebt waarbij Essential licenties voldoende zijn.

[blinchik]

Ik gebruik zowel VMWare (betalende enterprise versie) als Proxmox. Sommige zaken zijn echt wel veel flexibeler bij Proxmox. De backup is een apart (gratis) product bij Proxmox, PBS (Proxmox Backup Server) waar je eigenlijk alles mee kan doen wat je wil (file level restore, volledige vm's, de hele repository syncen naar een externe locatie, etc). Andere dingen die ik niet zo direct in VMWare zie: remote copy van een vm (dus van een omgeving naar een andere omgeving, gewoon over internet, super cool).

Plus van VMWare, iets meer mature (bv bij Proxmox een paar keer issues geweest dat Windows niet automatisch heropstarte als de client rebootte - dat heb ik dan weer bij VMWare niet gezien). Andere pluspunten: Site Recovery Manager (maar- wie heeft dat?)

[GekkePrutser]

Andere dingen die ik niet zo direct in VMWare zie: remote copy van een vm (dus van een omgeving naar een andere omgeving, gewoon over internet, super cool).

Daar heb je een apart programma voor: vCenter Converter. Ook gratis. vCenter is overigens niet nodig.

Backup is idd wel een zwak punt bij VMWare.

[Bor]

Het probleem is dat een backup een laatste redmiddel is maar dan hebben meerdere 'lagen' aan beveiliging al gefaalt.. Effectief moet een backup simpelweg niet nodig zijn... Als het wel nodig is, dan moet je eens kijken waarom het is dat je die backup nodig moet hebben en dat fixen (als in, investeer je geld daar in plaats van een backup)

Een backup is een maatregel tegen dataverlies en verlies van integriteit. Natuurlijk dien je zo veel mogelijk binnen de redelijkheid te doen om de situaties waarin je aangewezen bent op een backup te voorkomen maar om te zeggen dat daar 100 procent van de resources naar toe moeten is gewoon dom en gevaarlijk advies. Er zijn echt situaties die je met redundantie en andere preventieve maatregelen niet voor zal kunnen zijn.

[Reactie gewijzigd door Bor op 22 juli 2024 14:15]

[Bor]

Ik noem even een AD controller of Exchange server.

Dit is gewoonweg onzin. Sterker nog, in het geval van bijvoorbeeld AD levert Microsoft daar diverse oplossingen waarbij je o.a. kan kiezen of je authorative of non authorative wilt restoren. Ook Exchange backup en restore is gewoon (natuurlijk) mogelijk tot op brick level aan toe.

[Reactie gewijzigd door Bor op 22 juli 2024 14:15]

[Bor]

Any recovery plan should ensure that the age of the backup should not exceed the Active Directory Tombstone Lifetime.

Wederom, wat je aanhaalt onderbouw jouw stelling niet. Snap je wel hoe een tombstone werkt? Het stuk "Any recovery plan should ensure that the age of the backup should not exceed the Active Directory Tombstone Lifetime" is common knowlegde voor iemand die zich hier serieus mee bezig houdt. Feit is dat zowel AD als Exchange backup en restore gewoon mogelijk is. Klok en klepel.

Voor de rest mag je de op de man opmerkingen achterwege laten. Meerdere mensen hebben nu al aangetoond dat je er op meerdere punten naast zit...

[Reactie gewijzigd door Bor op 22 juli 2024 14:15]

[DVBNL]

Zelf gebruik ik Veeam voor back-ups naar hardened repositories welke ik weer op isolated bare-bone linux servers draai. Voor dit soort situaties is het noodzakelijk dat de software immutable flags kan zetten.

Ook heb ik een aantal Altaro servers draaien, prijs/kwaliteit is geweldig alleen supporten zij enkel nog hardened locations richting Azure Blob so far.

[Reactie gewijzigd door DVBNL op 22 juli 2024 14:15]

[Verwijderd]

Altaro, dat is een naam die ik al heel lang niet gehoord heb! Die kwam ik veel tegen op de VMware conferenties. Fijn om te horen dat ze nog steeds goede software maken.

[_root]

2 jaar geleden ben ik mijn klanten gaan migreren van esxi naar proxmox.
Ik gebruik ook PBS en dat kan voor mijn doeleinden meer dan genoeg, remote (encrypt) backup, file level restoren.
Op wat gekke rauwe randjes van proxmox na, is het geweldig en kan eigenlijk alles wat VMware ook kan. Ik zie geen toegevoegde waarde (meer) van VMware

[EXCalibur_EeK]

Heb nu S3 storage als capacity tier. Die is te koppelen aan Proxmox?

[Laurens84]

Dat klinkt dan wel weer heel goed. Zoals ik al in een andere reactie vertelde baar ik echter zorgen over het feit dat de passthrough functie experimenteel is. Ook heb ik gelezen dat het in het verleden ook nog best wel wat problemen had. Over de SRIOV status in proxmox weet ik eerlijk gezegt niets. Maar als passthrough al problemen heeft verwacht ik niet dat het bij SRIOV anders is.

Wat ook een beetje mee speelt is dat Proxmox op Ubuntu leunt. Ubuntu baant zich een weg waar ik niet achter sta dus daar blijf ik liever vandaan. Al moet ik toe geven dat ESXi ook niet veel beter is gezien ze proprietary zijn. Dan is Ubuntu wel "the lesser between two evil's".

[Computer guy]

Proxmox is debian onder de motorkap geen Ubuntu. (Ubuntu is wel een Debian based distro trouwens.)

[vali]

Ze maken gebruik van de kernel van Ubuntu

[Tr1pke]

Hier hetzelfde. Van ESXi naar proxmox. Wat een verademing. Ik ben zelfs ant ESXi geworden hier door. Waar je vroeger licenties voor nodig hebt is nu “gewoon” ingebakken

[leonmast]

Wij zijn ook overgestapt van VMware naar Proxmox met zo'n 30 Hosts en 800 VMs. Het is inderdaad een verademing zoals Eltweako zegt. Voor ons was de reden voornamelijk de kosten. Vmware en Veaam licenties zijn peperduur. Tot nu toe absoluut geen spijt gehad.

[bleep1912]

Hyper-v Core is gratis.

[basseytje]

esxi is ook gratis

[bleep1912]

Vanaf 8.0 niet meer. Maar je opmerking is eigenlijk niet relevant want zijn vraag was: wat is een goed alternatief voor esxi.

[jimzz]

Unraid, niet gratis wel simpel en native docker.

Voor klein, middenbedrijf wel aan te raden, anders zou ik eerder Proxmox aanraden.

[Reactie gewijzigd door jimzz op 22 juli 2024 14:15]

[GekkePrutser]

Jawel hoor, 8.0 is ook nog steeds gratis: https://customerconnect.v...n/evalcenter?p=free-esxi8

Ik heb gewoon weer een lifetime licentiecode ontvangen. Ik moest wel opnieuw "registreren" (niet een account aanmaken maar wat gegevens invullen) maar dat is bij elke major versie zo geweest.

Edit: Dit staat ook nog gewoon in de laatste licentie whitepaper:

VMware vSphere Hypervisor

vSphere Hypervisor is a free product that provides a simple way to get started with
virtualization at no cost. It provides only basic virtualization capabilities, allowing
customers to virtualize servers and run applications in VMs in a matter of minutes.
vSphere Hypervisor cannot connect to vCenter Server and therefore cannot be centrally
managed. Users can remotely manage individual vSphere Hypervisor hosts using the
VMware vSphere Client. There are no restrictions on the number of physical CPUs per
host and on the amount of RAM per server/host. The maximum vCPUs per VM is eight.

Ze maken het wel steeds moeilijker om dingen in te stellen (Sommige dingen kunnen alleen via vCenter of via ingewikkelde commando's) en om de gratis licentie te vinden op hun site maar dat is al jaren aan de gang.

[Reactie gewijzigd door GekkePrutser op 22 juli 2024 14:15]

[Xanthine]

Ik krijg nog steeds bij elke release van ESXi een nieuwe key opgestuurd door VMWare, dit al sinds 2011 en ik snap niet waarom Zo heb ik in oktober ook een key gekregen voor 8.0

[latka]

Je use case (router in proxmox) is triviaal of je nu passthrough doet of virt-io devices. Het werkt wel anders, dus zal wel een avondje kunnen kosten. Ik denk vooral dat Broadcom een 'Oracle' gaat doen: prijzen net zo lang verhogen tot het aantal uitstappers te groot wordt en daar dan 1 cent onderblijven. M.a.w. heren/dames inkopers: trek de portomonee maar.

[Laurens84]

Bij Proxmox had ik echter begrepen dat passthrough en SRIOV experimentele functies zijn. Dat schrikt mij wel een beetje af.

[Marve79]

Maar waar heb je dat voor nodig in de praktijk? GPU passthrough?

[Laurens84]

Yup, twee VM's hebben een GPU met passthrough. SRIOV is voor de NIC's. Verder trowuens ook nog wat usb controllers die met passthrough naar VM's gaan.

[Reactie gewijzigd door Laurens84 op 22 juli 2024 14:15]

[Teun!]

Oh ik dacht dat SRIOV een gpu feature was, dus in ieder geval bedankt hiervoor ik ga dit nog even googlen.

[Laurens84]

SRIOV is voor meer PCI hardware. Bij ESXi werkt het helaas echter alleen voor NIC's vanaf 10Gbit voor een of andere stomme reden. Iets met dat ze vinden dat het voor 1Gbit NIC's niet nuttig zou zijn ofzo.

[OruBLMsFrl]

Qua performance heb je dat ook op een 1 Gbps link niet nodig. Gebruik je iets anders dat SRVIO uniek mogelijk maakt, of is het vooral een stukje gave tech dat je graag wilt gebruiken? Werd vooral over gesproken bij 25G en 40G van wat ik me herinner, dat je ook 10G best nog wel zonder kan doen. Ligt natuurlijk ook aan hoe ruim je in de CPU zit, wat voor NIC je hebt, etc...

[UTMachine]

Welke usb controllers praat je over? Ik gebruik usbip (standaard in debian repo), naar mijn VM met debian. Werkt rete stabiel voor 5 USB devices o.a. Zwave, Zigbee, rfxcom, etc

[latka]

passthrough is niet echt experimenteel: het zit in de GUI en de kernel ondersteunt het gewoon. Het is wel zo dat er geen whitelist is van hardware en het in linux mogelijk is dingen te passthrough'en die daar niet helemaal lekker geschikt voor zijn (acs patches enzo). Dus je kunt veel meer passthrough doen dan onder ESX, ook met combinaties die je eigenlijk niet zou moeten doen. Dat kan dan wat instabiel worden.

[poktor]

Dit. Maar helaas voor Broadcom zijn er veel spelers in deze markt met goedkopere en zelfs helemaal gratis opensource producten, dus ik denk dat ze niet al te gek kunnen doen. Een hele mooie nieuwe speler in deze markt is bijvoorbeeld EVE.
https://www.eve-ng.net/
EVE is heel erg veelzijdig en ondersteunt zelfs fortigate, cisco en android. Mooie toevoeging is het werkblad waarin je de connecties tussen de verschillende VM's legt. Het is alsof je in Visio zit en lijntjes trekt, alleen zijn dat nu werkende fysieke verbindingen. Heel mooi!

[mysterion1989]

Proxmox kan gewoon firewall pfsense monowall opensense op werkt goed

[Stetsed]

Proxmox werkt helemaal okay voor een router, ik heb Opnsense, Pfsense en nu VyOS als VM gedraaid en alle keren werkte het perfect. Heb het met virtual bridges gedaan en met PCIE passthrough. Kan hem zeker recommenderen

[McBacon]

Ik had eerst ook ESXi draaien maar ik heb mijn shit een redelijk aantal jaar gelee gemigreerd naar libvirt, wat toevallig ook van Red Hat is maar je hebt geen gezeik met licenties. Je bent ook niet verplicht om Red Hat Linux te gebruiken, ik heb het zelf gewoon draaien op Ubuntu. Overigens is libvirt alleen een library voor het beheren van hypervisors, het virtualiseert zelf niks. Het kan direct overweg met o.a. ESXi, Hyper-V, Xen, OpenVZ, LXC en QEMU+KVM. Ik gebruik zelf die allerlaatste voor full VM's, vervolgens virt-manager (of een andere front-end) erbij en je hebt al iets vergelijkbaars als ESXi. Ik heb zelf gekozen voor libvirt i.p.v. Proxmox omdat ik weer niet (teveel) afhankelijk wilde zijn van een bepaalde (web)interface zoals ook bij ESXi, maar eventueel via terminal zelf wat kan goochelen. Voor mijn gevoel is Proxmox toch redelijk "gesloten" wat dat betreft. Front-ends voor libvirt zijn over het algemeen wel wat meer "Linux-y", dus minder fancy UI's enzo.

Features die je niet in kunt stellen via virt-manager maar wel ondersteund zijn door libvirt, kun je alsnog gebruiken als je gewoon de XML config van de VM aanpast, wat trouwens ook kan via virt-manager voor elk los specifiek stukje "hardware". Verder is SRIOV zo te zien prima ondersteund en niet experimenteel, je moet alleen wel ff op je IOMMU groups letten. Ik heb zelf de on-board graphics chip plus audio device als passthrough naar een VM, zodat ik Kodi op mijn TV kan afspelen. Zet ik de VM uit dan krijg ik het beeld van de host weer op de televee. Dat werkt in mijn ervaring dus 10x beter dan de passthrough van ESXi, die op zijn best "iffy" was.

Red Hat Virtualization wordt trouwens niet meer onderhouden met nieuwe features, de opvolger is OpenShift.

[GekkePrutser]

Ik heb een tijdje libvirt + QEMU/KVM gedraaid bovenop alpine linux maar dat ging niet bepaald fijn. Bij elke update had ikw eer een ander probleem met de kernel modules.

ESXi is ook niet altijd soepel ivm de zeer beperkte hardware support maar als het werkt is het wel goed (behalve de UI van ESXi die vaak niet goed refresht, ik denk dat ze dat gewoon niet fixen omdat ze willen dat je vCenter koopt).

Ik gebruikte trouwens meestal virsh, niet virt-manager omdat dat weer een GUI vereist.

[Reactie gewijzigd door GekkePrutser op 22 juli 2024 14:15]

[McBacon]

Ik heb een tijdje libvirt + QEMU/KVM gedraaid bovenop alpine linux maar dat ging niet bepaald fijn. Bij elke update had ikw eer een ander probleem met de kernel modules.

Weird, zelf eigenlijk nooit last van gehad. Ben niet bekend met Alpine ook, ik heb zelf vrijwel alles op Debian behalve dan mijn VM host. Ik gebruik idd ook meestal virsh, maar als je het virtuele display van je VM wil bekijken is een GUI wel handig. Uiteindelijk zal je die toch ergens moeten hebben om een display in te renderen. Volgens mij kan het ook wel met X forwarding maar dat werkt niet (zo goed) op een Mac.

ik denk dat ze dat gewoon niet fixen omdat ze willen dat je vCenter koopt

vCenter vond ik nog het meest irritant ja, je kan niet eens fatsoenlijk beheer doen zonder een hele VM op te moeten zetten met bijbehorende licentie (ook al heb je maar 1 host). Dan ging het nog niet eens om van die rare bugjes zoals jij noemde, maar als je wat meer wilde dan alleen start/stop/new/delete VM had je al snel vCenter nodig.

[bientjen]

truenas scale eens bekijken, kan je docker containers en full vm's op draaien

[Reactie gewijzigd door bientjen op 22 juli 2024 14:15]

[Stetsed]

TrueNAS scale is niet echt een vervangingen voor exsi simple weg omdat de virtualization feature set best well basis is. Als een NAS systeem is het top, voor een virtualization setup is het minder.

[The Realone]

Het is echter een reactie op iemand die het voor zijn thuisserver gebruikt, normaal gesproken kun je dan prima uit de voeten wat met basic virtualisatie. En de container ondersteuning is natuurlijk ook bijzonder prettig in zo'n omgeving. Ik heb de afgelopen aardig wat VMs kunnen consolideren in een hele rits containers.
In een professionele omgeving geef ik je volledig gelijk.

[Teun!]

Ik ben het met je eens. Ik zou truenas scale inderdaad nog niet echt production ready durven noemen. Proxmox daarintegen heb ik niks dan positiefs over te zeggen, als ook Truenas Core (voor backups, geen virtualisatie).

[Laurens84]

Net even opgezocht en wat over gelezen. Ziet er zeker leuk uit. Wellicht dat ik mij daar een keertje een weekendje over ontferm. Dank voor de tip!

[Marve79]

Proxmox werkt supersimpel en is naar mijn idee veel beter als je prive een hypervisor wilt draaien omdat het open source is en ook vanwege de grote community. De confguratie komt uiteindelijk toch wel allemaal op hetzelfde neer. Het grote nadeel van ESXi is als je iets meer wilt dat je direct vcenter nodig hebt.

[UTMachine]

Als VMware alles doet wat je ermee wilt doen, waarom overstappen?

Op het werk gebruiken ze alleen Linux, dus ik ben begonnen met Proxmox. Als ik vmware certified was, was er een 99% kans dat het VMware was geworden.

[Bierkameel]

Wat voor trukjes moest je uitvoeren dan voor die router? Meestal heb je niet meer nodig dan een LAN en WAN vswitch?

[jmvdkolk]

De CMA onderzocht onder meer of Broadcom ervoor kan zorgen dat hardware van concurrenten minder goed wordt ondersteund door de software van VMWware. Volgens de toezichthouder zou dat niet opwegen tegen het omzetverlies dat Broadcom daarmee zou leiden.

Die toezichthouder heeft helemaal gelijk, en ook helemaal ongelijk. Broadcom heeft zich al vaker niet laten tegen houden door dit soort logica. Ik ben bang dat dit het einde van WMWare gaat zijn.

[Fermion]

VMware is wel heel groot, dan moet we heel wat gebeuren omdat te laten omvallen.

[latka]

Het is groot, maar nauwelijks uniek. Ik ken ook weinig software die het wel doet op VMWare maar niet op andere hypervisors. Dus als de Broadcom iets te hard de prijs laat oplopen dan is het snel voorbij.

[Bor]

Ik ken ook weinig software die het wel doet op VMWare maar niet op andere hypervisors.

Dat is dan ook bijjna nooit het selling point volgens mij. Je kiest o.a. voor vmware wegens uitgebreide management en integratie mogelijkheden, omdat het min of meer nog steeds de defacto standaard is, vmware kennis en expertise makkelijk beschikbaar is en vmware een breed scala aan producten rond de hypervisor aanbied.

[latka]

Volgens mij kies je VMWare voornamelijk omdat je precies die expertise in huis hebt: beheerders zijn net mensen en minimaal net zo conservatief in de product keuze ;-)

[Gaat niet door]

VMware is natuurlijk niet alleen maar een HyperVisior. De Hypervisior is ESXi, maar het portofolio is veel groter dan dat. Denk bijvoorbeeld aan VMware vSAN voor storage of NSX-T voor netwerk virtualisatie. Tuurlijk het maakt allemaal gebruik van de hypervisor.

[Verwijderd]

En de IT wereld is ook al minimaal 5 jaar afgestapt van VM's... VM's waren een 'oplossing' om pruts software goed te laten werken maar met de komst van containers zijn we daar al lang van afgestapt.
Waarom een volaan OS draaien, als je enkel met de (micro) app afkunt...

Als je kijkt naar kosten, vrijwel iedere cloud aanbieder biedt dezelfde functionaliteit aan maar dan ingebouwd in het platform... T.C.O. is daar veel lager.

Daarnaast hebben alle producten van VMware tegenwoordig wel een open-source oplossing die even goed is of de wereld is al totaal veranderd qua instelling.

VMware vSAN:
https://en.wikipedia.org/wiki/Ceph_(software)
https://en.wikipedia.org/wiki/Gluster

VMware NSX-T:
Zero-trust networking... Stap gewoon over op een moderne werkplek en dan heb je al die complexiteit niet nodig.

[webgangster]

Alsof zero trust networking NSX-T kan vervangen, product kan meer dan je denkt. Maar hangt sterk af van je usecase en wat je nou wilt bereiken.

[Bor]

Alsof zero trust networking NSX-T kan vervangen

Natuurlijk niet. NSX is een oplossing waarmee je zero trust (gedeeltelijk) kan implementeren maar het kan zo veel meer waaronder het geven van inzicht. Het soort "VMware NSX-T -> stap maar over op een moderne werkplek" adviezen of vergelijkingen getuigen niet van kennis van en ervaring met het product.

[d3x]

Ach zulke stelling hebben zelfs geen greintje gedachtegang. De topic starter mag eens afkomen om onze 13000 van op "legacy" win en rhel met alle de en 3rd party over te zetten naar container.

Zelfs het cloud verhaal en TCO is totale bullshit als er veel data trafiek is in en uit.

NSX is geen zerotrust... Is maar een deel van zerotrust verhaal.

Zelfde met al die verhalen over proxomox beter en vervanger van. Kom eens af als je 1000 servers en meer hebt en een enterprise business met meerdere DC, multizone, metrocluster, DRP etc... Het verhaal zal snel stoppen.

[Reactie gewijzigd door d3x op 22 juli 2024 14:15]

[vali]

Ach zulke stelling hebben zelfs geen greintje gedachtegang. De topic starter mag eens afkomen om onze 13000 van op "legacy" win en rhel met alle de en 3rd party over te zetten naar container.

Prima mogelijk, maar je moet wel als een team samenwerken om de troep te migreren naar een gedegen omgeving. Probleem bij dat soort omgevingen zit hem niet in de 3rd party, maar in het beheer in het algemeen en vooral ook de samenwerkingen tussen de vele afdelingen.

Moraal is wel, containers gaat het zeker worden en misschien kan niet alles worden overgezet, overgrote deel kan er prima op draaien. Je hebt alleen mensen nodig met kennis/ervaring bij zo'n migratie en vervolgens de mensen nodig om het te gaan beheren. Hou je straks handje vol servers over die ergens op een VM draaien, kan je daar de "systeembeheerders" op zetten.

Maakt verder maakt het niet uit hoeveel servers je beheerd, als je automation op orde is dan maakt het niet uit of het 2000 of in jouw geval 13000 is. Ook het legacy verhaal met 3th party kan je gemakkelijk oplossen.

[Reactie gewijzigd door vali op 22 juli 2024 14:15]

[d3x]

container platformen moet je ook beheren hoor, al is het dan al veel meer door scripting en andere type mngmnt. maar je zit nog steeds met HW issues, patching, security, hw lifecycle
Daar ook van enkele 100'en in gebruik
Er is idd minder werk dan aan een VM farm met OS, maar dat komt vooral door OS, er zijn menig andere OS die minder onderhoud nodig hebben en je kan containers ook op een virtualisatie laag draaien, alhoewel dit een heel andere insteek is.

[vali]

container platformen moet je ook beheren hoor, al is het dan al veel meer door scripting en andere type mngmnt. maar je zit nog steeds met HW issues, patching, security, hw lifecycle

Zeker waar, maar oude omgevingen zou een container omgeving ook niet gaan werken gezien het grootste obstakel de beheerders zijn. Als je automation goed op orde is kan je ook een VM bijna zoals een container laten draaient. VM kapot? Opnieuw uitrollen en de data automatisch laten terugzetten. Binnen enkele minuten staat de bak er weer. Die werkwijze is belangrijker dan daadwerkelijk het OS en/of de applicatie.

Hardware issues en patching is zeker altijd aan de orde, maar met VM's en container is dat niet meer echt meer zoveel werk meer zoals vroeger dat was met fysieke bakken. Het is niet alsof er 13000 fysieke bakken in de datacenter staan om maar een voorbeeld te noemen.

[Verwijderd]

Alsof zero trust networking NSX-T kan vervangen, product kan meer dan je denkt. Maar hangt sterk af van je usecase en wat je nou wilt bereiken.
Uiteraard zijn er meer usecases te bedenken, ik heb zelf lange tijd VMware vCloud beheerd waar NSX ook een onderdeel van was. Maar het punt is dat als je een zero-trust omgeving hebt, je geen NSX meer nodig hebt voor het isolatie onderdeel.

[Bor]

VMware vSAN:
https://en.wikipedia.org/wiki/Ceph_(software)
https://en.wikipedia.org/wiki/Gluster

Dat zijn niet direct vergelijkbare oplossingen. Ken je Vmware vSAN wel? Niet elke netwerk storage oplossing is hetzelfde.

[syl765]

En de IT wereld is ook al minimaal 5 jaar afgestapt van VM's... VM's waren een 'oplossing' om pruts software goed te laten werken maar met de komst van containers zijn we daar al lang van afgestapt.
Waarom een volaan OS draaien, als je enkel met de (micro) app afkunt...

En toch zie je veel bedrijven hier ook weer gedeeltelijk van terugkomen. Met name de overhead netwerk wise, complexiteit enz maken dat het hele microservice gebeuren soms tot veel meer problemen lijd dan dat het problemen oplost.
Zelfs amazon prime liep tegen deze problemen aan en ook hier zie je dat men toch weer meerdere services gaat samenvoegen.. Waar men vroeger een simpele call deed naar een UDS moet je nu allerhande netwerk calls doen.
https://thenewstack.io/am...-to-a-monolith-after-all/

Je zal dus zien dat men voor sommige zaken toch weer een wat grote service of zelfs een VM zal kiezen om het werk zo efficient mogelijk gedaan te krijgen. Ik denk dus dat VM's zeker bestaan recht hebben en ook zullen blijven.

[Bor]

VM's waren een 'oplossing' om pruts software goed te laten werken maar met de komst van containers zijn we daar al lang van afgestapt.

Ook niet. VM's waren en zijn een oplossing om tot hardware onafhankelijkheid te komen, om schaal voordeel te halen (vele VM's op een enkele fysieke host) en om te komen tot een hoog beschikbare omgeving waar je on demand kan schalen en voordeel kan behalen door meerdere systemen op 1 systeem te draaien door bv memory sharing. En nee, daar zijn we echt niet "al lang van afgestapt".

[Verwijderd]

Ook niet. VM's waren en zijn een oplossing om tot hardware onafhankelijkheid te komen, om schaal voordeel te halen (vele VM's op een enkele fysieke host)
Dat was in de begin jaren... Tegenwoordig zie je precies het omgekeerde, een host vol inactive VM's (met gigantische overhead van het OS) en men wil graag gebruik maken van hardware (zoals TPU / GPU acceleratie).

en om te komen tot een hoog beschikbare omgeving
Als je een echt hoog beschikbare omgeving wil, dan doe je dat op applicatie niveau. Dat weten we al 20 jaar... Dan ga je niet gehele besturingssystemen / servers heen en weer verplaatsen... Dat bedoel ik ook met 'pruts software', jij 'fixed' een probleem dat eigenlijk gewoon in de applicatie afgevangen moet worden. Maar de applicatie is daar blijkbaar niet geschikt voor..

waar je on demand kan schalen
Verticaal schalen is niet horizontaal schalen... en verticaal schalen is sterk gelimiteerd. Tegenwoordig niet op hardware niveau maar op software. Daarom zie je juist van hosts vol VM's die geen drol doen de hele dag...

en voordeel kan behalen door meerdere systemen op 1 systeem te draaien door bv memory sharing. En nee, daar zijn we echt niet "al lang van afgestapt".
Mooie sluiter.... Memory sharing is (binnen VMware) al sinds 2016 standaard uitgeschakeld gezien de beveiligingsproblemen.... Nou vind jij 7 jaar misschien niet 'al lang' maar ik wel...
https://docs.vmware.com/e...A2-8303-B06DBC9054C5.html

Echt geweldig hier, allemaal ouderwetse knorrige systeembeheerders... Je zou denken dat IT-ers open staan voor vooruitgang... Tevens is de virtualisatie kennis hier niet echt up2date, zo te zien....

[Bor]

Tegenwoordig zie je precies het omgekeerde, een host vol inactive VM's (met gigantische overhead van het OS)

Je generaliseert er lekker op los. De ene omgeving is de andere niet. De omgevingen die ik tegen kom zijn vrij optimaal ingeregeld? Nogmaals, voor hypervisors en containers zijn beide use cases welke overlapppen maar niet hetzelfde hoeven te zijn.

Verticaal schalen is niet horizontaal schalen...

Klopt. Verticaal kan met een hypervisor ook afhankelijk van de inrichting. Ook niet elke container oplossing schaalt verticaal goed.

Mooie sluiter.... Memory sharing is (binnen VMware) al sinds 2016 standaard uitgeschakeld gezien de beveiligingsproblemen....

Intra-virtual machine sharing kan gewoon hoor?

Echt geweldig hier, allemaal ouderwetse knorrige systeembeheerders... Je zou denken dat IT-ers open staan voor vooruitgang... Tevens is de virtualisatie kennis hier niet echt up2date, zo te zien..

Tot nu toe ben jij degene die hier de feiten niet allemaal op een rij heeft zo te zien. Het onnodig persoonlijk maken is echt niet nodig. Het helpt al helemaal niet om je gelijk op deze manier aan te willen tonen. Laten we de discussie maar stoppen.

[Reactie gewijzigd door Bor op 22 juli 2024 14:15]

[Bor]

Zero-trust networking... Stap gewoon over op een moderne werkplek en dan heb je al die complexiteit niet nodig.

Grappig om te lezen gezien bijvoorbeeld Microsoft zero trust ook adviseert bij Azure en 'moderne' (jeukwoord) werkplekken.

Vm"s en containers zijn verder niet hetzelfde en niet direct 1 op 1 uitwisselbaar. Een VM geeft je doorgaans een veel grotere controle en invloed wat in bepaalde toepassingen vereist is.

[Reactie gewijzigd door Bor op 22 juli 2024 14:15]

[Verwijderd]

Grappig om te lezen gezien bijvoorbeeld Microsoft zero trust ook adviseert bij Azure en 'moderne' (jeukwoord) werkplekken.
Dat is ook wat ik bedoel? Stap over op een moderne werkplek, die is al gebaseerd op zero-trust networking.

Vm"s en containers zijn verder niet hetzelfde en niet direct 1 op 1 uitwisselbaar.
Dat zeg ik ook niet. Ik geef enkel aan dat de gedachte van een heel OS virtualiseren zeer ouderwets is.

Een VM geeft je doorgaans een veel grotere controle en invloed wat in bepaalde toepassingen vereist is.
En minimaal 10x zoveel overhead... Sorry, maar als je veel grote controle en invloed nodig hebt over een applicatie dan is er toch echt iets mis met de applicatie? Het is als dagelijk in een vrachtwagen rondrijden want je weet maar nooit of je iets moet vervoeren...

[Bor]

Dat is ook wat ik bedoel? Stap over op een moderne werkplek, die is al gebaseerd op zero-trust networking.

Een 'standaard' (als er al zoiets bestaat) 'moderne' werkplek voldoet 'standaard' niet automatisch aan het zero trust principe.

En minimaal 10x zoveel overhead... Sorry, maar als je veel grote controle en invloed nodig hebt over een applicatie dan is er toch echt iets mis met de applicatie? Het is als dagelijk in een vrachtwagen rondrijden want je weet maar nooit of je iets moet vervoeren...

Nee dan is er niet iets mis met de applicatie. Niet alle software is geschikt om in een container te draaien. Dat maakt het geen slechte software. Je kan het ook omdraaien en stellen dat het aan de container techniek ligt dat iets niet wil werken maar ook dat is veel te stellig. Daarbij kan het nodig zijn vanwege bv beveiliging of compliance om zaken gescheiden te draaien en verregaand te hardenen waarbij je bij container techniek tegen limitaties aan kan lopen. Beide technieken hebben hun eigen sterkte en zwaktes en eigen use cases. Je gaat echt (veel) te kort door de bocht.

[Verwijderd]

Een 'standaard' (als er al zoiets bestaat) 'moderne' werkplek voldoet 'standaard' niet automatisch aan het zero trust principe.
Ja, er bestaat prima 'zoiets'. Neem een Chromebook of M365 client... Die verbind je met internet en that's it... Natuurlijk heb je halve omgevingen (hybrid) maar dat is niet modern. Niet volgens Microsoft of andere leveranciers. Die zitten simpelweg in een migratie naar een moderne werkplek.

Niet alle software is geschikt om in een container te draaien. Dat maakt het geen slechte software.
Mee eens, maar je geeft als argument dat je 'veel grote controle en invloed nodig hebt'. Ik zie niet hoe dat als positief gezien kan worden, enkel als meer werk (dus kosten).... Verder schalen VM's natuurlijk alleen verticaal dus op langere termijn problematisch...

Beide technieken hebben hun eigen sterkte en zwaktes en eigen use cases.
Uiteraard.

Je gaat echt (veel) te kort door de bocht.
Valt wel mee, containerization is gewoon een moderner concept.
Het lost veel van de problemen op die we tegenkwamen in de jaren 2000 toen we massaal overstapten op ESX / hypervisors... Ik heb zeker 15 jaar zulke omgevingen weggezet en tegenwoordig zie je niemand meer die 'keuze' maken. Als het al gebeurd is het om legacy software draaiende te houden...

[Bor]

Ja, er bestaat prima 'zoiets'. Neem een Chromebook of M365 client... Die verbind je met internet en that's it...

Dat is niet wat zero trust is

Mee eens, maar je geeft als argument dat je 'veel grote controle en invloed nodig hebt'. Ik zie niet hoe dat als positief gezien kan worden, enkel als meer werk (dus kosten)....

Het is toch een voordeel wanneer je dat nodig bent? Kan je dat niet leveren dan kan je in sommige situaties gewoon niet voldoen. Ja dat kan meer kostbaar zijn maar kosten zijn nooit het enige argument.

Valt wel mee, containerization is gewoon een moderner concept.
Het lost veel van de problemen op die we tegenkwamen in de jaren 2000 toen we massaal overstapten op ESX / hypervisors...

Het is vooral anders in plaats van moderner. Je kan beide oplossingen maar gedeeltelijk vergelijken en ook containers kennen hun eigen nadelen en beperkingen net als hypervisors. Dat nu minder bedrijven de keuze maken voor hypervisors heeft natuurlijk niet (alleen) te maken met de komst van container technologie maar vooral ook met sterke verSaaSing. Je ziet hetzelfde bij containers.

[Verwijderd]

Dat is niet wat zero trust is
Je doet deze uitspraak:
Een 'standaard' (als er al zoiets bestaat) 'moderne' werkplek voldoet 'standaard' niet automatisch aan het zero trust principe.
Ik noem twee voorbeelden van moderne werkplekken die automatisch voldoen aan het zero trust principe:
Een Chromebook met Google Workspace: https://workspace.google.com/security/
Een M365 client, toegegeven die heeft wel eerst configuratie nodig maar dat is Microsoft: https://learn.microsoft.c...trust?view=o365-worldwide
Microsoft en Google werken beide standaard met zero-trust. Een moderne werkplek werkt net zo veilig en goed bij een co-workspace op het gasten wifi als 'op de zaak'.

Dat is niet wat zero trust is
Als jij denkt dat de bedrijfs oplossingen van Microsoft en Google niet weten 'wat zero trust is', dan moet je meer aan zelfreflectie doen.

Het is toch een voordeel wanneer je dat nodig bent? Kan je dat niet leveren dan kan je in sommige situaties gewoon niet voldoen. Ja dat kan meer kostbaar zijn maar kosten zijn nooit het enige argument.
Kosten zijn in de sectoren waar ik werkzaam ben helaas een zeer groot argument, zo niet de grootste. Het grootste probleem dat ik persoonlijk tegen kom, is kennis, beschikbaarheid en stagnatie. Oude systemen blijven draaien en geven enorme verborgen kosten. De mensen om die systemen correct te onderhouden zijn niet beschikbaar of werken enkel bij dure consultancy clubs (logisch). De VM's blijven maar draaien in een apart hoekje en niemand wil er nog aan zitten. Het is simpelweg slecht lifecycle management. Niet direct de 'schuld' van VM's maar wel een trend die vergroot is door virtualisatie. Virtualisatie fixed problemen die eigenlijk aan de applicatie kant opgelost moeten worden, bij containers is lifecycle management een standaard onderdeel van het proces.

Het is vooral anders in plaats van moderner.
Nee, het is echt moderner. Zowel in leeftijd als techniek. Ik kom uit de tijd van VMware GSX / ESX, dat is rond 2010. Containerd was pas uitgekomen in 2015. Gezien containers standaard netwerk geïsoleerd zijn, eenvoudiger update process, eenvoudiger uitrol process, betere beveiliging, eenvoudiger schaalbaar (niet altijd maar bij het forceert de applicatie bouwer om hier over na denken) vind ik dat enorm veel moderner... Alleen het feit dat je een heel OS moet updaten of enkel een container, moet dat argument wel duidelijk maken.

Het punt is dat applicatie zaken moeten gebeuren op applicatie niveau en containers zijn daar specifiek voor zijn ontworpen. L1 virtualisatie is ontworpen voor het virtualiseren van besturingssystemen.

Je kan beide oplossingen maar gedeeltelijk vergelijken en ook containers kennen hun eigen nadelen en beperkingen net als hypervisors.
Alles heeft voor en nadelen, dat hoef je niet te benoemen en lijkt me voor de hand liggend.

Dat nu minder bedrijven de keuze maken voor hypervisors heeft natuurlijk niet (alleen) te maken met de komst van container technologie maar vooral ook met sterke verSaaSing. Je ziet hetzelfde bij containers.
Klopt maar verSaaSing is juist een van de drijvers geweest van containerization. Met ziet dat verticaal schalen gewoon niet meer werkt dus kiezen alle moderne SaaS oplossingen voor containers. In een modern ontwikkel process is het niet eens een discussie (bijvoorbeeld een DevOPS opzet). Het idee van iedere keer gehele VM's uitrollen, patchen, software uitrol (op een of andere manier), terug naar stap 1, krijg je binnen geen enkele organisatie er nog door (bijvoorbeeld voor een businesscase). Een software ontwikkelaar typt tegenwoordig 'docker build' of heeft een container CI/CD pipeline. Ja, dat kan met VM's maar laten we eerlijk zijn, dat doet niemand... Toch?

[goarilla]

En minimaal 10x zoveel overhead.

En wat met commerciele linux, windows software. De ene leunt op libblas en de andere op .NET 3.5 ofzo ? Ik zou het heerlijk vinden om containers te hebben van alles maar sommige programma's hebben zoveel afhankelijkheden dat het te veel werk is. Zelfs met simpele OS upgrades heb ik vaak substantiele problemen. Debian bullseye -> bookworm nagios4: libgd ondersteund geen gd2 formaten meer, de nieuwe kernel van vorige of vorige vorige week brak check_load op localhost. Pnp4nagios werkt niet en ik zie me dat ook niet direct echt oplossen omdat het een mengelmoes is van shell, c, perl, zelfbereide (c-like) php op een gestript Kohana MVC OO-framework dat EOProject ging in 2016 en niet compatibel is op PHP 8 dat voor 1 of andere reden in deze debian versie echt niet gewoon downgradebaar is. In Bookworm maken ze blijkbaar de stance: nothing below php 8 !!! Leuk dan sta je daar. Blij dat dit maar een hobby meer is. Ik weet echt niet hoe jullie dat allemaal klaarspelen, zeker in deze tijd.

[InsanelyHack]

klopt maar houd je daardoor ook langer vast op oude software. Ik denk dat een gezonde mix goed is. Dus een containerplatform naast een virtualisatie platform evt in de cloud. Strategie moet zijn om nieuwe apps naar containerplatforms over te brengen of keuzes te maken die dit voordeel in zich hebben.

[Bor]

klopt maar houd je daardoor ook langer vast op oude software.

Ook moderne software kan op een hypervisor draaien natuurlijk. Je zal per toepassing / use case moeten kijken wat de beste oplossing is. Dat kan, zoals je zelf ook aangeeft, prima een mix van containers en hypervisors opleveren. De strategie moet zijn om software te kiezen welke goed past binnen jouw visie. Het gebruik van een container oplossing is geen doel op zich maar hoort te passen bij de wensen en eisen. In veel gevallen zullen containers ook overgeslagen worden en zet men bijvoorbeeld in op SaaS.

[InsanelyHack]

Het gebruik van een container oplossing is geen doel op zich maar hoort te passen bij de wensen en eisen.

Dat ben ik niet met je eens omdat een monoliet gewoon slecht schaalt dus voor mij is het wel een doel.

[Bor]

Kortom, je kiest een platform op basis van slechts 1 kenmerk zonder breder te kijken naar wat de beste oplossing is voor een workload? Dat lijkt mij en niet zo optimale aanpak als ik eerlijk ben. Elke oplossing vraagt om de meest optimale aanpak en daar speelt de mogelijkheid tot schalen misschien een rol maar dat doen doorgaans kosten, security, compliancy, support mogelijkheden etc ook.

[Reactie gewijzigd door Bor op 22 juli 2024 14:15]

[InsanelyHack]

Natuurlijk niet één eigenschap. Natuurlijk kijk je naar de workload en als het niet anders kan dan zij het zo maar bij greenfield software implementaties kijken wij naar de mogelijkheid om het evt op een containerplatform kan landen. We denken dat het toekomstbestendiger is, beter schaalt in de applicatie zelf maar ook in de onderliggende hardware en meestal is het platform ook een stuk goedkoper, is het ook cloud ready, is orchestratie een basisvoorziening. Wij gebruiken bijvoorbeeld heel veel van BMC en zij hebben al heel veel enterprise software van monolithische applicaties omgezet naar micro services op een containerplatform. Maar het opzetten, onderhouden en security kan best complexer zijn en vereist expertise.

[OruBLMsFrl]

Goed dat je dat zegt. Tegelijk maakt VSAN het VMWare platform veel duurder in licenties. NSX idem. Voor bepaalde omgevingen kan het werken, maar ze maakten die licenties nu al zodanig duur, dat je zelfs in de kleinere grootzakelijke omgevingen met wat goed inkopen nog voordeliger de hardware ervoor in huis haalt, dan via VMWare de software. Heb meegemaakt dat een bestaande VSAN omgeving wordt opgevolgd door een traditioneel SAN ervoor in de plaats voor minder geld. Bij VMWare dachten ze vast gaat zo een vaart niet lopen, maar wel dus. Gaat nergens over die VMWare prijzen voor wat extra stukken software in verhouding, wat meer concurrentie van Proxmox, Hyper-V en hopelijk nog wat meer zal ze goed doen.

[HellStorm666]

Wij lijken toch niet veel keuze te hebben.
We gebruiken Veeam voor de backups, echt super software!
Veeam ondersteund VMware en Hyper-V.
Maar ivm hardware-licentiesleutels, welke ook niet over zo'n USB->LAN adapter werkt, moet de hypervisor usb-passtrough ondersteunen.
Hyper-V valt daardoor af.

Proxmox (is dat al wel geschikt voor zakelijk gebruik?) is (nog) niet ondersteund door Veeam.

[LJAB]

Proxmox heeft een ingebouwd back-up systeem wat dan Veeam zou gaan (kunnen) vervangen..

https://www.proxmox.com/en/proxmox-backup-server/overview

Als je toch nog graag vm`s van Proxmox over wilt migreren naar een hyper-v/vmware in het geval van nood, kan je altijd nog de Veeam Agent gebruiken in de VM zelf.

[HellStorm666]

Thuis gebruik ik dat inderdaad al.
Maar de backup methode haalt t qua kwaliteit, mogelijkheden en robuustheid totaal niet bij Veeam.

[latka]

Ik ken Veaam niet dus ik kan het niet vergelijken. Maar als ik kijk naar de belangrijkste feature lijkt het wel heel erg op veeam (incremental backups, data dedup etc.).

[HellStorm666]

Sterke punten van Veeam.
Verschillende tiers (locaties) qua backup.
Opslag naar immutable storage (S3).
Virus-scan ed voordat je restore.
Restore als duplicate, evt. naar totaal andere hardware.
Los een enkele file terug kunnen zetten.
Automatisch checken of een backup ook te herstellen is.

Bij PBS kan je een losse file wel uit de backup halen. Maar alleen naar je eigen systeem, die dan nog weer naar de VM verplaatst moet worden.
Een restore is ook zonder virusscan.

Al met al is PBS voor thuis prima. Maar voor zakelijk gebruik is het nog niet voldoende.

[Verwijderd]

Wij lijken toch niet veel keuze te hebben.
We gebruiken Veeam voor de backups, echt super software!
Dat is toch echt wel een zelf-opgelegde limitering. Er zijn genoeg backup software opties te krijgen...
Maar gezien de meeste software tegenwoordig SaaS is, moet je je toch af gaan vragen waarom je zelf nog servers draait...

Maar ivm hardware-licentiesleutels, welke ook niet over zo'n USB->LAN adapter werkt, moet de hypervisor usb-passtrough ondersteunen.
Je laat je 'limiteren' doordat je zelf akkoord gaat met ouderwetse software... Met andere woorden, je probeert 'problemen' op te lossen die helemaal niet aan jou zijn om op te lossen. Je moet de leverancier schoppen dat deze eens een moderne oplossing gaat bieden in plaats van zelf pleisters te gaan plakken. Het probleem is dat als je zulke 'oplossingen' blijft ondersteunen, je over 20 jaar nog met dezelfde problemen zit.

[HellStorm666]

In sommige gevallen heb je niet veel keuze qua software.
Wij gebruiken Siemens hardware vanwegen wensen van de klant.
Dus moeten we TIA portal gebruiken.
En die gebruiken hardware sleutels.
En daarvoor heb je een eigen server nodig.

[Frame164]

Het kan wel draaien maar je wilt je software wel verifiëren op een andere hypervisor vervolgens migreren naar een nieuwe stack. Afhankelijk van je IT landscape kan dat een fors project kan dat flink in de papieren lopen waardoor je niet zomaar overstapt. En als je onverhoopt toch nog een applicatie vindt die niet lekker op een andere hypervisor draait zit je met een beetje pech met 2 stacks. Dan moet je wel een heel goed verhaal hebben wil je budget krijgen om te mogen migreren.

[Verwijderd]

En als je onverhoopt toch nog een applicatie vindt die niet lekker op een andere hypervisor draait zit je met een beetje pech met 2 stacks. Dan moet je wel een heel goed verhaal hebben wil je budget krijgen om te mogen migreren.
Het hele idee van virtualisatie is dat je de OS laag afscheid van de hardware (hypervisor). Als je vast zit aan een bepaalde 'stack', dan heb je toch al gefaald in je virtualisatie project....

Verder heb ik nog nooit een groot probleem gezien tussen virtualisatie oplossingen. Zoals aangegeven, virtualisatie maakt het wisselen van 'hardware' juist mogelijk.

Dan moet je wel een heel goed verhaal hebben wil je budget krijgen om te mogen migreren.
Ik denk eerder dat je wel met een heel goed verhaal moet komen om VMware nog te verantwoorden. Ik zou niet weten hoe men die 'business case' kan verantwoorden anders dan 'ik heb geen zin om te migreren'.

[Bor]

Als je vast zit aan een bepaalde 'stack', dan heb je toch al gefaald in je virtualisatie project....

Te kort door de bocht. Niet alle hypervisors ondersteunen officieel dezelfde guest OSsen terwijl deze ondersteuning wel een vereiste kan zijn voor sommige omgevingen en niet in de laatste plaats om beroep te kunnen doen op support waar nodig. Dit hoeft niet mee te spelen maar het kan wel. Een migratie van de ene stack naar een andere is vaak ook geen goedkope operatie trouwens.

[Alfa1970]

Dat hangt er maar helemaal vanaf onder welke tak van Broadcom VMWare komt te vallen.
Een van die takken van Broadcom is namelijk Computer Associates (CA), en dat is hét afvoer putje van IT bedrijven.
Als je onder die tak terecht komt betekend dat op den duur het einde van je bedrijf.
Innovatie nul, en veel (dure en) onbenullige updates waar je voor moet betalen.
CA peurt zo veel mogelijk geld uit een product om het vervolgens een langzame dood te laten sterven.

[MPAnnihilator]

Symantec was ook heel groot en ook overgenomen door Broadcom ( lees : om zeep )

[Mellow Jack]

Voor de markt niet perse negatief.... Ik zie graag wat extra concurrentie

[Bor]

Waar verwacht je dan dat de concurrentie toeneemt wanneer VMware onder een andere eigenaar komt? Ik verwacht to be honest dat er op dat punt maar weinig zal veranderen.

[well0549]

Das niet zo erg, als VMware dan naar wel blijft door draaien

[JeffMetDubbelF]

Java Spring framework is vooral onderhouden door VMware (vroeger Pivotal). Benieuwd wat daar van gaat overblijven.

[SlasZ]

Inderdaad, moest ik ook aan denken. Spring wordt veel gebruikt en na de overname van Pivotal in feite verder gegaan als ervoor. Hoop dat het zo blijft. Kan natuurlijk dat Broadcom hier weinig mee kan of wil doen en het opnieuw in de etalage zet.. heeft ook weinig met VM / netwerken te maken.

[-TAZZ-]

VMware was eerder onderdeel van EMC, toen was het een tijd van Dell, toen een tijdje op eigen benen en toen kwam Broadcom die het mogelijk gaat overnemen. Er zijn dus al vele eigenaren geweest en VMware heeft altijd haar eigen koers kunnen varen. En in de EMC tijd werd HP en alle andere storage net zo goed ondersteund. In de Dell tijd werkte het niks minder op HP, Cisco, [vul je eigen merk in].
Ja, het is een verandering, ja er zal intern best wat veranderen, maar over het grote geheel gezien zal Ver De software tak van Broadcom gaat verder onder de VMware vlag dus zullen er wat dubbele producten zijn waar mogelijk een keuze voor de een of ander wordt gemaakt maar VMware zal haar producten blijven maken, verkopen, en ondersteunen. Daarnaast is met de overname zo enorm veel geld gemoeid ($61 miljard) dat Broadcom het zich ook niet kan veroorloven om er een potje van te maken.
Dus relax, VMware gaat nergens heen.

[jinxter2001]

Ik heb een tijdgeleden mijn home lab esxi ook vervangen door proxmox. Verder geen hele spannende configuratie (pfSense, zabbix, wordpress omgevingen en wat spul wat ik zo nu en dan wil proberen).

Ben er meer dan blij mee, alles wat ik wil kan out-of-the-box. Belangrijkste is misschien wel backups en dus is nu fijn geregeld.

Zou een ieder echt eens aanraden naar proxmox te kijken als je een nieuw home lab opzet.

[GekkePrutser]

Ik gebruik alleen ESXi, het is wel een beetje irritant met hardware support soms (ik heb diverse NUCs en die worden niet geweldig ondersteund). Maar het is fijn omdat ik dan soms een VM thuis kan aanmaken en dan gewoon naar werk pompen.

Op het werk hebben we namelijk een hele vervelende MITM proxy met SSL inspectie ("Zscaler"), daardoor is het soms verrekte lastig om dingen te installeren. Vaak ook nog binnen een docker dus dan moet je daar de SSL certs en proxy instellingen weer in wurmen...

Als ik dan alleen wat uit wil proberen is het simpeler om het gewoon thuis op een echte internet verbinding in elkaar te blaffen in een uurtje en dan overpompen naar werk. Dan 2 dagen uitvogelen hoe ik die verrekte kloteproxy in al die docker containers geconfigureerd krijg. Dat verschilt vaak per produkt ook weer.

Want vaak gaat het alleen maar om open source dingetjes waar we de waarde even van willen inschatten.

[Reactie gewijzigd door GekkePrutser op 22 juli 2024 14:15]

[GekkePrutser]

Huh ik dacht dat het net overgenomen was door Dell??

Ik werkte vroeger veel met een produkt dat weer door VMWare was overgenomen (AirWatch) en dat was er helaas niet echt op vooruit gegaan. Sinds we over zijn op Intune niet echt meer naar omgekeken dus ik heb zo te zien een hoop gemist De laatste keer dat ik op de VMWorld was, was in 2018 (en helaas mag ik dit jaar ook niet want mijn rugzak begint nu echt aan vervanging toe te zijn )

Ik hoop wel dat ze de gratis ESXi in stand gaan houden

[Reactie gewijzigd door GekkePrutser op 22 juli 2024 14:15]