[Hyper-V] Extra host in cluster weigert VM's

[RammY]

Issue:
Ik heb 3 nodes in een Hyper-V cluster draaien.
Daar ik aan het migreren ben van Xen Server naar Hyper-V, is het de bedoeling dat er telkens een leeg gemaakt Xen node word geherinstalleerd met Windows om deze aan het cluster toe te voegen.

Ik had al een tijdje 3 nodes in een cluster staan.
Echter; nu wil ik een 4e node toevoegen, en dat gaat prima zonder fouten, maar wanneer ik het cluster join en de machines wil moven (of auto balance bij joinen) wil de nieuwe node geen VM's aannemen, omdat er zogenaamd een CPU incompatibility is.
"The virtual machine 'VM-NAAM' is using processor-specific features not supported on physical computer "HOST""

Best raar, want het zijn dezelfde stukken hardware
Ik heb het idee dat het mis gaat na de september updates.
De derde node heb ik op 26-08 geinstalleerd en die loopt prima.

Nou zou je zeggen: "Dan leg je het voor bij Microsoft".
Been there, done that.
Short answer: Your hardware does not support Windows Server 2016".
En klaar is Kees * RammY

Hardware:
HP ProLiant BL460c G7 blades (2x E5649 CPU)

Software:
Microsoft Hyper-V Server 2016

Eerst denk je nog; "kon wel eens aan die ene node liggen die ik nu toevoeg".
Helaas, ook een andere node doet exact hetzelfde.

Wat heb ik geprobeerd, ja wat niet
- Node swappen
- Zowel de laatste als ook de ISO gebruiken die ook voor de andere nodes gebruikt is.
- Wel of juist niet eerst updaten voor het joinen van het cluster
- Microsoft ingeschakeld
- BIOS versies gelijk trekken
- BIOS factory resetten / met elkaar vergelijken
- CPU's gecheckt met CPU-Z op de hosts (en op een guest na moven)

Wat wel werkt:
VM starten op de nieuwe node, dan kan ik hm het hele cluster over moven zonder problemen.
Echter waneer ik de VM uitzet en hij word weer gestart vanaf een andere node, dan is het weer "same @#$, different day".

Iemand nog ideeen?
En helaas, 2012R2 installeren gaat hm niet worden, de VM's hebben al een hogere versie dan dat 2012R2 aan kan.

[Crazymonkey]

Staat in het BIOS de zelfde power plans aan? Dit wil ook nog wel eens problemen geven. (spreek uit eigen ervaring)

[RammY]

Crazymonkey schreef op maandag 21 september 2020 @ 13:42:
Staat in het BIOS de zelfde power plans aan? Dit wil ook nog wel eens problemen geven. (spreek uit eigen ervaring)

Yep, alles op static high performance

Had zelfs in de eerste instantie op de 3 initiele nodes verschillende BIOS versies, zonder gezeur werkend.

[Vorkie]

https://www.altaro.com/hy...mpatibility-mode-hyper-v/

Vinkje eens aangezet op de VM's die dit probleem geven?

[Question Mark]

Heb je de firmware van de blades al eens gecontroleer / gelijkgetrokken?

Hyper-V ziet simpelweg een verschil in cpu's... Is het memory ook gelijk (geplaatst)? Er zit geen verschil in de NUMA nodes?

[RammY]

Vorkie schreef op maandag 21 september 2020 @ 13:46:
https://www.altaro.com/hy...mpatibility-mode-hyper-v/

Vinkje eens aangezet op de VM's die dit probleem geven?

Waarom zou in in de vredesdenaam compatibility mode willen gaan gebruiken terwijl ik dezelfde CPU's gebruik.
Ze zouden zelfs die optie helemaal uit Hyper-V moeten slopen!

Question Mark schreef op maandag 21 september 2020 @ 13:50:
Heb je de firmware van de blades al eens gecontroleer / gelijkgetrokken?

Hyper-V ziet simpelweg een verschil in cpu's... Is het memory ook gelijk (geplaatst)? Er zit geen verschil in de NUMA nodes?

Alle firmware is voor zover ik weet/kan zien gelijk.
Overigens zal dat dan eigenlijk alleen nog gelden voor de NIC's.
Dat is dan gelukkig weer de eenvoud van de G7, niet zoveel poespas als in huidige G's.

Memory zou vreemd zijn, 2 van de 3 nodes hebben 160GB, de andere 144 en dat levert ook geen issues op.
Verschil in NUMA nodes als in?
Het zijn de exact dezelfde CPU's dus...

[Vorkie]

RammY schreef op maandag 21 september 2020 @ 14:33:
[...]


Waarom zou in in de vredesdenaam compatibility mode willen gaan gebruiken terwijl ik dezelfde CPU's gebruik.
Ze zouden zelfs die optie helemaal uit Hyper-V moeten slopen!


[...]


Alle firmware is voor zover ik weet/kan zien gelijk.
Overigens zal dat dan eigenlijk alleen nog gelden voor de NIC's.
Dat is dan gelukkig weer de eenvoud van de G7, niet zoveel poespas als in huidige G's.

Memory zou vreemd zijn, 2 van de 3 nodes hebben 160GB, de andere 144 en dat levert ook geen issues op.
Verschil in NUMA nodes als in?
Het zijn de exact dezelfde CPU's dus...

toon volledige bericht

Dan doe je het niet, maar dan ga ik ook niet voor je verder zoeken, succes!

[MAX3400]

Nog een paar open deuren:

- mag je VM wel migreren CPU-technisch (zie VM-properties -> Processor -> Allow migration)?

- is de VM wel volledig HA (alle resources, CSV's, netwerken etc)?

- Secure Boot aan / uit?

- wat staat er onder de VM properties onder "Actions" ivm dynamic optimization?

- is je cluster niet "ineens" N+1 ipv N+0 en mag je daarom niet meer migreren (extra reserve dus)?

En, allicht een rotte(re) test: maak eens een TEST-VM aan op je bestaande cluster-node EN een andere TEST-VM op je "net toegevoegde" cluster-node en migreer die eens kruiselings?

RammY schreef op maandag 21 september 2020 @ 14:33:
[...]


Waarom zou in in de vredesdenaam compatibility mode willen gaan gebruiken terwijl ik dezelfde CPU's

Dat zou ik niet te hard roepen: 1 CPU kan meerdere family/revisiions hebben en dat heeft idd invloed op wat je wel/niet mag/kan migreren. Via Powershell (commando moet ik opzoeken) kan je echt een berg info per socket opvragen.

[ Voor 46% gewijzigd door MAX3400 op 21-09-2020 14:45 ]

[Question Mark]

RammY schreef op maandag 21 september 2020 @ 14:33:
[...]
Het zijn de exact dezelfde CPU's dus...

Dat blijf je herhalen, maar Hyper-V vind toch iets anders... Je testen wijzen alleen uit dat er verschillen zit in features die ontsloten worden naar de Vcpu's.

Controleer eens met tooling of bv de stepping van de CPU's ook gelijk is? Daarnaast kun je met CPU-Z op zowel de host als guest de features controleren.

[RammY]

Vorkie schreef op maandag 21 september 2020 @ 14:38:
[...]


Dan doe je het niet, maar dan ga ik ook niet voor je verder zoeken, succes!

Simpelweg gaat dat werken, maar dat is niet wat je wil.
Je limiteert je CPU gigantisch en het zou niet moeten hoeven omdat het dezelfde CPU's zijn.
Dus.. .Goed meegedacht maar helaas niet een oplossing

MAX3400 schreef op maandag 21 september 2020 @ 14:40:
Nog een paar open deuren:

- mag je VM wel migreren CPU-technisch (zie VM-properties -> Processor -> Allow migration)?

- is de VM wel volledig HA (alle resources, CSV's, netwerken etc)?

- Secure Boot aan / uit?

- wat staat er onder de VM properties onder "Actions" ivm dynamic optimization?

- is je cluster niet "ineens" N+1 ipv N+0 en mag je daarom niet meer migreren (extra reserve dus)?

En, allicht een rotte(re) test: maak eens een TEST-VM aan op je bestaande cluster-node EN een andere TEST-VM op je "net toegevoegde" cluster-node en migreer die eens kruiselings?


[...]

Dat zou ik niet te hard roepen: 1 CPU kan meerdere family/revisiions hebben en dat heeft idd invloed op wat je wel/niet mag/kan migreren. Via Powershell (commando moet ik opzoeken) kan je echt een berg info per socket opvragen.

toon volledige bericht

- Je bedoelt de optie: "Migratie to a physical computer with a different processor version" oftewel de compatibility mode Die staat dus uit.
- Yep, cluster validation vind het allemaal goed. Mis je een netwerk of een CSV dan gaat ie daar over mekkeren.
- Is een Gen1 VM, dus zonder secure boot.
- Ik kan dit actions tab wat jij noemt nergens vinden.
- Voor zover ik weet kun je een Hyper-V cluster niet N+0 uitvoeren
- Een VM die ik aanmaak of boot op de huidige nodes kunnen niet naar de nieuwe node. Een VM die ik aanmaak/boot op de nieuwe node kunnen wel naar de oude nodes. Echter wanneer deze weer uit gaat en gestart word op de huidige nodes kan deze nog steeds niet naar de nieuwe node. In geval van uitval zouden je machines niet starten, heb getwijfeld of ik dat een optie vond, maar dat vond ik niet

Question Mark schreef op maandag 21 september 2020 @ 14:49:
[...]

Dat blijf je herhalen, maar Hyper-V vind toch iets anders... Je testen wijzen alleen uit dat er verschillen zit in features die ontsloten worden naar de Vcpu's.

Controleer eens met tooling of bv de stepping van de CPU's ook gelijk is? Daarnaast kun je met CPU-Z op zowel de host als guest de features controleren.

CPU-Z geeft exact dezelfde CPU's aan.
Had ik gecheckt, niet in de TS gezet. (bij deze)
Tevens ook op een guest gecheckt of het veranderd bij het booten op een verschillende host.
Maar blijft hetzelfde.

Links bestaande host, rechts nieuwe host.

[ Voor 8% gewijzigd door RammY op 21-09-2020 15:33 ]

[MAX3400]

RammY schreef op maandag 21 september 2020 @ 15:23:
[...]

- Je bedoelt de optie: "Migratie to a physical computer with a different processor version" oftewel de compatibility mode Die staat dus uit.

En kan die aan? Of was dat al getest? Ik lees het niet?

- Voor zover ik weet kun je een Hyper-V cluster niet N+0 uitvoeren

Wel hoor

Een VM die ik aanmaak of boot op de huidige nodes kunnen niet naar de nieuwe node. Een VM die ik aanmaak/boot op de nieuwe node kunnen wel naar de oude nodes. Echter wanneer deze weer uit gaat en gestart word op de huidige nodes kan deze nog steeds niet naar de nieuwe node. In geval van uitval zouden je machines niet starten, heb getwijfeld of ik dat een optie vond, maar dat vond ik niet

Mmm, interessant... Allicht wederom open deur (maar lees ik ook nog niet?): neem aan dat alle hosts / policies hetzelfde zijn incl de firewall voor de migratie-poortjes alsmede de service-accounts?

[Question Mark]

Het enige wat ik nog vermoed is dat er verschil zit in spectre/meltdown patches die verschillend doorgevoerd zijn op de hosts en/of guests.

https://docs.microsoft.co...2017-5715-and-hyper-v-vms

Zijn de vm's overigens opnieuw aangemaakt, of ook gemigreerd vanaf je Xenserver cluster?

[RammY]

MAX3400 schreef op maandag 21 september 2020 @ 15:58:
[...]

En kan die aan? Of was dat al getest? Ik lees het niet?


[...]

[Afbeelding]
Wel hoor


[...]

Mmm, interessant... Allicht wederom open deur (maar lees ik ook nog niet?): neem aan dat alle hosts / policies hetzelfde zijn incl de firewall voor de migratie-poortjes alsmede de service-accounts?

toon volledige bericht

Voor CPU compat mode moet de VM uit.
Even geprobeerd op een VM welke op een bestaande node staat.
Wanneer je deze aanvinkt, de machine boot en de machine wil moven naar de nieuwe node.... je raad het al...
Zelfde CPU melding

En euh... waar vind jij die N+0 opties (kan het echt niet vinden )
Ah zo te zien via SCVMM, die gebruiken we niet

Hosts staan in de zelfde OU waar een policy voor firewalling op ligt.
Is dus hetzelfde voor alle hosts.

Question Mark schreef op maandag 21 september 2020 @ 16:11:
Het enige wat ik nog vermoed is dat er verschil zit in spectre/meltdown patches die verschillend doorgevoerd zijn op de hosts en/of guests.

https://docs.microsoft.co...2017-5715-and-hyper-v-vms

Zijn de vm's overigens opnieuw aangemaakt, of ook gemigreerd vanaf je Xenserver cluster?

VM's wisselen. Meerendeel komt van Xen en zijn dus geconverteerd.
Echter heb ik maarliefst 3 Windows VM's en de rest zijn CentOS 7 VM's (en nog 1 Ubuntu 18 bak )
Als de VM's gepatcht zouden zijn, zou dat toch niet uit mogen maken op welke hosts ze draaien?

[ Voor 30% gewijzigd door RammY op 21-09-2020 16:19 ]

[Question Mark]

RammY schreef op maandag 21 september 2020 @ 16:14:
[...]
Als de VM's gepatcht zouden zijn, zou dat toch niet uit mogen maken op welke hosts ze draaien?

Ook de host moet aangepast worden, zie hieronder een stuk uit de door mij al eerder aangehaalde link. Let even op het stukje in Bold.

Firmware updates from your OEM may contain new processor capabilities that can be used to protect against CVE-2017-5715 (IBRS, STIBP, IBPB). Once the virtualization host's firmware has been updated, the hypervisor can make these additional capabilities available to guest virtual machines after taking the following steps.

(Vandaar ook mijn eerdere vraag of de firmwares gelijk waren).

[ Voor 4% gewijzigd door Question Mark op 21-09-2020 16:28 ]

[RammY]

Question Mark schreef op maandag 21 september 2020 @ 16:27:
[...]

Ook de host moet aangepast worden, zie hieronder een stuk uit de door mij al eerder aangehaalde link. Let even op het stukje in Bold.


[...]


(Vandaar ook mijn eerdere vraag of de firmwares gelijk waren).

Ah juist, op de hosts zijn alleen nieuwe BIOS releases beschikbaar voor Spectre/Meltdown, deze zijn bewust niet geinstalleerd.
Zowel dus niet op de bestaande als op de nieuwe hosts.

[Rolfie]

Toevallig toch niet bepaalde MS Patches geïnstalleerd ergens?
Dat zou mijn eerste verdenking zijn. Eventueel andere firmwares op blade enclosure of andere hardware?

Alternatief zou om een boot te doen met Linux en daar de processor eens goed bekijken.

How to check processor details in linux

[Rolfie]

RammY schreef op maandag 21 september 2020 @ 16:34:
Ah juist, op de hosts zijn alleen nieuwe BIOS releases beschikbaar voor Spectre/Meltdown, deze zijn bewust niet geinstalleerd.
Zowel dus niet op de bestaande als op de nieuwe hosts.

Misschien toch een dubbel check uitvoeren, of ze echt dezelfde versies draaien? (zal je vast wel gedaan hebben).

[MAX3400]

Durf het al niet eens meer te vragen (want je hebt al veel uitgezocht):

- Gebruik je VT-d / VT-x en/of andere technologieen ergens diep verborgen in de BIOS?
- Staat hyper-threading aan/uit per host (en mogelijk ook binnen de VM)?
- Zijn al je Integration Services / Versies wel hetzelfde (host-wise)?

[RammY]

En we zijn er uit .....

Ik liep al even op de zaken vooruit, het gevalletje "welke ISO kies je om te installeren". (dacht dat mijn test niet ging werken maar toch proberen )

Nou had ik blijkbaar toch niet de ISO gebruikt waarmee de eerste 2 nodes in het cluster waren geinstalleerd.
Die heb ik vanmiddag wel gevonden en gebruikt.
Daarna dus alle updates los geinstalleerd.
Nog even getest voordat ik de September Update installeerde (KB4577015).
Dat werkte niet. Na installatie getest... en waarempel...werken!

Waarom de boel dan niet heeft gewerkt met een andere ISO is mij nog steeds een raadsel.
Want de 3e node in het cluster vond het gewoon allemaal prima terwijl deze niet met de oudste ISO geinstalleerd is.
Tocht iets in die September update dus.
Maar het blijft vreemd.

[Dennism]

Misschien wat lastiger uit te voeren, maar wat gebeurt er al je de cpu's uit een werkende node eens in de niet werkende node zet (en mogelijk omgekeerd). Als het dan ineens wel lukt weet je eigenlijk dat het aan de cpu's ligt (ook al lijken ze identiek), werkt het dan ook niet, dan weet je dat het ergens in de node zit.

[MAX3400]

RammY schreef op maandag 21 september 2020 @ 17:03:
"welke ISO kies je om te installeren"

Goed gevonden en opgelost; hopelijk kan je je eigen antwoord als beste markeren

[RammY]

Dennism schreef op maandag 21 september 2020 @ 17:04:
Misschien wat lastiger uit te voeren, maar wat gebeurt er al je de cpu's uit een werkende node eens in de niet werkende node zet (en mogelijk omgekeerd). Als het dan ineens wel lukt weet je eigenlijk dat het aan de cpu's ligt (ook al lijken ze identiek), werkt het dan ook niet, dan weet je dat het ergens in de node zit.

De kans dat dat zou werken was sowieso klein, want heb 2 verschillende servers getracht toe te voegen.
Ook wanneer een CPU-Z al aangeeft dat het dezelfde CPU's zijn, zou ik het nut niet zien van CPU's swappen.
Was sowieso te veel werk geweest maar bedankt voor het meedenken

[Dennism]

RammY schreef op maandag 21 september 2020 @ 17:09:
[...]


De kans dat dat zou werken was sowieso klein, want heb 2 verschillende servers getracht toe te voegen.
Ook wanneer een CPU-Z al aangeeft dat het dezelfde CPU's zijn, zou ik het nut niet zien van CPU's swappen.
Was sowieso te veel werk geweest maar bedankt voor het meedenken

Ik gaf dat vooral omdat ik jaren geleden (nehalem generatie uit mijn hoofd) dit soort issues eens heb getackled met VMWare en HP. Bleek toen aan een moederbord revisie of iets in die strekking te liggen. HP heeft dat destijds opgelost met een mobo swap. Dat was destijds zeer makkelijk te testen door de cpu's uit te wisselen.

[ Voor 5% gewijzigd door Dennism op 21-09-2020 17:17 ]

[RammY]

Over mobo's gesproken, 2 nodes zaten zowat naast elkaar met serienummer, zat 1 letter tussen.
Vandaar ook nog een 2e node geprobeerd in de eerste instantie.
Mogelijk dat MS daar een ingebouwd mechanisme voor heeft/had om zo brakke maandagmorgenmodellen te scheiden.
Maar gelukkig is dat dus niet het geval

[Question Mark]

RammY schreef op maandag 21 september 2020 @ 17:03:
Nog even getest voordat ik de September Update installeerde (KB4577015).
Dat werkte niet. Na installatie getest... en waarempel...werken!

Thx voor de terugkoppeling! Dit kan een ander potentieel heel veel tijd besparen. Dit soort zaken uittesten kan heel tijdrovend zijn.

[RammY]

Och... Zat maar een dikke week prutsen in

[TheGabeMan]

RammY schreef op maandag 21 september 2020 @ 17:03:
En we zijn er uit .....

Ik liep al even op de zaken vooruit, het gevalletje "welke ISO kies je om te installeren". (dacht dat mijn test niet ging werken maar toch proberen )

Nou had ik blijkbaar toch niet de ISO gebruikt waarmee de eerste 2 nodes in het cluster waren geinstalleerd.
Die heb ik vanmiddag wel gevonden en gebruikt.
Daarna dus alle updates los geinstalleerd.
Nog even getest voordat ik de September Update installeerde (KB4577015).
Dat werkte niet. Na installatie getest... en waarempel...werken!

Waarom de boel dan niet heeft gewerkt met een andere ISO is mij nog steeds een raadsel.
Want de 3e node in het cluster vond het gewoon allemaal prima terwijl deze niet met de oudste ISO geinstalleerd is.
Tocht iets in die September update dus.
Maar het blijft vreemd.

Wij zijn tegen het zelfde aangelopen. Hosts die in Oktober hun updates hadden gehad waren opeens niet meer Live Migration compatible. We zijn er achter gekomen dat een security update in combinatie met bepaalde firmware, de microcode van de CPU anders presenteert. Essentieel dat het de combinatie is, beiden apart levert geen issue op.

Ik kwam op dit draadje uit in mijn zoektocht naar uitleg voor management naar welk CPU niveau de CPU compatibility gaat wanneer je die aanzet op de VM, maar daar bleek dit draadje niet over te gaan. Zag wel jouw statement dat je liever hebt dat die functie er helemaal uit gaat. Geloof mij, voor grotere omgevingen ben je er blij mee. Met 400+ hosts, is het onmogelijk om elk cluster steeds met exact dezelfde hardware uit te breiden. Plus het steeds bouwen van een nieuwe cluster wanneer we nieuwe CPU types binnen krijgen, kost handen vol geld aan extra licenties voor failover capaciteit in het cluster, andere sizing, etc, etc.

Tevens bij een upgrade van je hele hardware platform voorkom je dat een VM down moet om naar een nieuw cluster te verplaatsen. Met veel klanten levert dat nogal wat project management op als je dat moet gaan afstemmen.

Qua performance verschil is het nauwelijks meetbaar en al helemaal niet merkbaar in productie. Er zijn natuurlijk altijd uitzonderingen en bepaalde applicaties die een bepaalde instructie set echt vereisen, maar dat zijn er echt heel weinig.