Azure Local op Proxmox: wat het kostte

1. Waarom Proxmox, en waarom dit een lab is

Het lab bestaat om ons eigen gereedschap te testen. De scripts achter ClusterDown.com en onze cluster assessments hebben echte clusters nodig die zich misdragen. Eerst draaide het genest op Windows Server 2025 Hyper-V, op een gehuurde dedicated server van Hetzner in Helsinki (Intel Core i9-13900, 128 GB). Dat werkte, maar de host veroorzaakte zelf de meeste storingen, en het cluster dat we met de hand hadden gebouwd, stond in Azure geregistreerd zonder de Azure Local-stack erachter.

Opnieuw bouwen op Hyper-V kon ook. We kozen om drie redenen voor Proxmox:

• Om te zien hoe goed het werkt. Ik wilde weten hoe een virtueel Azure Local-cluster standhoudt op een platform waarvoor Microsoft het niet heeft ontworpen, en breder: hoe goed Windows-workloads vandaag op Proxmox worden ondersteund.
• Klanten vragen ernaar. Veel organisaties die VMware verlaten, evalueren Proxmox. Als een klant vraagt of zijn Windows- en Hyper-V-kennis meegaat, willen we antwoorden vanuit eigen metingen.
• Een voorspelbaardere host. Een Linux-host met een kleine voetafdruk, ZFS-snapshots en -clones waarmee je een node in minuten opnieuw opbouwt, en geen Windows-rollen of maandelijkse hostupdates die het lab kunnen platleggen.

We wisten de server, installeerden Proxmox VE 9.2 op Debian 13, en rolden Azure Local 2609 vanuit Azure uit op twee geneste nodes.

Het Hyper-V-lab had vier nodes; dit heeft er twee. De reden is geheugen. Het handgebouwde Hyper-V-cluster draaide vier kleine nodes. Een echte Azure Local-uitrol vraagt minimaal 24 GB per virtuele node (wij kwamen uit op 32 GB), en één node draagt ook nog de Arc Resource Bridge-VM met 8 GB. Op een host met 128 GB die ook een domain controller, een beheerserver en andere workloads draait, passen vier van die nodes niet. We begonnen met drie en gingen naar twee. Een cluster met twee nodes is een ondersteunde Azure Local-configuratie; het heeft een witness nodig, dus gebruikten we een cloud witness in Azure.

Dit is een lab, geen aanbeveling. Microsoft ondersteunt een geneste Azure Local voor evaluatie op Hyper-V en op virtuele machines in Azure, niet op KVM. Voor Microsoft-workloads in productie blijft Hyper-V mijn hypervisor.

Het bouwen, het afbreken en het meeste zoekwerk deden Claude-agents die de opdrachten uitvoerden, terwijl ik de beslissingen nam. Doordat we een cluster in een paar uur vanaf nul konden opbouwen, konden we elke oplossing in dit artikel op een verse installatie testen.

2. Lees de omgevingscontrole in plaats van te gokken

De omgevingscontrole van Azure Local draait op de nodes en is gewone PowerShell. Faalde een controle, dan openden we de module van de controle zelf op de node en lazen wat er getest wordt. Dat bleek sneller dan welke zoekopdracht ook, om twee redenen:

• De controles zijn letterlijk. De meeste vergelijken één eigenschap met één waarde.
• De functies van de controle kun je direct op een node aanroepen. Dat geeft binnen seconden een antwoord, waar een volledige validatie vanuit Azure 30 tot 60 minuten duurt.

Hetzelfde geldt voor opslag. Test-Cluster draait lokaal in ongeveer zes seconden en laat zien of de schijven door de controle komen:

Test-Cluster -Node $env:COMPUTERNAME -Include 'Storage Spaces Direct'

3. Een KVM-gast die zich meldt als Hyper-V-VM

De eerste validatie faalde op alle nodes, op vier hardwarecontroles.

Virtueel of fysiek. De controle beslist dat met één vergelijking: Win32_ComputerSystem.Model -eq "Virtual Machine". Dat is wat Hyper-V meldt. Een QEMU-gast meldt "Standard PC (Q35 + ICH9, 2009)" en wordt beoordeeld als fysieke hardware, met de fysieke minima (32 GB geheugen in plaats van 24 GB). De instelling smbios1 van Proxmox lost het op: fabrikant "Microsoft Corporation", product "Virtual Machine".

ECC-geheugen. De controle telt geheugen als ECC als TotalWidth groter is dan DataWidth in de SMBIOS-tabel van de geheugenmodules (type 17). QEMU laat beide velden leeg. Wij geven QEMU met -smbios file= een eigen type 17-tabel van 60 bytes, met een totale breedte van 72 bits en een databreedte van 64. Vanaf 32 GB is het grootteveld in die tabel te klein en komt de geheugengrootte in het veld voor de uitgebreide grootte.

Leeftijd van het TPM-certificaat. De controle eist dat het endorsement-certificaat van de TPM minstens één dag oud is. Een virtuele TPM maakt dat certificaat aan als de VM wordt aangemaakt. Maak de nodes dus de dag vóór de validatie aan. Bouw je een node later opnieuw op, bewaar dan zijn TPM-schijf: het certificaat houdt dan zijn oorspronkelijke datum.

Gekoppelde media. Proxmox kan een SATA-cd-station niet tijdens bedrijf ontkoppelen, dus de installatiemedia tellen als gekoppeld tot de volgende volledige stop en start. Verwijder de stations en zet de VM daarna uit en weer aan.

Nog één uit de onbewaakte installatie. Onder UEFI wacht het installatieprogramma op "press any key to boot from CD", dus sturen we via de hypervisor de eerste seconden Enter. Toen we dat 20 seconden deden, kwam één Enter op de knop Cancel van het installatieprogramma terecht en stopte de installatie op 6% met "Are you sure you want to quit?". Acht seconden is genoeg.

4. De netwerkkaart moet 802.3 melden

De controle eist dat elke clusternetwerkkaart als fysiek medium 802.3 meldt, waarde 14. De virtio-kaart met de NetKVM-driver van Red Hat, de standaardkeuze op KVM, meldt 0 (niet gespecificeerd). Dat is bewust: een geëmuleerde kaart is geen fysiek Ethernet, en Microsoft documenteert 0 als de waarde voor geëmuleerde apparaten.

Eerste uitrol: vmxnet3. QEMU kan ook vmxnet3 van VMware emuleren. Azure Local heeft daar een ingebouwde driver voor die 14 meldt, en onze eerste uitrol draaide op vmxnet3. Het nadeel is dat een geëmuleerde kaart zich dan als fysieke hardware voordoet.

Tweede uitrol: virtio. NetKVM leest een instelling *PhysicalMediaType, dus zetten we die eerst in het register op 14. Na een herstart van de kaart, een herstart van de node en een koude start stond er in het register nog steeds 14 en meldde de kaart nog steeds 0. Windows gebruikt de waarde die de INF van het driverpakket installeert; die achteraf wijzigen heeft geen effect.

Wat wel werkt, is een extension-INF: een apart driverpakket zonder code dat die ene waarde instelt bovenop het ongewijzigde NetKVM-pakket van Red Hat. Windows past het toe na de basisdriver, en opnieuw na elke update van de basisdriver. We ondertekenen de catalogus met een eigen certificaat en zetten dat certificaat in de vertrouwde certificaatarchieven van de node, zodat het installeert met Secure Boot aan en zonder testmodus. Alle vier de kaarten op beide nodes meldden 802.3, en de tweede uitrol draaide volledig op virtio.

We gebruiken deze override alleen op onze eigen labnodes, en we hebben de makers van NetKVM niet gevraagd hun standaard te wijzigen. Voor een geëmuleerde kaart is 0 de juiste waarde.

5. VLAN-ID, schijfidentiteit en de klok

Elk van deze drie kostte een volledige validatieronde voordat we het vonden.

De eigenschap VLAN-ID moet een waarde hebben. De controle leest de kaarteigenschap VlanId en faalt als die geen waarde heeft. Op de opslagkaarten moet hij precies 0 zijn. Zowel vmxnet3 als NetKVM tonen de eigenschap zonder waarde. Stel hem op elke kaart in:

Set-NetAdapterAdvancedProperty -Name Storage1 -RegistryKeyword VlanId -RegistryValue 0

Elke schijf heeft een WWN nodig. Test-Cluster faalde op elke schijf met "Failed to get SCSI page 83h VPD descriptors". QEMU bouwt die identiteit uit de interne naam van de schijf (drive-scsi1), en die is op elke node hetzelfde. Failover Clustering heeft een unieke identiteit nodig. Een serienummer is niet genoeg; geef elke virtuele schijf een eigen wwn=-waarde, uniek in het hele lab.

De hardwareklok moet in dezelfde tijdzone staan als de gast. Na een herstart viel een node uit Azure Arc, met een klok die twee uur voorliep. Windows leest de hardwareklok als lokale tijd in zijn eigen tijdzone. Proxmox geeft Windows-gasten daarom standaard een hardwareklok in de lokale tijd van de host, en dat klopt zolang host en gast dezelfde tijdzone gebruiken. Bij ons niet: de host draait op Midden-Europese tijd, de Azure Local-nodes draaien in UTC. Elke node las een Midden-Europese klok als UTC en startte twee uur te vroeg. Zet voor gasten die in UTC draaien de hardwareklok per gast op UTC, gevolgd door een volledige stop en start:

qm set <vmid> --localtime 0

6. Een validatie die maar één keer slaagt

Dit probleem heeft niets met Proxmox te maken.

Onze vierde validatie slaagde. Elke validatie daarna bleef hangen, terwijl Azure een uur lang "provisioning" toonde en de node al lang succes had gemeld. De uitrolengine onthoudt welke stappen geslaagd zijn en slaat die bij de volgende ronde over. Op een volledig geslaagde staat is de hele validatie in ongeveer een seconde klaar. De stap die hem startte, kijkt elke tien seconden of de validatie bezig is, ziet die toestand nooit, en wacht op zijn eigen time-out van zestig minuten.

Wat we nu doen:

• Alles oplossen vóór de eerste validatie, met de eigen functies van de controle op een node.
• Na een geslaagde validatie de uitrol starten. Niet nog een keer valideren.
• Opnieuw beginnen vanuit een schone staat: de Azure-resources verwijderen, controleren of de naam van de Key Vault weer vrij is, en de OS-schijven van de nodes opnieuw opbouwen.

Het uitrolsjabloon van Microsoft beschrijft de volgorde zelf in de tekst van een parameter: "First must pass Validate prior running Deploy".

7. Uitroltijden en de grootte van de nodes

De eerste volledige ronde kostte vanaf een schone start 6 uur en 24 minuten. Daar zit in:

• opruimen en de nodes opnieuw opbouwen, ongeveer 25 minuten machinetijd;
• de Arc-registratie;
• een validatie van ongeveer een uur;
• een uitrol van 4 uur;
• ongeveer een half uur wachten op een interactieve aanmelding.

De langste losse stap was de Arc Resource Bridge, met 1 uur en 45 minuten. De tweede uitrol, op virtio, kostte alleen al voor de uitrol 6 uur en 17 minuten. Het hele verschil zat in diezelfde stap van de Arc Resource Bridge. De oorzaak hebben we niet gevonden.

Het cluster draait, maar met weinig ruimte:

• De nodes zijn klein. Elke node heeft vier virtuele processors, vastgezet op de E-cores van de host, omdat de snellere P-cores zijn gereserveerd voor CI-runners.
• Eén node draagt de Arc Resource Bridge. Die VM heeft zelf vier virtuele processors, in een node die er vier heeft. Dat geeft drie lagen virtualisatie.

Toen we maten, gebruikte die node al zijn processors. Genoeg om het cluster te draaien en niet veel meer. Een live geheugendump bevroor de node lang genoeg om door het cluster te worden verwijderd; dat beschreven we in Eén incident, twee rapporten.

Bij een herbouw zouden we elke node minstens acht virtuele processors geven en de nodes van de traagste cores afhouden. Dat is onze verwachting; we hebben het niet gemeten.

8. Microsoft-workloads op Proxmox: wat je wint en wat je opgeeft

Ik zou Proxmox niet aanraden als standaardplatform voor Microsoft-workloads. In bepaalde situaties is het een redelijke keuze, mits je weet wat je opgeeft.

Wat je wint

• Een gratis hypervisor. Proxmox VE is open source en gratis te gebruiken. Een optioneel abonnement, geprijsd per socket, geeft toegang tot de stabiele updatebron en tot ondersteuning van de leverancier. Vergeleken met de VMware-licenties die veel organisaties willen verlaten, is dat een groot verschil.
• Een voorspelbare host. Een Linux-host met een kleine voetafdruk, zonder Windows-rollen of maandelijkse hostupdates die het platform kunnen platleggen.
• Snel herbouwen. Met ZFS-snapshots, -clones en -templates is het opnieuw opbouwen van een node een kwestie van minuten.
• Volwassen Windows-ondersteuning. De virtio-drivers, UEFI met Secure Boot, een virtuele TPM en de gastagent werken allemaal, en gangbare backupproducten zoals Veeam ondersteunen Proxmox.

Wat je opgeeft

• De ondersteuningsverklaring van Microsoft. Microsoft ondersteunt Windows Server-gasten op hypervisors die door het Server Virtualization Validation Program (SVVP) zijn gekomen. Voor zover ik weet, staat Proxmox VE niet op die lijst. Microsoft helpt meestal toch, maar kan vragen een probleem na te bootsen op een ondersteund platform. Controleer de actuele SVVP-lijst voordat je erop bouwt.
• Ondersteuning van applicaties. SQL Server, Exchange en veel bedrijfsapplicaties verwijzen naar dezelfde lijst. Controleer dat per leverancier.
• Functies van het Microsoft-platform. Azure Local zelf, Windows Server Azure Edition met hotpatching, gratis Extended Security Updates op Azure Local, Hyper-V Replica, System Center Virtual Machine Manager en Shielded VMs bestaan alleen, of werken het best, op Hyper-V, Azure Local of Azure.
• Bestaande kennis en hulpmiddelen. Ervaring met Hyper-V en Failover Clustering gaat niet één op één mee. Clustering, opslag en netwerken werken op Proxmox anders.
• Standaardinstellingen die niet bij Windows passen. Wij liepen tegen een hardwareklok in lokale tijd aan, een netwerkkaart die "niet gespecificeerd" meldt, en een QEMU-gastagent die onder belasting niet meer reageerde.

Wat een gratis hypervisor niet verandert

Een gratis hypervisor maakt Windows niet gratis. Windows Server wordt gelicenseerd per fysieke core van de host, ongeacht de hypervisor, en Datacenter blijft de editie waarmee je een onbeperkt aantal Windows-VM's op een host licenseert. Hyper-V zit zonder meerprijs in Windows Server. De gratis losse Hyper-V Server stopte met versie 2019. De besparing is dus groot ten opzichte van VMware en klein ten opzichte van Hyper-V.

Ons advies

• Vooral Microsoft-workloads: blijf op Hyper-V of Azure Local. Ondersteuning, hulpmiddelen en de kennis van je team passen, en ook daar kost de hypervisor niets extra.
• Vooral Linux, met een beperkt aantal standaard Windows Server-VM's (domain controllers, bestandsservers, eenvoudige applicatieservers): Proxmox is te verdedigen. Controleer vóór je besluit de SVVP-status, de ondersteuning per applicatie, en een volledige backup- en hersteltest.
• Labs, test en training: Proxmox past goed. Daar gebruiken wij het voor.

We hebben de prestaties van Proxmox en Hyper-V niet op dezelfde hardware vergeleken. Dit advies gaat over ondersteuning, functies en beheer, niet over snelheid.

9. Checklist

1. Zet in SMBIOS de fabrikant op "Microsoft Corporation" en het model op "Virtual Machine".
2. Geef een SMBIOS type 17-tabel mee met een totale breedte groter dan de databreedte (ECC), en gebruik vanaf 32 GB het veld voor de uitgebreide grootte.
3. Maak de nodes minstens een dag vóór de eerste validatie aan. Bewaar de TPM-schijf als je een node opnieuw opbouwt.
4. Verwijder alle installatiemedia en doe een volledige stop en start.
5. Netwerkkaarten: vmxnet3, of virtio met een extension-INF die *PhysicalMediaType op 14 zet.
6. Zet VlanId op elke kaart op 0.
7. Geef elke virtuele schijf een unieke WWN.
8. Zet localtime 0 op Windows-gasten die in UTC draaien.
9. Draai de eigen functies van de controle en Test-Cluster op een node vóór de eerste validatie vanuit Azure.
10. Valideer één keer en rol dan uit. Valideer een geslaagde staat niet opnieuw.
11. Maak de nodes groot genoeg voor de Arc Resource Bridge. Vier virtuele processors per node bleek te krap.
12. Stuur bij onbewaakte installaties maar een paar seconden Enter.