[Hyper-V 2012 R2] Shutdown/reboot van 2008 R2 VM traag

[Urk]

Op een Dell R720 server met Windows Server 2012 R2 als Hyper-V host heb ik 2 x een Windows Server 2008 R2 VM draaien, wanneer ik een shutdown of reboot binnen de VM's duurt het afsluiten van deze VM's ontzettend lang, minimaal 10 minuten toont het scherm alleen "Stopping Services...".
Toen de 2008 R2 servers nog bare-metal servers waren was dit niet het geval. Ze zijn overgezet naar een virtuele server. Beide VM's hebben dit probleem.
Hierover al wat gezocht en topics gelezen op internet maar kom niet tot een ontdekking wat het probleem is en al helemaal niet tot een oplossing. Het vreemde is dat ik dit ook in andere netwerken al eens heb gezien. Iemand bekend met de euvel en wellicht een oplossing?

[MAX3400]

Wanneer is de laatste keer dat je je Integration Services IN de VM hebt geupdate en welke staan wel/niet aangevinkt op je VM settings?

[Verwijderd]

Kijk eens in je event viewer van de 2008R2 machines tussen de ogenblik dat je het restart commando geeft en de eigenlijke shutdown of er nog iets relevant gelogd wordt?

[DukeBox]

En anders met windows performance toolkit een shutdown analyse doen.

[Urk]

Goede input, dank jullie.
@MAX3400 : laatste keer update van Integration Services is al minimaal half jaar geleden vrees ik. Ga ik nu gelijk doen, ben toch bezig met Firmware en Driver updates van de Intel i350 NIC controllers, daar liep eea ook niet helemaal lekker (1Gbps Hyper-V Replica snelheid dropte na een minuutje ongeveer van volle snelheid naar ergens tussen de 0Mbps en 200Mbps )
@Verwijderd : ga ik doen, stom zelf nog niet aan gedacht

[GreeTz]

Zijn de VM's na de P2V actie ook opgeschoond / ontdaan van overbodige drivers en software?

[Urk]

Urk schreef op zaterdag 21 april 2018 @ 13:22:
[...]Ben toch bezig met Firmware en Driver updates van de Intel i350 NIC controllers, daar liep eea ook niet helemaal lekker (1Gbps Hyper-V Replica snelheid dropte na een minuutje ongeveer van volle snelheid naar ergens tussen de 0Mbps en 200Mbps )
[...]

Hmmm... dit probleem blijft gekgenoeg. Op 2 servers (Dell R720 en Dell R320) repliceer ik VM's van de R720 server naar de R320 server. Beide fysieke servers hebben een 4-poorts Intel i350 1Gbps netwerk controller. Daarvan heb ik zojuist zowel de firmware (v18.0.17) geupdate als de drivers (v18.3). Ik had verwacht dat het probleem hierna opgelost zou moeten zijn.

Wanneer ik de replica start via het netwerk gaat het overzetten van de VHD's in het begin lekker snel, rond de 950Mbps, echter na een seconde of 15 dropt de snelheid tussen de 0Mbps en ~150Mbps. En blijft in de performance grafiek steeds pieken en dalen geven. Wanneer ik daarna op beide fysieke Management NIC's VMQ en Offloading options op disabled zet blijft het wat langer goed gaat, ongeveer 1 a 2 minuten, daarna dropt ook de sneleid weer flink en houd ik geen 1Gbps verbinding...
Zie ook dit topic: https://social.technet.mi...ork?forum=winserverhyperv

[Urk]

GreeTz schreef op zaterdag 21 april 2018 @ 13:27:
Zijn de VM's na de P2V actie ook opgeschoond / ontdaan van overbodige drivers en software?

Ja, ik heb wel via de device manager, show hidden devices, oude netwerkkaarten weggehaald. Of is er nog een andere/betere manier om te zien of alle overbodige drivers zijn verwijderd?
Onnodige software heb ik wel verwijderd..

[MAX3400]

Werkt je replicatie ook traag als de VM's uit staan?

Op 10Gb verbindingen heb ik ook live-replication snelheden gezien van "enkele tientallen MB/s" maar dat is ook inherent aan replication; als je VHDX hebt, is het over het algemeen wel ietsjes sneller. Welke onderliggende storage heb je want een replication is ook vrij zwaar voor de IOPS; er wordt op veelal "in de virtual disks" gekeken naar changed blocks en die worden overgezet en toegepast.

Gebruik je encrypted of unencrypted replication?

[Urk]

@MAX3400 Toevallig staat de VM nu ook uit tijdens replicatie. Dus het is dus in beide gevallen traag...
De replicatie relatie die ik nu heb is unecrypted en uncompressed.
De onderliggende opslag op de R740 is een RAID5 array met nu nog 4 x 960GB Samsung Enterprise SSD's (moeten er later vandaag 6 worden , de storage op de R320 is een RAID5 array met 4 x 4TB SATA (die zijn dus wel wat langzamer maar moeten toch wel 100Mbyte/s aankunnen gok ik...
In de R320 heb ik een tijd geleden de RAID controller nog vervangen van de waardeloze PERC H310 (of hoe dat ding ook heette) naar een PERC H710P met 1GB cache

In de R720 server zitten trouwens in totaal 8 x 1Gbps poorten, 4 op een network daughter kaart (NDC) en 4 op een PCIe adapter. Zojuist de Management NIC verplaatst van een poort op de NDC naar een poort op de PCIe controller. Ook dat maakt geen verschil, na enige tijd (ongeveer na halve tot hele minuut)

Trouwens: het changed blocks verhaal kan ik me in vinden, echter is dat toch niet van toepassing op en initial replica zou ik zeggen, toch?

[ Voor 8% gewijzigd door Urk op 21-04-2018 16:14 ]

[DukeBox]

Urk schreef op zaterdag 21 april 2018 @ 16:03:
de storage op de R320 is een RAID5 array met 4 x 4TB SATA (die zijn dus wel wat langzamer maar moeten toch wel 100Mbyte/s aankunnen gok ik...

Sustained write misschien wel maar random write buiten je cache size ga je dat bij lange na niet redden. Als je dan meer dan 100 iops haalt mag je blij wezen.

[Urk]

DukeBox schreef op zaterdag 21 april 2018 @ 16:19:
[...]

Sustained write misschien wel maar random write buiten je cache size ga je dat bij lange na niet redden. Als je dan meer dan 100 iops haalt mag je blij wezen.

OK, maar een initial replica naar de destination is daar toch een sustained write?
Op de R320 server zie ik in de Resouce monitor ongeveer een write naar de VHD van ~20Mbyte/s

[ Voor 11% gewijzigd door Urk op 21-04-2018 16:30 ]

[DukeBox]

Hangt er vanaf hoe gefragmenteerd je disk/array is en hoe vol.

[Urk]

Ja, ok, snap ik. Echter blijf ik het wel vreemd vinden dat de eerste minuut ongeveer alles wel op bijna 1Gbps gaat, en zo'n 10 tot 15Gbyte lang, daarna zakt hij flink in. Die 10 tot 15Gbyte is geen RAID cache oid... Die is veel kleiner.. Twijfel toch of die NIC's wel goed performen.

Edit: klopt het ook op de R720 server dat de NIC steeds pieken en dalen laat zien, dus bij iedere update van 1 seconden fluctueerd de snelheid steeds, bijv: 213Mbps - 0Mbps - 24Mbps - 196Mbps - 0Mbps - 140Mbps etc..

Hier de grafiek:

[ Voor 34% gewijzigd door Urk op 21-04-2018 16:40 ]

[DukeBox]

Om uit te sluiten dat het storage gerelateerd is zou je een test met ip perf kunnen doen. Als het eerst goed is en dan inzakt duidt meestal op een volle write cache. Als er dan ook nog dingen als flow control aktief zijn kan je hele netwerk bokken door pauze frames.

[Urk]

OK, bedoel je met ip perf: https://iperf.fr ?

Wat me nu wel opvalt is wanneer ik vanaf server R720 naar een aparte NAS een grote file kopieer dat wel ook met ongeveer 45 tot 50Mbyte/s gaat. De NIC speed zie je dan in de taskmanager verhogen naar tussen de 350Mbps tot 700Mbps continue. Dat lijkt me toch te zeggen dat de R320 server de snelheid neit aankan om de VHD met 1Gbps (max netwerkspeed) te schrijven... Of zie ik dat verkeerd?

[DukeBox]

Urk schreef op zaterdag 21 april 2018 @ 20:49:
Dat lijkt me toch te zeggen dat de R320 server de snelheid neit aankan om de VHD met 1Gbps (max netwerkspeed) te schrijven... Of zie ik dat verkeerd?

Ja dat is ook wat ik vermoed. RAID5 is gewoon niet geschikt voor dit soort dingen aangezien het niet schaalt zoals RAID10 en varianten (RAID50/60). Met SSD caching kan je dat nog enigzins oplossen maar ook daar geldt dat als de cache volloopt de performance weg is.

[MAX3400]

Urk schreef op zaterdag 21 april 2018 @ 20:49:
Wat me nu wel opvalt is wanneer ik vanaf server R720 naar een aparte NAS een grote file kopieer dat wel ook met ongeveer 45 tot 50Mbyte/s gaat. De NIC speed zie je dan in de taskmanager verhogen naar tussen de 350Mbps tot 700Mbps continue. Dat lijkt me toch te zeggen dat de R320 server de snelheid neit aankan om de VHD met 1Gbps (max netwerkspeed) te schrijven... Of zie ik dat verkeerd?

Ik gok dat je bedoelt 50MB/s oftewel maximaal 400Mbit? Over welke NIC doe je dat want ik heb een vermoeden dat je je MGMT-NIC, VM-NIC, etc alsmede je vSwitches dus niet goed hebt staan? Maar dat is een aanname op basis van de geposte resultaten.

Verder, je post dat je VHD gebruikt (en geen VHDX); nog afgezien van de onderliggende storage, ga je eenvoudigweg een maximale vertraging van 8 inbouwen als je VHD op block-size niveau aan het repliceren bent t.o.v. VHDX. Dit omdat je 512-byte blocks vs. 4KB blocks mag schrijven.

Daarnaast, maar ook hier doe ik weer aannames, kan je allicht nog kijken naar ApplyChangeReplicaDiskThrottle, MaximumActiveTransfers, ApplyVHDLimit, ApplyChangeReplicaDiskThrottle en ApplyVMLimit in je registry.

En als laatste, je storage is zeker een issue of niet goed geconfigureerd of whatever; ik heb een "simpele" DS414 staan met 3x 3TB in RAID5 (geen SHR opstelling) en ik kan daar met 1Gbit kaartje rustig met 90MB/s naartoe schrijven via SMB3.0 met 4 threads tegelijk. Aangezien writes buiten je cache/flash/NVRAM omgaan, zou ik me initieel eerst eens gaan concentreren waarom je writes erg laag/ruk lijken te zijn. Doe dit vooralsnog buiten Hyper-V om en ga eens kijken naar je protocollen, optimalisaties etc. op beide storage-controllers/firmwares.

[Urk]

MAX3400 schreef op zaterdag 21 april 2018 @ 21:34:
[...]

Ik gok dat je bedoelt 50MB/s oftewel maximaal 400Mbit? Over welke NIC doe je dat want ik heb een vermoeden dat je je MGMT-NIC, VM-NIC, etc alsmede je vSwitches dus niet goed hebt staan? Maar dat is een aanname op basis van de geposte resultaten.
[...]

Klopt inderdaad, ik bedoelde inderdaad 50MByte/s, er komt zo'n 400Mbit/s bij op de NIC speed.
Ik doe dat over de Management NIC, en die staat apart van de VM NIC's en vSwitches.
Wat bedoel je dat ik dan niet goed zou hebben staan?

MAX3400 schreef op zaterdag 21 april 2018 @ 21:34:
[...]
Verder, je post dat je VHD gebruikt (en geen VHDX); nog afgezien van de onderliggende storage, ga je eenvoudigweg een maximale vertraging van 8 inbouwen als je VHD op block-size niveau aan het repliceren bent t.o.v. VHDX. Dit omdat je 512-byte blocks vs. 4KB blocks mag schrijven.
[...]

Klopt, moet wel VHD (en geen VHDX) gebruiken omdat de 2 virtuele servers nog Windows Server 2008 R2 draaien en dus niet op VHDX ondersteund worden. Een andere VM is Server 2012 R2 en die draait wel bovenop een VHDX.
Begrijp niet precies wat je bedoeld met je opmerking over vertraging van 8 inbouwen?

MAX3400 schreef op zaterdag 21 april 2018 @ 21:34:
[...]
Daarnaast, maar ook hier doe ik weer aannames, kan je allicht nog kijken naar ApplyChangeReplicaDiskThrottle, MaximumActiveTransfers, ApplyVHDLimit, ApplyChangeReplicaDiskThrottle en ApplyVMLimit in je registry.
[...]

Dank je, hier had ik al eerder naar gekeken en al die settings staan op default (of ontbreken) zoals in dit artikel vermeld: https://support.microsoft...-v-replica-hvr-in-windows
Begrijp ik hierbij goed dat de setting ApplyVHDLimit standaard 4 VHD's in paralel afhandelt (repliceert)?
Ik heb gekeken of het aanpassen van 1 van deze value's performance kan verbeteren maar dat zie en haal ik niet uit het artikel dat dat in mijn geval kan helpen.

[ Voor 61% gewijzigd door Urk op 21-04-2018 22:10 ]

[Urk]

Ik zie zojuist ook dat de 4TB Dell Seagate SATA disks in de PowerEdge R320 server (model ST4000NM0033) nog firmware GA0A, hebben. Er lijken na die firmware 3 nieuwe firmwares voor deze disken te zijn met de volgende verbeteringen/fixes:

GA0D (recommended):
Oplossing van softwarefouten:
- Lost mogelijke corner case op voor single block loss van WCE cachedata tijdens perioden van hoog systeem-foutherstel
- Lost diverse problemen op als een schijf vastloopt of er een time-out optreedt
- Onderhoud- en statusupdate
Verbeteringen:
- Wijzigingen in het energiebeheer tijdens inactieve tijd
- FW-verbeteringen voor herstel bij schijffouten

GA0F (recommend):
Fixes:
-Correct errors in managing EPC timers
-Correct drive-hang or timeout conditions
Enhancements:
-Modification to Idle time power management functionality
-Drive health and robustness enhancements

GA10 (Urgent):
Oplossingen:
- SMART-zoekfout bij tellen gecorrigeerd
Verbeteringen:
- Verbeterde gezondheid en robuustheid harde schijf


Het lijkt me dus slim om deze maar eens snel te updaten. dit verklaard misschien ook waarom ik eerder vandaag bij een reboot tijdens BIOS opeens een melding van de RAID controller kreeg dat hij disken was verloren (server uitgezet om niet te acknowledgen). Server daarna pnieuw aangezet (zonder disken te reseaten) en opeens werkt alles weer. Vreemd en niet zo best natuurlijk....

Ook is er nog een firmware van de PERC H710P controller met changelog:
Oplossing van softwarefouten
- Probleem opgelost waarbij cache verloren kan gaan met de foutmelding 'Cachedata verloren als gevolg van probleem met het geheugen/de batterij'. Dit probleem doet zich voor wanneer de PERC geconfigureerd is in de PCIe pass-thru-modus in ESXi.
- Probleem opgelost waarbij de controller niet reageert op het verlies van een specifieke schijflink, De schijfletter gaat knipperen en het probleem wordt geregistreerd in het logboek met systeemgebeurtenissen.
-Probleem opgelost waarbij IRQ alleen door één processor wordt verwerkt. IRQ is nu over alle processors verdeeld.

Ook dus nog wel nuttig denk ik

[ Voor 20% gewijzigd door Urk op 21-04-2018 22:27 ]

[MAX3400]

Urk schreef op zaterdag 21 april 2018 @ 22:04:
[...]

Klopt inderdaad, ik bedoelde inderdaad 50MByte/s, er komt zo'n 400Mbit/s bij op de NIC speed.
Ik doe dat over de Management NIC, en die staat apart van de VM NIC's en vSwitches.
Wat bedoel je dat ik dan niet goed zou hebben staan?

Voor 2 hosts met elk hun eigen storage, uit mijn hoofd, heb je minstens 3 dedicated NIC's nodig. MGMT, VM-public en REPL. Afhankelijk van je storage-protocol, zou een 4e NIC ook adviseerbaar zijn. Zolang de hosts niet geclusterd zijn, is 4 NIC's het minimum. Ongetwijfeld heb je dat staan maar ik had het nog niet gelezen in je setup / netwerk-tekening

[...]

Klopt, moet wel VHD (en geen VHDX) gebruiken omdat de 2 virtuele servers nog Windows Server 2008 R2 draaien en dus niet op VHDX ondersteund worden. Een andere VM is Server 2012 R2 en die draait wel bovenop een VHDX.

Je VM is toch unaware van het hypervisor-format? Zodra je 2012R2 als host hebt, kan je toch een VM met VHDX aanmaken en daar 2008 op installeren? Uiteindelijk doet de hypervisor de translation van "host format" naar "virtual IDE/SCSI"?

Begrijp niet precies wat je bedoeld met je opmerking over vertraging van 8 inbouwen?

VHDX kan in 4K blocksizes lezen/schrijven, VHD is 512 bytes. Dus grof gezegd, wil je een VHD van 4GB uitlezen, gebeurt dat in VHD dus grofweg in 1 miljard operations, terwijl een VHDX dat in 125 miljoen operations kan doen. Hoe meer je moet lezen, hoe meer je moet schrijven, hoe lager je average transfer wordt.

Verder is replication niet 1-op-1 bytes veranderen; op de destination wordt de hele VHD "uit elkaar getrokken" en asynchroon gevuld met de nieuwe blocks.

Dank je, hier had ik al eerder naar gekeken en al die settings staan op default (of ontbreken) zoals in dit artikel vermeld: https://support.microsoft...-v-replica-hvr-in-windows
Begrijp ik hierbij goed dat de setting ApplyVHDLimit standaard 4 VHD's in paralel afhandelt (repliceert)?
Ik heb gekeken of het aanpassen van 1 van deze value's performance kan verbeteren maar dat zie en haal ik niet uit het artikel dat dat in mijn geval kan helpen.

Testen... Het is helemaal ruk om achteraf dit soort settings te moeten/willen aanpassen maar het is niet anders. Ik zou ervoor kiezen om maximaal 1VHD tegelijk af te handelen in jouw geval.

[ Voor 5% gewijzigd door MAX3400 op 21-04-2018 22:26 ]

[Urk]

MAX3400 schreef op zaterdag 21 april 2018 @ 22:24:
[...]
Je VM is toch unaware van het hypervisor-format? Zodra je 2012R2 als host hebt, kan je toch een VM met VHDX aanmaken en daar 2008 op installeren? Uiteindelijk doet de hypervisor de translation van "host format" naar "virtual IDE/SCSI"?

VHDX kan in 4K blocksizes lezen/schrijven, VHD is 512 bytes. Dus grof gezegd, wil je een VHD van 4GB uitlezen, gebeurt dat in VHD dus grofweg in 1 miljard operations, terwijl een VHDX dat in 125 miljoen operations kan doen. Hoe meer je moet lezen, hoe meer je moet schrijven, hoe lager je average transfer wordt.
[...]

Damn.... hier kan je wel eens een heel goed punt hebben . Ik heb eigenlijk geen idee waarom ik VHD heb gebruikt en geen VHDX. Ik dacht omdat dat niet kon. Zojuist nogmaals gekeken en zie ik dat een Generation 1 VM ook gebruik kan maken van VHDX net zoals Generation 2. Ik ben ik de war met Generation 2 VM's die pas compatible zijn met minimaal Windows Server 2012 x64.

Nu dus slim om de VHD's over te zetten naar VHDX neem ik aan? Ik lees dat dat niet zomaar kan, klopt dat?

Edit: hmmmm. Hier heb ik dat dus vandaan....:


Er staat duidelijk This format is not supported in operating system earlier than Windows Server 2012, maarja mij niet duidelijk of hierbij het host OS wordt bedoeld (de Hyper-V host) of het Guest OS (in dit geval de 2008 R2 VM)??

[ Voor 12% gewijzigd door Urk op 21-04-2018 22:38 ]

[MAX3400]

Urk schreef op zaterdag 21 april 2018 @ 22:34:
[...]

Nu dus slim om de VHD's over te zetten naar VHDX neem ik aan? Ik lees dat dat niet zomaar kan, klopt dat?

Euh... VM uitzetten, rechtermuis, settings, HDD, convert? Iets in dit trant... Of anders Powershell gebruiken

Vergeet even niet dat je een 100% backup hebt gemaakt van de VHD en elders geparkeerd

[Urk]

Hmmm.... damn....zie m'n edit hierboven waartoe ik VHD's heb gebruikt ipv VHDX

[akimosan]

"This format is not supported in OS prior to Windows 2012."

Dat betekent dat een server met Windows Server 2008 R2 niet begrijpt wat hij met een VHDX file moet doen.
Je kunt de VM dus niet zonder meer overhevelen (of restoren) naar een Hyper-V 2008 R2 host EN je kunt de VHDX file niet zomaar mounten in Server 2008 R2. om nog even wat files vanaf te kopiëren in geval van crash. Terwijl je dat wel eenvoudig kunt in Windows Server 2012/2012 R2/2016 /8/8.1/10

Maar je VM Guest doet niets met de VHDX file.
Die ziet alleen maar dat er een "disk" is aangesloten op zijn "controller". Dat de VM data pompt in een VHD, VHDX of VMDK (VMware virtual disk format) is ie zich niet ven bewust.

Ja, je noemde het zelf al maar ik bevestig het nog even Volgende keer even googlen duckducken, he..

[ Voor 7% gewijzigd door akimosan op 24-04-2018 21:15 ]