Ga naar de inhoud

Categorie: Proxmox

Proxmox Detected Hardware Unit Hang op Intel NICs

Gisteravond kwam ik thuis en merkte al snel dat mijn telefoon niks meer deed ophalen van het internet. Vreemd ik had geen meldingen van UptimeRobot, Unifi app deed netjes mijn netwerk laten zien… okee dat moet dan DNS zijn, webpagina van Pi-Hole oproepen? Nope niks, Proxmox? Nope. Vreemd maar niet de eerste keer sinds ik Proxmox draai, even richting de zolder om eens te kijken wat de console aangeeft.

Niks op het login scherm,
ping google.com ... 100% packet loss
ping 8.8.8.8 ... 100% packet loss
ping 192.168.0.1 ... 100% packet loss
Prima rebootping 8.8.8.8 succes en binnen een paar min begon ook mijn telefoon weer te werken. Fijn! Nu het ergste wat is er gebeurd? journalctl --since "2026-08-21 18:00:00" --until "2026-08-22 19:00:00" en daar hebben we het

root@pve01:/# journalctl --since "2026-08-21 18:00:00" --until "2026-08-22 00:00:00"
Aug 21 18:00:01 pve01 kernel: e1000e 0000:00:1f.6 nic0: Detected Hardware Unit Hang:
                                TDH                  <33>
                                TDT                  <46>
                                next_to_use          <46>
                                next_to_clean        <32>
                              buffer_info[next_to_clean]:
                                time_stamp           <118af9753>
                                next_to_watch        <33>
                                jiffies              <118ec4681>
                                next_to_watch.status <0>
                              MAC Status             <80083>
                              PHY Status             <796d>
                              PHY 1000BASE-T Status  <3800>
                              PHY Extended Status    <3000>
                              PCI Status             <10>

Mijn logboek stond vol met bovenstaande meldingen, dikgedrukte rode tekst. Na wat Googlen kwam ik er achter dat dit al een oude bug, First2Host heeft over dit issue al in februari 2024 geschreven. Onderaan de pagina is de link te vinden naar het hele artikel ik heb de “tijdelijke fix™” gekopieerd

Getroffen netwerkadapters

Met het commando lspci -v | grep Ethernet kan je zien welke netwerkadaptors je gebruikt in je systeem. Hieronder een lijstje van de getroffen netwerk kaarten.

Ethernet Connection (6) I219-V
Ethernet Connection (6) I219-LM
Ethernet Connection (7) I219-LM
Ethernet Connection (11) I219-LM
Intel Corporation 82579LM Gigabit Network Connection (Lewisville) (rev 04)
Intel Corporation 82579V Gigabit Network Connection (rev 04)
Intel Corporation Ethernet Connection (7) I219-V (rev 10)
Intel Corporation Ethernet Connection (3) I218-LM (rev 03)
Intel Corporation NUC5i5 I218-V (rev 03)
Intel Corporation 7 Series/C210
Lenovo M93 Tiny I217-LM
Intel Corporation Ethernet Connection (11) I219-LM
Intel Corporation Ethernet Controller X550

Oplossing

De oplossing is om een aantal opties uit te zetten op je netwerk kaart. Met de oplossing zet je TSO (TCP Segmentation Offload) en GSO (Generic Segmentation Offload) uit. Nu heb ik deze fix bestempelt tot “Tijdelijke fix™” omdat de bug zelf al in 2012 bekend is gemaakt bij kernal.org en het nu 2026 is en nog geen fix hebben ga ik er vanuit dat dit nooit meer opgelost gaat worden.

Test fix (tot reboot)

Wil je het eerst testen voor de aanpassing permanent toevoegt aan je configuratie dan kan dat met onderstaand commando. Deze methode werkt tot een reboot van de server. In de errormelding staat je netwerk kaart, in mijn geval is dat dus “nic0”, pas hier je config op aan.

apt-get install ethtool -y
ethtool -K nic0 tso off gso off

Tijdelijke fix™ (tot je het er uit haalt)

De permanente oplossing moet je doen door de config van je netwerk kaart aan te passen. In de error melding staat je netwerk kaart, in mijn geval is dat dus “nic0”, pas hier je config op aan. Open je netwerk configuratie met: nano /etc/network/interfaces en voeg post-up /sbin/ethtool -K nic0 tso off gso off toe aan je config zoals hieronder zichtbaar is.

auto nic0
iface nic0 inet static
  address 5.5.5.555
  netmask 255.255.255.224
  gateway 5.5.5.55
  post-up /sbin/ethtool -K nic0 tso off gso off

Proxmox VM migratie tussen hosts

Afgelopen week heb ik een aantal VM’s verhuist tussen 2 Proxmox hosts die niet in een cluster zitten. Het was even uitzoeken en testen maar het zijn eigenlijk maar een paar stappen die je moet doorlopen.

Voorbereiding Netwerk

Zorg er voor dat de 2 machines vrij met elkaar kunnen praten. Omdat mijn migratie over een VPN tunnel gaan naar een VLAN waar normaal over de VPN geen toegang tot is heb ik gekozen om tussen de 2 IPadressen van de hosts een ANY: ANY regel op te zetten. Bij deze regel heb ik meteen een tijdsduur gezet zodat deze na 2 dagen weer zou sluiten. Ja als je de mogelijkheid hebt vooral even doen want dit vergeet je…

Voorbereiding Proxmox doel host

API Key aan maken

  1. Navigeer naar Datacenter > Permissions > API Tokens
  2. Klik op Add
  3. Kies de user, geef de token een naam, zet ‘Privilege Separation’ uit hierdoor neemt proxmox de rechten over van de user, kies een verloop datum handig als je nog wel eens een API Token vergeet te verwijderen.
  4. Nu krijg je het Token Secret, kopieer het Token ID en Secret om later te gebruiken. Deze is maar 1x zichtbaar.

Fingerprint boven toveren

  1. Datacenter > Host > System > Certificates
  2. Kies het Certificaat wat gebruikt wordt voor verbindingen. Ik gebruik zelf nog het standaard gegenereerde certificaat deze heet pve-ssl.pem
  3. Kopieer uit de informatie de Fingerprint

Netwerk NIC uitzoeken

Via welke netwerk kaart gaat de VM dadelijk naar de wereld babbelen? Standaard is dit vmbr0 – Linux Bridge. Mocht je dit even willen bekijken wat dit voor jouw is:

  1. Datacenter > Host > System > Network (het menu item boven de certificates van net)
  2. Kies de netwerk Name van de nic die je wilt gaan gebruiken.

Storage

De VM moet natuurlijk ook ergens opgeslagen worden. Kies hiervoor de een storage waar nog voldoende ruimte is

  1. Datacenter > Storage
  2. Kies hier een ID voor een storage waar je Disk images (VMs) of Container (LXC) naar toe kan schrijven. Ik kies hier voor local-lvm

VM ID

Bedenk op de ontvangende host een ID om de machine op te ontvangen. Ik kies hier 1002

Op de bron host

Op de verzendende host moeten we ook wat dingen doen

VM ID, wat is het ID van de VM die je wilt gaan verhuizen?

Migreren

Commando

Okee tijd om het commando op te bouwen. de laatste twee zijn optioneel --delete=1 (verwijder VM van de oorspronkelijke host na een succesvolle overdracht) --online (live migratie. Dit werkt alleen bij een VM en niet bij LXC containers, je migreert hier een machine terwijl deze aan staat. Let op dit kan alleen wanneer de IP adressen niet veranderen).

qm remote-migrate <VMID_BRON> <VMID_DOEL> 'host=<DOEL_IP>,apitoken=PVEAPIToken=<TOKEN_ID>=<TOKEN_SECRET>,fingerprint=<FINGERPRINT>' --target-bridge <NETWORK_BRIDGE> --target-storage <STORAGE_NAME> --online --delete=1
  • <VMID_BRON>: ID van de VM op de bron host machine
  • <VMID_DOEL>: ID van de VM op de doel host machine
  • <DOEL_IP>: IP van de doel host
  • <TOKEN_ID>: Het token ID van de API Token
  • <TOKEN_SECRET>: Het secret van de API Token
  • <FINGERPRINT>: De fingerprint van het SSL certificaat op de doel machine
  • <NETWORK_BRIDGE>: in de meeste gevallen is dit vmbr0
  • <STORAGE_NAME>: Naam van het storage op de doel host

in mijn geval komt er het volgende commando uit

qm remote-migrate 1002 1002 'host=10.20.80.11,apitoken=PVEAPIToken=root@pam!Migrate=cfed15e0-81f5-4f1c-b7f6-d091935808ed,fingerprint=00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD:EE:FF' --target-bridge vmbr0 --target-storage local-lvm --online --delete=1

Migratie starten

Plak het commando in de shell en druk op enter. Er zal een tunnel opgezet worden om de vm te migreren. Laat dit even rustig pruttelen.

Na Migratie

Heb je in het commando --delete=1 mee gegeven, dan ben je nu klaar

Heb je geen --delete=1 mee gegeven dan moet je handmatig de VM nog even wissen. Om dat te doen moet je deze eerst unlocken met qm unlock <VMID_BRON> en vervolgens kan je deze verwijderen via de interface

Is er toch iets verkeerd gegaan en wil je de bron VM weer in gebruik nemen zodat je het later nog eens kan proberen? Dan moet je de VM unlocken met qm unlock <VMID_BRON> en vervolgens kan je deze weer gebruiken zoals gewend. Vergeet niet op de doel machine de VM te verwijderen om zo netwerk conflikten te voorkomen.

Bronnen: https://www.thomas-krenn.com/en/wiki/Proxmox_Remote_Migration, https://www.reddit.com/r/Proxmox/comments/1seojb6/cheatsheet_for_migrating_vms_between_hosts/, vallen en opstaan

Proxmox uitgeschakeld?

Heb jij ook al een aantal keer een VM willen uitschakelen om er vervolgens achter te komen waarom niets meer werkt en denkt SHIT weer de server uitgeschakeld. Jep ik ben die dumdum die dat een aantal keer geprobeert heeft in productie. Waarom ze bij Proxmox de keuze hebben genomen om de hypervisior shutdown op precies dezelfde plek te zetten als de VM en LXC shutdown mag joost weten. Ook als dit een klacht is die al jaren op de forums heen en weer gaat. nu heb ik in een van die posts een fantastische oplossing gevonden. Gebruiker cmartin kwam met deze geweldige tip. ik heb deze iets terug gesnoeit zodat de shell nog wel beschikbaar is.

sed -i 's/restartBtn, shutdownBtn/g' /usr/share/pve-manager/js/pvemanagerlib.js

Wil je nu toch via de interface de hypervisior uitschakelen? Dat kan helaas niet meer, je zal even de shell moeten openen en shutdown -h now in moeten typen.

Waarom de knoppen weghalen? Nou je kan dit ook behalen door een 2e gebruiker met minder rechten aan te maken. Echter wanneer je de rechten voor shutdown weghaalt van een gebruiker haal je ook de hypervisior shell rechten weg omdat je daar ook shutdown kan doen… Ja leuk maar ik wil wel gewoon templates deployen etc.

Copyright Ronald van Heugten 1990 - 2026