Voor mijn labomgeving wilde ik een geautomatiseerde manier om een NetApp ONTAP Simulator 2-node cluster te deployen op Proxmox VE. Niet één keer handmatig klikken, maar een script dat ik aanroep en dat de rest zelf doet. Wat begon als een relatief eenvoudig idee, bleek een reeks van technische valkuilen te bevatten die me stuk voor stuk dwongen om dieper in zowel Proxmox als ONTAP te duiken.
In deze blog beschrijf ik wat het script doet, welke problemen ik tegenkwam en hoe ik ze heb opgelost. Het script is beschikbaar op GitHub.
Het script deployt volledig automatisch een ONTAP Simulator 2-node cluster op een Proxmox VE cluster. De stappen zijn:
sim-cluster01-01 en sim-cluster01-02Het resultaat: twee ONTAP Simulator nodes, gereed om opgestart en geconfigureerd te worden.
De OVA bevat 4 VMDK-bestanden. Ze worden uitgepakt en geïmporteerd in de volgorde die find ze teruggaf. Dat bleek problematisch: find zonder sortering geeft bestanden terug in bestandssysteemvolgorde, niet in naamvolgorde. Een simpele sort loste dit niet helemaal op, omdat sort de string disk10 voor disk2 plaatst.
De oplossing was sort -V versie sortering, die numerieke delen in bestandsnamen correct afhandelt. Klein detail, groot effect: een verkeerde diskvolgorde leidt tot een onbootbare VM.
Het script draait op een Proxmox node en voert commando’s uit op andere nodes via SSH. Om te bepalen of een commando lokaal of remote uitgevoerd moet worden, vergeleek het script de hostnaam van de doelnode met de lokale hostnaam.
Dit ging mis zodra de opgegeven naam (pve1) niet exact overeenkwam met hoe de machine zichzelf noemde (pve01). Het script stuurde commando’s dan via SSH naar zichzelf, wat met BatchMode=yes niet werkte. Alle hostnaamvergelijkingen zijn daarna genormaliseerd naar lowercase en controleren zowel de korte als de lange hostnaam.
De originele VMID-allocatie controleerde lokaal via qm status of een VMID al in gebruik was. Dat werkt niet in een Proxmox cluster: een VM op pve03 is onzichtbaar voor qm status op pve02.
Het resultaat was een foutmelding halverwege de deployment: VM 104 already exists on node 'pve03'. De fix was clusterbrede VMID-allocatie via pvesh get /cluster/resources, waarmee alle VMIDs in het hele cluster in één aanroep opgehaald worden.
Een Proxmox cluster laat toe dat twee VMs dezelfde naam hebben op verschillende nodes het systeem klaagt er niet over. Maar voor een labomgeving waar je meerdere ONTAP clusters wilt draaien, is dat verwarrend.
Het script controleert nu clusterbreed op VM-namen en hanteert een vast schema: {prefix}-cluster{NN}-01 en -02. Als sim-cluster01-01 en sim-cluster01-02 al bestaan, worden de nieuwe VMs automatisch sim-cluster02-01 en sim-cluster02-02. Het clusternummer wordt opgehoogd totdat beide namen van een paar vrij zijn. Eén bezette naam in een paar telt al als bezet.
Dit was verreweg de complexste uitdaging. Elke ONTAP node heeft een unieke SYS_SERIAL_NUM en SYSID. Als twee nodes dezelfde identity hebben, geeft ONTAP een panic bij het opstarten van het cluster. De OVA bevat altijd dezelfde standaardserials, dus node2 moest een andere identity krijgen.
ONTAP’s bootloader (VLOADER) accepteert setenv commando’s via de serial console. Het plan was om na het opstarten van de VM via expect en socat verbinding te maken met de serial console en de juiste waarden in te stellen.
Dit werkte niet betrouwbaar. VLOADER is slechts enkele seconden beschikbaar voor het venster sluit en ONTAP begint te booten. Tegen de tijd dat expect verbinding maakte, was VLOADER al voorbij.
De volgende aanpak: schrijf de juiste waarden via guestfish direct in het /env/env bestand op de VMDK, voor de import naar Proxmox. Dat bestand is wat VLOADER bij boot inleest.
Dit mislukte ook. De VMDK stond op de remote node (pve01), maar het script draaide op pve02. guestfish had geen toegang tot het bestand op het remote pad.
Pogingen om het script via SSH naar de remote node te sturen, leverden nieuwe problemen op: variabelen die lokaal werden geëxpandeerd, lege strings die aankwamen op de remote node, en een NFS-cache die de verificatie liet slagen terwijl de wijziging er niet in stond.
De doorbraak kwam door het probleem anders te benaderen. In plaats van de VMDK aan te passen voor de import, passen we de geïmporteerde RAW disk aan na de import. Die RAW disk staat gewoon op de datastore van de target node, volledig toegankelijk via guestfish.
Een handmatige test op pve01 bevestigde dat dit werkt:
VMID=101
RAW="/mnt/pve/datastore_ds02/images/${VMID}/vm-${VMID}-disk-0.raw"
guestfish -a "$RAW" -m /dev/sda2 -- upload /tmp/nieuwe_env.conf /env/env
guestfish --ro -a "$RAW" -m /dev/sda2 -- cat /env/env | grep SYS_SERIAL
De nieuwe waarden waren direct zichtbaar. Het script injecteert nu altijd na de import, met guestfish upload op de RAW disk op de target node.
Eén detail dat lang verborgen bleef: het /env/env bestand op de VMDK vfat-partitie gebruikt niet de verwachte KEY=VALUE syntax, maar de VLOADER-specifiekesetenv syntax:
setenv SYS_SERIAL_NUM "4082368-50-7"
setenv bootarg.nvram.sysid "4082368507"
Het script schreef aanvankelijk SYS_SERIAL_NUM=4082368-50-7, correct voor een shell-script, maar niet wat VLOADER leest. ONTAP boote dan met de originele serials uit de OVA. Na het corrigeren van de schrijfsyntax werden de juiste serials opgepikt.
De ONTAP Simulator werkt met twee vaste licentie-serials die voor elk 2-node cluster identiek zijn:
| Node | SYS_SERIAL_NUM | SYSID |
|---|---|---|
| Node 1 | 4082368-50-7 | 4082368507 |
| Node 2 | 4034389-06-2 | 4034389062 |
Dit zijn geen willekeurige getallen; ze zijn gekoppeld aan de Simulator licenties. Elk ONTAP Simulator cluster gebruikt dezelfde twee serials.
Na al deze iteraties is het script stabiel. Een aanroep zonder parameters deployt een volledig geconfigureerde 2-node ONTAP Simulator:
./ontap-sim-2node-proxmox.sh
De output toont precies wat er gebeurt, welke keuzes worden gemaakt en waar het script op wacht. Bij een tweede aanroep krijg je automatisch sim-cluster02-01 en sim-cluster02-02.
Het script is beschikbaar op GitHub: https://github.com/Paul-Visser-StoreLinq/create-ontap-simm-on-proxmox-pve
Automatisering van iets wat handmatig werkt is nooit zo eenvoudig als het lijkt. Elke aanname die je maakt over hostnamen, bestandspaden, variabelen en doorgave via SSH caching kan een valkuil zijn. De aanpak die uiteindelijk werkte was consistent: dingen eerst handmatig testen op de target node, bevestigen dat ze werken, en dan pas het script aanpassen.
Het gebruik van Claude als sparringpartner tijdens dit traject was voor mij nieuw. Niet alleen voor het schrijven van code, maar ook voor het systematisch doorzoeken van oorzaken en het evalueren van alternatieven. Dat heeft dit project aanzienlijk versneld.
Heb je vragen over dit script, of wil je weten hoe je een vergelijkbare labomgeving opzet? Laat het weten en neem direct contact op.