Hyper-V cluster upgrade

[yoeri1989]

Mijn situatie:

Er zijn 4 Hyper-v hosts opgenomen in een cluster op basis van Srv2016 en LBFO switch per host.
Er is 1 nieuwe host bijgekomen op basis van Srv2025 met een SET switch op de betreffende host.

Oude Namen:

HV01 - SRV2016
HV04 - SRV2016
HV05 - SRV2016
HV06 - SRV2016

Nieuwe naam:
BP-HV02 - Srv2025

Omdat de nieuwe host BP-HV02 niet opgenomen kon worden in het betreffende cluster door OS level verschillen is er besloten de oude hosts up te daten naar SRV2025.
Srv2025 ondersteund geen LBFO switches maar alleen SET switches, ook omdat het cluster naar OS level Srv2025 moet zal er eerst een tussen upgrade gemaakt moeten worden naar Srv2022.

Hiervoor is een start gemaakt met de HV01, deze is geupgrade naar Srv2022 als tussenstap, de LBFO switch is verwijderd en er is een SET switch aangemaakt op basis van dezelfde ip settings.
Als er nu vanuit het cluster een failover van een VM gedaan wordt naar HV01 verliest deze VM connectie met het netwerk. Dit zal komen doordat de rest van het cluster wel op LBFO switches communiceert met elkaar.

De vraag nu is of er een mogelijkheid bestaat om de hosts 1 voor 1 te upgraden en te voorzien van de juiste switch technologie zonder dat de communicatie over de oude LBFO switches verloren gaat.

De configuratie is als volgt:

Per oude host zijn de volgende interfaces actief (HV04, HV05, HV06):

A02 -> Storage interface -> 10.10.10.x
B02 -> Storage interface -> 10.10.20.x
CL01 -> Cluster interface -> 10.10.30.x
L01 -> NIC team member LBFO switch
L02 -> NIC team member LBFO switch
LAN -> LBFO Switch -> 172.21.1.x
LAN_Switch -> Hyper-v Switch
1 interface not configured

Per nieuwe host zijn de volgende interfaces actief:
A -> Storage interface -> 10.10.10.x
B -> Storage interface -> 10.10.20.x
Cluster -> Cluster interface -> 10.10.30.x
Prod 1 -> SET switch member
Prod 2 -> SET switch member
vEthernet(LB_Vswitch) -> SET Switch -> 172.21.1.x
Host -> Host interface -> 10.10.44.x
2 interfaces not configured.

Relevante software en hardware die ik gebruik
Server 2016
Server 2022
Server 2025
Fail over Cluster manager
Hyper-v

Wat ik al gevonden of geprobeerd heb
Via AI erachter gekomen dat mijn gedachtegang goed zit, echter loop ik nu vast in een plan te maken om verder te komen.

Uiteindelijk hoop ik dat iemand me de juiste richting in kan helpen om hier verder stappen in te kunnen ondernemen.

Alvast bedankt!

[Markozv]

Waarom zet je niet een nieuw Hyper V cluster op met HV01 / HV02 / HV03 uitgaande van voldoende resources. Dit cluster meteen opbouwen in 2025 en dan de Machines over te huizen van je 2016 cluster naar 2025 cluster in plaats van upgrade naar 2022 en dan 2025. Hierna de overige HV's opnieuw installeren met 2025 en deze toevoegen aan cluster

Gewoon gedachte van mij

[ Voor 14% gewijzigd door Markozv op 16-12-2025 15:04 ]

[yoeri1989]

Markozv schreef op dinsdag 16 december 2025 @ 15:02:
Waarom zet je niet een nieuw Hyper V cluster op met HV01 / HV02 / HV03 uitgaande van voldoende resources. Dit cluster meteen opbouwen in 2025 en dan de Machines over te huizen van je 2016 cluster naar 2025 cluster in plaats van upgrade naar 2022 en dan 2025. Hierna de overige HV's opnieuw installeren met 2025 en deze toevoegen aan cluster

Gewoon gedachte van mij

Na het updaten van HV01 en de problemen die er na ontstaan zijn is dit geen optie meer daar de resources niet meer toereikend zijn. Het idee was juist alles van HV01 drainen naar andere hosts en later terug zetten na de upgrade.

[Question Mark]

yoeri1989 schreef op dinsdag 16 december 2025 @ 15:15:
[...]


Na het updaten van HV01 en de problemen die er na ontstaan zijn is dit geen optie meer daar de resources niet meer toereikend zijn.

Hoe bedoel je "de resources" zijn niet toereikend? Het hele idee van een cluster is dat er uitval van hardware plaats kan vinden. Dan kun je toch tijdens een onderhoudsmoment een host opnieuw installeren en configureren, en vm's verplaatsen? Een cluster zou uit N+1 hosts moeten bestaan.

[yoeri1989]

Question Mark schreef op dinsdag 16 december 2025 @ 15:19:
[...]

Hoe bedoel je "de resources" zijn niet toereikend? Het hele idee van een cluster is dat er uitval van hardware plaats kan vinden. Dan kun je toch tijdens een onderhoudsmoment een host opnieuw installeren en configureren, en vm's verplaatsen? Een cluster zou uit N+1 hosts moeten bestaan.

Er waren genoeg resources indien HV01 nog zou functioneren zoals zou horen, echter door het verschil is virtuele switches lijken de VM's op HV01 niet meer goed te connecteren met het netwerk.

[Markozv]

Question Mark schreef op dinsdag 16 december 2025 @ 15:19:
[...]

Hoe bedoel je "de resources" zijn niet toereikend? Het hele idee van een cluster is dat er uitval van hardware plaats kan vinden. Dan kun je toch tijdens een onderhoudsmoment een host opnieuw installeren en configureren, en vm's verplaatsen? Een cluster zou uit N+1 hosts moeten bestaan.

Daarom vind ik het ook al zo vreemd dit, zoals ik het lees heeft hij nu zelfs zijn N+2 met die extra host, dus in mijn optiek kan er een nieuwe omgeving opgezet worden en VM's overzetten, daarna 1N drainen en opnieuw installeren en toevoegen aan het 2025 cluster

[yoeri1989]

Misschien niet geheel duidelijk:

Het bestaande cluster functioneert op OS level 2016 en moet dus uiteindelijk naar OS level 2025.
We hadden 4 hosts waar we een 5de host bij hebben willen toevoegen en er achter kwamen dat het OS level eerst gelijk moest zijn. We kunnen dus niets migreren naar de BP-HV02, daarnaast is er begonnen met HV01 te upgraden naar 2022 als tussenstap. Dit is in principe goed gegaan, echter moesten we de LBFO switch verwijderen en deze vervangen door een SET switch. Om deze reden krijgen vm's die terug gemigreerd worden naar HV01 niet de juiste netwerk instellingen.

[_JGC_]

Nog iets wat ik niet in je planning zie: zijn de CPU specs van de nieuwe machine identiek aan de oude? Zo nee, bereid je maar voor op VMs die niet willen migreren van de nieuwe hardware naar de oude hardware, tenzij je bereid bent alle VMs in CPU compatibility mode te draaien.

[Zwelgje]

je had gewoon een nieuw cluster moeten bouwen op 2025 en dan via een crosscluster migration (shared nothing storage) de VM's kunnen migreren. dan 1 node van het oude cluster in het nieuwe cluster hangen en de volgende leegspelen en omhangen

waarom kies je voor zoiets? had je dit niet even getest in een labomgeving (nestedVM's in hyperV bijvoorbeeld)

goed mosterd na de maaltijd, heb je niks aan behalve voor de volgende keer.

tip: AI gaat je niet helpen met je migratiezaken, hier komt het gewoon aan op rauwe kennis uit de praktijk

[Blokker_1999]

@yoeri1989, waar de communicatie lijkt mis te lopen is dat jij je bestaande cluster wenst te upgradent erwijl iedereen aangeeft van dat net niet te doen.

Je plaatst BP-HV02 en HV01 dus in 1 cluster, en je gaat die cluster eerst testen en zorgen dat die goed geconfigureerd is want zoals @_JGC_ aangeeft moet je dus opletten met CPU compatibiliteit. Dat is spijtig want je gaat nieuwe CPU technieken niet kunnen gebruiken omdat je dus met oude hosts gaat zitten in je cluster, maar that's life.

Dan heb je 2 hosts in je 2025 cluster en 3 hosts over in je 2016 cluster. Dan zoek je uit hoe je met minimale downtime je VMs kunt migreren van je 2016 cluster naar je 2025 cluster. Mogelijks ga je niet onmiddelijk alle VMs kunnen migreren, maar je gaat minstens 1 andere host uit je 2016 cluster vrij kunnen maken (zodat je 2016 cluster ook een cluster blijft), die converteren, de laatste VMs overzetten om dan de laatste 2 nodes opnieuw te installeren met 2025.

Theoretisch is het trouwens wel mogelijk om met LBFO te werken op 2025 geloof ik, alleen ten sterkste af te raden en niet ondersteund door Microsoft, dus als je ooit ondersteuning nodig hebt zou je daarbij in problemen komen.

Alternatief is natuurlijk om verder te investeren en de 4 oude nodes allemaal te vervangen door nieuwe nodes, zodat ze allemaal op dezelfde hardware en software draaien, waarbij je door de vooruitgang in techniek het voordeel hebt dat je opnieuw met een cluster van 4 of misschien zelfs maar 3 servers gaat toekomen daar deze vandaag veel krachtiger zijn dan toen de oude werden aangekocht.