Migreren van VMware ESXi naar Proxmox VE: technische gids om de meest kritieke fouten te voorkomen

Unischerer steeds meer organisaties overwegen de migratie van VMware ESXi naar Proxmox VE, vooral na veranderingen in het licentiebeleid die door Broadcom zijn doorgevoerd. Toch gaat het verplaatsen van virtuele machines tussen beide platforms veel verder dan het converteren van een VMDK-bestand of het importeren van een virtuele machine. Het verschil tussen een doordachte en een onvoorbereide migratie kan resulteren in uren downtime, blauwe schermen, Linux-systemen die niet opstarten, of prestatieverlies dat moeilijk te diagnosticeren is.

De kernpunten van migratie van VMware naar Proxmox VE in 20 seconden

• Een virtuele machine migreren is niet slechts het converteren van disks; het betreft ook het wijzigen van de hypervisor, drivers en input/output architectuur.
• Windows en Linux dienen voorbereid te worden vóór de definitieve uitschakeling in VMware om opstartproblemen te voorkomen.
• Opslag, netwerk en VirtIO-drivers vormen enkele van de meest gevoelige punten tijdens de overgang.
• Het uitvoeren van tests in een labomgeving en het beschikken over geverifieerde back-ups verkleinen het risico in productie aanzienlijk.

Het goede nieuws is dat Proxmox VE een volwassen platform biedt gebaseerd op open technologieën zoals KVM, QEMU, Linux en ZFS. Het minder goede nieuws is dat deze flexibiliteit ook vraagt om inzicht in hoe al deze componenten samenwerken. Deze gids verzamelt de belangrijkste technische aanbevelingen om risico’s tijdens een migratie te minimaliseren.

Migratie gaat niet alleen over het kopiëren van een virtuele schijf

Een veel voorkomende misvatting is dat het voldoende is om een virtuele machine in VMware ESXi uit te schakelen, de VMDK-schijf te converteren en deze te importeren in Proxmox VE.

In werkelijkheid veranderen er tijdens dat proces meerdere essentiële componenten:

• De hypervisor verandert van VMware ESXi naar KVM.
• De virtuele hardware die aan het besturingssysteem wordt gepresenteerd, wijzigt.
• Opslag- en netwerkdrivers worden aangepast.
• Het opslagbeheer wordt aangepast.
• Snapshot- en back-up mechanismen veranderen.

Als het gastbesturingssysteem niet voorbereid is op die veranderingen, kunnen er meteen startfouten optreden na de migratie.

Bij Windows-systemen komt het vaak voor dat de bekende INACCESSIBLE_BOOT_DEVICE (0x0000007B)-fout optreedt wanneer het systeem probeert op te starten met een niet-meer-bestaande driver.

Bij Linux-distributies gebaseerd op Red Hat, Rocky Linux, AlmaLinux of Suse, is een veelvoorkomend symptoom dat het systeem in de herstelconsole van dracut eindigt, omdat de initramfs niet de benodigde modules bevat om toegang te krijgen tot de nieuwe schijf.

Windows voorbereiden vóór het uitschakelen van de VM

Een goede praktijk is om het besturingssysteem voor te bereiden terwijl het nog draait op VMware.

Veelvoorkomende controles zijn onder andere:

In veel migraties wordt ook het viostor-service geconfigureerd om automatisch te starten door het Windows-register aan te passen.

Linux moet initramfs reconstrueren

Bij Linux-systemen ligt het probleem vaak in de initramfs.

Voor de definitieve uitschakeling is het verstandig om deze opnieuw te genereren, inclusief de VirtIO-modules die door KVM worden gebruikt.

In op Red Hat gebaseerde distributies kan een vergelijkbaar commando gebruikt worden:

dracut --add-drivers "virtio_blk virtio_scsi virtio_net virtio_pci" --force

Daarna is het aan te raden om te controleren:

• Of VirtIO-modules aanwezig zijn
• Het verwijderen van VMware-specifieke componenten wanneer ze niet meer nodig zijn
• De installatie van qemu-guest-agent

Niet alle distributies gebruiken dezelfde tools. Debian, Ubuntu en Suse hebben verschillende procedures. Het is altijd verstandig om de officiële documentatie te raadplegen.

Opslag is eigenlijk veel belangrijker dan je denkt

De conversie van de schijf gebeurt meestal met tools zoals:

qemu-img convert -f vmdk -O raw origine.vmdk bestemming.raw

Maar daarmee is het werk nog niet gedaan.

De uiteindelijke prestaties hangen af van de gebruikte backend in Proxmox VE.

Indien ZFS wordt gebruikt

Het is belangrijk om parameters zoals te bekijken:

• volblocksize
• ashift
• compressie
• ARC

Bijvoorbeeld bij databases kan een onjuiste volblocksize de zogenaamde Write Amplification verhogen, wat de prestaties negatief beïnvloedt.

Ook op servers met veel geheugen is het gebruikelijk de ARC-geheugenlimiet te beperken via zfs_arc_max, om te voorkomen dat het concurreren met virtuele machines om resources.

Indien Ceph wordt gebruikt

In omgevingen met Ceph RBD wordt vaak aangeraden de ondersteuning voor TRIM en discard te gebruiken, om ruimte vrij te maken.

Veelvoorkomende opties zijn:

• discard=on
• issue_discards=1

Deze instellingen hangen af van het type opslag en de gebruikte versies.

Het virtuele netwerk verandert ook

Een vaak onderschat punt is het netwerk.

In VMware wordt vaak gebruik gemaakt van:

• vSwitch (Standard)
• VMware Distributed Switch (vDS)
• Port Groups
• VLAN Trunk

In Proxmox VE zijn onder andere gangbare oplossingen:

• Linux Bridge
• Open vSwitch (optioneel)
• Proxmox SDN
• VXLAN
• EVPN

Het is niet voldoende om alleen de configuratie visueel te herhalen.

Ook moeten controlepunten zoals:

• MTU
• VLAN tagging
• Bonding
• LACP
• Jumbo Frames

Een kleine mismatch, zoals tussen MTU 9000 en 1500, kan leiden tot intermitterende verliezen die moeilijk te traceren zijn.

Back-ups niet vergeten

Een andere belangrijke verandering betreft de gegevensbescherming.

In VMware gebruiken veel organisaties VMware VADP met oplossingen van derden.

In Proxmox VE verloopt de integratie volledig anders en wordt vaak vertrouwt op Proxmox Backup Server (PBS), die onder andere biedt:

• Incrementale back-ups via QEMU’s Dirty Bitmaps
• Deduplicatie op blokniveau
• Compressie
• Encryptie
• Automatische controle van back-ups

Het is aanbevolen om vóór de migratie te controleren of de back-upstrategie nog steeds aan dezelfde recovery-vereisten (RPO en RTO) voldoet.

Checklist vóór de migratie

Voor het plannen van een onderhoudswindow is het verstandig om minimaal het volgende te controleren:

Migratie betekent ook verandering in beheer

Een veelgemaakte fout is te denken dat het verlaten van VMware alleen lagere licentiekosten betekent.

In werkelijkheid vertaalt dat besparingspotentieel zich vaak ook in de kennis die nodig is om een open platform te beheren.

Goed beheer van Proxmox VE vereist kennis van technologieën zoals:

• Linux
• QEMU/KVM
• ZFS
• Ceph
• Linux netwerkbeheer
• Automatisering
• High availability (HA)

Voor veel organisaties is dit juist een voordeel doordat het afhankelijkheid van propriëtaire software vermindert. Aan de andere kant vereist het personeel met ervaring of het inschakelen van gespecialiseerde consultants tijdens de overgang.

Veelgestelde vragen

Is het alleen converteren van een VMDK voldoende voor een migratie?

Nee. Behalve de virtuele schijf moeten ook controllers, systeemconfiguraties, netwerk, opslag en beheertools worden gecontroleerd en aangepast.

Moeten alle Windows-systemen VirtIO-drivers installeren?

In de meeste gevallen wel. Ze vooraf voorbereiden vermindert de kans op opstartfouten gerelateerd aan schijftoegang aanzienlijk.

Wat gebeurt er als Linux de VirtIO-modules niet in initramfs bevat?

Het systeem detecteert mogelijk de opslag niet bij opstarten en komt in een herstelomgeving of emergency mode terecht, afhankelijk van de distributie.

Biedt Proxmox VE back-up tools die vergelijkbaar zijn met die van VMware?

Ja. Proxmox Backup Server biedt incrementele back-ups, deduplicatie, encryptie en integriteitscontrole, hoewel het onderliggende model anders is dan VMware’s ecosysteem.

Belangrijk bericht

Deze gids is uitsluitend technisch en informatief. Iedere infrastructuur heeft eigen kenmerken met betrekking tot hardware, VMware ESXi- en Proxmox VE-versies, het gastbesturingssysteem, opslag en toepassingen.

De genoemde configuraties, commando’s en parameters zijn voorbeelden en moeten niet als universeel geldig worden beschouwd. Voor elke productie-migratie is het essentieel om de procedures in een testomgeving te valideren, geverifieerde back-ups te hebben en de officiële documentatie van VMware, Proxmox, QEMU, Microsoft, Red Hat, SUSE, Debian, Ubuntu, ZFS, Ceph en andere betrokken fabrikanten te raadplegen.

Parameterafstellingen zoals volblocksize, zfs_arc_max, discard, issue_discards of VirtIO-drivers moeten worden aangepast aan de workload, opslagarchitectuur en aanbevelingen van elke platform. Het uitvoeren van de beschreven procedures en de gevolgen ervan zijn volledig voor rekening van de beheerder of organisatie die het uitvoert.