Het grote Proxmox VE topic

[RobertMe]

Begint nogal een beetje heel erg raar te worden...

Hier beschrijven ze bij Proxmox de naamgeving. Waarbij en* gebruikt wordt sinds PVE 5. Dat matcht dus mooi met de eno1 die ik zie (note: gisteren schreef ik eno0, maar dit moet dus 1 zijn). Dit klopt dus ook met de daarop volgende uitleg hoe Systemd de device naming doet: eno[index] voor onboard devices (gaat dus om een onboard netwerk kaart). Maar hoe of wat die dan ook enp0s31f6 toevoegde?! Want die bestaat dus niet (de onboard kaart zit dus wel op PCIe bus 0, slot 31, function 6).

Maar... dit was blijkbaar voorheen ook al het geval v.w.b. de config, afgaande op de ZFS snapshots en oude kopie in /var/log/ifupdown2 (die kende ik nog niet, dus thanks @marccom). En afgaande op oude logs (journalctl en bestand in aangegeven dir) werkte dit voorheen gewoon prima?! De eerste log entries die verwijzen naar enp0s31f6 zijn van gisteravond. Sidenote: sinds ik een mini PCtje heb, zonder PVE, staat de PVE bak soms nog maar eens in de zoveel weken aan, on-demand, dus ik heb meerdere recente logs en het is niet "de laatste keer dat netwerk config werd toegepast is weken / maanden geleden want nooit meer opgestart".

Uiteraard kan ik de iface enp0s31f6 inet manual + enp0s31f6 bij bridge-ports dan wel weghalen. Maar... dan ben ik nog steeds niet verder.

Sure, de error m.b.t. dit device is dan weg. Maar het IPv6 stukje faalt nog steeds. Bij een systemctl restart networking / volledige (re)boot op dat vmbr0 niet bestaat (WTF?! Het staat dus onder de iface vmbr0 inet6 auto). En daarna als ik handmatig sudo ip token set ::30 dev vmbr0 doe met: Error: ipv6: Router advertisement is disabled on device.. Een error die volgens DuckDuckGo op het hele internet niet te vinden is.
En ga ik vervolgens in de sysctl kijken staan router advertisements gewoon aan:

robert@nas:~$ sysctl net.ipv6.conf.all.accept_ra
net.ipv6.conf.all.accept_ra = 1
robert@nas:~$ sysctl net.ipv6.conf.default.accept_ra
net.ipv6.conf.default.accept_ra = 1
robert@nas:~$ sysctl net.ipv6.conf.vmbr0.accept_ra
net.ipv6.conf.vmbr0.accept_ra = 1

Edit:
Google is behulpzamer. Die geeft op die RA is disabled een aantal hits op het Proxmox forum. accept_ra heeft blijkbaar 3 opties: 0, 1, 2. 1 enabled het alleen als forwarding uit staat. 2 override / forceert dat en enabled accept_ra altijd. Dan krijgt de bridge wel netjes een IPv6 adres via SLAAC. En als ik de ip link set token... uitvoer gaat dat ook goed.
Onderliggende ding is dus dat forwarding aan staat op de bridge. En ik denk eigenlijk dat ik de hele bridge niet nodig heb? Of in ieder geval geen forwarding? Want ik gebruik de PVE firewall niet en de LXCs hangen rechtstreeks aan het netwerk (met MACVLAN I guess). Maar forwarding 0 in de config file doet niks? Dus even puzzelen hoe ik dat voor elkaar krijg. In ieder geval werkt accept_ra 1 prima als in met sysctl forwarding uit zet.

[ Voor 15% gewijzigd door RobertMe op 31-12-2023 11:13 ]

[ZatarraNL]

Hallo allemaal,

Ik ben benieuwd of hier iemand een beetje licht kan laten schijnen op een vraagstuk waar ik al een tijdje mee worstel. Wat is de beste manier om een HA Truenas VM in te richten op Proxmox?

Context:
Ik draai een 3-node proxmox cluster met een Qdevice (Rpi), want meestal zijn 2 nodes uitgeschakeld om stroom te besparen. Deze komen dagelijks online voor replication. Geen Ceph, want dat kan niet als ik 2 nodes wil uitzetten (heb ik eerder gehad, maar het stroomverbruik van 3 nodes is toch wel hoog met zo'n 200W idle). Je mag het zien als een homelab omgeving. Ik heb daarnaast zowel offsite of offline backup.

Ik heb nu 8 stuks enterpise ssd's liggen die ik over 2 nodes wil verdelen als een ZFS1 raid met single redundancy. Hierop wil ik alle VM's en LXC's laten draaien. Replication zorgt dan voor een kopie op iedere node. Als ik wil kan ik elke node inzetten, en HA zorgt ervoor dat VM's met hooguit een dag aan dataverlies weer worden aangeslingerd.

Truenas:
Eén van mijn VM's is een truenas Core VM. Ik had een tweetal schijven met passthrough doorgezet. Werkt prima. Maar daarmee kan ik niet makkelijk wisselen tussen nodes met HA. Dat zal toch met een virtual disk moeten. Ik heb voldoende opslag beschikbaar op de eerder beschreven beide ZFS1-pools.

Dilemma's:
1. Disk passthrough wordt overal geadviseerd voor Truenas vanwege de werking van ZFS. Maar dit kan niet samen met HA.
2. Een Truenas ZFS-pool van een enkele virtuele disk lijkt problemen te geven met betrouwbaarheid van de data, al begrijp ik niet helemaal waarom. ZFS op ZFS lijkt niet te mogen. En beide pools zouden dan niet meer data mogen bevatten dan 80%, wat resulteert in een maximale poolgrootte van 64%. Dat vind ik jammer.
3. Eigenlijk wordt er geadviseerd om een mirror van virtual disks te maken. Maar dan houdt ik nog minder over. Vind ik nog meer jammer.
4. Truenas Core lijkt niet overweg te kunnen met Ext4 of andere file systems. Misschien kan ik beter overstappen naar Truenas Scale, of helemaal iets anders kiezen.

Wat zouden jullie doen? Zijn er zinvolle alternatieven? Of deze route helemaal loslaten?

[ComTech]

Na een reboot van mijn NUC starten mijn VM's niet meer op.
Ik krijg de volgende error

code:

TASK ERROR: activating LV 'pve/data' failed:   Check of pool pve/data failed (status:1). Manual repair required!

Iemand idee?

[Airw0lf]

ComTech schreef op dinsdag 2 januari 2024 @ 16:32:
Na een reboot van mijn NUC starten mijn VM's niet meer op.
Ik krijg de volgende error

code:

TASK ERROR: activating LV 'pve/data' failed:   Check of pool pve/data failed (status:1). Manual repair required!

Iemand idee?

Volume corrupt? Booiten met een life ISO en FSCK gedaan?

[powerboat]

ZatarraNL schreef op dinsdag 2 januari 2024 @ 11:57:
Hallo allemaal,

Ik ben benieuwd of hier iemand een beetje licht kan laten schijnen op een vraagstuk waar ik al een tijdje mee worstel. Wat is de beste manier om een HA Truenas VM in te richten op Proxmox?

Context:
Ik draai een 3-node proxmox cluster met een Qdevice (Rpi), want meestal zijn 2 nodes uitgeschakeld om stroom te besparen. Deze komen dagelijks online voor replication. Geen Ceph, want dat kan niet als ik 2 nodes wil uitzetten (heb ik eerder gehad, maar het stroomverbruik van 3 nodes is toch wel hoog met zo'n 200W idle). Je mag het zien als een homelab omgeving. Ik heb daarnaast zowel offsite of offline backup.

Ik heb nu 8 stuks enterpise ssd's liggen die ik over 2 nodes wil verdelen als een ZFS1 raid met single redundancy. Hierop wil ik alle VM's en LXC's laten draaien. Replication zorgt dan voor een kopie op iedere node. Als ik wil kan ik elke node inzetten, en HA zorgt ervoor dat VM's met hooguit een dag aan dataverlies weer worden aangeslingerd.

Truenas:
Eén van mijn VM's is een truenas Core VM. Ik had een tweetal schijven met passthrough doorgezet. Werkt prima. Maar daarmee kan ik niet makkelijk wisselen tussen nodes met HA. Dat zal toch met een virtual disk moeten. Ik heb voldoende opslag beschikbaar op de eerder beschreven beide ZFS1-pools.

Dilemma's:
1. Disk passthrough wordt overal geadviseerd voor Truenas vanwege de werking van ZFS. Maar dit kan niet samen met HA.
2. Een Truenas ZFS-pool van een enkele virtuele disk lijkt problemen te geven met betrouwbaarheid van de data, al begrijp ik niet helemaal waarom. ZFS op ZFS lijkt niet te mogen. En beide pools zouden dan niet meer data mogen bevatten dan 80%, wat resulteert in een maximale poolgrootte van 64%. Dat vind ik jammer.
3. Eigenlijk wordt er geadviseerd om een mirror van virtual disks te maken. Maar dan houdt ik nog minder over. Vind ik nog meer jammer.
4. Truenas Core lijkt niet overweg te kunnen met Ext4 of andere file systems. Misschien kan ik beter overstappen naar Truenas Scale, of helemaal iets anders kiezen.

Wat zouden jullie doen? Zijn er zinvolle alternatieven? Of deze route helemaal loslaten?

Als het enkel is om VM's op te hosten zou je eens kunnen kijken naar Proxmox als 2 node cluster (ZFS replicatie), weliswaar niet helemaal HA maar beter dan niets.

Ik zou sowieso Scale boven core kiezen omdat dit denk ik wel de toekomst is.

[ZatarraNL]

powerboat schreef op dinsdag 2 januari 2024 @ 16:49:
[...]


Als het enkel is om VM's op te hosten zou je eens kunnen kijken naar Proxmox als 2 node cluster (ZFS replicatie), weliswaar niet helemaal HA maar beter dan niets.

Ik zou sowieso Scale boven core kiezen omdat dit denk ik wel de toekomst is.

Scale liever dan core. Ok. Maar welke format zou je kiezen voor de virtual disks?

[John245]

ZatarraNL schreef op dinsdag 2 januari 2024 @ 17:09:
[...]

Scale liever dan core. Ok. Maar welke format zou je kiezen voor de virtual disks?

Heb jij je hele netwerk ook HA? Heb jij je SPOF's in kaart gebracht?

[powerboat]

ZatarraNL schreef op dinsdag 2 januari 2024 @ 17:09:
[...]

Scale liever dan core. Ok. Maar welke format zou je kiezen voor de virtual disks?

Hoe bedoel je? Als je een 2 node cluster Proxmox cluster bouwd dan heb je geen Truenas nodig.

Wil je wel Truenas gebruiken dan zou ik disk passthrough of pci passthrough toepassen, maar dan kun je niet HA toepassen.

Mocht je een vdisk aan je Truenas hangen dan zou ik een enkele RAW disk toevoegen waar geen gekke dingen opgedaan worden.

[ZatarraNL]

John245 schreef op dinsdag 2 januari 2024 @ 19:24:
[...]

Heb jij je hele netwerk ook HA? Heb jij je SPOF's in kaart gebracht?

Bij lange na niet. Maar wel voldoende voor mijn situatie. Ik kan wel een dag data missen, maar ik wil de containers zo snel mogelijk weer up and running. De nodes en het netwerk zitten onder een ups, maar na 15 min houdt die toch ook echt op. De nodes hebben een een dedicated backbone. Binnen het redelijke heb ik het aardig op orde.

[powerboat]

John245 schreef op dinsdag 2 januari 2024 @ 19:24:
[...]

Heb jij je hele netwerk ook HA? Heb jij je SPOF's in kaart gebracht?

Ja, heb een 3 node Epyc cluster met CEPH, met 2x10Gbit switches. De SPOF zit aan de WAN kant heb maar (nog) maar een internet verbinding en de OPNSense maar die kan ik wel live migreren .

[ZatarraNL]

powerboat schreef op dinsdag 2 januari 2024 @ 19:43:
[...]


Hoe bedoel je? Als je een 2 node cluster Proxmox cluster bouwd dan heb je geen Truenas nodig.

Wil je wel Truenas gebruiken dan zou ik disk passthrough of pci passthrough toepassen, maar dan kun je niet HA toepassen.

Mocht je een vdisk aan je Truenas hangen dan zou ik een enkele RAW disk toevoegen waar geen gekke dingen opgedaan worden.

Het gaat mij dan vooral om de samba shares. Die heb ik nu onder proxmox zelf, maar wil ik liever onder brengen in een vm. Ik las van veel mensen die hier truenas voor gebruiken. Die combinatie schrijft truenas zelf ook over. Maar dan vooral met pci passthrough. En dan kan ik niet zo makkelijk van node wisselen.

En RAW disk is misschien zo gek nog niet. Zal me eens in verdiepen. Dank.

[John245]

powerboat schreef op dinsdag 2 januari 2024 @ 19:48:
[...]


Ja, heb een 3 node Epyc cluster met CEPH, met 2x10Gbit switches. De SPOF zit aan de WAN kant heb maar (nog) maar een internet verbinding en de OPNSense maar die kan ik wel live migreren .

Hier ook aardig op orde. Pas 2 10Gbit Unifi Aggregation switches in het netwerk gehangen en mijn meest belangrijke Node heeft 4x1Gbit en 2x10Gbit (die beide naar een van de aggregatie switches gaan) en IPMI. Alles zit op UPS en heb ook nog het Victron systeem als UPS voor de volledige woning. Heb wel redundant WAN. Maar dat is niet bedoeld om externe back-ups te maken (is nl een 5 g abonnementje). Hier als FW 2 x een XGS-126 (Sophos).

[nero355]

ZatarraNL schreef op dinsdag 2 januari 2024 @ 19:50:
Het gaat mij dan vooral om de samba shares.
Die heb ik nu onder proxmox zelf, maar wil ik liever onder brengen in een vm.

Ik las van veel mensen die hier truenas voor gebruiken.

Maar wat heb je nodig qua Samba functionaliteit precies

In principe heb je niet meer nodig dan :
- Een VM met daarin Debian bijvoorbeeld.
- Vervolgens installeer je Samba Server.
- Maak je wat Samba Shares aan.

En KLAAR!!!

En in jouw geval komt daar nog het installeren en inrichten van OpenZFS erbij, maar dat is maar één tussenstap


Als je niks bijzonders van plan bent dan is het gebruik van TrueNAS voor wat Samba Shares een beetje zoiets als een doos willen vervoeren en daar meteen een vrachtwagen voor pakken, terwijl een stationwagon of zelfs nog minder dan dat ook prima voldoet...

[powerboat]

nero355 schreef op woensdag 3 januari 2024 @ 16:53:
[...]

Als je niks bijzonders van plan bent dan is het gebruik van TrueNAS voor wat Samba Shares een beetje zoiets als een doos willen vervoeren en daar meteen een vrachtwagen voor pakken, terwijl een stationwagon of zelfs nog minder dan dat ook prima voldoet...

Ja, maar doe jij ook niet zomaar dingen gewoon omdat het kan ?

[nero355]

powerboat schreef op woensdag 3 januari 2024 @ 16:57:
Ja, maar doe jij ook niet zomaar dingen gewoon omdat het kan ?

Jawel, maar in dit geval overruled mijn "Zo puur mogelijk verslaving" de boel en dan kom je toch op zoiets uit

[ZatarraNL]

nero355 schreef op woensdag 3 januari 2024 @ 17:00:
[...]

Jawel, maar in dit geval overruled mijn "Zo puur mogelijk verslaving" de boel en dan kom je toch op zoiets uit

Haha! Dit komt inderdaad wel een beetje in de buurt van "omdat het kan". Nu is een vrachtwagen net zo snel geïnstalleerd als een stationwagen, dus waarom geen vrachtwagen?

Ik wil truenas ook een beetje verkennen. En de wijze waarop je met permissies kan spelen bevalt wel. Het is dan ook misschien een beetje meer dan een simpele samba server. Ik wil vooral begrijpen hoe het werkt en waarom bepaalde dingen wel of niet verstandig zijn.

[nero355]

ZatarraNL schreef op woensdag 3 januari 2024 @ 18:19:
Ik wil truenas ook een beetje verkennen. En de wijze waarop je met permissies kan spelen bevalt wel. Het is dan ook misschien een beetje meer dan een simpele samba server. Ik wil vooral begrijpen hoe het werkt en waarom bepaalde dingen wel of niet verstandig zijn.

Dan wordt het natuurlijk een heel ander verhaal en moet je het gewoon lekker gaan verkennen!

[powerboat]

ZatarraNL schreef op woensdag 3 januari 2024 @ 18:19:
[...]

Haha! Dit komt inderdaad wel een beetje in de buurt van "omdat het kan". Nu is een vrachtwagen net zo snel geïnstalleerd als een stationwagen, dus waarom geen vrachtwagen?

Ik wil truenas ook een beetje verkennen. En de wijze waarop je met permissies kan spelen bevalt wel. Het is dan ook misschien een beetje meer dan een simpele samba server. Ik wil vooral begrijpen hoe het werkt en waarom bepaalde dingen wel of niet verstandig zijn.

Als je dan toch bezig bent! Dan zou ik ook een DC opzetten, bij voorkeur een Samba ADC en deze koppelen met TrueNas i.c.m. ntfs permissies

[ZatarraNL]

powerboat schreef op woensdag 3 januari 2024 @ 18:25:
[...]


Als je dan toch bezig bent! Dan zou ik ook een DC opzetten, bij voorkeur een Samba ADC en deze koppelen met TrueNas i.c.m. ntfs permissies

Ehm, Ik ben bezig met een ldap server. Mag dat ook? Maar als je tips hebt, bij voorkeur te combineren met Microsoft accounts, dan hoor ik het graag. 😊

[ Voor 13% gewijzigd door ZatarraNL op 03-01-2024 18:28 ]

[powerboat]

ZatarraNL schreef op woensdag 3 januari 2024 @ 18:27:
[...]

Ehm, Ik ben bezig met een ldap server. Mag dat ook? Maar als je tips hebt, bij voorkeur te combineren met Microsoft accounts, dan hoor ik het graag. 😊

Samba ADC i.c.m. Truenas werkt erg mooi i.c.m. Windows & Linux. Heb dat bij een klant van mij draaien

[nero355]

ZatarraNL schreef op woensdag 3 januari 2024 @ 18:27:
Ehm, Ik ben bezig met een ldap server. Mag dat ook? Maar als je tips hebt, bij voorkeur te combineren met Microsoft accounts, dan hoor ik het graag. 😊

Microsoft Account = Pure Evil

Maar je zou nog wat Kerberos en RADIUS in de soep erbij kunnen gooien en dan ben je helemaal voorzien qua allerlei "authenticatiegekkigheid" !!!

[John245]

Ik heb 2 Unifi Aggregation Switches en wil mijn Server zodanig verbinden dat indien 1 van de aggregatie switches down gaar de server wel zijn connectie behoudt. Hiervoor wil ik de Server zowel verbinden met Aggregation Switch een (1) en aggregatie switch twee (2). Is het hiervoor voldoende de vet gemaakte tekst aan de interface configuratie (van de Proxmox Node) toe te voegen?

auto lo
iface lo inet loopback

iface eth0 inet manual
iface eth1 inet manual

auto vmbr0
iface vmbr0 inet static
address 192.168.10.2/24
gateway 192.168.10.1
bridge-ports eth0 eth1
bridge-stp off
bridge-fd 0

[nero355]

John245 schreef op zaterdag 6 januari 2024 @ 17:37:
Ik heb 2 Unifi Aggregation Switches en wil mijn Server zodanig verbinden dat indien 1 van de aggregatie switches down gaar de server wel zijn connectie behoudt.
Hiervoor wil ik de Server zowel verbinden met Aggregation Switch een (1) en aggregatie switch twee (2).

Ondersteunen je Switches een LACP Configuratie verspreid over beide Switches

Is het hiervoor voldoende de vet gemaakte tekst aan de interface configuratie (van de Proxmox Node) toe te voegen?

auto lo
iface lo inet loopback

iface eth0 inet manual
iface eth1 inet manual

auto vmbr0
iface vmbr0 inet static
address 192.168.10.2/24
gateway 192.168.10.1
bridge-ports eth0 eth1
bridge-stp off
bridge-fd 0

NOPE.AVI

Je moet alles slopen en een bond0 aanmaken die je vervolgens in de vmbr0 gooit

[John245]

nero355 schreef op zaterdag 6 januari 2024 @ 18:47:
[...]

Ondersteunen je Switches een LACP Configuratie verspreid over beide Switches


[...]

NOPE.AVI

Je moet alles slopen en een bond0 aanmaken die je vervolgens in de vmbr0 gooit

Mijn gedachte was er is altijd maar 1 NIC actief dus het maakt niet uit wat er gesupport wordt.

Maar het zou dus moeten worden:

auto lo
iface lo inet loopback

iface eth0 inet manual

iface eth1 inet manual

auto bond0
iface bond0 inet manual
bond-slaves eth0 eth1
bond-miimon 100
bond-mode 802.3ad
bond-xmit-hash-policy layer2+3

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

[Airw0lf]

John245 schreef op zaterdag 6 januari 2024 @ 19:20:
[...]

Mijn gedachte was er is altijd maar 1 NIC actief dus het maakt niet uit wat er gesupport wordt.

Maar het zou dus moeten worden:

auto lo
iface lo inet loopback

iface eth0 inet manual

iface eth1 inet manual

auto bond0
iface bond0 inet manual
bond-slaves eth0 eth1
bond-miimon 100
bond-mode 802.3ad
bond-xmit-hash-policy layer2+3

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

Ik weet niet - lacp verdeeld over twee switches met elk een poort...
Volgens mij gaat dat niet werken?!
Maar je kan eens proberen met "bond-mode 5".
Die bond-mode 5 vereist geen instellingen aan de switchpoorten.

Ik heb hier in /etc/network/interfaces het volgende staan:

code:

# Add eth0 to bond0
auto eth0
iface eth0 inet manual
   bond-master bond0
   bond-primary eth0

# Dito for eth1
auto eth1
iface eth1 inet manual
   bond-master bond0

# The bonding network interface
auto bond0
iface bond0 inet dhcp
   bond-slaves eth0 eth1
   bond-mode 5

In jou geval zal het "inet static" en een IP adres zijn.

[John245]

Airw0lf schreef op zaterdag 6 januari 2024 @ 19:52:
[...]


Ik weet niet - lacp verdeeld over twee switches met elk een poort...
Volgens mij gaat dat niet werken?!
Maar je kan eens proberen met "bond-mode 5".
Die bond-mode 5 vereist geen instellingen aan de switchpoorten.

Ik heb hier in /etc/network/interfaces het volgende staan:

code:

# Add eth0 to bond0
auto eth0
iface eth0 inet manual
   bond-master bond0
   bond-primary eth0

# Dito for eth1
auto eth1
iface eth1 inet manual
   bond-master bond0

# The bonding network interface
auto bond0
iface bond0 inet dhcp
   bond-slaves eth0 eth1
   bond-mode 5

In jou geval zal het "inet static" en een IP adres zijn.

@Airw0lf
Wat ik schreef werkt volgens Proxmox in deze situatie: https://pve.proxmox.com/p...lt-network-setup-bond.svg

Wat is er in mijn situatie dan anders? Ik probeer dingen te begrijpen voordat ik wijzigingen aanbreng.

[ Voor 3% gewijzigd door John245 op 06-01-2024 20:22 ]

[GoBieN-Be]

Een LAG over meerdere switches heen kan je maken als de switches in een stack zitten of indien ze M(C)LAG ondersteunen.
Wikipedia: Multi-chassis link aggregation group

Wellicht kan het wel zonder LAG als je de Linux bond op een failover mode instelt die geen switch support nodig heeft.

[Airw0lf]

John245 schreef op zaterdag 6 januari 2024 @ 20:22:
[...]

@Airw0lf
Wat ik schreef werkt volgens Proxmox in deze situatie: https://pve.proxmox.com/p...lt-network-setup-bond.svg

Wat is er in mijn situatie dan anders? Ik probeer dingen te begrijpen voordat ik wijzigingen aanbreng.

Voor zover mij bekend: een mlag is een lacp variant bedoeld voor twee switches met een backplane verbinding waardoor ze (een soort van) een geheel zijn. Ik weet niet of jouw switches dat hebben - vandaar de suggestie om mode-5 te gebruiken. En eens zien wat je gaat krijgen.

Je initiële post met een vmbr-interface met 2 NIC's zou het eigenlijk ook moeten doen.
Duurde even voor ik wat passende documentatie had gevonden:
https://www.baeldung.com/linux/bridging-network-interfaces
https://wiki.debian.org/BridgeNetworkConnections
Voorwaarde is wel dat je deze twee regels weg laat:

code:

bridge-stp off
bridge-fd 0

Kan zijn dat je met path-costs moet spelen om zeker te zijn dat bij normaal bedrijf het beste pad beschikbaar is.

Voor de volledigheid: ik begeef me hiermee enigszins op glad ijs omdat ik hier zelf nooit serieus gebruik van heb gemaakt. Tis te zeggen... ik heb grote(re) netwerken gebouwd met bridges - maar nooit via de Linux bridge tools.

[ Voor 39% gewijzigd door Airw0lf op 07-01-2024 08:30 ]

[stormfly]

John245 schreef op zaterdag 6 januari 2024 @ 20:22:
[...]

@Airw0lf
Wat ik schreef werkt volgens Proxmox in deze situatie: https://pve.proxmox.com/p...lt-network-setup-bond.svg

Wat is er in mijn situatie dan anders? Ik probeer dingen te begrijpen voordat ik wijzigingen aanbreng.

Wat er anders is: jij hebt twee losse UniFi switches zonder slim protocol ertussen zoals mLAG in het plaatje. Je kunt bij UniFi wel LACP configureren, maar slechts 1 server met 2 porten op 1 switch. De complexiteit ontstaat omdat jij 1 server met 2 porten op 2 switches wilt aansluiten.

Ik ben er geen guru in, maar als je de twee porten in een bridge zou stoppen dan is het in feite switch (server) op switch (unifi) aangesloten en krijg je last van STP/broadcast forwarding. Ik zou focussen op zo simpel mogelijk, zonder gebruik van een bridge en focusseren op een bond zonder LACP.

Bond-5 of de configuratie die je zelf had geschreven kan ook interessant zijn, twee linken aan vmbr0 koppelen.

[Airw0lf]

stormfly schreef op zondag 7 januari 2024 @ 09:57:
[...]


Wat er anders is: jij hebt twee losse UniFi switches zonder slim protocol ertussen zoals mLAG in het plaatje. Je kunt bij UniFi wel LACP configureren, maar slechts 1 server met 2 porten op 1 switch. De complexiteit ontstaat omdat jij 1 server met 2 porten op 2 switches wilt aansluiten.

Ik ben er geen guru in, maar als je de twee porten in een bridge zou stoppen dan is het in feite switch (server) op switch (unifi) aangesloten en krijg je last van STP/broadcast forwarding. Ik zou focussen op zo simpel mogelijk, zonder gebruik van een bridge en focusseren op een bond zonder LACP.

Bond-5 of de configuratie die je zelf had geschreven kan ook interessant zijn, twee linken aan vmbr0 koppelen.

Voor de duidelijkheid (mijn 0,100 Euro) :
(1) - als je twee ethernet linken in een vmbr interface steekt ben je toch echt wel aan het bridgen (via de Linux brutils). Dan moet je echt wel zoiets als stp gebruiken om het te laten werken bij een dual home (driehoeks opstelling) met twee verschillende switches. Met de aanname dat die twee switches onderling een (lacp?) verbinding hebben.
(2) - een bond-5 verbinding met twee ethernet linken is niet hetzelfde als een vmbr0 met twee ethernet linken - in een bond-verbinding is geen stp nodig.
(3) - als ik vragen mag: wat bedoel je precies met "STP/broadcast fowarding"?

[ Voor 10% gewijzigd door Airw0lf op 07-01-2024 10:27 ]

[stormfly]

Airw0lf schreef op zondag 7 januari 2024 @ 10:19:
[...]


Als je twee linken in een vmbr interface steekt ben je toch echt wel aan het bridgen (via de Linux brutils) en moet je stp gebruiken om het te laten werken bij een dual home (driehoeks opstelling) met twee verschillende switches die onderling een (lacp?) verbinding hebben.

Ik weet dat niet in detail, is vmbr de afkorting voor vlan bridge?

Als ik vragen mag: wat bedoel je precies met "STP/broadcast fowarding"?

Dat je ergens een port op STP blocking krijgt omdat je een vierkant hebt waardoor er een broadcast storm ontstaat door die broadcast pakketten oneindig blijven forwarden.

[Loekie]

Wij draaien een vergelijkbare setup met 2 adapters in een bond in active-backup(hierbij is dus 1 adapter actief) en die is dan gekoppeld aan een vmbr.
Indien een switch dan een update krijgt, switched the active adapter naar de andere switch.

[stormfly]

Loekie schreef op zondag 7 januari 2024 @ 10:32:
Wij draaien een vergelijkbare setup met 2 adapters in een bond in active-backup(hierbij is dus 1 adapter actief) en die is dan gekoppeld aan een vmbr.
Indien een switch dan een update krijgt, switched the active adapter naar de andere switch.

nic0+nic1 -> bond -> vmbr0

Heb je de config in CLI format, om het concreet te maken?

[Airw0lf]

stormfly schreef op zondag 7 januari 2024 @ 10:23:
[...]


Ik weet dat niet in detail, is vmbr de afkorting voor vlan bridge?

Pfff - ik herinner me vaag iets van virtual machine bridge.

[...]

Dat je ergens een port op STP blocking krijgt omdat je een vierkant hebt waardoor er een broadcast storm ontstaat door die broadcast pakketten oneindig blijven forwarden.

Ja - zoiets - maar zover komt het in de praktijk niet - tenzij er geen stp actief is.

Als bridges een loop detecteren stoppen ze met het verwerken van normale netwerk pakketjes. En gaan ze eerst in learning mode om op basis van die resultaten te bepalen welke poorten forwarding en blocking moeten zijn. Daarna gaan ze verder met de verwerking van normale netwerk pakketjes.

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

[John245]

Airw0lf schreef op zaterdag 6 januari 2024 @ 23:09:
[...]


Voor zover mij bekend: een mlag is een lacp variant bedoeld voor twee switches met een backplane verbinding waardoor ze (een soort van) een geheel zijn. Ik weet niet of jouw switches dat hebben - vandaar de suggestie om mode-5 te gebruiken. En eens zien wat je gaat krijgen.

Je initiële post met een vmbr-interface met 2 NIC's zou het eigenlijk ook moeten doen.
Duurde even voor ik wat passende documentatie had gevonden:
https://www.baeldung.com/linux/bridging-network-interfaces
https://wiki.debian.org/BridgeNetworkConnections
Voorwaarde is wel dat je deze twee regels weg laat:

code:

bridge-stp off
bridge-fd 0

Kan zijn dat je met path-costs moet spelen om zeker te zijn dat bij normaal bedrijf het beste pad beschikbaar is.

Voor de volledigheid: ik begeef me hiermee enigszins op glad ijs omdat ik hier zelf nooit serieus gebruik van heb gemaakt. Tis te zeggen... ik heb grote(re) netwerken gebouwd met bridges - maar nooit via de Linux bridge tools.

@Airw0lf Bedankt voor de 2e referentie (deze had ik nog niet).

Misschien handig voor de discussie om er een plaatje bij te hebben:

[Airw0lf]

John245 schreef op zondag 7 januari 2024 @ 11:20:
[...]

@Airw0lf Bedankt voor de 2e referentie (deze had ik nog niet).

Misschien handig voor de discussie om er een plaatje bij te hebben:
[Afbeelding]

Mooi en symmetrisch plaatje met veel lijntjes...

Maarreehh... mijn glazen bol heeft zijn beste tijd wel gehad. Ook ben ik enigszins op leeftijd waardoor mijn telepatische gaves ook niet meer zijn wat het was...

[stormfly]

John245 schreef op zondag 7 januari 2024 @ 11:20:
[...]

@Airw0lf Bedankt voor de 2e referentie (deze had ik nog niet).

Misschien handig voor de discussie om er een plaatje bij te hebben:
[Afbeelding]

Mooi ontwerp, ik denk dat je nu moet overstappen naar de bouwfase in je LAB omgeving om e.a. te gaan testen en dan ook even vastleggen in dit topic wat wel/niet werkt.

Overigens hoe gaat de failover tussen de firewalls, hebben ze sessie sync? Hoe ziet het LAN dat er internet is via 5G ipv vast?

Het blijft een nadeel met UniFi dat je geen "stacks" kunt maken met switches, waardoor je altijd geneuzel hebt met spanningtree en inherent daaraan; geblokkeerde paden om loops te voorkomen.

[John245]

stormfly schreef op zondag 7 januari 2024 @ 12:09:
[...]


Mooi ontwerp, ik denk dat je nu moet overstappen naar de bouwfase in je LAB omgeving om e.a. te gaan testen en dan ook even vastleggen in dit topic wat wel/niet werkt.

Overigens hoe gaat de failover tussen de firewalls, hebben ze sessie sync? Hoe ziet het LAN dat er internet is via 5G ipv vast?

Het blijft een nadeel met UniFi dat je geen "stacks" kunt maken met switches, waardoor je altijd geneuzel hebt met spanningtree en inherent daaraan; geblokkeerde paden om loops te voorkomen.

Een en ander is al gebouwd en "niet gedocumenteerd" getest.

Heb nog wat andere projectjes lopen, maar ben van plan om in de komende periode (hopelijk Q1 2024) de test scrips in JIRA (Zephyr scale) te gaan schrijven en uit te voeren.

Failover
De failover van de Sophos FW's werkt als volgt (ik heb een active - passive configuratie i.v.m. de licentiekosten):

The list below details the behavior when a failover occurs.

If a device doesn't receive any communication from the HA peer within the predetermined time, the peer device is considered to have failed. This process is termed device failover, as when this occurs, the active device takes over the peer device.
The device failover detection time (peer timeout) is four seconds. When the primary device stops sending heartbeat packets, it's declared inactive at the end of four seconds (250 milliseconds x 16 timeouts). The peer is considered active if a heartbeat is received within fourteen timeouts. Failover is triggered at the end of seven seconds (three-second link uptime + four-second device failover detection time) from the time cluster has come up. You can't change the failover threshold.

WAN
Sophos heeft twee (2) WAN connecties. Respectievelijk Experiabox en Netgear Nighthawk. De Experiabox is Actief en wordt niet geactiveerd indien er een andere WAN connectie failt. De Netgear Nighthawk is gedefinieerd als backup and wordt geactiveerd indien een andere WAN connectie faalt (in mijn geval de Experiabox). Het LAN ziet niet het verschil tussen vast of 5G internet. Wel stuurt Sophos een e-mail indien de actieve internet verbinding wegvalt. Zou hier vast wel iets kunnen doen met een API om het internetverkeer te beperken.

Ik zal zeker in dit topic vastleggen wat wel/en niet werkt. En verwelkom natuurlijk ook feedback voor additionele test scripts.

[John245]

Airw0lf schreef op zondag 7 januari 2024 @ 11:54:
[...]


Mooi en symmetrisch plaatje met veel lijntjes...

Maarreehh... mijn glazen bol heeft zijn beste tijd wel gehad. Ook ben ik enigszins op leeftijd waardoor mijn telepatische gaves ook niet meer zijn wat het was...

Heb ook wel een plaatje dat laat zien welke poort met welke poort verbonden is, maar dat maakt het niet overzichtelijker

Naar welke info ben je op zoek?

[Airw0lf]

@John245 - afgaande op de laatste twee posts (die info miste ik):
Richt het zo in dat "links" je primaire pad is. En "rechts" je backup.pad.

Dat wil zeggen dat bij normaal bedrijf alle sessies over "links" lopen.
Waardoor je "rechts" vrij houdt voor (bijvoorbeeld) firmware updates en 5G testen.

Geen van de apparaten heeft ondersteuning voor een failover met behoudt van sessies.
Dus als er ergens een probleem is, dan moeten alle sessies opnieuw gestart worden.
Als alle sessie dan langs "rechts" gaan lopen heb je "links" vrij voor (bijvoorbeeld) firmware updates.

Wel is het dan zaak dat je tussen beide modems en eerste laag UB switches ook kruislings een touwtje kunt (en wil) leggen. Dit om er voor te zorgen dat alle sessies bij een geplande "failover" nog steeds langs de normale Internet pijp naar buiten kunnen... als je bedoeld wat ik begrijp...

[John245]

Airw0lf schreef op zondag 7 januari 2024 @ 12:46:
@John245 - afgaande op de laatste twee posts (die info miste ik):
Richt het zo in dat "links" je primaire pad is. En "rechts" je backup.pad.

Dat wil zeggen dat bij normaal bedrijf alle sessies over "links" lopen.
Waardoor je "rechts" vrij houdt voor (bijvoorbeeld) firmware updates en 5G testen.

Geen van de apparaten heeft ondersteuning voor een failover met behoudt van sessies.
Dus als er ergens een probleem is, dan moeten alle sessies opnieuw gestart worden.
Als alle sessie dan langs "rechts" gaan lopen heb je "links" vrij voor (bijvoorbeeld) firmware updates.

Wel is het dan zaak dat je tussen beide modems en eerste laag UB switches ook kruislings een touwtje kunt (en wil) leggen. Dit om er voor te zorgen dat alle sessies bij een geplande "failover" nog steeds langs de normale Internet pijp naar buiten kunnen... als je bedoeld wat ik begrijp...

@airwolf
Links is totaal primair. Rechts is t/m de firewall het backup pad, de rest is wel primair. (Rechts staat in gebouw A en links staat in gebouw . Ik zie dat ik wat lijntjes niet had ingekleurd, hierbij een update. De grijze lijntjes (4) boven de FW's zijn CAT verbindingen.



In het diagram lopen er lijntjes van:
FW 1 --> Switch 1
FW 1 --> Switch 2
FW 2 --> Switch 2
FW 2 --> Switch 1
Switch 1 --> Switch 2

De kruislingse verbindingen tussen de Experiabox, Netgear en eerste laag switches is toch niet noodzakelijk? De kruislingse verbindingen eronder lossen dat toch op? Iedere FW kan via de Experiabox of de Netgear.

[ Voor 8% gewijzigd door John245 op 07-01-2024 13:09 ]

[Airw0lf]

John245 schreef op zondag 7 januari 2024 @ 13:05:
[...]

Links is totaal primair. Rechts is t/m de firewall het backup pad, de rest is wel primair.

[...]

Misschien dat het zo bedoeld is. Maar weet een applicatie dat ook?
Oftewel - waarop baseer je dat?

[Airw0lf]

John245 schreef op zondag 7 januari 2024 @ 13:05:
[...]

De kruislingse verbindingen tussen de Experiabox, Netgear en eerste laag switches is toch niet noodzakelijk? De kruislingse verbindingen eronder lossen dat toch op? Iedere FW kan via de
Experiabox of de Netgear.

Ok - maar zo gezien heb je die extra switchlaag toch niet nodig?
Ook kan je volstaan met het dubbel ontsluiten van de access laag?
Bij alles vanaf de aggregatielaag volstaat dan een enkelvoudige aansluiting?

Tijdens normaal bedrijf bewandelen alle pakketjes het "linker" pad.
In een fall-back bewandelen ze het "rechter" pad.

Of mis ik nu iets?

[John245]

Airw0lf schreef op zondag 7 januari 2024 @ 16:39:
[...]


Misschien dat het zo bedoeld is. Maar weet een applicatie dat ook?
Oftewel - waarop baseer je dat?

Een applicatie weet dat niet. Er kan maar een (1) Sophos FW actief zijn. En een applicatie maakt het niet uit of Firewall 1 of Firewall 2 actief is.

Of bedoel je dat de applicatie niet weet of de internet connectie vast of 5G is? Met als gevolg dat een back-up de 5G kan gebruiken? (Dat laatste wil ik in de toekomst wel oplossen).

Of bedoel je wat anders?

[John245]

Airw0lf schreef op zondag 7 januari 2024 @ 17:00:
[...]


Ok - maar zo gezien heb je die extra switchlaag toch niet nodig?
Ook kan je volstaan met het dubbel ontsluiten van de access laag?
Bij alles vanaf de aggregatielaag volstaat dan een enkelvoudige aansluiting?

Tijdens normaal bedrijf bewandelen alle pakketjes het "linker" pad.
In een fall-back bewandelen ze het "rechter" pad.

Of mis ik nu iets?

@Airw0lf
"Ok - maar zo gezien heb je die extra switchlaag toch niet nodig?"
Zonder die UniFi vijf (5) port switches heb ik geen internet op mijn rechter (Sophos). In het scenario dat de linker FW (primair) uitvalt zou ik dan geen internet toegang hebben. Of bedoelde je niet deze switchlaag?

Jou aanname:
"Tijdens normaal bedrijf bewandelen alle pakketjes het "linker" pad.
In een fall-back bewandelen ze het "rechter" pad."

Is incorrect. In normaal bedrijf volgen de pakketjes:

Experiabox --> 5 Ports UniFi witch (rlinks) --> FW (links) --> Aggregation switch 1 --> Switch (links)
|
--Aggregation switch 2--> Switch (rechts)

De aggregatieswitches en de grote switches zijn beide een access laag (op de aggregatie switches zit bijvoorbeeld een NAS en Proxmox Server). . Op dit moment zijn de 48 poort switches nog 1 SFP. Worden in de toekomst geupdate naar SFP+ (en twijfel nog tussen 4 ports SFP+ of 2 ports SFP+).

[GoBieN-Be]

John245 schreef op zondag 7 januari 2024 @ 13:05:
[...]

De kruislingse verbindingen tussen de Experiabox, Netgear en eerste laag switches is toch niet noodzakelijk? De kruislingse verbindingen eronder lossen dat toch op? Iedere FW kan via de Experiabox of de Netgear.

Bij het falen van de linkse kleine WAN switch, gaat je linkse firewall (primair) geen toegang hebben tot de Experiabox en overschakelen op de 5G. Terwijl er met de Experiabox niks mis is, enkel de kleine linkse switch is kapot. Je firewall zal ook niet auto overschakelen naar de andere passieve firewall in zo'n geval.

Indien je op de linkse firewall de WAN-EXPERIA poort kan bridgen naar 2 interfaces dan trek je een 2de kabel naar de rechtse WAN switch en van daar uit ook een kabel naar de Experiabox die ook meerdere poorten heeft zo te zien. Echter maak je dan eigenlijk een lus, dus zou je moeten spanning tree configureren op de kleine WAN switches.

Wordt wat ingewikkeld precies. Misschien toch gewoon laten naar 5G overschakelen als die linkse WAN switch het begeeft en dan gewoon indien nodig manueel de firewall ook overschakelen of vlug de switches gaan omwisselen.

[Airw0lf]

John245 schreef op zondag 7 januari 2024 @ 17:36:
[...]

@Airw0lf
"Ok - maar zo gezien heb je die extra switchlaag toch niet nodig?"
Zonder die UniFi vijf (5) port switches heb ik geen internet op mijn rechter (Sophos). In het scenario dat de linker FW (primair) uitvalt zou ik dan geen internet toegang hebben. Of bedoelde je niet deze switchlaag?

Ja - ik bedoelde deze switchlaag.
Die EB van KPN heeft toch 4 lanpoorten?
Daar kan je dan toch de twee Sophos firewalls op aansluiten?

Jou aanname:
"Tijdens normaal bedrijf bewandelen alle pakketjes het "linker" pad.
In een fall-back bewandelen ze het "rechter" pad."

Is incorrect. In normaal bedrijf volgen de pakketjes:

Experiabox --> 5 Ports UniFi witch (rlinks) --> FW (links) --> Aggregation switch 1 --> Switch (links)
|
--Aggregation switch 2--> Switch (rechts)

De aggregatieswitches en de grote switches zijn beide een access laag (op de aggregatie switches zit bijvoorbeeld een NAS en Proxmox Server). . Op dit moment zijn de 48 poort switches nog 1 SFP. Worden in de toekomst geupdate naar SFP+ (en twijfel nog tussen 4 ports SFP+ of 2 ports SFP+).

Het probleem met dit soort vraagstukken is doorgaans:
(1) - welke mechanismes zijn beschikbaar om een foutsituatie te detecteren
(2) - welke mechanismes zijn er om het bijbehorende backup pad te activeren
(3) - hoe en op welk moment ga je terug naar normaal bedrijf

Foutdetectie is makkelijk - een of meer verbindingen vallen weg.
Maar automagically het juiste backup pad activeren is vaak een ander verhaal.
Zeker met zoveel schakels in een keten en de hoge vermazing.

Zie ook onderstaande afbeelding (geen idee of dit te doen is):
Mij lijkt dit handiger - met de aanname dat - afgezien van de 5G router - alle genoemde apparaten stp ondersteunen.

De linker Sophos router is normaliter root-bridge (met de rechter Sophos router als fall-back).
Door te spelen met path-costs op de uitgaande poorten vanuit de onderste 4 switches dwing je af welk pad op enig moment actief moet zijn. Daarbij bepaald elke switch voor zich het "goedkoopste" pad naar de root-bridge.

Voor zover ik nu kan overzien kun je hiermee alle enkelvoudige foutsituaties ondervangen; inclusief een passend backup pad.

[John245]

GoBieN-Be schreef op zondag 7 januari 2024 @ 19:51:
[...]


Bij het falen van de linkse kleine WAN switch, gaat je linkse firewall (primair) geen toegang hebben tot de Experiabox en overschakelen op de 5G. Terwijl er met de Experiabox niks mis is, enkel de kleine linkse switch is kapot. Je firewall zal ook niet auto overschakelen naar de andere passieve firewall in zo'n geval.

Indien je op de linkse firewall de WAN-EXPERIA poort kan bridgen naar 2 interfaces dan trek je een 2de kabel naar de rechtse WAN switch en van daar uit ook een kabel naar de Experiabox die ook meerdere poorten heeft zo te zien. Echter maak je dan eigenlijk een lus, dus zou je moeten spanning tree configureren op de kleine WAN switches.

Wordt wat ingewikkeld precies. Misschien toch gewoon laten naar 5G overschakelen als die linkse WAN switch het begeeft en dan gewoon indien nodig manueel de firewall ook overschakelen of vlug de switches gaan omwisselen.

Dat scenario is inderdaad correct. Heb wel een spare liggen, dus eventueel makkelijk op te lossen. Wat betreft bekabeling er liggen 10 CAT kabels tussen beide gebouwen dus daar zit voorlopig geen beperking.

Ik probeer het te visualiseren, maar vrees dat mijn viualisatie niet correct is.

[ Voor 3% gewijzigd door John245 op 07-01-2024 20:54 ]

[John245]

Airw0lf schreef op zondag 7 januari 2024 @ 20:28:
[...]


Ja - ik bedoelde deze switchlaag.
Die EB van KPN heeft toch 4 lanpoorten?
Daar kan je dan toch de twee Sophos firewalls op aansluiten?


[...]


Het probleem met dit soort vraagstukken is doorgaans:
(1) - welke mechanismes zijn beschikbaar om een foutsituatie te detecteren
(2) - welke mechanismes zijn er om het bijbehorende backup pad te activeren
(3) - hoe en op welk moment ga je terug naar normaal bedrijf

Foutdetectie is makkelijk - een of meer verbindingen vallen weg.
Maar automagically het juiste backup pad activeren is vaak een ander verhaal.
Zeker met zoveel schakels in een keten en de hoge vermazing.

Zie ook onderstaande afbeelding (geen idee of dit te doen is):
Mij lijkt dit handiger - met de aanname dat - afgezien van de 5G router - alle genoemde apparaten stp ondersteunen.

De linker Sophos router is normaliter root-bridge (met de rechter Sophos router als fall-back).
Door te spelen met path-costs op de uitgaande poorten vanuit de onderste 4 switches dwing je af welk pad op enig moment actief moet zijn. Daarbij bepaald elke switch voor zich het "goedkoopste" pad naar de root-bridge.

Voor zover ik nu kan overzien kun je hiermee alle enkelvoudige foutsituaties ondervangen; inclusief een passend backup pad.

[Afbeelding]

Ik kan het overschakelen naar de fallback FW komend weekend testen. Maar ik ben bang dat de FW niet overschakelt van links naar recht omdat ik een active-passive set-up heb in plaats van active-active (in verband met licentiekosten).

Ik laat de resultaten weten.

[Airw0lf]

John245 schreef op zondag 7 januari 2024 @ 21:02:
[...]

Ik kan het overschakelen naar de fallback FW komend weekend testen. Maar ik ben bang dat de FW niet overschakelt van links naar recht omdat ik een active-passive set-up heb in plaats van active-active (in verband met licentiekosten).

Ik laat de resultaten weten.

Mmm - je zou eens kunnen kijken hoe ver je komt als beide Sophos dozen als standalone niet-HA apparaten ingezet worden - eigenlijk heb je dan een vorm van active-active. Alleen ga je voor een fail-over leunen op stp (versus Sophos zijn eigen kunstje). De HA-link is dan niet meer nodig.

De bridge poorten van je Proxmox servers kunnen dan meespelen in het stp spel - alles bij elkaar misschien net zo handig in jou situatie?!

[ Voor 15% gewijzigd door Airw0lf op 07-01-2024 21:26 ]

[John245]

Airw0lf schreef op zondag 7 januari 2024 @ 21:15:
[...]


Mmm - je zou eens kunnen kijken hoe ver je komt als beide Sophos dozen als standalone niet-HA apparaten ingezet worden - eigenlijk heb je dan een vorm van active-active. Alleen ga je voor een fail-over leunen op stp (versus Sophos zijn eigen kunstje).

De bridge poorten van je Proxmox servers kunnen dan meespelen in het stp spel - alles bij elkaar misschien net zo handig in jou situatie?!

@airwolf Standalone is zelfs geen optie. Daarvoor heb ik een extra licentie nodig (die zeer kostbaar is).

[Airw0lf]

John245 schreef op zondag 7 januari 2024 @ 21:26:
[...]

@airwolf Standalone is zelfs geen optie. Daarvoor heb ik een extra licentie nodig (die zeer kostbaar is).

Volgens mij was een OpnSense-koppeltje handiger geweest...

[ Voor 9% gewijzigd door Airw0lf op 07-01-2024 21:30 ]

[John245]

Airw0lf schreef op zondag 7 januari 2024 @ 21:29:
[...]


Volgens mij was een OpnSense-koppeltje handiger geweest...

Misschien wel. De eerste FW was gratis bij aanschaf van de licentie. De 2e moest ik wel betalen. En het werkt wel heel prettig out of the box. En die WAN switches kosten niet veel.

[nero355]

John245 schreef op zaterdag 6 januari 2024 @ 19:20:
Mijn gedachte was er is altijd maar 1 NIC actief dus het maakt niet uit wat er gesupport wordt.

Maar het zou dus moeten worden:

auto lo
iface lo inet loopback

iface eth0 inet manual

iface eth1 inet manual

auto bond0
iface bond0 inet manual
bond-slaves eth0 eth1
bond-miimon 100
bond-mode 802.3ad
bond-xmit-hash-policy layer2+3

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

Kunnen nog wat optimalisaties bij aan de LACP kant, maar in principe wordt het dan zoiets inderdaad

Ik was alleen vergeten dit erbij te zetten :

GoBieN-Be schreef op zaterdag 6 januari 2024 @ 21:17:
Een LAG over meerdere switches heen kan je maken als de switches in een stack zitten of indien ze M(C)LAG ondersteunen.
Wikipedia: Multi-chassis link aggregation group

Wellicht kan het wel zonder LAG als je de Linux bond op een failover mode instelt die geen switch support nodig heeft.

Want als je dat niet hebt dan is het einde verhaal...

Als dit echter klopt :

stormfly schreef op zondag 7 januari 2024 @ 09:57:
Wat er anders is: jij hebt twee losse UniFi switches zonder slim protocol ertussen zoals mLAG in het plaatje. Je kunt bij UniFi wel LACP configureren, maar slechts 1 server met 2 porten op 1 switch.

stormfly schreef op zondag 7 januari 2024 @ 12:09:
Het blijft een nadeel met UniFi dat je geen "stacks" kunt maken met switches, waardoor je altijd geneuzel hebt met spanningtree en inherent daaraan; geblokkeerde paden om loops te voorkomen.

Dan heb je dus voor de verkeerde Switches gekozen!

En vraag ik me ook meteen af waarom die krengen Aggregation Switches heten als ze zoiets belangrijks niet kunnen ?!?!

Typisch Ubiquiti UniFi gezeik weer...

[John245]

nero355 schreef op maandag 8 januari 2024 @ 19:05:
[...]

Kunnen nog wat optimalisaties bij aan de LACP kant, maar in principe wordt het dan zoiets inderdaad

Ik was alleen vergeten dit erbij te zetten :

[...]

Want als je dat niet hebt dan is het einde verhaal...

Als dit echter klopt :

[...]


[...]

Dan heb je dus voor de verkeerde Switches gekozen!

En vraag ik me ook meteen af waarom die krengen Aggregation Switches heten als ze zoiets belangrijks niet kunnen ?!?!

Typisch Ubiquiti UniFi gezeik weer...

Ik ga het in de toekomst zien. Maar ik neem aan dat ze niet voor niks aggregation switches heten.

[John245]

Airw0lf schreef op zondag 7 januari 2024 @ 20:28:
[...]


Ja - ik bedoelde deze switchlaag.
Die EB van KPN heeft toch 4 lanpoorten?
Daar kan je dan toch de twee Sophos firewalls op aansluiten?


[...]


Het probleem met dit soort vraagstukken is doorgaans:
(1) - welke mechanismes zijn beschikbaar om een foutsituatie te detecteren
(2) - welke mechanismes zijn er om het bijbehorende backup pad te activeren
(3) - hoe en op welk moment ga je terug naar normaal bedrijf

Foutdetectie is makkelijk - een of meer verbindingen vallen weg.
Maar automagically het juiste backup pad activeren is vaak een ander verhaal.
Zeker met zoveel schakels in een keten en de hoge vermazing.

Zie ook onderstaande afbeelding (geen idee of dit te doen is):
Mij lijkt dit handiger - met de aanname dat - afgezien van de 5G router - alle genoemde apparaten stp ondersteunen.

De linker Sophos router is normaliter root-bridge (met de rechter Sophos router als fall-back).
Door te spelen met path-costs op de uitgaande poorten vanuit de onderste 4 switches dwing je af welk pad op enig moment actief moet zijn. Daarbij bepaald elke switch voor zich het "goedkoopste" pad naar de root-bridge.

Voor zover ik nu kan overzien kun je hiermee alle enkelvoudige foutsituaties ondervangen; inclusief een passend backup pad.

[Afbeelding]

@Airw0lf
Ik heb wel een switch gebruikt om de Netgear met beide FW's te verbinden.

Theoretisch en practisch kan jou plaatje ook werken. Maar Sophos support zegt:
"Thank you for reaching out to the community, please refer the following guides to narrow down the situation. Although we will not recommend to keep WAN link under the HA monitoring, as in any ISP fluctuation scenario there will be an unnecessary failover. Though we would request you to verify the HA settings from the following guide below:"

Indien ik de kabel uit de Experiabox verwijder schakelt de FW netjes over op 5G (backup). Indien ik de Kabel weer in de Experiabox stop heb ik weer gewoon vast internet.

Ik heb het zo ingesteld dat indien er overgeschakeld wordt van 5G naar vast alle verbindingen gehost worden vanaf de herstelde verbinding.

Ik krijg waarschuwingen per e-mail indien de primaire internetverbinding DOWN gaat en ook als die weer UP is.

Internet redundantie werkt dus.

Voor mijn backup naar de Cloud ga ik een FW regel instellen die ervoor zorgt dat dit alleen mogelijk is indien de priaire verbinding actief is.

[John245]

Airw0lf schreef op zondag 7 januari 2024 @ 20:28:
[...]


Ja - ik bedoelde deze switchlaag.
Die EB van KPN heeft toch 4 lanpoorten?
Daar kan je dan toch de twee Sophos firewalls op aansluiten?


[...]


Het probleem met dit soort vraagstukken is doorgaans:
(1) - welke mechanismes zijn beschikbaar om een foutsituatie te detecteren
(2) - welke mechanismes zijn er om het bijbehorende backup pad te activeren
(3) - hoe en op welk moment ga je terug naar normaal bedrijf

Foutdetectie is makkelijk - een of meer verbindingen vallen weg.
Maar automagically het juiste backup pad activeren is vaak een ander verhaal.
Zeker met zoveel schakels in een keten en de hoge vermazing.

Zie ook onderstaande afbeelding (geen idee of dit te doen is):
Mij lijkt dit handiger - met de aanname dat - afgezien van de 5G router - alle genoemde apparaten stp ondersteunen.

De linker Sophos router is normaliter root-bridge (met de rechter Sophos router als fall-back).
Door te spelen met path-costs op de uitgaande poorten vanuit de onderste 4 switches dwing je af welk pad op enig moment actief moet zijn. Daarbij bepaald elke switch voor zich het "goedkoopste" pad naar de root-bridge.

Voor zover ik nu kan overzien kun je hiermee alle enkelvoudige foutsituaties ondervangen; inclusief een passend backup pad.

[Afbeelding]

De primaire FW kan overgenomen worden door de secundaire FW indien de verbinding met de vaste internetverbinding wegvalt.

Op basis van aanbevelingen van Sophos besloten dit niet te doen. Maar getest en technisch werkt het.

Maar als ik daar redundantie wil hebben voor een kabelbreuk kan ik natuurlijk ook een extra kabeltje naar de primaire FW leggen.

[bdu]

Ik loop nu meerdere keren tegen hetzelfde issue aan waardoor mij hele setup vast loopt en de enige remedie een herstart lijkt te zijn.

Ik heb een installatie met een x aantal containers en een aantal VM. Deze draaien prima. 1 van de vm's in een truenas installatie met twee 4tb ssd's (ZFS) welke dienen als opslag. Ook gebruik ik hiervan een NSF share welke door proxmox dient als opslag, voor onder andere backups.

Nu hetvolgende scenario. Ik draai een backup van verschillende containers en vm's, naar de truenas opslag. En ineens is de truenas storage niet meer beschikbaar en loopt de gehele installatie vast.

Ik heb op moment van de backup (Jan 15 14:42:19) de logs, zie hieronder:

https://pastebin.com/fsJ4HGew

Proxmox UI geeft geen status meer weer , het stoppen van de truenas VM is ook niet meer mogelijk. niet via UI maar ook niet via cli; via CLI krijg ik:

root@pve-ryzen:~# qm stop 205
trying to acquire lock...
can't lock file '/var/lock/qemu-server/lock-205.conf' - got timeout
root@pve-ryzen:~# qm start 205
trying to acquire lock...
can't lock file '/var/lock/qemu-server/lock-205.conf' - got timeout
root@pve-ryzen:~# qm unlock 205
trying to acquire lock...
can't lock file '/var/lock/qemu-server/lock-205.conf' - got timeout

Hebben jullie enig idee wat het zou kunnen zijn Durf geen backup meer te draaien

[Goof2000]

bdu schreef op maandag 15 januari 2024 @ 15:18:
Ik loop nu meerdere keren tegen hetzelfde issue aan waardoor mij hele setup vast loopt en de enige remedie een herstart lijkt te zijn.

Ik heb een installatie met een x aantal containers en een aantal VM. Deze draaien prima. 1 van de vm's in een truenas installatie met twee 4tb ssd's (ZFS) welke dienen als opslag. Ook gebruik ik hiervan een NSF share welke door proxmox dient als opslag, voor onder andere backups.

Nu hetvolgende scenario. Ik draai een backup van verschillende containers en vm's, naar de truenas opslag. En ineens is de truenas storage niet meer beschikbaar en loopt de gehele installatie vast.

Ik heb op moment van de backup (Jan 15 14:42:19) de logs, zie hieronder:

https://pastebin.com/4M3rqP42

Proxmox UI geeft geen status meer weer , het stoppen van de truenas VM is ook niet meer mogelijk. niet via UI maar ook niet via cli; via CLI krijg ik:


[...]


Hebben jullie enig idee wat het zou kunnen zijn Durf geen backup meer te draaien

Toevallig een Kingston nvme? (omdat uit te sluiten)
Zo niet, welke hardware gebruik je?

[bdu]

Goof2000 schreef op maandag 15 januari 2024 @ 15:20:
[...]


Toevallig een Kingston nvme? (omdat uit te sluiten)
Zo niet, welke hardware gebruik je?

Nee, geen kingston; dit is mijn configuratie:

#	Category	Product	Prijs	Subtotaal
1	Processors	AMD Ryzen 7 5700G Boxed	€ 187,68	€ 187,68
1	Barebones	ASRock DeskMini X300	€ 149,90	€ 149,90
1	Processorkoeling	Noctua NH-L9a-AM4 chromax.black	€ 54,90	€ 54,90
1	Geheugen intern	Crucial CT2K32G4SFD832A	€ 149,42	€ 149,42
2	Solid state drives	Samsung 870 QVO 4TB	€ 178,-	€ 178,-
1	Solid state drives	Samsung 980 Pro (zonder heatsink) 2TB	€ 137,49	€ 137,49
1	Serversoftware	TrueNAS Scale	€ 0,-	€ 0,-
1	Overige componenten	ASRock DeskMini 2x USB 2.0 cable	€ 9,95	€ 9,95
			Totaal	€ 867,34

[nero355]

bdu schreef op maandag 15 januari 2024 @ 15:24:
Dit is mijn configuratie:

- AMD Ryzen 7 5700G Boxed
- ASRock DeskMini X300
- Samsung 870 QVO 4TB
- Samsung 980 Pro (zonder heatsink) 2TB

Het zou me niet verbazen als één van die 4 de oorzaak is van de problemen eerlijk gezegd :

- AMD < Intel als het gaat om virtualisatie wat mij betreft!
- Consumer/Gamer Samsung SSD's zijn voor dit soort dingen gewoon geen handige keuze als je het echt goed wilt doen!
Zie :
- nero355 in "Het grote Proxmox VE topic"
- nero355 in "Het grote Proxmox VE topic"

[bdu]

nero355 schreef op maandag 15 januari 2024 @ 20:04:
[...]

Het zou me niet verbazen als één van die 4 de oorzaak is van de problemen eerlijk gezegd :

- AMD < Intel als het gaat om virtualisatie wat mij betreft!
- Consumer/Gamer Samsung SSD's zijn voor dit soort dingen gewoon geen handige keuze als je het echt goed wilt doen!
Zie :
- nero355 in "Het grote Proxmox VE topic"
- nero355 in "Het grote Proxmox VE topic"

Maar verder doen die ssd's het prima. Ook het wegschrijven van grotere bestanden of grotere collecties met foto's gaat zonder problemen.

Het lijkt het meer in de NFS share te liggen die de weg kwijt raakt.. Maar zou niet weten waarom dat gebeurd als proxmox de backup wegschrijft, in dit geval niet eens echt veel data.

[powerboat]

bdu schreef op maandag 15 januari 2024 @ 15:18:
Ik loop nu meerdere keren tegen hetzelfde issue aan waardoor mij hele setup vast loopt en de enige remedie een herstart lijkt te zijn.

Ik heb een installatie met een x aantal containers en een aantal VM. Deze draaien prima. 1 van de vm's in een truenas installatie met twee 4tb ssd's (ZFS) welke dienen als opslag. Ook gebruik ik hiervan een NSF share welke door proxmox dient als opslag, voor onder andere backups.

Nu hetvolgende scenario. Ik draai een backup van verschillende containers en vm's, naar de truenas opslag. En ineens is de truenas storage niet meer beschikbaar en loopt de gehele installatie vast.

Ik heb op moment van de backup (Jan 15 14:42:19) de logs, zie hieronder:

https://pastebin.com/fsJ4HGew

Proxmox UI geeft geen status meer weer , het stoppen van de truenas VM is ook niet meer mogelijk. niet via UI maar ook niet via cli; via CLI krijg ik:


[...]


Hebben jullie enig idee wat het zou kunnen zijn Durf geen backup meer te draaien

Misschien dumb question maar loopt die telkens vast bij 205? En is de 205 niet toevallig de TrueNAS die je probeert te backuppen?

[bdu]

powerboat schreef op maandag 15 januari 2024 @ 20:30:
[...]


Misschien dumb question maar loopt die telkens vast bij 205? En is de 205 niet toevallig de TrueNAS die je probeert te backuppen?

Nee, helaas. Daar had ik eerder al eens problemen mee. 205 werd dit keer niet gebackuped.

Nu was het vrijwel direct na het backuppen van container 100, daar draait mijn unifi controller op. Maar dat kan toch bijna niets met de beschikbaarheid van de NFS te maken hebben? (of toch wel??)

[powerboat]

bdu schreef op maandag 15 januari 2024 @ 22:20:
[...]

Nee, helaas. Daar had ik eerder al eens problemen mee. 205 werd dit keer niet gebackuped.

Nu was het vrijwel direct na het backuppen van container 100, daar draait mijn unifi controller op. Maar dat kan toch bijna niets met de beschikbaarheid van de NFS te maken hebben? (of toch wel??)

Heb je een HBA kaart via pci passthrough beschikbare gemaakt aan je Truenas?

Heb daarmee ook wel eens een issue gehad.

[bdu]

powerboat schreef op dinsdag 16 januari 2024 @ 00:22:
[...]


Heb je een HBA kaart via pci passthrough beschikbare gemaakt aan je Truenas?

Heb daarmee ook wel eens een issue gehad.

Nee, schijven geef ik vanaf de host direct door aan Truenas.

[nero355]

bdu schreef op dinsdag 16 januari 2024 @ 07:47:
Nee, schijven geef ik vanaf de host direct door aan Truenas.

Wat ik al eerder zei : AMD < Intel als het om dit soort dingen gaat en dus ook AMD IOMMU < Intel IOMMU a.k.a. Intel VT-D

Zie bijvoorbeeld de AMD EPYC problemen die er waren onder VMWare ESXi in het verleden en misschien nog steeds er in mindere/lichtere mate zijn...

Begrijp me niet verkeerd : Ik ben dol op die AsRock A300/X300 kastjes, maar ik zou ze niet voor virtualisatie toepassingen gebruiken!

[John245]

nero355 schreef op dinsdag 16 januari 2024 @ 17:10:
[...]

Wat ik al eerder zei : AMD < Intel als het om dit soort dingen gaat en dus ook AMD IOMMU < Intel IOMMU a.k.a. Intel VT-D

Zie bijvoorbeeld de AMD EPYC problemen die er waren onder VMWare ESXi in het verleden en misschien nog steeds er in mindere/lichtere mate zijn...

Begrijp me niet verkeerd : Ik ben dol op die AsRock A300/X300 kastjes, maar ik zou ze niet voor virtualisatie toepassingen gebruiken!

Hier een Intel® Xeon® Silver 4314 Processor - 16 Cores - 32 Threads - 2.4Ghz - 3.4Ghz turbo - 24MB Cache - 2S - 135W

Ideaal voor Proxmox.

[rachez]

nero355 schreef op maandag 15 januari 2024 @ 20:04:
[...]

- Consumer/Gamer Samsung SSD's zijn voor dit soort dingen gewoon geen handige keuze als je het echt goed wilt doen!
Zie :
- nero355 in "Het grote Proxmox VE topic"
- nero355 in "Het grote Proxmox VE topic"

Tja dat is ook maar jezelf quoten . Draai zelf in een nuc al meer dan 10 jaar samsung consumers ssd's zonder issues.

Ok toegegeven heb het ook wel eens gehad met een beruchte ssd van een ander merk dat er een bug in zat, dus je hebt echt wel een punt, maar om nou te zeggen dat het niet kan in een homelab, gaat mij nog een brug te ver.

Maak gewoon goede backups van je vm's op andere storage en zet de backups terug bij issues.

[powerboat]

Schijven doorgeven hoeft op zich geen probleem te zijn heb dat ook in een paar configuraties op die manier gedaan.

[GoBieN-Be]

Ik draai al jaren zowel Intel als AMD.
Beide zijn bij mij foutloos.
Bij mijn conusmer AMD platform (gebruik als ESXi host) gebruik ik zelfs ECC RAM.
Qua SSD's gebruik ik al jaren Samsung en WD consumer SSD's, met slechts1 probleemgeval, kan ik ook niet klagen.
Dat terzijde, als reactie op ongefundeerde beweringen dat Intel beter is dan AMD.

Een interessant stuk in de log zijn deze 2 lijnen waarmee de uitval begint.

Jan 15 14:42:20 pve-ryzen kernel: EXT4-fs (dm-32): write access unavailable, skipping orphan cleanup
Jan 15 14:42:20 pve-ryzen kernel: EXT4-fs (dm-32): mounted filesystem db8a37a6-4cca-4ea1-98b9-4add6b612ccb ro without journal. Quota mode: none.

Dit lijkt erop te wijzen dat je filesystem (EXT4) in read-only mode vliegt voor één of andere reden.
Ik zou zoeken naar meer logs over filesystem.

Je moet eens uitzoeken als dm-32 slaat op de storage van de VM 100 (lxc) of van de Truenas VM (waar je naar probeert te schrijven).

[ Voor 12% gewijzigd door GoBieN-Be op 16-01-2024 22:39 ]

[powerboat]

Draai meerdere platformen bij klanten zowel amd als Intel. Kan niet zeggen dat de een slechter is als de ander.

[Zwelgje]

powerboat schreef op dinsdag 16 januari 2024 @ 22:38:
Draai meerdere platformen bij klanten zowel amd als Intel. Kan niet zeggen dat de een slechter is als de ander.

Exact, recent nog een nieuwe Citrix omgeving opgeleverd met 20 ESXi hosts die allemaal op AMD processoren draaien. geen centje pijn.

[zeroday]

bdu schreef op maandag 15 januari 2024 @ 22:20:
[...]

Nee, helaas. Daar had ik eerder al eens problemen mee. 205 werd dit keer niet gebackuped.

Nu was het vrijwel direct na het backuppen van container 100, daar draait mijn unifi controller op. Maar dat kan toch bijna niets met de beschikbaarheid van de NFS te maken hebben? (of toch wel??)

Hoe back je up? met PBS welke een VM is binnen je proxmox?
Als dat zo is dan kan het gewoon de combinatie met NFS en de PBS binnen proxmox zijn. Dat heb ik een hele tijd zo draaiende gehad met hier en daar issues dat dingen fout gingen zoals je hier beschrijft. (backups die failen, maar het systeem bleef wel doordraaien).

Ik heb daarom PBS nu onafhankelijk draaien op een Intel Nuc en al mijn voorgaande problemen zijn verdwenen. Enerzijds omdat ik de backup nu niet via NFS op de PBS laat lopen maar via SMB

Hoewel ik een fan van NFS ben, lees ik her en der dat men meer en meer fan is van SMB ivm de stabiliteit en snelheid (zal vast en zeker ooit een keer anders zijn geweest). Niettemin, hier draaien de backups zonder problemen.

Dus wellicht is het het proberen waard om naast de NFS share ook een SMB share van je Truenas server te gebruiken en dat te configureren voor backup. Wellicht geeft dat een oplossing.

[Villager]

Ik heb sinds kort ook iets geks met één van m'n Proxmox servertjes.
Ik heb ongeveer twee weken geleden 2 containers aangemaakt. Alles werkte prima. Backups gemaakt naar m'n Synology NAS, dus helemaal in orde. Vandaag restore ik een backup en merkt dat het opstarten veel langer duurt dan anders. Ga ik kijken en nu verwijst de root disk naar de Synology!

Snap er niks van. Hoe kan ik dat nu weer herstellen dat het weer van de "data" directory opstart?

Edit: heb t al gevonden. Bij de restore staat er (nu) standaard restoren naar Synology. Aangepast naar data en nu gaat t goed...

[ Voor 9% gewijzigd door Villager op 17-01-2024 17:11 ]

[nero355]

rachez schreef op dinsdag 16 januari 2024 @ 19:27:
Tja dat is ook maar jezelf quoten

Maar niet zonder reden

Draai zelf in een nuc al meer dan 10 jaar samsung consumers ssd's zonder issues.

Met of zonder veel Writes naar die SSD ??

Ok toegegeven heb het ook wel eens gehad met een beruchte ssd van een ander merk dat er een bug in zat, dus je hebt echt wel een punt, maar om nou te zeggen dat het niet kan in een homelab, gaat mij nog een brug te ver.

Technisch gezien zijn het niet eens echte SSD's als je naar de opzet van de Stroomverliesbescherming kijkt...

powerboat schreef op dinsdag 16 januari 2024 @ 19:54:
Schijven doorgeven hoeft op zich geen probleem te zijn heb dat ook in een paar configuraties op die manier gedaan.

OK, maar dan is het wel zo handig om de exacte details van de opzet en de gebruikte hardware te weten...

GoBieN-Be schreef op dinsdag 16 januari 2024 @ 22:03:
Ik draai al jaren zowel Intel als AMD.
Beide zijn bij mij foutloos.

Ook daarvoor geldt : Hoe ziet de setup eruit ?!

Bij mijn conusmer AMD platform (gebruik als ESXi host) gebruik ik zelfs ECC RAM.

Waarvan dus nog niet helemaal zeker is of het wel 100% werkt, ondanks het feit dat het alleen werkt zonder errors...

Verder kan je bij Intel i3 en Gxxx modellen ook ECC RAM gebruiken en ondertussen misschien ook wel de duurdere Mainstream modellen!

Qua SSD's gebruik ik al jaren Samsung en WD consumer SSD's, met slechts1 probleemgeval, kan ik ook niet klagen.

Zoek eens op hoe Samsung Consumer SSD's in elkaar zitten en hoe de Workstation/Enterprise modellen in elkaar zitten en vertel me dan nog steeds dat je het prima vindt om ze te gebruiken!

Zelfs de SSD waarop mijn Games staan zit beter in elkaar dan die 850 Pro en 980 Pro achtigen : product: Crucial M500 2,5"
En dat is dan niet eens de DC versie!

Dat terzijde, als reactie op ongefundeerde beweringen dat Intel beter is dan AMD.

Ik zou zeggen ga eens kletsen met @|sWORDs| in Het grote ESXi/vSphere Topic en kijk hoe het ervoor staat, want er is echt serieus veel mis mee geweest in het verleden en wie weet wat er allemaal nog niet is opgelost !!

powerboat schreef op dinsdag 16 januari 2024 @ 22:38:
Draai meerdere platformen bij klanten zowel amd als Intel.
Kan niet zeggen dat de een slechter is als de ander.

Zwelgje schreef op woensdag 17 januari 2024 @ 07:00:
Exact, recent nog een nieuwe Citrix omgeving opgeleverd met 20 ESXi hosts die allemaal op AMD processoren draaien. geen centje pijn.

Wel of geen IOMMU om maar wat te noemen

[dcm360]

nero355 schreef op woensdag 17 januari 2024 @ 20:27:
[...]


Waarvan dus nog niet helemaal zeker is of het wel 100% werkt, ondanks het feit dat het alleen werkt zonder errors...

Verder kan je bij Intel i3 en Gxxx modellen ook ECC RAM gebruiken en ondertussen misschien ook wel de duurdere Mainstream modellen!

Mooie grap, tegenwoordig mag je gewoon een Xeon kopen, de i3's en G modellen doen het ook niet meer.

[...]

Wel of geen IOMMU om maar wat te noemen

Oh, begin vooral maar niet over IOMMU. Bij het enige Intel-bord dat ik heb zitten de netwerkkaarten en het M.2-slot in dezelfde groep. En bedankt voor de geweldige implementatie.

[nero355]

dcm360 schreef op woensdag 17 januari 2024 @ 22:32:
Mooie grap, tegenwoordig mag je gewoon een Xeon kopen, de i3's en G modellen doen het ook niet meer.

Hmm... vooruitgang door achteruitgang... fijn...

Oh, begin vooral maar niet over IOMMU. Bij het enige Intel-bord dat ik heb zitten de netwerkkaarten en het M.2-slot in dezelfde groep. En bedankt voor de geweldige implementatie.

Klinkt als een brak ontworpen moederbord...

Over wat voor een "geweldig" stuk hardware hebben we het dan precies ??
Kunnen we die mooi met zijn allen vermijden!

[Zwelgje]

https://bnc.nl/proxmox-meetup/

lokale IT partij (Groningen) organiseert dit. zal ongetwijfeld te maken hebben met de problemen bij broadcom/vmware

[nero355]

Zwelgje schreef op vrijdag 19 januari 2024 @ 14:40:
https://bnc.nl/

lokale IT partij (Groningen)

Leuke naam voor een dergelijk bedrijf : Wikipedia: BNC connector

[_Eend_]

Zwelgje schreef op vrijdag 19 januari 2024 @ 14:40:
https://bnc.nl/proxmox-meetup/

lokale IT partij (Groningen) organiseert dit. zal ongetwijfeld te maken hebben met de problemen bij broadcom/vmware

Jammer dat Grûnn zo ver weg is, het lijkt mij wel interessant om daar als thuisgebruiker er naar toe te gaan

[John245]

_Eend_ schreef op vrijdag 19 januari 2024 @ 21:34:
[...]


Jammer dat Grûnn zo ver weg is, het lijkt mij wel interessant om daar als thuisgebruiker er naar toe te gaan

Voor mij relatief dichtbij. Jammer dat ze geen duidelijk programma hebben.

[powerboat]

Dat is inderdaad jammer, zou voor mij vanuit het zuiden zo'n 5 a 6 uur rijden zijn

[John245]

powerboat schreef op zaterdag 20 januari 2024 @ 11:31:
Dat is inderdaad jammer, zou voor mij vanuit het zuiden zo'n 5 a 6 uur rijden zijn

Dan woon je wel heel zuidelijk. Maastrich Groningen is ca 3,75 uur.

[powerboat]

John245 schreef op zaterdag 20 januari 2024 @ 11:45:
[...]

Dan woon je wel heel zuidelijk. Maastrich Groningen is ca 3,75 uur.

Retourtje (5 a 6 uur)

[Vos]

Nieuwe Proxmox gebruiker hier, weet iemand hoe ik de disk size van mijn local (pve) verhoog? Dit staat op 100GB, maar door wat Home Assistant backups zit ik snel op de max.

Heb een 512 GB SSD, gebruik de mini pc enkel voor HA. Wil uiteindelijk ook op een andere plek backups neerzetten (nas of cloud) maar voor nu eerst op de mini pc zelf.

Wat is qua grootte aan te raden?

Local-lvm zit op 26.18 GB van 375.11 GB.

[ Voor 6% gewijzigd door Vos op 24-01-2024 08:35 ]

[stormfly]

Vos schreef op woensdag 24 januari 2024 @ 08:19:
Nieuwe Proxmox gebruiker hier, weet iemand hoe ik de disk size van mijn local (pve) verhoog? Dit staat op 100GB, maar door wat Home Assistant backups zit ik snel op de max.

Heb een 512 GB SSD, gebruik de mini pc enkel voor HA. Wil uiteindelijk ook op een andere plek backups neerzetten (nas of cloud) maar voor nu eerst op de mini pc zelf.

Wat is qua grootte aan te raden?

Local-lvm zit op 26.18 GB van 375.11 GB.

[Afbeelding]

Dat is handwerk

Als er 1 VM op staat zou ik die backuppen eraf halen en even een fresh install draaien. En tijdens de installatie de disk naar maximaal vergroten, dat is install optie.

[ Voor 9% gewijzigd door stormfly op 24-01-2024 14:03 ]

[Vos]

stormfly schreef op woensdag 24 januari 2024 @ 13:12:
[...]


Dat is handwerk

Als er 1 VM op staat zou ik die backuppen eraf halen en even een fresh install draaien. En tijdens de installatie de disk naar maximaal vergroten, dat is install optie.

Bedankt, ik heb inderdaad maar 1 VM draaien. Dan is die fresh install wellicht meest handige optie. Je doelt dan toch een volledig verse Proxmox install? Moet ik mijn Home Assistant even backuppen en die weer terug plaatsen.

[ Voor 4% gewijzigd door Vos op 24-01-2024 15:43 ]

[John245]

Vos schreef op woensdag 24 januari 2024 @ 14:56:
[...]

Bedankt, ik heb inderdaad maar 1 VM draaien. Dan is die fresh install wellicht meest handige optie. Moet ik mijn Home Assistant even backuppen en die weer terug plaatsen.

En de licentie activeren als je die heb.

[H143]

vraag,

ik draai al een aantal jaren proxmox op mn homelab en een vm installeren e.d. is geen probleem
ik heb een aantal vm's draaien welke ook vanaf buiten bereikbaar zijn dmv NGINX proxy manager en dit gaat ook perfect.

nu wil ik graag een service ook vanaf buitenaf bereiken maar voor de rest gescheiden houden van mijn netwerk, is dit mogelijk binnen proxmox en een standaard kpn box 12 modem/router?

[powerboat]

H143 schreef op woensdag 24 januari 2024 @ 21:44:
vraag,

ik draai al een aantal jaren proxmox op mn homelab en een vm installeren e.d. is geen probleem
ik heb een aantal vm's draaien welke ook vanaf buiten bereikbaar zijn dmv NGINX proxy manager en dit gaat ook perfect.

nu wil ik graag een service ook vanaf buitenaf bereiken maar voor de rest gescheiden houden van mijn netwerk, is dit mogelijk binnen proxmox en een standaard kpn box 12 modem/router?

Weet niet of de xperiabox VLAN's ondersteund, anders heb je als mogelijkheid OPNsense / PFSense achter de Experiabox zetten en dan OPNsense als router gebruiken.

Je kunt dan kiezen om de Experiabox in bridge mode te zetten of NAT achter NAT toe te passen.

[Airw0lf]

H143 schreef op woensdag 24 januari 2024 @ 21:44:
vraag,

ik draai al een aantal jaren proxmox op mn homelab en een vm installeren e.d. is geen probleem
ik heb een aantal vm's draaien welke ook vanaf buiten bereikbaar zijn dmv NGINX proxy manager en dit gaat ook perfect.

nu wil ik graag een service ook vanaf buitenaf bereiken maar voor de rest gescheiden houden van mijn netwerk, is dit mogelijk binnen proxmox en een standaard kpn box 12 modem/router?

Nee - dit is niet mogelijk met een Box12.

Om zoiets voor elkaar te krijgen heb je minimaal een managed L3 switch nodig.
Dus een die overweg kan met vlans en routing. Een andere optie is een tweede router.
Beiden kun je via Proxmox inzetten in de vorm van OpenVSwitch en OpnSense.
De eerste als een APT-package en de tweede als VM.

In beide gevallen maak je een DMZ van het LAN-segment tussen Box12 en de v-switch/v-router.
In beide gevallen worden de LAN-poorten van Box12 gezien als DMZ.

Tot slot: een Box12 blijf in alle gevallen als router (met NAT!) werken - die kent *geen* bridge modus - althans niet in de consumenten uitvoering. Een zakelijk KPN EEN MKB abonnement kan dat wel - vermits je een abonnement neemt met 2 publieke IP adressen.

[ Voor 17% gewijzigd door Airw0lf op 26-01-2024 07:14 ]

[Stimpy68]

Misschien mensen die hier hetzelfde hebben? In mijn homelab heb ik 2 proxmox hosts, 1 intel en 1 AMD, en ja ik weet dat je beter dezelfde hardware kunt hebben Dus mijn setup is niet echt standaard. Maar tot op heden werkte het helemaal prima. Maar kwam er vandaag achter dat als ik een VM migrate naar een andere host, dat deze crashed, wat voorheen nooit het geval was. Na de laatste kernel update van PVE werkte het ook gewoon zonder issues.
Maar gekke is dat mijn pfsense VM zonder problemen heen en weer kan, maar een andere VM (Ubuntu en Debian) crashen. Heb het ook met de PBS geprobeerd, ook deze crashed. Bij alles staat de cpu op kvm64, dus niet op host.
Een kennis van mij heeft dezelfde setup, alleen wel 2 intel hosts, en heeft geen problemen.

Heb een stukje uit een syslog kunnen krijgen:

code:

[ 6755.079893] BUG: unable to handle page fault for address: ffffffff9606e623\cf1\highlight1 
[ 6755.079977] #PF: supervisor write access in kernel mode\cf1\highlight1 
[ 6755.080014] #PF: error_code(0x0003) - permissions violation\cf1\highlight1 
[ 6755.080053] PGD 7120e067 P4D 7120e067 PUD 7120f063 PMD 6fc001e1\cf1\highlight1 
[ 6755.080101] Oops: 0003 [#1] SMP PTI\cf1\highlight1 
[ 6755.080132] CPU: 1 PID: 1254 Comm: containerd-shim Not tainted 5.10.0-27-amd64 #1 Debian 5.10.205-2\cf1\highlight1 
[ 6755.080191] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014\cf1\highlight1 
[ 6755.080274] RIP: 0010:kvm_kick_cpu+0x23/0x30\cf1\highlight1 
[ 6755.080308] Code: 00 00 00 0f 1f 40 00 0f 1f 44 00 00 48 63 ff 53 48 c7 c0 88 95 01 00 31 db 48 8b 14 fd 20 f9 17 97 0f b7 0c 02 b8 05 00 00 00 <0f> 01 c1 5b c3 cc cc cc cc 0f 1f 40 00 0f 1f 44 00 00 55 48 c7 c5\cf1\highlight1 
[ 6755.080448] RSP: 0018:ffffc17a020afc50 EFLAGS: 00010046\cf1\highlight1 
[ 6755.080490] RAX: 0000000000000005 RBX: 0000000000000000 RCX: 0000000000000002\cf1\highlight1 
[ 6755.080543] RDX: ffff9bdafbd00000 RSI: 00000000000000ff RDI: 0000000000000002\cf1\highlight1 
[ 6755.080595] RBP: ffff9bdafbd33c40 R08: ffff9bdafffc5ec0 R09: 0000000000000139\cf1\highlight1 
[ 6755.080649] R10: 0000000000000000 R11: 0000000000000016 R12: 0000000000000004\cf1\highlight1 
[ 6755.080699] R13: 0000000000000206 R14: ffff9bdaf1ac4fe4 R15: 0000000000000002\cf1\highlight1 
[ 6755.080759] FS:  000000c000048090(0000) GS:ffff9bdafbc80000(0000) knlGS:0000000000000000\cf1\highlight1 
[ 6755.080816] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\cf1\highlight1 
[ 6755.080870] CR2: ffffffff9606e623 CR3: 0000000131a5c000 CR4: 00000000000006e0\cf1\highlight1 
[ 6755.080927] Call Trace:\cf1\highlight1 
[ 6755.080977]  ? __die_body.cold+0x1a/0x1f\cf1\highlight1 
[ 6755.081014]  ? kvm_kick_cpu+0x23/0x30\cf1\highlight1 
[ 6755.081047]  ? no_context+0x1a6/0x3c0\cf1\highlight1 
[ 6755.081089]  ? kvm_kick_cpu+0x23/0x30\cf1\highlight1 
[ 6755.081121]  ? exc_page_fault+0xd9/0x160\cf1\highlight1 
[ 6755.081157]  ? asm_exc_page_fault+0x1e/0x30\cf1\highlight1 
[ 6755.081194]  ? kvm_kick_cpu+0x23/0x30\cf1\highlight1 
[ 6755.081715]  __pv_queued_spin_unlock_slowpath+0x99/0xd0\cf1\highlight1 
[ 6755.082311]  __raw_callee_save___pv_queued_spin_unlock_slowpath+0x11/0x24\cf1\highlight1 
[ 6755.082957]  .slowpath+0x9/0x16\cf1\highlight1 
[ 6755.083556]  try_to_wake_up+0x1c8/0x4f0\cf1\highlight1 
[ 6755.084133]  wake_up_q+0x5b/0xa0\cf1\highlight1 
[ 6755.085019]  futex_wake+0x153/0x180\cf1\highlight1 
[ 6755.085642]  do_futex+0x7c7/0xbc0\cf1\highlight1 
[ 6755.086490]  ? __schedule+0x28a/0x870\cf1\highlight1 
[ 6755.087329]  ? schedule+0x46/0xb0\cf1\highlight1 
[ 6755.088035]  ? _cond_resched+0x16/0x50\cf1\highlight1 
[ 6755.088690]  ? do_nanosleep+0x9b/0x1a0\cf1\highlight1 
[ 6755.089562]  ? _copy_from_user+0x2b/0x70\cf1\highlight1 
[ 6755.090307]  __x64_sys_futex+0x146/0x1d0\cf1\highlight1 
[ 6755.090990]  ? switch_fpu_return+0x44/0xc0\cf1\highlight1 
[ 6755.091728]  do_syscall_64+0x33/0x80\cf1\highlight1 
[ 6755.092512]  entry_SYSCALL_64_after_hwframe+0x62/0xc7\cf1\highlight1

[nero355]

Airw0lf schreef op donderdag 25 januari 2024 @ 07:12:
Nee - dit is niet mogelijk met een Box12.

Sterker nog :
Er is eigenlijk heel weinig mogelijk met die dingen en daarom doe je er verstandig aan om de hele meuk door eigen apparatuur te vervangen op het moment dat je wat meer wilt dan de standaard huis, tuin en keuken gebruiker !!

Om zoiets voor elkaar te krijgen heb je minimaal een managed L3 switch nodig.
Dus een die overweg kan met vlans en routing. Een andere optie is een tweede router.
Beiden kun je via Proxmox inzetten - de eerste als een APT-package en de tweede als VM.

Je moet gewoon iets hebben dat kan NATten en VLAN's kent en dat kan prima via een pfSense/OPNsense VM onder andere

Tot slot: een Box12 blijf in alle gevallen als router (met NAT!) werken - die kent *geen* bridge modus - althans niet in de consumenten uitvoering.
Een zakelijk KPN EEN MKB abonnement kan dat wel - vermits je een abonnement neemt met 2 publieke IP adressen.

Vroeger kon je die dingen nog los kopen zonder KPN Firmware erop, maar als je dan toch al bezig bent dan zijn er ook andere veel betere opties!

[Zwelgje]

Stimpy68 schreef op donderdag 25 januari 2024 @ 13:00:
Misschien mensen die hier hetzelfde hebben? In mijn homelab heb ik 2 proxmox hosts, 1 intel en 1 AMD, en ja ik weet dat je beter dezelfde hardware kunt hebben Dus mijn setup is niet echt standaard. Maar tot op heden werkte het helemaal prima. Maar kwam er vandaag achter dat als ik een VM migrate naar een andere host, dat deze crashed, wat voorheen nooit het geval was. Na de laatste kernel update van PVE werkte het ook gewoon zonder issues.
Maar gekke is dat mijn pfsense VM zonder problemen heen en weer kan, maar een andere VM (Ubuntu en Debian) crashen. Heb het ook met de PBS geprobeerd, ook deze crashed. Bij alles staat de cpu op kvm64, dus niet op host.
Een kennis van mij heeft dezelfde setup, alleen wel 2 intel hosts, en heeft geen problemen.

Heb een stukje uit een syslog kunnen krijgen:

code:

[ 6755.079893] BUG: unable to handle page fault for address: ffffffff9606e623\cf1\highlight1 
[ 6755.079977] #PF: supervisor write access in kernel mode\cf1\highlight1 
[ 6755.080014] #PF: error_code(0x0003) - permissions violation\cf1\highlight1 
[ 6755.080053] PGD 7120e067 P4D 7120e067 PUD 7120f063 PMD 6fc001e1\cf1\highlight1 
[ 6755.080101] Oops: 0003 [#1] SMP PTI\cf1\highlight1 
[ 6755.080132] CPU: 1 PID: 1254 Comm: containerd-shim Not tainted 5.10.0-27-amd64 #1 Debian 5.10.205-2\cf1\highlight1 
[ 6755.080191] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014\cf1\highlight1 
[ 6755.080274] RIP: 0010:kvm_kick_cpu+0x23/0x30\cf1\highlight1 
[ 6755.080308] Code: 00 00 00 0f 1f 40 00 0f 1f 44 00 00 48 63 ff 53 48 c7 c0 88 95 01 00 31 db 48 8b 14 fd 20 f9 17 97 0f b7 0c 02 b8 05 00 00 00 <0f> 01 c1 5b c3 cc cc cc cc 0f 1f 40 00 0f 1f 44 00 00 55 48 c7 c5\cf1\highlight1 
[ 6755.080448] RSP: 0018:ffffc17a020afc50 EFLAGS: 00010046\cf1\highlight1 
[ 6755.080490] RAX: 0000000000000005 RBX: 0000000000000000 RCX: 0000000000000002\cf1\highlight1 
[ 6755.080543] RDX: ffff9bdafbd00000 RSI: 00000000000000ff RDI: 0000000000000002\cf1\highlight1 
[ 6755.080595] RBP: ffff9bdafbd33c40 R08: ffff9bdafffc5ec0 R09: 0000000000000139\cf1\highlight1 
[ 6755.080649] R10: 0000000000000000 R11: 0000000000000016 R12: 0000000000000004\cf1\highlight1 
[ 6755.080699] R13: 0000000000000206 R14: ffff9bdaf1ac4fe4 R15: 0000000000000002\cf1\highlight1 
[ 6755.080759] FS:  000000c000048090(0000) GS:ffff9bdafbc80000(0000) knlGS:0000000000000000\cf1\highlight1 
[ 6755.080816] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\cf1\highlight1 
[ 6755.080870] CR2: ffffffff9606e623 CR3: 0000000131a5c000 CR4: 00000000000006e0\cf1\highlight1 
[ 6755.080927] Call Trace:\cf1\highlight1 
[ 6755.080977]  ? __die_body.cold+0x1a/0x1f\cf1\highlight1 
[ 6755.081014]  ? kvm_kick_cpu+0x23/0x30\cf1\highlight1 
[ 6755.081047]  ? no_context+0x1a6/0x3c0\cf1\highlight1 
[ 6755.081089]  ? kvm_kick_cpu+0x23/0x30\cf1\highlight1 
[ 6755.081121]  ? exc_page_fault+0xd9/0x160\cf1\highlight1 
[ 6755.081157]  ? asm_exc_page_fault+0x1e/0x30\cf1\highlight1 
[ 6755.081194]  ? kvm_kick_cpu+0x23/0x30\cf1\highlight1 
[ 6755.081715]  __pv_queued_spin_unlock_slowpath+0x99/0xd0\cf1\highlight1 
[ 6755.082311]  __raw_callee_save___pv_queued_spin_unlock_slowpath+0x11/0x24\cf1\highlight1 
[ 6755.082957]  .slowpath+0x9/0x16\cf1\highlight1 
[ 6755.083556]  try_to_wake_up+0x1c8/0x4f0\cf1\highlight1 
[ 6755.084133]  wake_up_q+0x5b/0xa0\cf1\highlight1 
[ 6755.085019]  futex_wake+0x153/0x180\cf1\highlight1 
[ 6755.085642]  do_futex+0x7c7/0xbc0\cf1\highlight1 
[ 6755.086490]  ? __schedule+0x28a/0x870\cf1\highlight1 
[ 6755.087329]  ? schedule+0x46/0xb0\cf1\highlight1 
[ 6755.088035]  ? _cond_resched+0x16/0x50\cf1\highlight1 
[ 6755.088690]  ? do_nanosleep+0x9b/0x1a0\cf1\highlight1 
[ 6755.089562]  ? _copy_from_user+0x2b/0x70\cf1\highlight1 
[ 6755.090307]  __x64_sys_futex+0x146/0x1d0\cf1\highlight1 
[ 6755.090990]  ? switch_fpu_return+0x44/0xc0\cf1\highlight1 
[ 6755.091728]  do_syscall_64+0x33/0x80\cf1\highlight1 
[ 6755.092512]  entry_SYSCALL_64_after_hwframe+0x62/0xc7\cf1\highlight1

KVM64 moet je in principe niet meer gebruiken, als je hem op QEMU64 zet?

https://qemu-project.gitl...stem/qemu-cpu-models.html

AMD/intel cross migratie kan goed gaan, tot de VM een instructie wil uitvoeren die hij net nog wel kon doen maar nu niet meer op de ander CPU type.

die PfSense VM doet dat blijkbaar niet

[Stimpy68]

@Zwelgje Okay, heb m aangepast, maar helaas... zelfde

[GoBieN-Be]

@Stimpy68

kvm64 (x86-64-v1): Compatible with Intel CPU >= Pentium 4, AMD CPU >= Phenom.

x86-64-v2: Compatible with Intel CPU >= Nehalem, AMD CPU >= Opteron_G3. Added CPU flags compared to x86-64-v1: +cx16, +lahf-lm, +popcnt, +pni, +sse4.1, +sse4.2, +ssse3.

x86-64-v2-AES: Compatible with Intel CPU >= Westmere, AMD CPU >= Opteron_G4. Added CPU flags compared to x86-64-v2: +aes.

x86-64-v3: Compatible with Intel CPU >= Broadwell, AMD CPU >= EPYC. Added CPU flags compared to x86-64-v2-AES: +avx, +avx2, +bmi1, +bmi2, +f16c, +fma, +movbe, +xsave.

x86-64-v4: Compatible with Intel CPU >= Skylake, AMD CPU >= EPYC v4 Genoa. Added CPU flags compared to x86-64-v3: +avx512f, +avx512bw, +avx512cd, +avx512dq, +avx512vl.

[Stimpy68]

@GoBieN-Be Bedankt. Ik heb 2 VM's gemigreerd, 1 met x86-64-v2-AES en 1 met kvm64. Beide Debian. Beide crashen bij migreren. De AMD host is een HP t620 Plus met een AMD GX-420CA cpu (kabini core?).
Wat ik al eerder aan gaf, vorige maand werkte het nog zonder problemen eigenlijk. Ik vermoed zelf dat er iets in de Debian kernel veranderd is (Ubuntu ook overigens, heb 1 VM met Ubuntu die ook crashed wat nooit gebeurde) waardoor de boel nu onderuit gaat. PFsense heeft er helemaal geen last van...

Dit jaar wil ik sowieso mijn HomeLab een upgrade gaan geven met identieke Hardware en meer memory. Maar het frustreert mij nu even dat iets wat voorheen gewoon werkte nu ineens niet meer werkt

[nero355]

Stimpy68 schreef op donderdag 25 januari 2024 @ 18:41:
k heb 2 VM's gemigreerd, 1 met x86-64-v2-AES en 1 met kvm64. Beide Debian.
Beide crashen bij migreren.

De AMD host is een HP t620 Plus met een AMD GX-420CA cpu (kabini core?).
Wat ik al eerder aan gaf, vorige maand werkte het nog zonder problemen eigenlijk.

Ik vermoed zelf dat er iets in de Debian kernel veranderd is (Ubuntu ook overigens, heb 1 VM met Ubuntu die ook crashed wat nooit gebeurde) waardoor de boel nu onderuit gaat. PFsense heeft er helemaal geen last van...

Dat is gek, want je bent x86-64 spul naar een x86 systeem aan het migreren volgens alle data die ik online kan vinden over die AMD GX Serie

Dit jaar wil ik sowieso mijn HomeLab een upgrade gaan geven met identieke Hardware en meer memory. Maar het frustreert mij nu even dat iets wat voorheen gewoon werkte nu ineens niet meer werkt

IMHO had je dat spul nooit moeten kopen, want volgens mij stamt dat nog uit de Geode tijd of iets in die richting van AMD en dat was echt pure troep!

Heb nog een ex-pfSense bakkie met maar 100 Mbps LAN ergens staan met die SoC erin en dat is dan eigenlijk ook nog wel het enige waar je ze voor wilt gebruiken...

[Stimpy68]

@nero355 Ja ja ja.... Je begint eens met wat hardware en bouwt wat, en lange tijd werkt dat gewoon prima. Op die t620 draaien alleen een paar CT's en docker dingen, de andere is een qotom bakje met een i5. En migreerde mijn pfsense er heen als ik de andere pve host moest rebooten vanwege een update bijv. Dat werkt gelukkig nog wel.

Maar het blijft inderdaad raar, en wat ik ook al aan gaf, tot vorige maand werkte het ook allemaal prima met migreren, en nu is het stuk. Geen heel groot issue, maar meer een luxe probleem

Dit jaar gaat het vervangen worden in ieder geval voor wat moderner spul.

[ Voor 3% gewijzigd door Stimpy68 op 26-01-2024 15:01 ]