Twee standaardinstellingen van Proxmox VE 9 die je misschien mist: Hyper-V-enlightenments en CPU-microcode

Twee instellingen die je ooit koos en vergat

Proxmox VE 9 doet twee nuttige dingen voor je zonder dat je erom vraagt. Het geeft een gast met het Fisher-Price OS (Windows) de paravirtuele functies die hij nodig heeft om fatsoenlijk op KVM te draaien, en het laadt bij het opstarten actuele CPU-microcode.

Beide gaan automatisch. Beide hangen ook af van een beslissing die je één keer nam, misschien jaren geleden, en waar je sindsdien niet meer naar hebt gekeken.

De eerste hangt af van het OS Type dat je koos toen de VM werd aangemaakt. Kies een van de Microsoft Windows-items en Proxmox voegt bij elke start de Hyper-V-enlightenments toe. Laat het op Other staan, wat makkelijk gebeurt als je een schijf importeert of iets ouds kloont, en de gast krijgt er niet één. Hij start, hij draait, hij is trager, en niets vertelt het je.

De tweede hangt af van hoe de host bij versie 9 is gekomen. De installer van 9.0 zet de firmware-component van Debian aan en installeert het microcodepakket voor jouw CPU. Een host die vanaf 8.x is geüpgraded, houdt de repository’s die hij had, en bij de meeste daarvan betekent dat helemaal geen microcodepakket. Op een AMD Zen 5-host met kernel 6.17.9 of nieuwer is dat geen theoretisch gat: gasten met de EPYC-CPU-typen starten niet meer.

De rest van dit stuk neemt ze een voor een door: wat het is, de precieze regel die Proxmox toepast, hoe je het aanzet waar het ontbreekt, en hoe je bewijst dat het is aangeslagen. De regels komen uit de code van qemu-server en pve-manager op een live 9.2-host, niet uit het geheugen, want twee ervan zijn niet wat de meeste mensen zouden raden.

Wat een enlightenment eigenlijk is

Een gastbesturingssysteem dat voor echte hardware is geschreven, steekt veel moeite in dingen die binnen een VM verspilling zijn. Het programmeert timers via geëmuleerde chips, draait rondjes op locks die vastgehouden worden door een vCPU die niet eens is ingepland, en laat watchdogs afgaan als de host een paar milliseconden steelt.

Paravirtualisatie lost dat op door de gast te laten weten dat hij een gast is en hem rechtstreeks met de hypervisor te laten praten. Linux doet dat met de eigen interfaces van KVM. Het Fisher-Price OS (Windows) spreekt maar één paravirtueel dialect, dat van Hyper-V, dus KVM implementeert dat dialect en vertelt de gast dat hij op een Hyper-V-compatibele hypervisor draait. Elk onderdeel daarvan heet een enlightenment.

Niets daarvan staat aan tenzij iets erom vraagt. De documentatie van QEMU is er duidelijk over: “No Hyper-V enlightenments are enabled by default by either KVM or QEMU”¹. Op Proxmox is qemu-server degene die erom vraagt, en die vraagt alleen als het OS-type een van de Microsoft Windows-items is.

Je kunt het verschil op elke host zien. Dit is een Linux-VM op mijn 9.2-node, ostype: l26, CPU-type host:

# qm showcmd 101 --pretty | grep -- -cpu
  -cpu host,+kvm_pv_eoi,+kvm_pv_unhalt \

Twee KVM-flags voor de eigen paravirtuele interrupt- en spinlockafhandeling van Linux, en helemaal geen hv_-flags. Goed voor Linux. Fout voor een gast die alleen Hyper-V verstaat.

Wat elke enlightenment doet, volgens de beschrijvingen van QEMU¹:

Het OS-type is de schakelaar

De regel zit in één functie, get_hyperv_enlightenments in CPUConfig.pm van qemu-server². Eerst wordt het OS-type omgezet in een versienummer: win11 wordt 11, win10 wordt 10, w2k8 en wvista worden allebei 6, en de typen voor XP en 2003 worden 5. Linux, Other en al het andere worden 0.

Daarna lopen de poorten op volgorde.

Een regel lezen is één ding. Hem draaien is beter. Dus laadde ik de geïnstalleerde CPUConfig.pm op twee 9.2-hosts, mijn AMD Ryzen-node voor de AMD-rijen en een Intel Celeron N5100-node voor de Intel-rijen, en riep die functie aan met elke combinatie:

Drie dingen daarin zijn het weten waard voordat je de GUI in duikt.

Een UEFI-gast met een OS-type ouder dan 8.x krijgt niets. De code keert vroeg terug als de firmware OVMF is en de versie onder 8 ligt. Een 7/2008r2-gast die je naar UEFI hebt verhuisd, is stilletjes elke enlightenment kwijt die hij had.

hv_evmcs wil drie dingen tegelijk. Een Intel-host, het OS-type 11/2022/2025 en machineversie 11.0+pve2 of later. Een 10/2016/2019-gast krijgt hem standaard nooit, hoe nieuw zijn machineversie ook is.

De leverancier van de host wordt gelezen als de VM start. De controle roept read_cpuinfo aan op de node die de VM start, niet op de plek waar de VM is aangemaakt. In een gemengd Intel- en AMD-cluster krijgt dezelfde VM hv_evmcs op de ene node en niet op de andere, bij elke koude start opnieuw bepaald.

De oudere poorten op machineversie (2.3, 2.6, 2.12, 3.1) doen er alleen toe voor VM’s die vastgepind zijn op machines uit het verre verleden van QEMU. Alles wat je vandaag aanmaakt, komt er zonder meer doorheen.

Kies dus het OS-type dat het dichtst bij de gast ligt, niet het nieuwste in de lijst. Een 10/2016/2019-gast hoort op 10/2016/2019. De documentatie van Proxmox geeft nog een reden waarom het type ertoe doet, los van deze flags: het bepaalt ook dingen als of de virtuele RTC op lokale tijd loopt³.

Waarom je oudere VM’s de fix van juli missen

hv_evmcs als standaard is nieuw. Het kwam in qemu-server 9.2.0 op 15 juli 2026, om “mitigate guest freezes and 100% CPU usage seen on certain Intel CPUs with Windows guests that use Virtualization-Based Security (VBS)”⁴, en het is gekoppeld aan machineversie 11.0+pve2.

Die koppeling is het addertje, want Proxmox pint de machineversie van elke VM met een Microsoft Windows-OS-type vast op het moment dat hij wordt aangemaakt. De documentatie geeft de reden: “Windows is sensitive to changes in the virtual hardware - even between cold boots”³. Het is een verstandige beslissing. Het betekent ook dat een VM die in juni 2026 is aangemaakt op 11.0+pve1 of ouder zit, en daar blijft tot iemand hem verplaatst.

Gaat iemand hem voor je verplaatsen? Nee. De nieuwe standaard geldt voor nieuwe VM’s en voor VM’s die je bewust ophoogt, en verder voor niks.

Heb je Intel-hosts met 11/2022/2025-gasten waarop VBS aanstaat, en is er een daarvan op 100% CPU vastgelopen, dan is dit het eerste wat je controleert:

qm config <vmid> | grep -E '^(ostype|machine):'

Een ostype: win11 met een machine:-regel onder pc-q35-11.0+pve2 moet omhoog om de fix te krijgen. Ophogen verandert de virtuele hardware die de gast ziet, en dat is precies waar het vastpinnen tegen beschermt. Doe het dus in een onderhoudsvenster, met eerst een back-up of snapshot, via Hardware → Machine → Edit, vink Advanced aan en kies de versie.

Begint de regel met pc-i440fx-, dan is de versie het kleinere probleem: die gast hoort helemaal niet op i440fx, om de redenen in Gebruik altijd Q35, niet i440fx, en Instellen, en bewijzen dat het is aangeslagen hieronder behandelt dat.

Twee verwante standaarden kwamen in dezelfde paar maanden binnen en zijn het weten waard nu je er toch mee bezig bent. qemu-server 9.1.12 zette de flags cet-ibt en cet-ss uit voor het type 11/2022/2025, omdat gasten met VBS niet meer opstartten met QEMU 11.0 en de 7.x-kernels die ze doorgaven⁴. En 9.1.14 maakte de CPU-eigenschap level beschikbaar, die de documentatie omschrijft als “a known workaround for Hyper-V boot failures of Windows guests on recent Intel hosts when the CPU type is host or max”³.

De kant van QEMU, release voor release

qemu-server bouwt de commandoregel. pve-qemu-kvm is de QEMU die hem uitvoert, en de fix van juli heeft ze allebei nodig.

Machineversie 11.0+pve2 is alleen te kiezen als er een QEMU 11.0-binary is geïnstalleerd, want qemu-server weigert elke machineversie die nieuwer is dan de QEMU die hij op de host vindt⁵. De +pve2 is de eigen revisieteller van qemu-server, niet die van QEMU, dus elke 11.0-build voldoet. Op de dag dat 9.2.0 uitkwam, zag het paar er zo uit:

Zorgt apt ervoor dat je ze allebei hebt? Nee. qemu-server 9.2.0 declareert niets strengers dan pve-qemu-kvm (>= 7.1~)⁶, dus een node waarop QEMU op 10.x is vastgehouden neemt de nieuwe qemu-server zonder morren aan, en kan daarna de machineversie waar de fix aan hangt niet aanbieden. Controleer ze allebei, op elke node. Dit is mijn 9.2-host vandaag, al ruim voorbij allebei:

# pveversion -v | grep -E '^(qemu-server|pve-qemu-kvm):'
pve-qemu-kvm: 11.0.3-4
qemu-server: 9.2.11

Elke QEMU-release sinds Proxmox VE 9.0 op 10.0.2 uitkwam⁷ heeft eigen fixes meegebracht voor gasten met het Fisher-Price OS (Windows). Dit zijn de fixes die de gast raken, uit de pakketchangelog van Proxmox⁸ en de upstream changelogs van QEMU⁹:

QEMU 11.0 maakte ook iets stuk: het begon cet-ibt en cet-ss door te geven, en dat is wat VBS-gasten niet meer liet opstarten en qemu-server 9.1.12 ertoe bracht ze uit te zetten, zoals hierboven behandeld.

Met de fixes voor de guest agent in dezelfde releases zit het anders. QEMU 10.1, 10.2 en 11.0 repareerden elk delen van de VSS- en filesystem-freeze-afhandeling van de guest agent, waaronder de “Access denied Event ID 8194” die 11.0 verhielp⁹. Niets daarvan komt mee met pve-qemu-kvm. De agent voor die gast wordt geleverd op de ISO met virtio-win-drivers¹⁰, dus hij verandert alleen als je de agent in de VM bijwerkt.

De twee flags die je zelf kunt zetten

Proxmox laat je geen willekeurige CPU-flags aan een VM toevoegen. Hardware → Processors → Edit, vink Advanced aan, en Extra CPU Flags biedt een vaste lijst, gedefinieerd in CPUFlags.pm¹¹. Twee items op die lijst zijn enlightenments, en het zijn de twee die Proxmox standaard niet zet, of tot juli niet zette.

Allebei werden ze opt-in in qemu-server 6.0-6 op 23 juli 2019, in de changelog omschreven als “sometimes problematic”⁴. hv-tlbflush is dat zeven jaar lang gebleven. Dat zegt wel iets over hoeveel testwerk hij vraagt voordat je hem over een cluster uitrolt.

De eigen notitie van QEMU bij hv-evmcs is dat hij alleen voor Intel is, en dat “some virtualization features (e.g. Posted Interrupts) are disabled when hv-evmcs is enabled”¹. Hem met de hand aanzetten op een gast die niets met geneste virtualisatie doet, levert je niets op en kost je dat.

Instellen, en bewijzen dat het is aangeslagen

Voor een nieuwe VM: Create VM → OS, zet Type op Microsoft Windows en Version op wat er het dichtst bij komt.

Voor een bestaande: Options → OS Type → Edit, kies de versie, OK. Proxmox pint de machineversie vast wanneer je een bestaande VM naar een Microsoft Windows-type omzet, net als bij het aanmaken⁴, dus reken erop dat de machine:-regel in de configuratie ook verandert.

En zet hem op q35. Een gast met enlightenments heeft op pc-i440fx niets te zoeken. Het is de chipset zonder PCIe-bus, en de redenen gaan veel verder dan passthrough; ze staan allemaal in Gebruik altijd Q35, niet i440fx.

De wizard houdt je niet tegen, en voor de meeste Microsoft Windows-types zet hij je er zelfs neer. De eigen documentatie van Proxmox noemt Intel 440FX “the default”³, en de OS-standaarden van de GUI wijken daar voor precies één item van af: 11/2022/2025 krijgt machine: 'q35' en bios: 'ovmf'¹². Elk ander Microsoft Windows-type erft de generieke standaarden, en die zetten helemaal geen machine. Een 10/2016/2019-gast die je aanmaakt door steeds op Next te klikken, belandt dus op i440fx: met enlightenments en tegelijk op de verkeerde chipset.

Wijzig het op het tabblad System voordat je de wizard afrondt. Voor een VM die al bestaat is van chipset wisselen een grotere verandering aan de virtuele hardware dan een hogere machineversie, dus gelden dezelfde regels voor onderhoudsvenster en back-up, en de q35-post behandelt wat de gast daarmee doet.

Zet hem daarna echt uit. De enlightenments zijn argumenten op de commandoregel van QEMU, en die regel wordt alleen opgebouwd als het QEMU-proces start. Een herstart vanuit de gast houdt hetzelfde proces, dus ook de oude flags. Sluit af, wacht op stopped, en dan Start.

Bewijs het vanaf de host, want daar zit het antwoord:

qm showcmd <vmid> --pretty | grep -o "hv_[a-z_]*[=0-9a-fx]*" | sort -u

Dat print wat qemu-server bij de volgende start aan QEMU geeft. Een 11/2022/2025-gast op 11.0+pve2 op Intel hoort er elf te tonen: hv_evmcs, hv_ipi, hv_relaxed, hv_reset, hv_runtime, hv_spinlocks=0x1fff, hv_stimer, hv_synic, hv_time, hv_vapic en hv_vpindex. Dezelfde gast op AMD toont er tien. Een lege uitvoer betekent dat het OS-type geen Microsoft Windows-type is, of dat het een type van vóór 8.x op UEFI is.

Start een gast na de wijziging niet meer op, zet het OS-type dan voor één start terug op Other om de enlightenments als oorzaak aan te wijzen of uit te sluiten. Hij draait zonder. Alleen slechter.

Microcode: wat het oplost en waar het vandaan komt

De tweede standaard zit onder de hypervisor, niet erboven.

CPU-microcode is de firmware van de leverancier voor de processor zelf. Updates verhelpen beveiligingslekken en ernstige CPU-bugs, en de beheerdershandleiding van Proxmox maakt het punt dat telt voor wie zich zorgen maakt over snelheidsverlies: “a patched microcode is usually still more performant than an unpatched microcode where the kernel itself has to do mitigations”¹³.

Er zijn drie plekken waar het vandaan kan komen, en ze staan los van elkaar.

De BIOS-route is degene die Proxmox aanbeveelt¹³. De route via vroeg laden is het vangnet voor als de bordleverancier is gestopt met BIOS-updates, wat bij alles van een paar jaar oud meestal zo is.

Die derde rij verraste me. Proxmox heeft in zijn eigen repository een nieuwere amd64-microcode dan Debian in trixie heeft¹⁴, met dezelfde pinprioriteit, dus apt kiest die van Proxmox. Op een AMD-host met de Proxmox-repository ingesteld is dat de versie die je uiteindelijk draait, en zoals de volgende sectie laat zien, is het de versie die ertoe doet.

Vroeg laden is wat dit stuk inricht. De microcode gaat de initramfs in en de kernel past hem toe aan het allereerste begin van de boot, voordat er iets anders draait.

Laat laden past hem toe op een draaiend systeem. De eigen documentatie van de kernel heeft een sectie met de titel “Why is late loading dangerous?” en sinds 5.19 staat het niet meer standaard aan¹⁵. Debian blokkeert het ook. Dit is het bestand op mijn host, letterlijk:

# cat /etc/modprobe.d/amd64-microcode-blacklist.conf
# The microcode module attempts to apply a microcode update when
# it autoloads.  This is not always safe, so we block it by default.
blacklist microcode

Laat het met rust. De host hierboven heeft het en toont toch een geslaagde vroege update, dus het zit nergens in de weg.

Beide routes vragen een herstart. Daar kom je niet onderuit.

En het is alleen x86. De handleiding van Proxmox zegt ronduit: “There is no equivalent operating-system-level microcode package for arm64”¹³.

Waarom een geüpgradede host er geen heeft

“Non-free” in non-free-firmware gaat over de licentie, niet over geld of een Proxmox-abonnement. De wiki van Debian legt het uit: de kernelkant is vrije software, maar de updatedata van de leverancier is “opaque”, “and its contents are unknown to Debian”¹⁶. Daarom zit het in een eigen component, en daarom krijgt een Debian-systeem het niet tenzij die component aanstaat.

De installer van Proxmox VE 9.0 zet hem aan. Volgens de release notes zal de ISO “Install the microcode package matching the current platform”, en “installations now have the non-free-firmware repository enabled”⁷. Een upgrade doet geen van beide, omdat die de repositoryregels behoudt die je op 8.x had.

De checker meldt het wel, en harder dan ik had verwacht. Dit is hij op mijn Intel-node, die vanaf 8.x is geüpgraded:

# pve8to9 | grep -i -B1 -A2 microcode
PASS: Legacy file '/etc/sysctl.conf' is not present.
INFO: Checking if matching CPU microcode package is installed.
FAIL: unable to determine installed intel-microcode version.
WARN: The matching CPU microcode package 'intel-microcode' could not be found! Consider installing it to receive the latest security and bug fixes for your CPU.
	apt install intel-microcode
SKIP: NOTE: Expensive checks, like CT cgroupv2 compat, not performed without '--full' parameter

De FAIL is een bijwerking: het opzoeken van de versie logt een fout voor elk pakket dat niet geïnstalleerd is, nog voordat de microcodecontrole aan haar eigen waarschuwing toekomt¹⁷. Hoe dan ook, pve8to9 is een controle, geen slagboom. Hij voert de upgrade niet uit en kan er ook geen tegenhouden, dus een upgrade vaart er zo langs.

Doet dat er in de praktijk toe? Hier zijn twee gevallen waarin het dat doet, en het eerste is van mij.

Die Intel-node is een Celeron N5100. Zijn sources list had non-free-firmware al, dus het pakket was één commando verwijderd, en tot 27 oktober 2026 had niemand dat commando gedraaid. De kernel merkte het, ook al deed verder niemand dat:

# dmesg | grep -i microcode
[    0.000000] x86/CPU: Running old microcode
[    0.497219] microcode: Current revision: 0x0000001d
# lscpu | grep -i 'old microcode'
Vulnerability Old microcode:             Vulnerable

De kernel houdt “a table of released microcode” bij, en een CPU die op iets ouders opstartte “will say ‘Vulnerable’”¹⁸. Hoe oud is oud? De release notes van Intel geven daar voor deze chip antwoord op¹⁹:

De BIOS is versie 5.19, gedateerd 8 november 2022, en laadt nog steeds de allereerste microcode die Intel ooit voor dit onderdeel uitbracht, terwijl er bij het bouwen al twee nieuwere uit waren. Dat is precies het geval waarvoor de route met vroeg laden bestaat: vier updates in een pakket dat de host al kon zien. Ik heb het geïnstalleerd terwijl ik dit schreef, en wat dat deed staat onder Aanzetten, omdat het een addertje laat zien.

Het tweede geval is dat van AMD. Zen 5-processors hebben een bug in de RDSEED-instructie²⁰. De release notes van Proxmox 9.1 leggen vast wat er daarna gebeurt: kernels vanaf 6.17.9, “without active microcode update will disable the RDSEED32 CPU-bit, and will fail to run Qemu guests with a CPU type that exposes that bit (for example EPYC or EPYC-v4)”²¹. De fix is amd64-microcode 3.20251202.1~bpo13+1 of nieuwer, en dat is de versie van de Proxmox-repository, niet die van Debian.

Daarbinnen zit nog een tweede valkuil. Op Zen 5-borden waarvan de BIOS ouder is dan de fix voor AMD’s Entrysign-kwetsbaarheid, weigert de kernel de nieuwe microcode en logt hij No sha256 digest for patch ID, en het advies van Proxmox is een BIOS-update²¹. Op die hardware werkt de OS-route dus pas als de bordleverancier zijn deel heeft gedaan.

Aanzetten

Leg eerst vast waar je staat. Op de host, als root:

pveversion
grep -m1 vendor_id /proc/cpuinfo                 # GenuineIntel or AuthenticAMD
grep microcode /proc/cpuinfo | uniq              # revision running now
dpkg -l intel-microcode amd64-microcode 2>/dev/null | grep ^ii
dmesg | grep -i microcode
lscpu > /root/lscpu-before.txt                   # vulnerabilities and mitigations

Toont dpkg het passende pakket al als ii, dan is de host klaar en kun je doorgaan naar het controleren van het resultaat.

Zet de component aan. De apt van trixie geeft de voorkeur aan het deb822-formaat .sources, en de upgradehandleiding van Proxmox wijst naar apt modernize-sources om de oude eenregelige bestanden om te zetten, waarbij de originelen als .bak bewaard blijven²². Voeg daarna non-free-firmware toe aan de Components:-regel van zowel de hoofd- als de security-stanza in /etc/apt/sources.list.d/debian.sources. Dit is het bestand op mijn host, dat van de installer kwam:

Types: deb
URIs: http://deb.debian.org/debian/
Suites: trixie trixie-updates
Components: main contrib non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Types: deb
URIs: http://security.debian.org/debian-security/
Suites: trixie-security
Components: main contrib non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Beide stanza’s, omdat Debian microcode via beide routes naar stable levert. Het security-archief heeft intel-microcode 3.20250812.1~deb13u1, terwijl het hoofdarchief al door is naar 3.20251111.1~deb13u1²³, en je wilt de nieuwste van de twee.

Installeer degene die bij de CPU past.

apt update
apt install intel-microcode     # Intel
apt install amd64-microcode     # AMD

Alleen die voor jouw leverancier. Vanaf dan komt nieuwe microcode binnen met gewone apt full-upgrade-runs, en elke nieuwe versie vraagt net als de eerste een herstart.

Het installeren bouwt de initramfs opnieuw, want daar moet vroege microcode staan. De kernel leest hem uit een ongecomprimeerd archief vooraan in de initrd, als kernel/x86/microcode/GenuineIntel.bin of AuthenticAMD.bin¹⁵, en het installatiescript van het pakket roept de initramfs-trigger aan om hem daar te zetten²⁴. Dit is mijn Intel-node die het pakket kreeg terwijl dit stuk geschreven werd:

# grep -A6 'Setting up intel-microcode' /var/log/apt/term.log
Setting up intel-microcode (3.20251111.1~deb13u1) ...
intel-microcode: microcode will be updated at next boot
Processing triggers for man-db (2.13.1-1) ...
Processing triggers for initramfs-tools (0.148.4) ...
update-initramfs: Generating /boot/initrd.img-7.0.14-24-pve
Running hook script 'zz-proxmox-boot'..
Re-executing '/etc/kernel/postinst.d/zz-proxmox-boot' in new private mount namespace..

zz-proxmox-boot is de hook van Proxmox. Op een host waarvan de EFI-partities door proxmox-boot-tool worden bijgehouden, kopieert hij het nieuwe image daarheen; deze heeft er geen om te synchroniseren.

Kijk nu welk image hij genereerde. Zonder opgegeven kernel bouwt update-initramfs -u alleen de nieuwste opnieuw: “The default is the latest kernel version”²⁵. Dezelfde node, direct daarna:

# uname -r
7.0.14-23-pve
# for f in /boot/initrd.img-*; do echo "$f: $(lsinitramfs $f 2>/dev/null | grep -c GenuineIntel.bin)"; done
/boot/initrd.img-7.0.12-1-pve: 0
/boot/initrd.img-7.0.14-11-pve: 0
/boot/initrd.img-7.0.14-12-pve: 0
/boot/initrd.img-7.0.14-19-pve: 0
/boot/initrd.img-7.0.14-23-pve: 0
/boot/initrd.img-7.0.14-24-pve: 1
/boot/initrd.img-7.0.14-8-pve: 0

Eén image op de zeven bevat de microcode, en het is niet het image dat de host draait.

Bouw dus na het installeren elk image opnieuw, en opnieuw na elke microcode-update, omdat elke update dezelfde herbouw van alleen de nieuwste kernel start. Draai daarna de lus hierboven nog eens om het te bewijzen:

update-initramfs -u -k all

Herstart en controleer. Dit is mijn AMD 9.2-host nadat het pakket uit de Proxmox-repository erop stond:

# grep microcode /proc/cpuinfo | uniq
microcode	: 0xa500012
# dmesg | grep -i microcode
[    0.587928] microcode: Current revision: 0x0a500012
[    0.587930] microcode: Updated early from: 0x0a50000d

Updated early from is de regel die het bewijst. De eigen beheerdershandleiding van Proxmox toont nog de oudere formulering, microcode updated early to revision¹³; de huidige kernel print de twee regels hierboven²⁶. Beide vormen betekenen dat het gelukt is.

Geen zo’n regel is op zich geen fout. Hij verschijnt alleen als het pakket iets nieuwers bevat dan zowel de ingebouwde revisie van de CPU als de revisie die de BIOS laadde. Een pakket dekt heel veel CPU-modellen, en de handleiding heeft gelijk dat de datum erop je niet vertelt wanneer jouw model voor het laatst iets kreeg¹³.

Uitrollen over een cluster

De repositorywijziging en de installatie kunnen op alle nodes tegelijk. Er verandert niets tot een herstart. De herstarts gaan één node tegelijk, en elke node is gezond voordat de volgende neergaat.

HA-onderhoudsmodus houdt bij waar elke HA-gast vandaan kwam en zet hem terug zodra de node uit onderhoud is²⁷. Niet-HA-gasten zijn jouw werk.

Over noout verschillen de meningen, en beide kanten hebben een punt. Ceph markeert een stille OSD snel als down, maar pas als out na mon_osd_down_out_interval, standaard tien minuten²⁸, en het is out dat de herverdeling start. Een normale herstart is ruim binnen die tijd terug. Een server met een lange POST, een firmwareprompt of een trage RAID-controller misschien niet. Met noout groeit een trage herstart niet uit tot een herverdeling. De prijs is dat je moet onthouden hem weer uit te zetten, en een vergeten noout verbergt later een echte storing.

Doe het hele cluster in één venster. Nodes met verschillende microcoderevisies zijn precies de situatie waarin een gast met CPU-type host, die de functies van de fysieke CPU rechtstreeks ziet, live kan migreren naar een node die een andere set meldt.

Als een microcode-update misgaat

Zeldzaam, maar het gebeurt, en de handleiding van Proxmox behandelt het degelijk¹³.

Voor die eenmalige boot: GRUB-menu (houd Shift ingedrukt als het verborgen is), E op het Proxmox-item, voeg dis_ucode_ldr toe aan de regel die met linux begint, en dan Ctrl+X. Een host op systemd-boot in plaats van GRUB staat in het hoofdstuk over bootloaders van de beheerdershandleiding.

Het downgraden, op Intel:

apt list -a intel-microcode               # what versions exist
apt install intel-microcode=<version>     # pick the earlier one
apt-mark hold intel-microcode             # stop the next upgrade undoing it
reboot

Gebruik amd64-microcode op AMD. Downgraden, nooit purgen.

Een standaard is een belofte aan wie het verwachte pad nam

Geen van beide is een bug. Proxmox deed beide keren het verstandige: de functie aanzetten waar het veilig is, uit laten waar het dat misschien niet is, en de virtuele hardware vastpinnen waar de gast kieskeurig over is. De installer is verbeterd, de upgradecontrole meldt het, de changelog zegt wat er veranderde en wanneer. Proxmox heeft zijn deel gedaan.

Maar een standaard is een belofte aan degene die het deed zoals de leverancier verwachtte. Verse installatie, juist OS-type, VM aangemaakt na juli. Iedereen wiens omgeving een geschiedenis heeft, en dat is iedereen die iets echts draait, valt deels buiten die belofte, en het gat kondigt zichzelf niet aan. Het duikt op als een gast die wat traag is, een VBS-bevriezing die niemand aan een machineversie koppelt, of een Zen 5-node waar de EPYC-gasten na een kernelupdate niet meer starten.

Release notes beschrijven wat een nieuwe installatie krijgt. Over wat je hosts werkelijk draaien zeggen ze niks, en dat zijn verschillende vragen. De enige manier om de tweede te beantwoorden is gaan kijken: qm showcmd op de gasten, dmesg op de hosts, de machineregel in de configuratie. Niets daarvan kost meer dan een minuut per machine.

Die minuut is het werk. Proxmox geeft je het gereedschap om te controleren, en als zodanig is het gat tussen wat je aannam en wat er draait aan jou om te dichten, niet aan hen.