vSphere naar Proxmox: wat er echt meeverhuist

Elke migratiegids over weggaan bij VMware begint bij de schijf, omdat de schijf het onderdeel is waar een bestand van bestaat. Zet de VMDK om, importeer hem, start hem op, klaar.

De schijf is het makkelijke deel. Wat een vSphere-machine laat werken zit op vier andere plekken, en geen daarvan zit in de VMDK: hoe het platform de machine identificeert, hoe de gast bij de eerste start ingericht wordt, van welke virtuele hardware de gast stuurprogramma's heeft, en welke agent binnen de gast de vragen erover beantwoordt. Elk daarvan is op Proxmox een ander probleem, en maar één ervan meldt zich als het misgaat.

Dit is wat wij vonden bij het bouwen van lees- en schrijfpaden tegen allebei, gemeten tegen vCenter 6.7.0 build-24323669.

De schijf, en de ene aanroep die er niet is

Er zijn twee vormen van virtuele schijf in het spel. Een draaiende vSphere-VM heeft een platte VMDK plus een kleine descriptor. Een OVA of een gedownload cloudimage heeft een stream-optimized VMDK: gecomprimeerd, sequentieel en zo niet opstartbaar.

Het voor de hand liggende conversiepad is CopyVirtualDisk_Task met een bestemmingsspec die het doelformaat noemt. Die aanroep bestaat op een losse ESXi-host en bestaat niet op vCenter: hij antwoordt "The requested operation is not implemented by the server". Het is een goed voorbeeld van een bredere valkuil in deze API, waar dezelfde operatie op het ene beheerniveau wel bestaat en op het andere niet.

Twee dingen werken wél, en die zijn in deze volgorde het kennen waard:

• CopyVirtualDisk_Task zónder bestemmingsspec werkt op vCenter 6.7 en kopieert een schijf met behoud van zijn type. Op deze vCenter eist hij het argument datacenter; de vorm met alleen een datastorepad wordt geweigerd.
• Het OVF-importpad (CreateImportSpec → ImportVApp → HttpNfcLease → HTTP POST → HttpNfcLeaseComplete) accepteert een stream-optimized schijf en zet hem onderweg om. Het heeft alleen de .ovf-descriptor nodig, niet de hele OVA: een OVA is een tar-archief met de descriptor vooraan, op te halen met één range-verzoek van 128 kB.

Aan de Proxmox-kant is qm disk import het equivalent, die een VMDK aanneemt en hem in het eigen formaat van de doelopslag wegschrijft. Dat deel is werkelijk rechttoe rechtaan.

Provisioning is aan de twee kanten anders gemodelleerd. vSphere heeft twee vlaggen, thinProvisioned en eagerlyScrub, en die vormen geen keuze uit drie: thin sluit eager uit, dus de geldige toestanden zijn thin, thick lazy zeroed en thick eager zeroed. Alles wat dit als één opsomming met vier waarden modelleert, stuurt vroeg of laat een onmogelijke combinatie.

Identiteit: het ID dat je hebt is geen identiteit

Deze bijt maanden later, niet op de dag van de migratie.

Een vSphere-object wordt geadresseerd met een managed object reference, iets als vm-101. Dat ziet eruit als een ID en is het niet: het is een sleutel in de database van díe ene vCenter. Bouw die database opnieuw op of zet hem terug, dan volgt de verwijzing de machine niet, en wordt hij opnieuw uitgedeeld aan een andere VM. Wat je een halfjaar geleden opsloeg wijst nu naar de machine van iemand anders, en de operatie die je op het punt stond uit te voeren is een power-off.

De duurzame identifier is config.instanceUuid. Sla die op, en los de verwijzing per operatie op via FindByUuid.

Proxmox heeft de tegenovergestelde vorm. Een VM is een vmid: stabiel, leesbaar voor mensen, zichtbaar in elk commando, uniek per cluster. Daar werkt het prettiger mee, en het heeft zijn eigen gevolg voor een migratie. Je kiest nieuwe identiteiten, dus elk extern systeem dat naar een machine verwees met haar vSphere-identifier moet opnieuw gericht worden.

Het locatiemodel verschilt ook. Met DRS aan verandert de host waarop een VM draait zonder dat iemand het vraagt, dus een kloon krijgt een resource pool mee en vSphere kiest. Op Proxmox is de node de eenheid, en verplaatsen tussen nodes is expliciet. Een inventaris die "welke host" vastlegde voor een DRS-cluster, legde iets vast dat vanzelf verandert.

Gastinrichting is een ander mechanisme

Allebei de platformen kunnen een gast bij de eerste start inrichten. Ze doen dat op manieren die geen regel code delen.

Op vSphere is de route die werkt zonder van de gast af te hangen guestinfo: vier sleutels in extraConfig, gelezen door de VMware-databron van cloud-init.

De .encoding-sleutels zijn niet optioneel. Laat je ze weg, dan leest cloud-init de base64-tekst als de inhoud zelf, en komt de machine op met een hostnaam van veertig tekens onzin. Geen fout, gewoon een verkeerd antwoord.

Het alternatief, VMware's eigen CustomizeVM_Task, heeft VMware Tools in de gast nodig en op oudere Linux-sjablonen een werkende perl, en dat is het soort eis dat je ontdekt als een provisioningrun halverwege blijft hangen.

Op Proxmox is de inrichting een cloud-init-schijf die aan de VM hangt, ingesteld met een kleine set sleutels: ipconfig0 tot en met ipconfig3, nameserver, searchdomain, ciuser, cipassword, sshkeys, citype, ciupgrade.

Eén daarvan heeft een valkuil die onzichtbaar blijft tot een klant klaagt. ciupgrade heeft default = 1 in het Proxmox-schema, dus hem weglaten betekent niet "geen pakketten bijwerken bij de eerste start"; het betekent "bijwerken". Een uitgevinkt vakje moet als een expliciete ciupgrade=0 verstuurd worden, anders liegt dat vakje. Hij bestaat bovendien niet vóór PVE 8.1, waar hem meesturen een harde fout is in plaats van een genegeerde sleutel.

Twee andere dingen gaan aan beide kanten op dezelfde manier mis. Het instance-ID moet veranderen zodra een machine een nieuwe identiteit krijgt: de iid-local01 uit de meeste voorbeelden betekent dat een gekloonde machine de configuratie van het sjabloon houdt. En de interface heeft niet de naam die je verwacht: ens160 op VMware, iets anders op KVM. Netplan met match: {name: "e*"} in plaats van een gegokte apparaatnaam is wat één image op allebei laat werken.

Virtuele hardware waar drivers voor zijn

vmxnet3 is op VMware de verstandige standaard voor een netwerkkaart, en die heeft een voorwaarde: hij heeft VMware Tools in de gast nodig. Installeer een sjabloon zonder Tools, geef hem een vmxnet3-kaart, en het besturingssysteem ziet helemaal geen netwerkkaart.

Dat doet er twee keer toe. Ervóór, omdat een sjabloon dat op ESXi prima opstart in plaats daarvan e1000e nodig kan hebben. En erná, omdat de snelle keuze van Proxmox virtio is, wat zijn eigen stuurprogramma's nodig heeft: aanwezig in modern Linux, absoluut niet in een kale Windows-image. e1000 is op beide platformen de trage, saaie, overal werkende optie, en dat is de juiste eerste start voor een machine die je aan het verhuizen bent.

De schijfcontroller heeft dezelfde soort probleem: op Proxmox is virtio-scsi het snelle pad, en dat is opnieuw een stuurprogrammavraag. Wij hebben niet gemeten wat het wisselen van controllertype doet met een al geïnstalleerde gast, en het is een veelvoorkomende oorzaak van een machine die netjes migreert en daarna niet opstart.

De agent in de gast verandert van naam

Een verrassend groot deel van wat een paneel toont, komt helemaal niet van de hypervisor.

Op vSphere komt guest.ipAddress van VMware Tools. Het echte schijfgebruik ook, via guest.disk: de summary.storage.committed op datastoreniveau is het provisioningcijfer en leest verkeerd bij een thin schijf. Draaien Tools niet, dan zijn die velden leeg, en leeg betekent "ik weet het niet", nooit "de machine heeft geen adres".

Na de verhuizing komt diezelfde informatie van qemu-guest-agent, een ander pakket met een andere naam, dat geïnstalleerd moet worden. Een vloot die zonder dat migreert, ziet er in je eigen inventaris uit als een vloot die zijn adressen kwijt is.

Nog één waarschuwing bij dat adres: het komt binnen over het eigen kanaal van de hypervisor naar de gast, niet over het netwerk. Het kan volkomen kloppen voor een machine waarvan de kaart nergens aan hangt. Het enige dat bereikbaarheid bewijst, is hem bereiken.

Netwerk, en de verbinding die er stilletjes geen is

vSphere heeft twee soorten netwerkbacking en die lijken niet op elkaar. Naar een standaard Network wordt verwezen met een naam; naar een DistributedVirtualPortgroup met de UUID van zijn switch plus zijn eigen portgroepsleutel.

Bouw alleen de eerste vorm en je krijgt, in elke omgeving met een distributed switch, een kaart die nergens aan hangt. vCenter weigert hem niet, want de naam bestaat wel degelijk als netwerkobject. De machine start op zonder verbinding en de fout zit binnen in de gast.

Proxmox is eenvoudiger: een NIC noemt een bridge, met een optionele VLAN-tag. De koppeling schrijf je zelf; er is geen automatische vertaling van een portgroep naar een bridge. Nog twee dingen om te beslissen vóór de eerste verhuizing:

• MAC-adressen. Ze meenemen houdt DHCP-reserveringen en licentiebindingen geldig, en betekent dat twee machines een MAC-adres delen als het origineel ooit weer aangezet wordt. Kies bewust.
• De firewall per VM. vSphere heeft die niet; dat is NSX, een apart product. Proxmox heeft hem wel. Machines die van VMware komen hebben nooit een firewall op hypervisorniveau gehad, en er een aanzetten is een project en geen vinkje.

Wat niet meereist, en in geen enkel bestand staat

Sommige dingen hebben geen tegenhanger, en een plan dat ze niet benoemt ontdekt ze één voor één:

• Snapshots. De machine gaat over als een platte schijf; een snapshotboom is een vSphere-structuur waar niets voor is om hem in te importeren.
• Changed block tracking, en daarmee elke incrementele backuphistorie die daarvan afhing.
• Tags, eigen attributen en mappen. Die leven in de database van vCenter, niet op de machine.
• Resource pools, DRS-regels, reserveringen en shares. Proxmox heeft geen vergelijkbare planner, dus een plaatsingsbeleid dat als DRS-regels geschreven is, wordt een reeks beslissingen over op welke node een machine staat.
• De hardwareversie van de VM. Een vSphere-begrip zonder Proxmox-tegenhanger, dus alles wat daarop gesleuteld is in je automatisering is nu dode code.

Wat ons eigen gereedschap wel en niet doet

Om duidelijk te zijn: wij hebben geen migratie van vSphere naar Proxmox gebouwd. Ons migratiegereedschap dekt vandaag precies één route, tussen twee gamepanelen, en die zit achter een schakelaar die uitstaat.

Twee regels uit het bouwen van die ene route zijn het jatten toch waard, want ze maken van een migratie iets toetsbaars in plaats van iets hoopvols. De bron is alleen-lezen, als constante en niet als vlag, dus er bestaat geen configuratie waarin het gereedschap schrijft naar het systeem dat je verlaat. En een dry run is verplicht vóór een echte uitvoering, met achteraf een telling per categorie, bron tegen bestemming. Een migratie die je niet kan vertellen hoeveel machines ze verplaatst heeft, is niet klaar; die is opgehouden.

Dit kwam voort uit het bouwen van de vSphere- en Proxmox-integraties voor Provibr, een server-managementpaneel voor hostingproviders, waar beide hypervisors via één interface leesbaar moeten zijn zonder dat de een als de ander beschreven wordt. De installatienotities staan in de vSphere- en Proxmox-documentatie.