Het grote Proxmox VE topic

[Disksoft]

avdpeijl schreef op zondag 25 juni 2023 @ 12:01:
Hier wisselende ervaring met de upgrade naar proxmox v8.
Twee systemen met realtek ethernet: beide type RTL8111/8168/8411 rev 15.

Systeem 1: MSI B150 moederboard -> geen problemen, systeem draait stabiel op de nieuwe kernel met zo'n 10 containers
Systeem 2: Dell Wyse 5070 -> Na migratie: de realtek valt na een paar uur telkens uit. Beetje afhankelijk van volume denk ik. Op console staat alles nog up, maar geen ping meer mogelijk.

Gisteravond reboot op de Dell gedaan met kernel 5.15 en alles lijkt weer stabiel te draaien

Ik heb op deze mini-pc ook nog een intel i210 kaart geprikt zitten, maar deze was al onbetrouwbaar op proxmox 7 (dan na paar weken onverklaarbare uitval). Hardware issue, of toch driver issue? Op deze server draait alleen een opnsense VM.

Ik heb hetzelfde probleem met een HP ProDesk met een Realtek adapter.
Nu kwam ik dit tegen op het internet: https://bugzilla.kernel.org/show_bug.cgi?id=107421

I had the same issue (network driver crashes after a while) with kernel 5.x and 6.x on debian 11 with proxmox.

But I could resolve the problem disable ASPM:
Editing /etc/default/grub with:

GRUB_CMDLINE_LINUX="pcie_aspm=off pcie_port_pm=off"

grub-update and reboot. After this it works fine for me.

vervolgens reageert iemand met:

That's something you can do also during runtime w/o disabling ASPM for all devices. Just use the standard sysfs attributes under /sys/class/net/<if>/device/link.

Nu ben ik niet heel erg thuis in Linux maar weet iemand hoe ik dit moet doen?
Het pad is een map, maar daar zie ik geen bestanden in staan `<if>` is bij mij `enp2s0 `.

[John245]

Disksoft schreef op maandag 26 juni 2023 @ 08:04:
[...]


Ik heb hetzelfde probleem met een HP ProDesk met een Realtek adapter.
Nu kwam ik dit tegen op het internet: https://bugzilla.kernel.org/show_bug.cgi?id=107421


[...]


vervolgens reageert iemand met:


[...]


Nu ben ik niet heel erg thuis in Linux maar weet iemand hoe ik dit moet doen?
Het pad is een map, maar daar zie ik geen bestanden in staan `<if>` is bij mij `enp2s0 `.

Mijn HA cluster update gefixt. Bleek dat ik de kernel gepind had.

Live migraties werken. Reboot werkt ook veilig (VM's blijven operationeel). Nu kijken naar de long term stabilty.

[_Eend_]

Disksoft schreef op maandag 26 juni 2023 @ 08:04:
[...]


Ik heb hetzelfde probleem met een HP ProDesk met een Realtek adapter.
Nu kwam ik dit tegen op het internet: https://bugzilla.kernel.org/show_bug.cgi?id=107421


[...]


vervolgens reageert iemand met:


[...]


Nu ben ik niet heel erg thuis in Linux maar weet iemand hoe ik dit moet doen?
Het pad is een map, maar daar zie ik geen bestanden in staan `<if>` is bij mij `enp2s0 `.

Dat is een leuke. In eerste instantie dacht ik dat je heel simpel gewoon twee bestandjes kon aanmaken in de bewuste map met de namen pcie_aspm en pcie_port_pm en in beide bestanden alleen het woord off.

Maar dat werkt niet Ik krijg hier onder Fedora 38 iig de melding permission denied, ook als root. Schijnbaar moet je hiervoor sysfsutils installeren.

Ik ga nog even verder klooien.

edit:
Aan de andere kant, je kunt het ook via grub.cfg doen zoals in je een na laatste quote, al dan niet tijdelijk.

[ Voor 6% gewijzigd door _Eend_ op 26-06-2023 11:48 ]

[RobertMe]

_Eend_ schreef op maandag 26 juni 2023 @ 11:20:
[...]


Dat is een leuke. In eerste instantie dacht ik dat je heel simpel gewoon twee bestandjes kon aanmaken in de bewuste map met de namen pcie_aspm en pcie_port_pm en in beide bestanden alleen het woord off.

Maar dat werkt niet Ik krijg hier onder Fedora 38 iig de melding permission denied, ook als root. Schijnbaar moet je hiervoor sysfsutils installeren.

Ik ga nog even verder klooien.

Je zult, tijdens boot, off moeten schrijven naar deze "bestanden". Dit zijn namelijk geen echte bestanden. sysfs is een virtueel bestandssysteem waarmee je met de kernel interfaced. Door off te schrijven naar dat "bestand" zeg je dus letterlijk op dat moment tegen de kernel "zet het nu uit".

[_Eend_]

RobertMe schreef op maandag 26 juni 2023 @ 11:46:
[...]

Je zult, tijdens boot, off moeten schrijven naar deze "bestanden". Dit zijn namelijk geen echte bestaande. sysfs is een virtueel bestandssysteem waarmee je met de kernel interfaced. Door off te schrijven naar dat "bestand" zeg je dus letterlijk op dat moment tegen de kernel "zet het nu uit".

Dank, net nadat ik het had gepost had ik al zo'nn "hier is wat mee"-gevoel bij, ondertussen had ik er al het nodige over gelezen.

[zeroday]

net met 'clustertje' met 2 NUC's naar proxmox 8 overgebracht
de eerste netjes met alle machines ' down ' .. via het tteck update script alles ineens bijgewerkt .. en met 6 minuten was mijn NUC weer online

de 2e NUC ook bijgewerkt maar daar ' vergeten ' de VM's en LXC's uit te zetten maar het enige verschil was dat bij de reboot toen de machines nog uit moesten .. ipv dat de reboot ineens ging.

Omgeving nu binnen een kwartier naar 8.03 ..
's kijken wat er anders is

[John245]

Hier een cluster met 3 Nodes. 2 Nodes werken tot nu toe stabiel.

Intel NUC al 2 maal een freeze binnen 24 uur. Nog een keer geherstart. Als dit niet werkt laatste FW er is op zetten.

[nero355]

rachez schreef op zondag 25 juni 2023 @ 18:21:
Eigenlijk adviseren ze dan beiden: console of ssh, maar bij voorkeur console.
Maar hoe dan ook, console is zeker beter gezien de eerdere ervaringen.

Reden is denk ik dat ssh updates kan krijgen of andere netwerkcomponenten waardoor je je ssh connectie kan verliezen.

Daarom dus mijn suggestie : nero355 in "Het grote Proxmox VE topic"

Dan kan je daarna gewoon weer verder!

[rachez]

@nero355
Je bedoelt om met screen je upgrade te starten?

Je ssh connectie naar de proxmox server verbreekt dan toch ook als op de server de ssh daemon stopt, alleen je connectie naar je terminal/putty sessie blijft bestaan.

[John245]

zeroday schreef op maandag 26 juni 2023 @ 12:01:
net met 'clustertje' met 2 NUC's naar proxmox 8 overgebracht
de eerste netjes met alle machines ' down ' .. via het tteck update script alles ineens bijgewerkt .. en met 6 minuten was mijn NUC weer online

de 2e NUC ook bijgewerkt maar daar ' vergeten ' de VM's en LXC's uit te zetten maar het enige verschil was dat bij de reboot toen de machines nog uit moesten .. ipv dat de reboot ineens ging.

Omgeving nu binnen een kwartier naar 8.03 ..
's kijken wat er anders is

Heb je Intel NUC's en draai je ZFS? Mijn NUC is denk ik niet compatible met de kernel. Als ik de kernel downgrade geen problemen.

[commentator]

rachez schreef op woensdag 28 juni 2023 @ 19:32:
@nero355
Je bedoelt om met screen je upgrade te starten?

Je ssh connectie naar de proxmox server verbreekt dan toch ook als op de server de ssh daemon stopt, alleen je connectie naar je terminal/putty sessie blijft bestaan.

yep ssh zou dan kunnen stoppen maar omdat ie in screen loopt loopt je upgrade door

[rachez]

commentator schreef op woensdag 28 juni 2023 @ 19:45:
[...]

yep ssh zou dan kunnen stoppen maar omdat ie in screen loopt loopt je upgrade door

Hoe werkt dat dan als de ssh daemon op de proxmox server zelf het sshd proces stopt? (Ik ken verder screen niet goed, dus ben oprecht nieuwsgierig)

[commentator]

rachez schreef op woensdag 28 juni 2023 @ 19:59:
[...]

Hoe werkt dat dan als de ssh daemon op de proxmox server zelf het sshd proces stopt? (Ik ken verder screen niet goed, dus ben oprecht nieuwsgierig)

de ssh verbreekt de verbinding omdat die bijgewerkt wordt
binnen screen blijft de rest doorlopen
zodra je dan weer verbinding maakt ga je binnen de screen sessie verder waar je gebleven bent

[RobertMe]

rachez schreef op woensdag 28 juni 2023 @ 19:59:
[...]

Hoe werkt dat dan als de ssh daemon op de proxmox server zelf het sshd proces stopt? (Ik ken verder screen niet goed, dus ben oprecht nieuwsgierig)

screen is sowieso ouderwets, tmux FTW.

Maar screen draait dus losgekoppeld van de terminal (mogelijk als een "daemon" en vervolgens een "UI proces" in de terminal). Als de terminal "sluit" blijft screen dus verder doordraaien, en de processen die binnen screen gestart zijn dan ook. Op een later moment kun je (al dan niet in een nieuwe SSH sessie of een lokale login) weet opnieuw attachen aan die screen instance en heb je dus weer inzicht in/controle over de processen die je eerder gestart hebt.

En leuke aan tmux is dat je meermaals kunt attachen aan dezelfde sessie (leuk als je dat bv doet vanaf telefoon met klein scherm en een 4K monitor met full screen terminal ). Daarnaast kun je in tmux het "venster" ook splitsen in meerdere panes (dus bv 2 "tabs" side by side) etc etc etc.

[rachez]

commentator schreef op woensdag 28 juni 2023 @ 20:02:
[...]

de ssh verbreekt de verbinding omdat die bijgewerkt wordt
binnen screen blijft de rest doorlopen
zodra je dan weer verbinding maakt ga je binnen de screen sessie verder waar je gebleven bent

Net even wat testjes gedaan en jullie hebben gelijk. Je kan het sshd proces op de server stoppen en het command gestart met screen op de client loopt gewoon door.

Thx, weer wat geleerd!

[Church of Noise]

MakhouT schreef op zondag 5 februari 2023 @ 14:37:
Huh ik heb iets vreemd aan de hand. Ik geraak niet meer op de webinterface van proxmox?
Na even te zoeken bleek dat mijn NUC in sleep mode is gegaan (of is uitgegaan)? Ik zou verwachten nu dat proxmox geinstalleerd is dat deze blijft 24/7 blijft aanstaan?

Kan het zijn dat die uit is gevallen omdat ik die aangesloten heb aan mijn TV met de HDMI kabel en als ik de TV uitzet dat de NUC ook uitgaat door HDMI CEC?
Dat zou wel jammer zijn, want ideaal gezien had ik mijn NUC ook nog gebruikt als Plex client (ik weet wel nog niet of het mogelijk is)

Heb je hiervoor ondertussen een oplossing gevonden? Ik heb iets gelijkaardig voor, maar dan met mijn computerscherm: uitschakelen -> NUC gaat in sleep.

[_JGC_]

commentator schreef op woensdag 28 juni 2023 @ 19:45:
[...]

yep ssh zou dan kunnen stoppen maar omdat ie in screen loopt loopt je upgrade door

Zelfs als je ssh stopt blijft je huidige sessie gewoon doorlopen.

Wat ik wel een keer gehad heb is een upgrade waarbij ssh werd verwijderd door een gedeeltelijke upgrade en conflicten, toen was het wel direct over en uit.

[John245]

Church of Noise schreef op woensdag 28 juni 2023 @ 22:49:
[...]

Heb je hiervoor ondertussen een oplossing gevonden? Ik heb iets gelijkaardig voor, maar dan met mijn computerscherm: uitschakelen -> NUC gaat in sleep.

Deed deze dat niet bij Proxmox 7? ZIe ook mijn eerder problemen met de NUC na upgrade.

[Church of Noise]

John245 schreef op donderdag 29 juni 2023 @ 06:37:
[...]

Deed deze dat niet bij Proxmox 7? ZIe ook mijn eerder problemen met de NUC na upgrade.

Ik heb het voor met Debian (kwam hier terecht na een forum zoektocht), en heb de NUC nog maar net...

[zeroday]

John245 schreef op woensdag 28 juni 2023 @ 19:45:
[...]

Heb je Intel NUC's en draai je ZFS? Mijn NUC is denk ik niet compatible met de kernel. Als ik de kernel downgrade geen problemen.

nee geen ZFS
nvme en ene ssd disk als boot/data ..
en dan gewoon alle default gelaten.

ZFS had ik in mijn HP Microservers draaien met meerdere disken maar dat was erg lastig ivm verouderde HDD's en een paar keer een storing . .het lijkt dan simpel om te herstellen, maar het ontbrak me aan kennis

[John245]

zeroday schreef op donderdag 29 juni 2023 @ 13:08:
[...]


nee geen ZFS
nvme en ene ssd disk als boot/data ..
en dan gewoon alle default gelaten.

ZFS had ik in mijn HP Microservers draaien met meerdere disken maar dat was erg lastig ivm verouderde HDD's en een paar keer een storing . .het lijkt dan simpel om te herstellen, maar het ontbrak me aan kennis

Vermoedelijk de oorzaak gevonden. Als ik bij de kernel 6.x een HDMI dummy aansluit is het probleem verholpen. Nog ff kijken hoe stabiel dit is. Dit probleem had ik niet bij de 5.15.x kernel.

[nero355]

rachez schreef op woensdag 28 juni 2023 @ 19:32:
Je bedoelt om met screen je upgrade te starten?

Je ssh connectie naar de proxmox server verbreekt dan toch ook als op de server de ssh daemon stopt, alleen je connectie naar je terminal/putty sessie blijft bestaan.

rachez schreef op woensdag 28 juni 2023 @ 19:59:
Hoe werkt dat dan als de ssh daemon op de proxmox server zelf het sshd proces stopt? (Ik ken verder screen niet goed, dus ben oprecht nieuwsgierig)

_JGC_ schreef op woensdag 28 juni 2023 @ 23:03:
Zelfs als je ssh stopt blijft je huidige sessie gewoon doorlopen.

Wat ik wel een keer gehad heb is een upgrade waarbij ssh werd verwijderd door een gedeeltelijke upgrade en conflicten, toen was het wel direct over en uit.

In principe is het zo dat je met Screen/Tmux/Byobu volledig onafhankelijk bent van de manier waarop je met de Server bent verbonden :
- Start je sessie via SSH
- Disconnect om wat voor reden dan ook...
- Reconnect via de Console door fysiek achter je Server te gaan zitten.
- Disconnect/Deattach
- Reconnect via IPMI/iDRAC/iLO/enz.
- Disconnect/Deattach
- En dan weer vanaf je telefoon met SSH reconnecten of zo...
- enz...
- enz..
- enz.



Alleen als je Server een reboot doet ben je de sessie kwijt en zal je overnieuw moeten beginnen!

RobertMe schreef op woensdag 28 juni 2023 @ 20:10:
screen is sowieso ouderwets, tmux FTW.

Zie mijn Disclaimer @ nero355 in "Het grote Proxmox VE topic"

Church of Noise schreef op woensdag 28 juni 2023 @ 22:49:
Heb je hiervoor ondertussen een oplossing gevonden? Ik heb iets gelijkaardig voor, maar dan met mijn computerscherm: uitschakelen -> NUC gaat in sleep.

John245 schreef op donderdag 29 juni 2023 @ 13:57:
Vermoedelijk de oorzaak gevonden. Als ik bij de kernel 6.x een HDMI dummy aansluit is het probleem verholpen. Nog ff kijken hoe stabiel dit is. Dit probleem had ik niet bij de 5.15.x kernel.

Ik zou het BIOS/UEFI in duiken en dan alle HDMI-CEC zooi uitschakelen of in ieder geval alle HDMI opties nalopen!

[Church of Noise]

Dank @nero355!

Blijkt een weerkerend probleem bij die generatie NUC.Ook CEC uitschakelen doet niks. Nog 2 opties over na alle andere te hebben geprobeerd (bvb,aspm uit werkt maar het vermogen bij idle gaat van 3 naar meer dan 6W, rest helpt niks) :
1) hdmi dummy (besteld)
2) firmware update (maar vereist windows dus effe Win11 op een USB stick gooien en proberen)

[John245]

Church of Noise schreef op donderdag 29 juni 2023 @ 18:22:
Dank @nero355!

Blijkt een weerkerend probleem bij die generatie NUC.Ook CEC uitschakelen doet niks. Nog 2 opties over na alle andere te hebben geprobeerd (bvb,aspm uit werkt maar het vermogen bij idle gaat van 3 naar meer dan 6W, rest helpt niks) :
1) hdmi dummy (besteld)
2) firmware update (maar vereist windows dus effe Win11 op een USB stick gooien en proberen)

je kan toch de OS onafhankelijke .bio file gebruiken. Of bedoel je met FW geen BIOS?

[Church of Noise]

John245 schreef op donderdag 29 juni 2023 @ 18:24:
[...]

je kan toch de OS onafhankelijke .bio file gebruiken. Of bedoel je met FW geen BIOS?

Exact. BIOS deed ik al met de .bio, ik bedoel hier de fw voor de HDMI.

[John245]

nero355 schreef op donderdag 29 juni 2023 @ 16:07:

[...]

Ik zou het BIOS/UEFI in duiken en dan alle HDMI-CEC zooi uitschakelen of in ieder geval alle HDMI opties nalopen!

@nero355 zou je dat ook in mijn geval doen? Er is niks gewijzigd het werkt gewoon niet met de nieuwe kernel. En de HDMI dummy lost het op.

[John245]

Church of Noise schreef op donderdag 29 juni 2023 @ 18:29:
[...]

Exact. BIOS deed ik al met de .bio, ik bedoel hier de fw voor de HDMI.

Ok zie dat in mijn geval ook een FW update voor de HDMI beschikbaar is. Ben wel benieuwd naar je resultaat.

[nero355]

Church of Noise schreef op donderdag 29 juni 2023 @ 18:22:
Blijkt een weerkerend probleem bij die generatie NUC.Ook CEC uitschakelen doet niks. Nog 2 opties over na alle andere te hebben geprobeerd (bvb,aspm uit werkt maar het vermogen bij idle gaat van 3 naar meer dan 6W, rest helpt niks) :
1) hdmi dummy (besteld)
2) firmware update (maar vereist windows dus effe Win11 op een USB stick gooien en proberen)

John245 schreef op donderdag 29 juni 2023 @ 19:43:
Zou je dat ook in mijn geval doen?

Er is niks gewijzigd het werkt gewoon niet met de nieuwe kernel. En de HDMI dummy lost het op.

Laten we eens beginnen bij het begin :

Welke Intel NUC's hebben jullie precies

Gezien het feit dat @Church of Noise het heeft over firmware flashen vanuit Windows verwacht ik één van de generaties die een DP naar HDMI oplossing hadden om een hogere versie dan HDMI 1.4 aan te kunnen bieden destijds ?!

Een HDMI Dummy lost vaak twee problemen op :
- HDMI Handshake richting een Versterker actief laten blijven.
- Headless kunnen draaien zonder de hele tijd een Monitor aan de PC te moeten hangen...

Een extra optie voor @John245 is om misschien eens te kijken hoe je een Bug Report kan indienen bij de juiste Kernel Maintainer die zich met dat gedeelte bezighoudt ?!

[Church of Noise]

Ik heb een NUC8i3BEK met inderdaad een LSPCon chip die DP to HDMI doet...

Liefst van al zou ik natuurlijk hebben dat de HDMI FW update het ding fixt, want ik wil het systeem gewoon écht headless draaien zonder dat de HDMI meuk uberhaupt moet ingeschakeld zijn (ik vermoed dat die met de dummy in realiteit ingeschakeld blijft).

[nero355]

@Church of Noise

Ik kreeg net een brainfart : Wat gebeurt er als je de Intel iGPU Driver niet laat inladen

[John245]

nero355 schreef op donderdag 29 juni 2023 @ 19:55:
[...]


[...]


Een extra optie voor @John245 is om misschien eens te kijken hoe je een Bug Report kan indienen bij de juiste Kernel Maintainer die zich met dat gedeelte bezighoudt ?!

Ik heb een NUC7i7DNHE.

Deze heeft: Dual HDMI 2.0a, 4-lane eDP 1.4

Had al een bericht op het Proxmox forum. In de reply nu een "staff member" getagd.

[Church of Noise]

nero355 schreef op donderdag 29 juni 2023 @ 20:07:
@Church of Noise

Ik kreeg net een brainfart : Wat gebeurt er als je de Intel iGPU Driver niet laat inladen

Ook al aan gedacht, maar nog niet uitgevist hoe dat werkt in Linux (Debian)...
Ik laat t weten als ik het gevonden heb!

[zx9r_mario]

Proxmox 8 upgrade op een HP Microserver N36L ging probleemloos

[John245]

Proxmox 8 upgrade op een Supermicro X12SPM-LN6TF, 3xPCI-e Gen 4, 8xDDR4, 2xIntel 10Gbe, 4xIntel 1Gbe, 1xM.2 NVMe, 10xSATA3, 4xNVMe Server gaat probleemloos.

[ElMacaroni]

code:

proxmox:~# dmesg | grep Hardware
[    0.487127] Hardware name: HPE ProLiant MicroServer Gen10/ProLiant MicroServer Gen10, BIOS 5.12 02/19/2020
proxmox:~# pveversion
pve-manager/8.0.3/bbf3993334bfa916 (running kernel: 6.2.16-3-pve)

[m-buurman]

Church of Noise schreef op donderdag 29 juni 2023 @ 20:05:
Ik heb een NUC8i3BEK met inderdaad een LSPCon chip die DP to HDMI doet...

Liefst van al zou ik natuurlijk hebben dat de HDMI FW update het ding fixt, want ik wil het systeem gewoon écht headless draaien zonder dat de HDMI meuk uberhaupt moet ingeschakeld zijn (ik vermoed dat die met de dummy in realiteit ingeschakeld blijft).

Ik heb op een NUC8i3BEH Proxmox headless draaien. Eenmaal geïnstalleerd heb ik alles afgekoppeld, verplaatst, gestart en nooit meer naar omgekeken. Wat zijn de problemen?

[John245]

m-buurman schreef op donderdag 29 juni 2023 @ 23:27:
[...]


Ik heb op een NUC8i3BEH Proxmox headless draaien. Eenmaal geïnstalleerd heb ik alles afgekoppeld, verplaatst, gestart en nooit meer naar omgekeken. Wat zijn de problemen?

Welke Proxmox versie? Mijn NUC had ook nooit problemen tot Proxmox 8.0.3.

[m-buurman]

John245 schreef op donderdag 29 juni 2023 @ 23:30:
[...]

Welke Proxmox versie? Mijn NUC had ook nooit problemen tot Proxmox 8.0.3.

Ik heb hem op de dag van release direct bijgewerkt naar 8. De update ging probleemloos en tot op heden ervaar ik ook geen problemen

[Church of Noise]

m-buurman schreef op donderdag 29 juni 2023 @ 23:27:
[...]


Ik heb op een NUC8i3BEH Proxmox headless draaien. Eenmaal geïnstalleerd heb ik alles afgekoppeld, verplaatst, gestart en nooit meer naar omgekeken. Wat zijn de problemen?

Wanneer er geen hdmi ingeplugd is, start ie niet, en als ie al draait en je haalt de stekker er uit, dan wordt ie onbereikbaar.

[zeroday]

Church of Noise schreef op donderdag 29 juni 2023 @ 20:05:
Ik heb een NUC8i3BEK met inderdaad een LSPCon chip die DP to HDMI doet...

Liefst van al zou ik natuurlijk hebben dat de HDMI FW update het ding fixt, want ik wil het systeem gewoon écht headless draaien zonder dat de HDMI meuk uberhaupt moet ingeschakeld zijn (ik vermoed dat die met de dummy in realiteit ingeschakeld blijft).

hier
1x DMI: Intel(R) Client Systems NUC8i7BEH/NUC8BEB, BIOS BECFL357.86A.0092.2023.0214.1114 02/14/2023

1x DMI: Intel(R) Client Systems NUC8i5BEH/NUC8BEB, BIOS BECFL357.86A.0092.2023.0214.1114 02/14/2023

geen issues zover ik kan zien, althans alles draait gewoon

[Church of Noise]

zeroday schreef op vrijdag 30 juni 2023 @ 13:17:
[...]


hier
1x DMI: Intel(R) Client Systems NUC8i7BEH/NUC8BEB, BIOS BECFL357.86A.0092.2023.0214.1114 02/14/2023

1x DMI: Intel(R) Client Systems NUC8i5BEH/NUC8BEB, BIOS BECFL357.86A.0092.2023.0214.1114 02/14/2023

geen issues zover ik kan zien, althans alles draait gewoon

Dank! Headless? En heb je PCIE ASPM aan staan?
Heb zelf ook de laatste BIOS overigens. Straks de HDMI update installeren, fingers crossed.

[zeroday]

Church of Noise schreef op vrijdag 30 juni 2023 @ 13:28:
[...]

Dank! Headless? En heb je PCIE ASPM aan staan?
Heb zelf ook de laatste BIOS overigens. Straks de HDMI update installeren, fingers crossed.

Headless.
PCIE ASPM ?
lspci -vvv | grep LnkCtl:
LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes, Disabled- CommClk-
LnkCtl: ASPM L1 Enabled; RCB 64 bytes, Disabled- CommClk-
LnkCtl: ASPM L1 Enabled; RCB 64 bytes, Disabled- CommClk+
LnkCtl: ASPM L1 Enabled; RCB 64 bytes, Disabled- CommClk+
LnkCtl: ASPM L1 Enabled; RCB 64 bytes, Disabled- CommClk+
LnkCtl: ASPM L1 Enabled; RCB 64 bytes, Disabled- CommClk+

Ik heb eigenlijk bij ontvangst van de 2e hands NUC's het naar default BIOS gebracht en de secure boot uitgezet en eigenlijk al het andere default gelaten.

Bij 1 NUC had ik hele vage problemen met allerlei errors omdat de vorige gebruiker allerlei instellingen voor de BIOS had veranderd. Na reset, no problem.

En zojuist m'n 3e NUC voorzien van een update naar PBS 3.0


PS.. enige issue wat ik had was een issue met de netwerk adapter in Proxmox en dat heb ik met een bepaalde regel op kunnen lossen. (ik verloor hier en daar de verbinding en op cluster niveau zag je de node rood worden)

[ Voor 10% gewijzigd door zeroday op 30-06-2023 14:04 ]

[m-buurman]

Church of Noise schreef op vrijdag 30 juni 2023 @ 13:28:
[...]

Dank! Headless? En heb je PCIE ASPM aan staan?
Heb zelf ook de laatste BIOS overigens. Straks de HDMI update installeren, fingers crossed.

Ik heb de een na nieuwste bios (90 ipv 92), secure boot uit en verder niks exotische en hetzelfde als zeroday aangeeft kwa ASPM.

[Loekie]

avdpeijl schreef op zondag 25 juni 2023 @ 12:01:
Hier wisselende ervaring met de upgrade naar proxmox v8.
Twee systemen met realtek ethernet: beide type RTL8111/8168/8411 rev 15.

Systeem 1: MSI B150 moederboard -> geen problemen, systeem draait stabiel op de nieuwe kernel met zo'n 10 containers
Systeem 2: Dell Wyse 5070 -> Na migratie: de realtek valt na een paar uur telkens uit. Beetje afhankelijk van volume denk ik. Op console staat alles nog up, maar geen ping meer mogelijk.

Gisteravond reboot op de Dell gedaan met kernel 5.15 en alles lijkt weer stabiel te draaien

Ik heb op deze mini-pc ook nog een intel i210 kaart geprikt zitten, maar deze was al onbetrouwbaar op proxmox 7 (dan na paar weken onverklaarbare uitval). Hardware issue, of toch driver issue? Op deze server draait alleen een opnsense VM.

Ik heb ook een paar 5070 met de SFP uitbreiding ipv wireless(dus 2* de RTL8168) en ben van builtin driver r8169 naar r8168 geswitched via het r8168-dkms pakket uit non-free.
Hier draaien ze na switch naar 8 weer stabiel, eerder was het na 4-6 uur over.

[Church of Noise]

m-buurman schreef op vrijdag 30 juni 2023 @ 15:03:
[...]


Ik heb de een na nieuwste bios (90 ipv 92), secure boot uit en verder niks exotische en hetzelfde als zeroday aangeeft kwa ASPM.

Ondertussen BIOS settings gereset (en nadien ook secure boot uitgeschakeld, en nadien ook BT, WAN en audio), BIOS is de laatste versie en sinds deze avond ook de HDMI. Nog steeds zelfde: bij unpluggen van HDMI kabel of in slaap gaan van het scherm (bij canvasblank=x na x seconden) verliest ie plots netwerk-connectiviteit. Bevestigd doordat zowel Home Assistant als de SSH sessie verbreken, en opnieuw inloggen lukt niet. M'n router ziet ook geen verkeer meer dan.

[nero355]

Church of Noise schreef op donderdag 29 juni 2023 @ 20:12:
Ook al aan gedacht, maar nog niet uitgevist hoe dat werkt in Linux (Debian)...
Ik laat t weten als ik het gevonden heb!

Zoiets :
- https://superuser.com/que...-graphic-card-on-os-level
- https://forum.proxmox.com...raphic-passthrough.30451/
Waarbij vooral dit belangrijk is :

# nano /etc/modprobe.d/blacklist.conf

code:

blacklist snd_hda_intel
blacklist snd_hda_codec_hdmi
blacklist i915

Dus let erop dat je ALLES wat er qua driver onderdelen wordt ingeladen wordt disabled :
- Videokaart
- Videokaart HDMI geluid
- Blijkbaar ook nog een losse Intel Sound driver

[thecompany]

Ik krijg vanmiddag de NUC 12 pro binnen en ben van plan om daar Proxmox op te draaien voor alle docker containers die ik nu op 3 aparte pi's draai.

Nu is het meeste mij wel duidelijk, alleen 1 vraagje, bestaat er zoiets als een Kubernetes Service/Ingress alternatief (nginx?) die automatisch op basis van een (LXC) container name het ip adres kan resolven? Dus plex.proxmox.local -> 192.168.2.45.

Of ontkom ik er niet aan om static IP adresses te gebruiken, via router of static in container, en mijn huidige nginx Docker container te gebruiken met hardcoded ips?

Edit: ik kom zojuist dit tegen: https://nginxproxymanager.com/ en dit script: https://github.com/tteck/...n/ct/nginxproxymanager.sh

Dit zou het al iets eenvoudiger maken om mijn services te hosten

[ Voor 15% gewijzigd door thecompany op 01-07-2023 10:01 ]

[Airw0lf]

thecompany schreef op zaterdag 1 juli 2023 @ 09:28:
Ik krijg vanmiddag de NUC 12 pro binnen en ben van plan om daar Proxmox op te draaien voor alle docker containers die ik nu op 3 aparte pi's draai.

Nu is het meeste mij wel duidelijk, alleen 1 vraagje, bestaat er zoiets als een Kubernetes Service/Ingress alternatief (nginx?) die automatisch op basis van een (LXC) container name het ip adres kan resolven? Dus plex.proxmox.local -> 192.168.2.45.

Ja hoor - zoiets kan je doen via dhcp en dns - vooropgesteld dat al je nodes een unieke en begrijpelijke/leesbare naam hebben.

Of ontkom ik er niet aan om static IP adresses te gebruiken, via router of static in container, en mijn huidige nginx Docker container te gebruiken met hardcoded ips?

Ligt er een beetje aan hoe je je Docker netwerk ingeregeld hebt.

Maar je zou een tussenvorm kunnen doen via zoiets als pihole:
(1) - je laat pihole via dhcp een IP adres toewijzen.
(2) - je zoekt via "settings => dhcp" de naam en ip adres op
(3) - kopieert die naar de static dhcp lease config
(4) - optioneel: naam en IP adres aanpassen
(5) - save

Vanaf dat moment heeft een device (fysiek of virtueel) een "vast" ip adres.

[ Voor 4% gewijzigd door Airw0lf op 01-07-2023 10:01 ]

[lithoijen]

Allen, ik kan even hulp gebruiken na mijn update naar proxmox 8.

Na de update kan ik de proxmox host niet meer bereiken (wel 1 van de vm's die erop draait) Na wat speurwerk (als 100% amateur) denk ik dat de update ervoor heeft gezorgd dat er is geschoven met de pci devices waardoor de setup niet meer klopt. Ik krijg het alleen niet opgelost. Iemand die even mee kan denken?

output van cat /etc/network/interfaces:

code:

# network interface settings; autogenerated
# Please do NOT modify this file directly, unless you know what
# you're doing.
#
# If you want to manage parts of the network configuration manually,
# please utilize the 'source' or 'source-directory' directives to do
# so.
# PVE will preserve these directives, but will NOT read its network
# configuration from sourced files, so do not attempt to move any of
# the PVE managed interfaces into external files!

/16 /2# network interface settings; autogenerated

auto lo
iface lo inet loopback

iface enp1s0 inet manual

iface enp2s0 inet manual

iface enp3s0 inet manual

iface enp4s0 inet manual

iface enp5s0 inet manual

iface enp6s0 inet manual

auto vmbr0
iface vmbr0 inet static
        address 192.168.1.2/24
        gateway 192.168.1.1
        bridge-ports enp7s0
        bridge-stp off
        bridge-fd 0

output van lspci

code:

lspci
00:00.0 Host bridge: Intel Corporation Device 4601 (rev 04)
00:02.0 VGA compatible controller: Intel Corporation Alder Lake-UP3 GT2 [Iris XeGraphics] (rev 0c)
00:04.0 Signal processing controller: Intel Corporation Alder Lake Innovation Platform Framework Processor Participant (rev 04)
00:06.0 PCI bridge: Intel Corporation 12th Gen Core Processor PCI Express x4 Controller #0 (rev 04)
00:0a.0 Signal processing controller: Intel Corporation Platform Monitoring Technology (rev 01)
00:0d.0 USB controller: Intel Corporation Alder Lake-P Thunderbolt 4 USB Controller (rev 04)
00:14.0 USB controller: Intel Corporation Alder Lake PCH USB 3.2 xHCI Host Controller (rev 01)
00:14.2 RAM memory: Intel Corporation Alder Lake PCH Shared SRAM (rev 01)
00:15.0 Serial bus controller: Intel Corporation Alder Lake PCH Serial IO I2C Controller #0 (rev 01)
00:15.1 Serial bus controller: Intel Corporation Alder Lake PCH Serial IO I2C Controller #1 (rev 01)
00:16.0 Communication controller: Intel Corporation Alder Lake PCH HECI Controller (rev 01)
00:17.0 SATA controller: Intel Corporation Alder Lake-P SATA AHCI Controller (rev 01)
00:19.0 Serial bus controller: Intel Corporation Alder Lake-P Serial IO I2C Controller #0 (rev 01)
00:19.1 Serial bus controller: Intel Corporation Alder Lake-P Serial IO I2C Controller #1 (rev 01)
00:1c.0 PCI bridge: Intel Corporation Device 51bc (rev 01)
00:1c.5 PCI bridge: Intel Corporation Device 51bd (rev 01)
00:1c.6 PCI bridge: Intel Corporation Device 51be (rev 01)
00:1c.7 PCI bridge: Intel Corporation Alder Lake PCH-P PCI Express Root Port #9(rev 01)
00:1d.0 PCI bridge: Intel Corporation Device 51b0 (rev 01)
00:1d.1 PCI bridge: Intel Corporation Alder Lake PCI Express x1 Root Port #10 (rev 01)
00:1f.0 ISA bridge: Intel Corporation Alder Lake PCH eSPI Controller (rev 01)
00:1f.3 Audio device: Intel Corporation Alder Lake PCH-P High Definition Audio Controller (rev 01)
00:1f.4 SMBus: Intel Corporation Alder Lake PCH-P SMBus Host Controller (rev 01)
00:1f.5 Serial bus controller: Intel Corporation Alder Lake-P PCH SPI Controller(rev 01)
01:00.0 Non-Volatile memory controller: Micron/Crucial Technology P2 NVMe PCIe SSD (rev 01)
02:00.0 Ethernet controller: Intel Corporation Ethernet Controller I226-V (rev 04)
03:00.0 Ethernet controller: Intel Corporation Ethernet Controller I226-V (rev 04)
04:00.0 Ethernet controller: Intel Corporation Ethernet Controller I226-V (rev 04)
05:00.0 Ethernet controller: Intel Corporation Ethernet Controller I226-V (rev 04)
06:00.0 Ethernet controller: Intel Corporation Ethernet Controller I226-V (rev 04)
07:00.0 Ethernet controller: Intel Corporation Ethernet Controller I226-V (rev 04)
root@pve:~#

ip a geeft:

code:

root@pve:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
7: enp7s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 34:1a:4c:03:a6:64 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::361a:4cff:fe03:a664/64 scope link
       valid_lft forever preferred_lft forever

via bovenstaande ip6 adres is de machine over ssh wel bereikbaar.

Iemand die me in de goede richting kan sturen?

[Airw0lf]

lithoijen schreef op zaterdag 1 juli 2023 @ 10:48:

output van cat /etc/network/interfaces:

code:

# network interface settings; autogenerated
# Please do NOT modify this file directly, unless you know what
# you're doing.
#
# If you want to manage parts of the network configuration manually,
# please utilize the 'source' or 'source-directory' directives to do
# so.
# PVE will preserve these directives, but will NOT read its network
# configuration from sourced files, so do not attempt to move any of
# the PVE managed interfaces into external files!

/16 /2# network interface settings; autogenerated

auto lo
iface lo inet loopback

iface enp1s0 inet manual

iface enp2s0 inet manual

iface enp3s0 inet manual

iface enp4s0 inet manual

iface enp5s0 inet manual

iface enp6s0 inet manual

auto vmbr0
iface vmbr0 inet static
        address 192.168.1.2/24
        gateway 192.168.1.1
        bridge-ports enp7s0
        bridge-stp off
        bridge-fd 0

Iemand die me in de goede richting kan sturen?

Probeer eens...

code:

iface enp7s0 inet manual

... toe te voegen aan /etc/network/interfaces

[lithoijen]

Dat lijkt niks te helpen, ben zo weer thuis dan doe ik een tweede poging dan weet ik het zeker.

[nero355]

thecompany schreef op zaterdag 1 juli 2023 @ 09:28:
Ik krijg vanmiddag de NUC 12 pro binnen en ben van plan om daar Proxmox op te draaien voor alle docker containers die ik nu op 3 aparte pi's draai.

Nu is het meeste mij wel duidelijk, alleen 1 vraagje, bestaat er zoiets als een Kubernetes Service/Ingress alternatief (nginx?) die automatisch op basis van een (LXC) container name het ip adres kan resolven? Dus plex.proxmox.local -> 192.168.2.45.

Of ontkom ik er niet aan om static IP adresses te gebruiken, via router of static in container, en mijn huidige nginx Docker container te gebruiken met hardcoded ips?

Edit: ik kom zojuist dit tegen: https://nginxproxymanager.com/ en dit script: https://github.com/tteck/...n/ct/nginxproxymanager.sh

Dit zou het al iets eenvoudiger maken om mijn services te hosten

Wat je wilt is inderdaad zoiets :

Airw0lf schreef op zaterdag 1 juli 2023 @ 09:59:
Ja hoor - zoiets kan je doen via dhcp en dns - vooropgesteld dat al je nodes een unieke en begrijpelijke/leesbare naam hebben.

Ligt er een beetje aan hoe je je Docker netwerk ingeregeld hebt.

Maar je zou een tussenvorm kunnen doen via zoiets als pihole:
(1) - je laat pihole via dhcp een IP adres toewijzen.
(2) - je zoekt via "settings => dhcp" de naam en ip adres op
(3) - kopieert die naar de static dhcp lease config
(4) - optioneel: naam en IP adres aanpassen
(5) - save

Vanaf dat moment heeft een device (fysiek of virtueel) een "vast" ip adres.

En dat is een tijdje geleden helemaal uitgekauwd voor iemand die totaal niet wist waar die mee bezig was dus zoek dat effe op/scroll een flink stukje terug

lithoijen schreef op zaterdag 1 juli 2023 @ 13:13:
Dat lijkt niks te helpen, ben zo weer thuis dan doe ik een tweede poging dan weet ik het zeker.

Het is precies wat je zelf zei :

lithoijen schreef op zaterdag 1 juli 2023 @ 10:48:
Na wat speurwerk (als 100% amateur) denk ik dat de update ervoor heeft gezorgd dat er is geschoven met de pci devices waardoor de setup niet meer klopt.

Dus je moet inderdaad effe dit toepassen op je setup :

Airw0lf schreef op zaterdag 1 juli 2023 @ 11:24:
Probeer eens...

code:

iface enp7s0 inet manual

... toe te voegen aan /etc/network/interfaces

[lithoijen]

@nero355 & @Airw0lf Zojuist geprobeerd, maar helaas, zonder effect (natuurlijk even gereboot na de aanpassing). Het vreemde is dat ik de machine wel via ssh kan benaderen op het ip6 adres (met en zonder aanpassingen aan de /etc/network/interfaces file) Overigens lukt dit alleen na een: ip link set enps0 up commando

Ik snap niet goed wat er misgaat en weet ook niet meer ion welke richting ik moet zoeken. Het gekke is, de Opnsense VM die op de proxmox server draait, waar 5 van de 6 netwerkpoorten naar zijn doorgezet via PCI passtrough werkt prima. Daar lijkt ook niks te zijn veranderd aan de PCI volgorde.

Misschien nog als aanvulling, ik draaide al de 6.2 kernel onder proxmox 7.4 daar heeft dus geen grote wijziging plaatsgevonden.

[ Voor 9% gewijzigd door lithoijen op 01-07-2023 15:35 ]

[Airw0lf]

lithoijen schreef op zaterdag 1 juli 2023 @ 15:30:
@nero355 & @Airw0lf Zojuist geprobeerd, maar helaas, zonder effect (natuurlijk even gereboot na de aanpassing). Het vreemde is dat ik de machine wel via ssh kan benaderen op het ip6 adres (met en zonder aanpassingen aan de /etc/network/interfaces file) Overigens lukt dit alleen na een: ip link set enps0 up commando

Ik snap niet goed wat er misgaat en weet ook niet meer ion welke richting ik moet zoeken. Het gekke is, de Opnsense VM die op de proxmox server draait, waar 5 van de 6 netwerkpoorten naar zijn doorgezet via PCI passtrough werkt prima. Daar lijkt ook niks te zijn veranderd aan de PCI volgorde.

Misschien nog als aanvulling, ik draaide al de 6.2 kernel onder proxmox 7.4 daar heeft dus geen grote wijziging plaatsgevonden.

Waar komt die enps0 ineens vandaan? Moet dat niet enp0s0 (o.i.d.) zijn?

Vanwaar die passthrough?

Bijzonder... wat geeft "cat /etc/network/interfaces" en "ip a"?
Graag de volledige output - idealiter zonder passthrough?

[ Voor 4% gewijzigd door Airw0lf op 01-07-2023 16:24 ]

[lithoijen]

@Airw0lf
Je hebt natuurlijk gelijk mbt enps0 dat is een typo, dat moest enp7s0 zijn.
Geen idee hoe ik de PCI passtrough tijdelijk uitzet mbv de CLI, mocht dit nodig zijn kun je me dan even een hint geven?

Bij deze nogmaals de outputs (staan boven ook al gepost, maar nu nogmaals voor het geval er iets is gewijzigd):

cat /etc/network/interfaces

code:

root@pve:~# cat /etc/network/interfaces
# network interface settings; autogenerated
# Please do NOT modify this file directly, unless you know what
# you're doing.
#
# If you want to manage parts of the network configuration manually,
# please utilize the 'source' or 'source-directory' directives to do
# so.
# PVE will preserve these directives, but will NOT read its network
# configuration from sourced files, so do not attempt to move any of
# the PVE managed interfaces into external files!

/16 /2# network interface settings; autogenerated

auto lo
iface lo inet loopback

iface enp1s0 inet manual

iface enp2s0 inet manual

iface enp3s0 inet manual

iface enp4s0 inet manual

iface enp5s0 inet manual

iface enp6s0 inet manual

iface enp7s0 inet manuel

auto vmbr0
iface vmbr0 inet static
        address 192.168.1.2/24
        gateway 192.168.1.1
        bridge-ports enp7s0
        bridge-stp off
        bridge-fd 0

ip a

code:

root@pve:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
7: enp7s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 34:1a:4c:03:a6:64 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::361a:4cff:fe03:a664/64 scope link
       valid_lft forever preferred_lft forever

ter volledigheid ook nog de lspci output:

code:

root@pve:~# lspci
00:00.0 Host bridge: Intel Corporation Device 4601 (rev 04)
00:02.0 VGA compatible controller: Intel Corporation Alder Lake-UP3 GT2 [Iris Xe Graphics] (rev 0c)
00:04.0 Signal processing controller: Intel Corporation Alder Lake Innovation Platform Framework Processor Participant (rev 04)
00:06.0 PCI bridge: Intel Corporation 12th Gen Core Processor PCI Express x4 Controller #0 (rev 04)
00:0a.0 Signal processing controller: Intel Corporation Platform Monitoring Technology (rev 01)
00:0d.0 USB controller: Intel Corporation Alder Lake-P Thunderbolt 4 USB Controller (rev 04)
00:14.0 USB controller: Intel Corporation Alder Lake PCH USB 3.2 xHCI Host Controller (rev 01)
00:14.2 RAM memory: Intel Corporation Alder Lake PCH Shared SRAM (rev 01)
00:15.0 Serial bus controller: Intel Corporation Alder Lake PCH Serial IO I2C Controller #0 (rev 01)
00:15.1 Serial bus controller: Intel Corporation Alder Lake PCH Serial IO I2C Controller #1 (rev 01)
00:16.0 Communication controller: Intel Corporation Alder Lake PCH HECI Controller (rev 01)
00:17.0 SATA controller: Intel Corporation Alder Lake-P SATA AHCI Controller (rev 01)
00:19.0 Serial bus controller: Intel Corporation Alder Lake-P Serial IO I2C Controller #0 (rev 01)
00:19.1 Serial bus controller: Intel Corporation Alder Lake-P Serial IO I2C Controller #1 (rev 01)
00:1c.0 PCI bridge: Intel Corporation Device 51bc (rev 01)
00:1c.5 PCI bridge: Intel Corporation Device 51bd (rev 01)
00:1c.6 PCI bridge: Intel Corporation Device 51be (rev 01)
00:1c.7 PCI bridge: Intel Corporation Alder Lake PCH-P PCI Express Root Port #9 (rev 01)
00:1d.0 PCI bridge: Intel Corporation Device 51b0 (rev 01)
00:1d.1 PCI bridge: Intel Corporation Alder Lake PCI Express x1 Root Port #10 (rev 01)
00:1f.0 ISA bridge: Intel Corporation Alder Lake PCH eSPI Controller (rev 01)
00:1f.3 Audio device: Intel Corporation Alder Lake PCH-P High Definition Audio Controller (rev 01)
00:1f.4 SMBus: Intel Corporation Alder Lake PCH-P SMBus Host Controller (rev 01)
00:1f.5 Serial bus controller: Intel Corporation Alder Lake-P PCH SPI Controller (rev 01)
01:00.0 Non-Volatile memory controller: Micron/Crucial Technology P2 NVMe PCIe SSD (rev 01)
02:00.0 Ethernet controller: Intel Corporation Ethernet Controller I226-V (rev 04)
03:00.0 Ethernet controller: Intel Corporation Ethernet Controller I226-V (rev 04)
04:00.0 Ethernet controller: Intel Corporation Ethernet Controller I226-V (rev 04)
05:00.0 Ethernet controller: Intel Corporation Ethernet Controller I226-V (rev 04)
06:00.0 Ethernet controller: Intel Corporation Ethernet Controller I226-V (rev 04)
07:00.0 Ethernet controller: Intel Corporation Ethernet Controller I226-V (rev 04)

klopt het dat de lijn:
iface enp1s0 inet manual
eruit mag, die netwerkinterface lijkt me niet meer te bestaan.

Is er verder nog meer info nodig?

code:

2023-07-01T17:11:23.917309+02:00 pve kernel: [    1.321012] igc 0000:02:00.0 enp2s0: renamed from eth0
2023-07-01T17:11:23.917309+02:00 pve kernel: [    1.360844] igc 0000:05:00.0 enp5s0: renamed from eth3
2023-07-01T17:11:23.917309+02:00 pve kernel: [    1.404794] igc 0000:04:00.0 enp4s0: renamed from eth2
2023-07-01T17:11:23.917310+02:00 pve kernel: [    1.436741] igc 0000:03:00.0 enp3s0: renamed from eth1
2023-07-01T17:11:23.917312+02:00 pve kernel: [    1.440679] usb 4-2: new SuperSpeed USB device number 2 using xhci_hcd
2023-07-01T17:11:23.917313+02:00 pve kernel: [    1.452683] igc 0000:06:00.0 enp6s0: renamed from eth4
2023-07-01T17:11:23.917313+02:00 pve kernel: [    1.462132] usb 4-2: New USB device found, idVendor=0951, idProduct=1666, bcdDevice= 1.10
2023-07-01T17:11:23.917313+02:00 pve kernel: [    1.462136] usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
2023-07-01T17:11:23.917313+02:00 pve kernel: [    1.462138] usb 4-2: Product: DataTraveler 3.0
2023-07-01T17:11:23.917314+02:00 pve kernel: [    1.462139] usb 4-2: Manufacturer: Kingston
2023-07-01T17:11:23.917314+02:00 pve kernel: [    1.462140] usb 4-2: SerialNumber: E0D55E6A0DEAE490C9B01298
2023-07-01T17:11:23.917317+02:00 pve kernel: [    1.468852] igc 0000:07:00.0 2023-07-01T17:11:23.917309+02:00 pve kernel: [    1.321012] igc 0000:02:00.0 en>
2023-07-01T17:11:23.917309+02:00 pve kernel: [    1.360844] igc 0000:05:00.0 enp5s0: renamed from eth3
2023-07-01T17:11:23.917309+02:00 pve kernel: [    1.404794] igc 0000:04:00.0 enp4s0: renamed from eth2
2023-07-01T17:11:23.917310+02:00 pve kernel: [    1.436741] igc 0000:03:00.0 enp3s0: renamed from eth1
2023-07-01T17:11:23.917312+02:00 pve kernel: [    1.440679] usb 4-2: new SuperSpeed USB device number 2 using xhci_hcd
2023-07-01T17:11:23.917313+02:00 pve kernel: [    1.452683] igc 0000:06:00.0 enp6s0: renamed from eth4
2023-07-01T17:11:23.917313+02:00 pve kernel: [    1.462132] usb 4-2: New USB device found, idVendor=0951, idProduct=1666, bcdDevice= 1.10
2023-07-01T17:11:23.917313+02:00 pve kernel: [    1.462136] usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
2023-07-01T17:11:23.917313+02:00 pve kernel: [    1.462138] usb 4-2: Product: DataTraveler 3.0
2023-07-01T17:11:23.917314+02:00 pve kernel: [    1.462139] usb 4-2: Manufacturer: Kingston
2023-07-01T17:11:23.917314+02:00 pve kernel: [    1.462140] usb 4-2: SerialNumber: E0D55E6A0DEAE490C9B01298
2023-07-01T17:11:23.917317+02:00 pve kernel: [    1.468852] igc 0000:07:00.0 enp7s0: renamed from eth5

[ Voor 22% gewijzigd door lithoijen op 01-07-2023 17:24 ]

[Airw0lf]

@lithoijen ik geloof dat de laatste twee berichten even langs elkaar heen gingen... daarom nogmaals...

Vanwaar die passthrough eigenlijk?
Hardware offloading met OpnSense is geen handige.
Tenminste niet als je gebruik maakt van DPI.

Ik mis een interface - bij de output van een eerdere lspci stonden er 6 ethernet controllers - in de laatste output 5.

Verwijder /var/log/syslog eens - en doe dan een reboot.
Wat zie je dan aan interfaces terugkomen in /var/log/syslog?

Mijn ervaring is dat er met enp-interfaces doorgaans niks gebeurd.
Dus tja - misschien eerst maar eens terug naar de basis?

Wat geeft "ip a" met passthrough helemaal uitgeschakeld?
Of nog beter - wat als je boot met Debian-Live-USB?

[ Voor 48% gewijzigd door Airw0lf op 01-07-2023 16:55 ]

[lithoijen]

@Airw0lf
Ik heb de network adapters (op 1 na, die voor proxmox is bedoeld) doorgezet naar Opnsense (daar staat hardware offloading trouwens uit). Daarin heb ik een ergens een tutoral gevolgd, leek me logisch, op deze manier hangt mijn proxmox computer ook niet direct aan het internet, maar zit Opnsense ertussen als een firewall. DPI heb ik voor nu niet aanstaan, dat is eventueel een optie voor in de toekomst.

De missende interface heb ik zojuist even nagekeken, ook dat is een kopie past foutje, ik pas bovenstaande post even aan.

Ik wil ip a best even draaien zonder passtrough, maar dan moet ik eerst even uitzoeken hoe ik dat uitzet in de cli. Daar kom ik op terug zodra ik dat heb uitgevogeld.


Ik kom wat geks tegen in de configuratiefile in de qemu-server directory: Lijkt me toch logisch te zijn.

code:

agent: 1
boot: order=scsi0
cores: 2
cpu: host
hostpci0: 0000:02:00.0
hostpci1: 0000:03:00.0
hostpci2: 0000:04:00.0
hostpci3: 0000:05:00.0
hostpci4: 0000:06:00.0
memory: 8048
meta: creation-qemu=7.2.0,ctime=1684268202
name: opnsense2
numa: 0
onboot: 1
ostype: l26
scsi0: backup:103/vm-103-disk-0.qcow2,iothread=1,size=40G
scsihw: virtio-scsi-single
smbios1: uuid=2632349e-dd08-48de-8770-a89f88b3c929
sockets: 1
startup: order=1
vmgenid: 8f4ee5c2-3f6e-4865-b72d-56f56bb48b7b

Kloppen die hostpci benamingen van mijn Opensense VM, daar werkt wel alles zoals vanouds.

Debian live cd heb ik nog niet geprobeerd.

Wat betreft /var/log/syslog dat is een heel boek maar ik vind onder andere:

code:

2023-07-01T17:12:59.849864+02:00 pve kernel: [  101.910255] igc 0000:07:00.0 2023-07-01T17:12:59.849864+02:00 pve kernel: [  101.910255] igc 0000:07:00.0 en>
2023-07-01T17:12:59.849901+02:00 pve kernel: [  101.910487] IPv6: ADDRCONF(NETDEV_CHANGE): enp7s0: link becomes ready
enp7s0: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
2023-07-01T17:12:59.849901+02:00 pve kernel: [  101.910487] IPv6: ADDRCONF(NETDEV_CHANGE): enp7s0: link becomes ready

2023-07-01T17:11:23.917309+02:00 pve kernel: [    1.360844] igc 0000:05:00.0 enp5s0: renamed from eth3
2023-07-01T17:11:23.917309+02:00 pve kernel: [    1.404794] igc 0000:04:00.0 enp4s0: renamed from eth2
2023-07-01T17:11:23.917310+02:00 pve kernel: [    1.436741] igc 0000:03:00.0 enp3s0: renamed from eth1
2023-07-01T17:11:23.917313+02:00 pve kernel: [    1.452683] igc 0000:06:00.0 enp6s0: renamed from eth4
2023-07-01T17:11:23.917317+02:00 pve kernel: [    1.468852] igc 0000:07:00.0 enp7s0: renamed from eth5

@nero355 Heb jij misschien nog tips?

[ Voor 65% gewijzigd door lithoijen op 01-07-2023 17:34 ]

[cville]

Ik denk dat ik een ProxMox netwerk probleem heb.

Ik probeer een Python app die mijn PV inverters via modbus uitleest, van een Intel NUC naar een ProxMox lxc te migreren. Ik krijg de volgende foutmelding van het module pymodbus:

code:

ERROR reading registers: Exception Response(131, 3, GatewayNoResponse)

Er is wel verbinding naar de inverters zoals uit het volgende blijkt:

code:

Connection to Modbus server established. Socket ('192.168.178.220', 37492)

maar er komt geen data terug. Ik kan de code wel draaien op een willekeurig bare metal platform (Windows, Ubuntu) maar niet op een container.

Hoe pak ik dit aan?

[ElMacaroni]

in mijn "ip a" staat vmbr0 er tussen.

code:

6: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 46:24:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 192.168.123.123/24 brd 192.168.123.255 scope global vmbr0
       valid_lft forever preferred_lft forever
    inet6 2a02:a462:a1ca:1:abcd:abcd:fe97:f3ae/64 scope global dynamic mngtmpaddr
       valid_lft 7147sec preferred_lft 3547sec
    inet6 fe80::4424:abcd:abcdf3ae/64 scope link
       valid_lft forever preferred_lft forever

Doe eens "ifup vmbr0" en dan "ip a" ?

[ Voor 76% gewijzigd door ElMacaroni op 01-07-2023 17:48 ]

[cville]

code:

pi@p1[~] ifup vmbr0
ifup: unknown interface vmbr0

pi@p1[~] ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether e6:e9:53:43:08:d7 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.178.80/24 metric 1024 brd 192.168.178.255 scope global dynamic eth0
       valid_lft 52496sec preferred_lft 52496sec
    inet6 fe80::e4e9:53ff:fe43:8d7/64 scope link
       valid_lft forever preferred_lft forever

En nu?

[Airw0lf]

@lithoijen :
Wat me opvalt is dat bij alle stappen de vmbr0 nergens terug te vinden is.
Ook niet nadat de bijbehorende fysieke poort opgenomen is in /etc/network/interfaces en passthrough is uitgeschakeld.

Je zou bijna zeggen dat de bridge-utils weggevallen zijn...

Daarom:
Wat is de output van "brctl show"?
Wat geeft "apt install bridge-utils"?

[ Voor 3% gewijzigd door Airw0lf op 01-07-2023 18:16 ]

[ElMacaroni]

Of een uitkomst van een dmesg | grep eth0 ?

[Airw0lf]

@cville :

Basic Proxmox huiswerk gaan maken?

Heb je in /etc/network/interfaces wel een vmbr0 interface aangemaakt?
En voor welke fysieke interface?

[lithoijen]

@ElMacaroni ifup vmbro geeft een permission denied, ook als root
@Airw0lf
brctl show doet niks
"apt install bridge-utils" geeft een foutmelding en het advies om een dpkg -configure -a te doen

En alles werkt weer!

Blijkbaar toch ergens blijven hangen in de update. Allemaal maar met name @Airw0lf bedankt voor de hulp!

[ElMacaroni]

En wat doet "ip a" nu?

[lithoijen]

root@pve:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
7: enp7s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master vmbr0 state UP group default qlen 1000
link/ether 34:1a:4c:03:a6:64 brd ff:ff:ff:ff:ff:ff
8: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 34:1a:4c:03:a6:64 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.2/24 scope global vmbr0
valid_lft forever preferred_lft forever
inet6 fe80::361a:4cff:fe03:a664/64 scope link
valid_lft forever preferred_lft forever
9: tap100i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr0 state UNKNOWN group default qlen 1000
link/ether 4e:5c:4e:1f:e4:3e brd ff:ff:ff:ff:ff:ff
10: tap104i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master fwbr104i0 state UNKNOWN group default qlen 1000
link/ether 52:0d:d4:6f:ba:64 brd ff:ff:ff:ff:ff:ff
11: fwbr104i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether f6:4a:b5:3d:da:c7 brd ff:ff:ff:ff:ff:ff
12: fwpr104p0@fwln104i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
link/ether fe:48:ab:de:09:f4 brd ff:ff:ff:ff:ff:ff
13: fwln104i0@fwpr104p0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master fwbr104i0 state UP group default qlen 1000
link/ether 5a:12:37:a3:dd:0f brd ff:ff:ff:ff:ff:ff

[cville]

Airw0lf schreef op zaterdag 1 juli 2023 @ 18:22:
@cville :

Basic Proxmox huiswerk gaan maken?

Heb je in /etc/network/interfaces wel een vmbr0 interface aangemaakt?
En voor welke fysieke interface?

Dank voor je reactie. Volgens mij wel. Hier wat data uit de GUI:

name: eth0
bridge: vmbr0
vlan tag: no vlan

Is dat wat je bedoelt?

[Airw0lf]

cville schreef op zaterdag 1 juli 2023 @ 19:43:
[...]

Dank voor je reactie. Volgens mij wel. Hier wat data uit de GUI:

name: eth0
bridge: vmbr0
vlan tag: no vlan

Is dat wat je bedoelt?

Inderdaad - die ja.

Waarbij bij eth0 alle velden leegblijven en autostart uit staat.
De IP gegevens van eth0 moet je dan invullen bij vmbr0.
Waarbij je bij vmbr0 autostart aan zet en via bridge ports weer wijst naar eth0.

Dat zou de zaak in beweging moeten brengen.

[ Voor 5% gewijzigd door Airw0lf op 01-07-2023 21:00 ]

[nero355]

lithoijen schreef op zaterdag 1 juli 2023 @ 16:25:
Geen idee hoe ik de PCI passtrough tijdelijk uitzet mbv de CLI, mocht dit nodig zijn kun je me dan even een hint geven?

Voor mijn eigen nieuwgierigheid : Kon je dan wel of niet via het IPv6 Link-Local Address bij de webGUI komen ??

[cville]

Airw0lf schreef op zaterdag 1 juli 2023 @ 20:57:
[...]


Inderdaad - die ja.

Waarbij bij eth0 alle velden leegblijven en autostart uit staat.
De IP gegevens van eth0 moet je dan invullen bij vmbr0.
Waarbij je bij vmbr0 autostart aan zet en via bridge ports weer wijst naar eth0.

Dat zou de zaak in beweging moeten brengen.

Je brengt me aan het twijfelen. Hierbij een screenshot. Wat moet ik nog toevoegen?

[lithoijen]

nero355 schreef op zaterdag 1 juli 2023 @ 21:15:
[...]

Voor mijn eigen nieuwgierigheid : Kon je dan wel of niet via het IPv6 Link-Local Address bij de webGUI komen ??

Nee dat leek niet te werken, al heb ik daar ook niet heel veel tijd in gestoken. het ip6 adres + poortnummer werkte in ieder geval niet. SSH op ip6 ging gelukkig wel, kon ik tenminste ctrl-c, ctrl-v ipv alles overtypen of fotograferen

[ Voor 12% gewijzigd door lithoijen op 01-07-2023 22:26 ]

[Airw0lf]

cville schreef op zaterdag 1 juli 2023 @ 21:31:
[...]

Je brengt me aan het twijfelen. Hierbij een screenshot. Wat moet ik nog toevoegen?

[Afbeelding]

Ik herken die afbeelding niet - maar DHCP moet voor eth0 in ieder geval uit staan.

Kan je inloggen met ssh en dan cat /etc/network/interfaces doen?
Dat schakelt sneller omdat ik je dan meteen kan vertellen welke aanpassingen er nodig zijn.

[cville]

Airw0lf schreef op zaterdag 1 juli 2023 @ 22:48:
[...]


Ik herken die afbeelding niet - maar DHCP moet voor eth0 in ieder geval uit staan.

Kan je inloggen met ssh en dan cat /etc/network/interfaces doen?
Dat schakelt sneller omdat ik je dan meteen kan vertellen welke aanpassingen er nodig zijn.

Zeker:

code:

pi@p1[~] cat /etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)
# Include files from /etc/network/interfaces.d:
source /etc/network/interfaces.d/*

/etc/network/interfaces.d is leeg. Ziet er een beetje mager uit.

[cville]

Airw0lf schreef op zaterdag 1 juli 2023 @ 22:48:
[...]


Ik herken die afbeelding niet - maar DHCP moet voor eth0 in ieder geval uit staan.

Kan je inloggen met ssh en dan cat /etc/network/interfaces doen?
Dat schakelt sneller omdat ik je dan meteen kan vertellen welke aanpassingen er nodig zijn.

T.a.v. dhcp: de container krijgt een vast IP adres via de router (192.168.178.80). Is dat nog steeds een probleem?

[Airw0lf]

cville schreef op zondag 2 juli 2023 @ 09:49:
[...]

Zeker:

code:

pi@p1[~] cat /etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)
# Include files from /etc/network/interfaces.d:
source /etc/network/interfaces.d/*

/etc/network/interfaces.d is leeg. Ziet er een beetje mager uit.

Inderdaad - vul dat eens aan met:

code:

iface eth0 inet manual

auto vmbr0
iface vmbr0 inet dhcp
        bridge-ports eth0
        bridge-stp off
        bridge-fd 0

En dan een reboot; gevolgd door een login met "ip a".

Wat rolt er dan uit?

Bovenstaand met de aanname dat de output afkomstig is van Proxmox - en niet van een LXC container.

Mij viel de prompt ook op: pi@p1
Tjekvraag: wat wil pi zeggen?
Ik hoop niet dat je Proxmox samen met pihole hebt geinstalleerd...

[ Voor 14% gewijzigd door Airw0lf op 02-07-2023 10:16 ]

[cville]

Airw0lf schreef op zondag 2 juli 2023 @ 10:08:
[...]


Inderdaad - vul dat eens aan met:

code:

iface eth0 inet manual

auto vmbr0
iface vmbr0 inet dhcp
        bridge-ports eth0
        bridge-stp off
        bridge-fd 0

En dan een reboot; gevolgd door een login met "ip a".

Wat rolt er dan uit?

code:

pi@p1[~] ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0@if12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether e6:e9:53:43:08:d7 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.178.80/24 metric 1024 brd 192.168.178.255 scope global dynamic eth0
       valid_lft 86371sec preferred_lft 86371sec
    inet6 fe80::e4e9:53ff:fe43:8d7/64 scope link
       valid_lft forever preferred_lft forever

[Airw0lf]

cville schreef op zondag 2 juli 2023 @ 10:13:
[...]

code:

pi@p1[~] ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0@if12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether e6:e9:53:43:08:d7 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 192.168.178.80/24 metric 1024 brd 192.168.178.255 scope global dynamic eth0
       valid_lft 86371sec preferred_lft 86371sec
    inet6 fe80::e4e9:53ff:fe43:8d7/64 scope link
       valid_lft forever preferred_lft forever

Loop nog eens langs mijn vorige post - dit lijkt de output van een LXC container - niet die van een Proxmox server...

[cville]

Airw0lf schreef op zondag 2 juli 2023 @ 10:08:
[...]


Inderdaad - vul dat eens aan met:

code:

iface eth0 inet manual

auto vmbr0
iface vmbr0 inet dhcp
        bridge-ports eth0
        bridge-stp off
        bridge-fd 0

En dan een reboot; gevolgd door een login met "ip a".

Wat rolt er dan uit?

Bovenstaand met de aanname dat de output afkomstig is van Proxmox - en niet van een LXC container.

Mij viel de prompt ook op: pi@p1
Tjekvraag: wat wil pi zeggen?
Ik hoop niet dat je Proxmox samen met pihole hebt geinstalleerd...

pi is mijn standaard non-root user name die ik oorspronkelijk gebruikte toen al mijn servers RPI's waren. Ben ik blijven gebruiken omdat het lekker kort is. Ik draai geen pihole. Je opmerking over de host is correct maar zag ik pas na een refresh. Ik ga nu terug naar het begin en je de gevraagde info leveren maar nu van de host.

[cville]

@Airw0lf Zo beter?

code:

pi@nea[~] cat /etc/network/interfaces
auto lo
iface lo inet loopback

iface eno1 inet manual

auto vmbr0
iface vmbr0 inet static
        address 192.168.178.209/24
        gateway 192.168.178.1
        bridge-ports eno1
        bridge-stp off
        bridge-fd 0

[Airw0lf]

cville schreef op zondag 2 juli 2023 @ 10:27:
@Airw0lf Zo beter?

code:

pi@nea[~] cat /etc/network/interfaces
auto lo
iface lo inet loopback

iface eno1 inet manual

auto vmbr0
iface vmbr0 inet static
        address 192.168.178.209/24
        gateway 192.168.178.1
        bridge-ports eno1
        bridge-stp off
        bridge-fd 0

Inderdaad - dit is wat ik onder Proxmox zou verwachten.

Een LXC container werkt vrijwel altijd met eth0.
Bij Proxmox kan dat ook - maar dan moet je iets aanpassen in grub.

[cville]

Airw0lf schreef op zondag 2 juli 2023 @ 12:43:
[...]


Inderdaad - dit is wat ik onder Proxmox zou verwachten.

Een LXC container werkt vrijwel altijd met eth0.
Bij Proxmox kan dat ook - maar dan moet je iets aanpassen in grub.

Kun je me nu een hint geven t.a.v. de oorspronkelijke modbus error? Heb je meer diagnostics nodig?

[Airw0lf]

cville schreef op zondag 2 juli 2023 @ 12:46:
[...]

Kun je me nu een hint geven t.a.v. de oorspronkelijke modbus error? Heb je meer diagnostics nodig?

En in je laatste post over je Proxmox config staat 192.168.178.1 als gateway.
Misschien zit daar iets? Is dat ook ingesteld bij alle andere apparaten?

Staat er nog ergens een niet-meer-bestaand DNS server adres?

De inverters hier hebben naast de modbus ook een ingebouwde webinterface.
Bij jou ook? Werkt dat deel wel?

Heb je er een firewall tussen staan?
Of hoe staat dit ingesteld in Proxmox en in de container?

[ Voor 28% gewijzigd door Airw0lf op 02-07-2023 13:03 ]

[cville]

Airw0lf schreef op zondag 2 juli 2023 @ 12:57:
[...]


Ergens in een post spreek je over een gateway met IP adres 192.168.178.80.
En in je laatste post over je Proxmox config staat 192.168.178.1 als gateway.
Misschien zit daar iets?

Heb je er een firewall tussen staan? Of hoe staat dit ingesteld in Proxmox en de container?

192.168.178.80 is het IP adres van de LXC container p1; ik kan me niet herinneren daarover als een gateway gesproken te hebben. De foutmelding "ERROR reading registers: Exception Response(131, 3, GatewayNoResponse)" noemt wel een gateway maar ik kan er niet achter komen wat hiermee bedoeld wordt.

192.168.178.1 is het IP adres van mijn router.

Ik heb nooit iets aan de firewall instellingen van de host of de container gedaan; die staan dus allemaal default.

[Airw0lf]

@cville
Wat is de gateway die genoemd wordt?

Wat gebeurd als je de fw van Proxmox en de container uitschakelt?

[cville]

Airw0lf schreef op zondag 2 juli 2023 @ 13:10:
@cville
Wat is de gateway die genoemd wordt?

Dat was ook mijn vraag; ik kan ondanks uitvoerig zoeken, geen antwoord vinden.

Wat gebeurd als je de fw van Proxmox en de container uitschakelt?

Ik heb net zowel de docs als de GUI nagekeken en geconcludeerd dat de FW uit staat (is default).

[Airw0lf]

cville schreef op zondag 2 juli 2023 @ 13:18:
[...]

Dat was ook mijn vraag; ik kan ondanks uitvoerig zoeken, geen antwoord vinden.

[...]

Ik heb net zowel de docs als de GUI nagekeken en geconcludeerd dat de FW uit staat (is default).

Tis een Python stack toch - kan je niet een python "iets" lanceren wat de gateway opvraagt van de modbus? En anders op het apparaat gaan kijken bij de modbus parameters?

Kan je een TCP-ping doen naar die modbus zijn IP en poortnummer? Wat geeft dat als resultaat?

Andere invalshoek: wat als je er een VM van maakt? Werkt het dan wel?

[ Voor 22% gewijzigd door Airw0lf op 02-07-2023 14:04 ]

[nero355]

cville schreef op zaterdag 1 juli 2023 @ 17:41:
Ik denk dat ik een ProxMox netwerk probleem heb.

Ik denk dat je een totaal ander probleem hebt, want dit :

Ik probeer een Python app die mijn PV inverters via modbus uitleest, van een Intel NUC naar een ProxMox lxc te migreren. Ik krijg de volgende foutmelding van het module pymodbus:

code:

ERROR reading registers: Exception Response(131, 3, GatewayNoResponse)

Er is wel verbinding naar de inverters zoals uit het volgende blijkt:

code:

Connection to Modbus server established. Socket ('192.168.178.220', 37492)

maar er komt geen data terug.

Lijkt niks te maken te hebben met de netwerk gerelateerde instellingen van je Proxmox Server als ik wat rond ga zoeken op het internet

Ik kan de code wel draaien op een willekeurig bare metal platform (Windows, Ubuntu) maar niet op een container.

Hoe pak ik dit aan?

Wie of wat is dat 192.168.178.220 apparaat precies ?!

Volgens mij zit je meer met een soort rechten probleem of een algemene toegang tot een apparaat probleem of zo...


Disclaimer :
Ik doe niks met dat soort apparatuur, maar sinds je voor lokaal verkeer geen Gateway of DNS Servers nodig hebt lijkt dit meer een fout in de configuratie van het hele Python/PV uitleesgebeuren te zijn

[cville]

nero355 schreef op zondag 2 juli 2023 @ 16:15:
[...]

Ik denk dat je een totaal ander probleem hebt, want dit :

[...]

Lijkt niks te maken te hebben met de netwerk gerelateerde instellingen van je Proxmox Server als ik wat rond ga zoeken op het internet


[...]

Wie of wat is dat 192.168.178.220 apparaat precies ?!

Dat is de container waarvan ik op dat moment mijn programma draaide. Eerst terug naar de gateway. Na meer onderzoek is mijn conclusie dat hiermee het apparaat bedoeld wordt dat ModBus TCP praat en de ruwe data van de sensoren vertaald naar TCP waarna pymodbus er wat mee kan. Mijn inverters hebben IP nummers 192.168.178.110 en 113 en zijn door meerdere applicaties benaderbaar maar wel allemaal bare metal applicaties.

Uitgangspunten zijn:
1. mijn code draait op beide bare-metal platformen die ik tot mijn beschikking heb maar niet op een container (meerdere containers geprobeerd).
2. op de container laat mijn code wel zien dat er een connectie opgebouwd wordt maar faalt wanneer de inverters data terugsturen.

Nou heb ik zeer beperkte netwerk kennis maar het is voor mij moeilijk voor te stellen dat het probleem ergens anders ligt dan de ProxMox netwerk configuratie. Het is wel zo dat ik vanuit een aantal containers probleemloos andere devices (niet-modbus) kan benaderen. Voorbeelden zijn mijn P1 port en mijn Kia (via API).

Mijn dank voor het meedenken maar ik kom nog niet verder. Kun je argumenten aanvoeren waarom na het bovenstaande gelezen te hebben, dit geen netwerk probleem is?

Volgens mij zit je meer met een soort rechten probleem of een algemene toegang tot een apparaat probleem of zo...


Disclaimer :
Ik doe niks met dat soort apparatuur, maar sinds je voor lokaal verkeer geen Gateway of DNS Servers nodig hebt lijkt dit meer een fout in de configuratie van het hele Python/PV uitleesgebeuren te zijn

[nero355]

cville schreef op zondag 2 juli 2023 @ 16:33:
Mijn dank voor het meedenken maar ik kom nog niet verder.
Kun je argumenten aanvoeren waarom na het bovenstaande gelezen te hebben, dit geen netwerk probleem is?

Dat heb je zelf ondertussen al gevonden net als ik met wat gesearch :

Eerst terug naar de gateway.

Na meer onderzoek is mijn conclusie dat hiermee het apparaat bedoeld wordt dat ModBus TCP praat en de ruwe data van de sensoren vertaald naar TCP waarna pymodbus er wat mee kan.

Uitgangspunten zijn:
1. mijn code draait op beide bare-metal platformen die ik tot mijn beschikking heb maar niet op een container (meerdere containers geprobeerd).
2. op de container laat mijn code wel zien dat er een connectie opgebouwd wordt maar faalt wanneer de inverters data terugsturen.

Ga dan eens zoeken waarom dat precies gebeurt ?!

In de LXC zou je bijvoorbeeld kunnen checken of er geen firewall regels door een of andere installatie script zijn toegevoegd :

# iptables -L 

of wat er ook actief is in je LXC : ufw ?! nftables ?!

Het is wel zo dat ik vanuit een aantal containers probleemloos andere devices (niet-modbus) kan benaderen.
Voorbeelden zijn mijn P1 port en mijn Kia (via API).

Ga dan dus eens kijken wat de boel tegenhoudt : https://modbus.org/docs/M...mentation_Guide_V1_0b.pdf
Vermeldt bijvoorbeeld een Access Control Module in hoofdstuk 4.2.3 die me heel erg doet denken aan NFS instellingen die bepalen welke IP adressen er allemaal bij de data mogen komen

[cville]

Airw0lf schreef op zondag 2 juli 2023 @ 13:46:
[...]


Tis een Python stack toch - kan je niet een python "iets" lanceren wat de gateway opvraagt van de modbus? En anders op het apparaat gaan kijken bij de modbus parameters?

Kan je een TCP-ping doen naar die modbus zijn IP en poortnummer? Wat geeft dat als resultaat?

Hierbij ping & nmap data van mijn NUC (bare metal Ubuntu):

code:

pi@eon:[~]: nmap -p 502 192.168.178.113

Starting Nmap 7.60 ( https://nmap.org ) at 2023-07-02 16:45 CEST
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 3.05 seconds
pi@eon:[~]: nmap -p 502 192.168.178.110

Starting Nmap 7.60 ( https://nmap.org ) at 2023-07-02 16:46 CEST
Nmap scan report for SMA3002969674-4.fritz.box (192.168.178.110)
Host is up (0.00045s latency).

PORT    STATE SERVICE
502/tcp open  mbap

Nmap done: 1 IP address (1 host up) scanned in 0.04 seconds
pi@eon:[~]: ping 192.168.178.113
PING 192.168.178.113 (192.168.178.113) 56(84) bytes of data.
64 bytes from 192.168.178.113: icmp_seq=1 ttl=64 time=0.568 ms
64 bytes from 192.168.178.113: icmp_seq=2 ttl=64 time=0.442 ms
^C
--- 192.168.178.113 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 0.442/0.505/0.568/0.063 ms
pi@eon:[~]: ping 192.168.178.110
PING 192.168.178.110 (192.168.178.110) 56(84) bytes of data.
64 bytes from 192.168.178.110: icmp_seq=1 ttl=64 time=0.433 ms
64 bytes from 192.168.178.110: icmp_seq=2 ttl=64 time=4.06 ms
64 bytes from 192.168.178.110: icmp_seq=3 ttl=64 time=0.412 ms
^C
--- 192.168.178.110 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2029ms
rtt min/avg/max/mdev = 0.412/1.636/4.065/1.717 ms
pi@eon:[~]:

En hierbij hetzelfde vanaf de container:

code:

pi@p1[~] nmap -p 502 192.168.178.113
Starting Nmap 7.80 ( https://nmap.org ) at 2023-07-02 16:50 CEST
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 3.02 seconds
pi@p1[~] nmap -p 502 192.168.178.110
Starting Nmap 7.80 ( https://nmap.org ) at 2023-07-02 16:50 CEST
Nmap scan report for SMA3002969674-4.fritz.box (192.168.178.110)
Host is up (0.0047s latency).

PORT    STATE SERVICE
502/tcp open  mbap

Nmap done: 1 IP address (1 host up) scanned in 0.04 seconds
pi@p1[~] ping 192.168.178.113
PING 192.168.178.113 (192.168.178.113) 56(84) bytes of data.
64 bytes from 192.168.178.113: icmp_seq=1 ttl=64 time=1.02 ms
64 bytes from 192.168.178.113: icmp_seq=2 ttl=64 time=0.569 ms
64 bytes from 192.168.178.113: icmp_seq=3 ttl=64 time=0.621 ms
^C
--- 192.168.178.113 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2010ms
rtt min/avg/max/mdev = 0.569/0.738/1.024/0.203 ms
pi@p1[~] ping 192.168.178.110
PING 192.168.178.110 (192.168.178.110) 56(84) bytes of data.
64 bytes from 192.168.178.110: icmp_seq=1 ttl=64 time=0.543 ms
64 bytes from 192.168.178.110: icmp_seq=2 ttl=64 time=0.654 ms
64 bytes from 192.168.178.110: icmp_seq=3 ttl=64 time=0.765 ms
^C
--- 192.168.178.110 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2029ms
rtt min/avg/max/mdev = 0.543/0.654/0.765/0.090 ms

Ik kan het verschil tussen 110 en 113 niet verklaren. Alle productie code die ik vanaf mijn NUC draai werkt naar beide inverters.

Andere invalshoek: wat als je er een VM van maakt? Werkt het dan wel?

Dat kan ik eventueel later nog proberen. Ik moet dan eerst een VM aanmaken want ik gebruikt uitsluitend containers.

[Airw0lf]

@cville
Ik zag in je posts deze langskomen: SMA3002969674-4
Wat erop wijst dat je dezelfde soort inverters gebruikt als ik.
Welke types heb je precies?

Een VM activeren is eigenlijk niet zo heel veel meer werk dan een LXC container.
Scheelt minder dan een uur - in ieder geval minder dan wat je er tot nu toe aan tijd in hebt zitten... zo is mijn inschatting...

Andere suggestie/idee:
Ik heb hier zowel VM's als LXC containers draaien.
Maar niks met Python en het via Modbus uitlezen van cijfers.
Wat zou ik aan mijn kant moeten regelen om dezelfde dingen te kunnen doen als jij?
Zodat ik aan mijn kant via zowel de VM als de LXC container kan tjekke of ik tegen dezelfde dingen aanloop?

Aangezien dit redelijk off-topic is lijkt het me handig(er) om dit via DM's te doen - mocht je dit zien zitten. We kunnen altijd hier posten wat de oplossing is geweest.

[ Voor 18% gewijzigd door Airw0lf op 02-07-2023 17:16 ]

[cville]

nero355 schreef op zondag 2 juli 2023 @ 16:48:
[...]

Dat heb je zelf ondertussen al gevonden net als ik met wat gesearch :

[...]




[...]

Ga dan eens zoeken waarom dat precies gebeurt ?!

En ik maar denken dat ik daar al de hele middag mee bezig ben

In de LXC zou je bijvoorbeeld kunnen checken of er geen firewall regels door een of andere installatie script zijn toegevoegd :

# iptables -L 

of wat er ook actief is in je LXC : ufw ?! nftables ?!

iptables -L geeft geen output en alle firewalls staan uit (default)

[...]

Ga dan dus eens kijken wat de boel tegenhoudt : https://modbus.org/docs/M...mentation_Guide_V1_0b.pdf
Vermeldt bijvoorbeeld een Access Control Module in hoofdstuk 4.2.3 die me heel erg doet denken aan NFS instellingen die bepalen welke IP adressen er allemaal bij de data mogen komen

Ik heb nog eens naar de documentatie van de SMA inverters gekeken maar er is geen access control en ook geen mogelijkheid om IP nummers te configureren.

[Airw0lf]

cville schreef op zondag 2 juli 2023 @ 17:16:
[...]

Ik heb nog eens naar de documentatie van de SMA inverters gekeken maar er is geen access control en ook geen mogelijkheid om IP nummers te configureren.

Welke modellen gebruik je dan?

Want de mijne hebben dat wel - sterker nog de webui en modbus hebben aparte toegangscontrole. Met daarnaast op 3 niveaus IP adressen:
- de inverter als AP
- de inverter als wifi-client
- de inverter via UTP

[cville]

Airw0lf schreef op zondag 2 juli 2023 @ 17:11:
@cville
Ik zag in je posts deze langskomen: SMA3002969674-4
Wat erop wijst dat je dezelfde soort inverters gebruikt als ik.
Welke types heb je precies?

Een VM activeren is eigenlijk niet zo heel veel meer werk dan een LXC container.
Scheelt minder dan een uur - in ieder geval minder dan wat je er tot nu toe aan tijd in hebt zitten... zo is mijn inschatting...

Andere suggestie/idee:
Ik heb hier zowel VM's als LXC containers draaien.
Maar niks met Python en het via Modbus uitlezen van cijfers.
Wat zou ik aan mijn kant moeten regelen om dezelfde dingen te kunnen doen als jij?
Zodat ik aan mijn kant via zowel de VM als de LXC container kan tjekke of ik tegen dezelfde dingen aanloop?

Aangezien dit redelijk off-topic is lijkt het me handig(er) om dit via DM's te doen - mocht je dit zien zitten. We kunnen altijd hier posten wat de oplossing is geweest.

Mijn inverters staan in mijn signature. Je aanbod om via DM verder te gaan neem ik graag aan. Ik kan er alleen op z'n vroegst vanavond pas mee verder.

[cville]

Airw0lf schreef op zondag 2 juli 2023 @ 17:19:
[...]


Welke modellen gebruik je dan?

Want de mijne hebben dat wel - sterker nog de webui en modbus hebben apart toegangscontrole. Met daarnaast op 3 niveaus IP adressen:
- de inverter als AP
- de inverter als wifi-client
- de inverter via UTP

Ik ben niet precies genoeg geweest: je kunt het IP nummer van de inverter wel aanpassen maar ik had het over IP nummers die geautoriseerd zijn om ModBus data op te vragen. Die kun je volgens mij niet configureren omdat er geen access control lijkt te zijn.

Onze posts hebben elkaar gekruist; zie ook mijn vorige reactie.

[cville]

@Airw0lf @nero355
Ik ben eruit; d.w.z. ik ken de oorzaak maar heb geen fundamentele oplossing maar wel een workaround. Het gaat hier m.i. toch niet om een ProxMox netwerkprobleem.

Wat is er aan de hand? Ik heb vergeten jullie te informeren over het feit dat er 2 verschillende pymodbus versies in het geding zijn, te weten 2.3.0 en 3.3.2. Ik heb als test pymodbus 2.3.0 op een LXC container geïnstalleerd (een downgrade) en toen werkte het wel. Omdat ik ondanks zeer uitvoerig zoeken er niet achter kan komen waarom 3.3.2. niet werkt, heb ik 2.3.0 als workaround geïnstalleerd.

Het blijft natuurlijk problematisch dat pymodbus een zeer misleidende foutmelding gegenereerd, een die lijkt op een netwerk probleem.

In ieder geval bedankt voor het meedenken. @Airw0lf als je om inhoudelijke redenen interesse hebt in het via modbus uitlezen van je inverter, kun je mij een PM sturen.

[Airw0lf]

cville schreef op maandag 3 juli 2023 @ 19:07:
@Airw0lf @nero355

[...]

In ieder geval bedankt voor het meedenken. @Airw0lf als je om inhoudelijke redenen interesse hebt in het via modbus uitlezen van je inverter, kun je mij een PM sturen.

Gedaan - wij danken u!

[nero355]

cville schreef op maandag 3 juli 2023 @ 19:07:
Ik ben eruit; d.w.z. ik ken de oorzaak maar heb geen fundamentele oplossing maar wel een workaround.
Het gaat hier m.i. toch niet om een ProxMox netwerkprobleem.

Wat is er aan de hand? Ik heb vergeten jullie te informeren over het feit dat er 2 verschillende pymodbus versies in het geding zijn, te weten 2.3.0 en 3.3.2. Ik heb als test pymodbus 2.3.0 op een LXC container geïnstalleerd (een downgrade) en toen werkte het wel. Omdat ik ondanks zeer uitvoerig zoeken er niet achter kan komen waarom 3.3.2. niet werkt, heb ik 2.3.0 als workaround geïnstalleerd.

Hmm... lijkt verdacht veel op een Python 2.x.x vs. 3.x.x probleem dus

Dat had ik je in principe ook wel kunnen vertellen, maar totaal niet aan gedacht...

Het blijft natuurlijk problematisch dat pymodbus een zeer misleidende foutmelding gegenereerd.

Daar heb ik de laatste jaren bijna alleen maar last van...

Error geeft melding X terwijl het dus eigenlijk probleem Y of Z is en je de oplossing totaal ergens anders moet zoeken!

[cville]

nero355 schreef op maandag 3 juli 2023 @ 20:20:
[...]




[...]

Hmm... lijkt verdacht veel op een Python 2.x.x vs. 3.x.x probleem dus

Dat had ik je in principe ook wel kunnen vertellen, maar totaal niet aan gedacht...

Dat is het dus niet; ik gebruik al jaren Python 3 en dus ook voor beide versies. Het probleem is dat ik nergens de relevante verschillen tussen de 2 versies kan vinden, ook niet in de release notes.

[Kriss1981]

Hallo allemaal, recent ben ik overgestapt van TrueNAS Core naar Proxmox.

In TrueNAS draaide ik een aantal Jails met daarin Plex, Sonarr, Transmission en Unifi controller. Momenteel draait diezelfde software in verschillende containers (LXC) in Proxmox.

Ik wilde graag mn firewall (OPNsense) in een VM wil draaien, maar voordat ik daarmee begin moet Proxmox wel stabiel blijven draaien. En daar zit nu het probleem. Proxmox gaat onderuit wanneer er ook maar iets van load is. Als ik bijvoorbeeld Plex een library laat scannen, reageert de Proxmox Web Gui niet meer en worden alle LXC containers gereboot.

Iemand enig idee waar dit aan kan liggen?

mijn config is in mijn ogen vrij simpel:

• Proxmox 8 geinstalleerd op ZFS
• Privilged LXC debian SAMBA
• Privilged LXC ubuntu Plex
• Privilged LXC ubuntu Sonarr en Transmission
• Unprivilged LXC debian Unifi