PXE problemen in VMware VDI's

[WhizzCat]

Ok, dan kom ik er ook even in, maar het is wellicht een vraag dat een eigen topic waardig is.

2 Coreswitches



Nah ja, plaatje ziet er niet zo heel mooi uit, maar goed, even beschrijving.

Core1/Core2 draaien alle Layer3 zaken voor Vlan10. Iedere ServerSw zit ob.v. STP aan 2 coreswitches, 1 actieve link dus.

Het blade enclosure hangt met een soort STP aan de beide serverswitches. Op de Hyper-V/ESX hosts zijn er 2 NIC's die via de MS/VMware software geteamed zijn, er vind dus para virtualisatie van de netwerkkaart plaats en het OS doet failover.

Apparatuur:

- HP 54xx switches met een van de laatste firmwares
- HP C7000 Blade Enclosures met Gen9 Blades. Netwerk met Virtual Connect

Ok, nou moeten dus de VDI's booten van hun image op de PVS server via PXE en dat werkt sinds afgelopen week vaker niet dan wel, heel soms werkt het ook wel. Dit alles zit dus Layer2 binnen 1 vlan! Dat is dan ook meteen het hele gekke aan het verhaal. De enige conclusie die wij kunnen trekken is dat er iets met ARP/Layer2 qua networking niet 100% in orde is.

Als we een VDI booten naast de PVS server (dus op VMware) is het bloedsnel en werkt het perfect, hence, het zit ergens in het netwerk, maar we hebben niets veranderd ... as per usual

Maar wat? Uiteraard hebben we al van alles lopen proberen, alle servers gereboot etc. Wat wel beter lijkt te gaan is als we de teaming op de Hyper-V er af halen en 1 NIC direct aan het VDI netwerk koppelen. Ook hier is de "oplossing" niet 100% water dicht, maar het werkt wel beter.

Ook hebben we de Layer3 VRRP tussen de core switches gewisseld, lijkt ook niet tot het gewenste resultaat te leiden.

Wij zijn even helemaal de weg kwijt, net als onze ARP pakketjes

Gevonden op internet (we gaan vandaag verder met testen overigens):
- Mogelijk broadcast limit? Zou een verklaring kunnen zijn waarom het normaal wat traag is
- Iets met STP? Is immers layer 2

Zijn er hier nog mensen met slimme ideeën? Bedankt alvast!

[Freeaqingme]

WhizzCat schreef op zaterdag 18 mei 2019 @ 08:55:
Ok, dan kom ik er ook even in, maar het is wellicht een vraag dat een eigen topic waardig is.

[...]

Zijn er hier nog mensen met slimme ideeën? Bedankt alvast!

Tenzij hier mensen op magische wijze in één keer de oorzaak gokken lijkt me het een mooi iets voor een eigen topic. (TS is alvast uitgebreid genoeg ).

Having said that, het probleem is dus min of meer reproduceerbaar? In dat geval kan je wellicht met een test VM continue booten, en her en der wat packet dumps maken om te kijken of je ergens pakketjes ziet verdwijnen oid?

Ik heb iets dergelijks ook wel eens gezien waarbij 2 VRRP-nodes zo af en toe wisselden van master, maar de gratuitous ARP niet altijd werd verstuurd (of ontvangen, not sure). Zou zoiets dergelijks spelen dan zou je verwachten in je logfiles iets van VRRP-meldingen langs te zien komen.

[WhizzCat]

Freeaqingme schreef op zaterdag 18 mei 2019 @ 17:25:
[...]


Tenzij hier mensen op magische wijze in één keer de oorzaak gokken lijkt me het een mooi iets voor een eigen topic. (TS is alvast uitgebreid genoeg ).

Having said that, het probleem is dus min of meer reproduceerbaar? In dat geval kan je wellicht met een test VM continue booten, en her en der wat packet dumps maken om te kijken of je ergens pakketjes ziet verdwijnen oid?

Ik heb iets dergelijks ook wel eens gezien waarbij 2 VRRP-nodes zo af en toe wisselden van master, maar de gratuitous ARP niet altijd werd verstuurd (of ontvangen, not sure). Zou zoiets dergelijks spelen dan zou je verwachten in je logfiles iets van VRRP-meldingen langs te zien komen.

Goeie suggestie, waarvoor dank! Denk dat het wel een eigen topic waardig is ja Enfin, we zijn nog altijd druk bezig. Het lijkt inderdaad richting ARP/netwerk te zijn, maar een VM naast de PVS servers op dezelfde ESX host vertoont dezelfde kuren, het niet willen ophalen van z'n default PVS bootfile. Via een andersoortige TFTP client de file ophalen, b.v. gewoon via Windows of Linux, gaat in alle gevallen goed. Layer 2 en 3 geroute dus.

Ow ja, VRRP, dat hebben we gechecked door VRRP aan 1 kant uit te zetten

[ Voor 3% gewijzigd door WhizzCat op 18-05-2019 18:47 ]

[Vorkie]

WhizzCat schreef op zaterdag 18 mei 2019 @ 18:47:
[...]


Goeie suggestie, waarvoor dank! Denk dat het wel een eigen topic waardig is ja Enfin, we zijn nog altijd druk bezig. Het lijkt inderdaad richting ARP/netwerk te zijn, maar een VM naast de PVS servers op dezelfde ESX host vertoont dezelfde kuren, het niet willen ophalen van z'n default PVS bootfile. Via een andersoortige TFTP client de file ophalen, b.v. gewoon via Windows of Linux, gaat in alle gevallen goed. Layer 2 en 3 geroute dus.

Ow ja, VRRP, dat hebben we gechecked door VRRP aan 1 kant uit te zetten

Dus op de ESX host heb je dezelfde problemen?

Gaat de initiële ophalen van de bootfile fout, als in ,PXE boot blijft wachten op het bestand of krijg je geen OPTION / IP mee en blijft ie hangen op DHCP?

Je zou namelijk eens kunnen kijken naar je IP helper instellingen (DHCP + PVS server er aan toevoegen), maar ook de delay op de DHCP server (staat default op 2 sec zo uit mijn hoofd), iets verhogen.

Verder kan je eens kijken of je hier wat mee ziet in het PXE proces: https://support.citrix.com/article/CTX217122

Als jullie eens 1 uplink van de PVS ESX host los gehaald? (Als eerste) Of nog beter, van alles, dan kan je in ieder geval STP uitsluiten.

PVS heeft ook maar 1 NIC? Of 2?

kleine braindump, geen idee of je er wat aan hebt

[Equator]

Even afgesplitst

[Endpoint]

Misschien mogelijk ergens een mtu size die roet in het eten gooit?

Heb het zelf wel eens meegemaakt

[Uberprutser]

Ik heb dit meermaals in een zelfde situatie gezien en daarbij kreeg bleek het aan ESXi te liggen welke niet goed samen wilde werken met PXE; sommige DHCP options werden ergens gedropt. Oplossing was uiteindelijk om een .iso te gebruiken ipv PXE en dat werkte prima.

Niet iets om je root cause mee te vinden maar wel iets wat het bij mij heeft opgelost.

edit: Die Procurve 5400 dozen hebben wel een broadcast limiet per port en je krijgt ook geen errors als je door die limiet probeert heen te duwen. Aangezie nje zelf aangeeft dat alles in een L2 domein zit is dit een leuke om naar te kijken.

[ Voor 25% gewijzigd door Uberprutser op 19-05-2019 08:54 ]

[WhizzCat]

We gaan vandaag verder met troubleshooten. Gisteren dusdanig veel VDI's toch nog klaar weten te stomen dat we vandaag hopelijk gewoon met de boel aan het werk kunnen.

Vorkie schreef op zaterdag 18 mei 2019 @ 19:18:
[...]

Dus op de ESX host heb je dezelfde problemen?

Gaat de initiële ophalen van de bootfile fout, als in ,PXE boot blijft wachten op het bestand of krijg je geen OPTION / IP mee en blijft ie hangen op DHCP?

Je zou namelijk eens kunnen kijken naar je IP helper instellingen (DHCP + PVS server er aan toevoegen), maar ook de delay op de DHCP server (staat default op 2 sec zo uit mijn hoofd), iets verhogen.

Verder kan je eens kijken of je hier wat mee ziet in het PXE proces: https://support.citrix.com/article/CTX217122

Als jullie eens 1 uplink van de PVS ESX host los gehaald? (Als eerste) Of nog beter, van alles, dan kan je in ieder geval STP uitsluiten.

PVS heeft ook maar 1 NIC? Of 2?

kleine braindump, geen idee of je er wat aan hebt

De PVS is multihomed, dus gezeik met DHCP options is mogelijk ja. Dat van die delay wist ik niet op de DHCP server, dat is een goeie!

STP hebben we al uitgesloten door e.e.a. aan Blade enclosures met de 2e uplink los te trekken, dus dat moet dan over 1 Layer2 pad heen gaan. Tevens is hiermee de VirtualConnect in de Enclosures gereset (overigens ook vrij recente firmware, iig < 1 jaar oud).

Endpoint schreef op zaterdag 18 mei 2019 @ 21:47:
Misschien mogelijk ergens een mtu size die roet in het eten gooit?

Heb het zelf wel eens meegemaakt

Hmm, die optie ga ik vandaag ook even aan de externe netwerkers door geven. Had ik ook nog niet aan gedacht. Mijn brein was na 2x 10u extra werken min of meer offline Tnx!

Ballebek schreef op zondag 19 mei 2019 @ 08:49:
Ik heb dit meermaals in een zelfde situatie gezien en daarbij kreeg bleek het aan ESXi te liggen welke niet goed samen wilde werken met PXE; sommige DHCP options werden ergens gedropt. Oplossing was uiteindelijk om een .iso te gebruiken ipv PXE en dat werkte prima.

Niet iets om je root cause mee te vinden maar wel iets wat het bij mij heeft opgelost.

edit: Die Procurve 5400 dozen hebben wel een broadcast limiet per port en je krijgt ook geen errors als je door die limiet probeert heen te duwen. Aangezie nje zelf aangeeft dat alles in een L2 domein zit is dit een leuke om naar te kijken.

Tja, het is zowel op Hyper-V als VMware, dus ESX an sich kunnen we 99% zeker wel uitsluiten. Het gaat overigens ook mis als ik domweg mijn laptop in dat VLAN prik en probeer een VM te booten van PXE (dus VMware workstation). Platform lijkt er niet toe te doen.

Ja, die broadcast limit is wel een ding. We zien op bepaalde poorten wel veel drops, dus we hebben, zoals hierboven, dat geprobeerd uit te sluiten door links down te brengen, maar dat lijkt ook geen soelaas te bieden. Broadcast limit staat ondertussen op de uplinks op 25% (van 10 Gbit). Dat zou afdoende moeten denken wij, maar ik zal 't zeker nog even aandragen vandaag weer.

Tot zover allen dank voor 't meedenken! Keep you posted!

-edit-
@Equator tnx, het is inderdaad niet echt een klein vraagje meer

[Endpoint]

Geef je de instellingen door via dhcp opties of bdm ISO?

Als het dhcp is, probeer dan eens inderdaad de ISO om je VDI mee te booten

[SambalBij]

WhizzCat schreef op zaterdag 18 mei 2019 @ 08:55:
Als we een VDI booten naast de PVS server (dus op VMware) is het bloedsnel en werkt het perfect, hence, het zit ergens in het netwerk, maar we hebben niets veranderd ... as per usual

WhizzCat schreef op zaterdag 18 mei 2019 @ 18:47:
Het lijkt inderdaad richting ARP/netwerk te zijn, maar een VM naast de PVS servers op dezelfde ESX host vertoont dezelfde kuren, het niet willen ophalen van z'n default PVS bootfile.

Ja wat is het nou?
Werkt een VDI VM op ESX naast de PVC VM nou wel of niet? Als je met een VM op ESX ook problemen hebt, zou het ook best in de netwerk laag van VMWare kunnen zitten.
Check eens (en speel eventueel wat met) de security settings van je vSwitch en/of port group? In dit soort situaties die wat geavanceerdere (lees discutabele) netwerktechnieken gebruiken, willen de opties voor 'promisquous mode' (kan nodig zijn voor ontvangen van broadcast/multicast verkeer) en 'allow mac address changes' (in geval van gratuitous arp) nog wel eens helpen.

[WhizzCat]

Endpoint schreef op maandag 20 mei 2019 @ 12:40:
Geef je de instellingen door via dhcp opties of bdm ISO?

Als het dhcp is, probeer dan eens inderdaad de ISO om je VDI mee te booten

BDM werkt nagenoeg altijd. 66/67 komen via DHCP, Win2k12 En dat werkt gewoon altijd, zoals ook de Citrix PXEChecker tool aangeefft.

SambalBij schreef op maandag 20 mei 2019 @ 12:57:
[...]

BDM lijkt wel goed te gaan. Instellingen komen via een Win2k12 DHCP server en die geeft wat logmeldingen (failover hot standby config), maar IP's uitdelen werkt eigenlijk altijd goed. Opties mee geven ook. Dit blijkt ook uit testen met PXETester van Citrix.

[...]

Ja wat is het nou?
Werkt een VDI VM op ESX naast de PVC VM nou wel of niet? Als je met een VM op ESX ook problemen hebt, zou het ook best in de netwerk laag van VMWare kunnen zitten.
Check eens (en speel eventueel wat met) de security settings van je vSwitch en/of port group? In dit soort situaties die wat geavanceerdere (lees discutabele) netwerktechnieken gebruiken, willen de opties voor 'promisquous mode' (kan nodig zijn voor ontvangen van broadcast/multicast verkeer) en 'allow mac address changes' (in geval van gratuitous arp) nog wel eens helpen.

Nee, het is geen ESX issue. Het speelt op zowel HyperV als ESX.

Ik heb wel een status update:

We hebben maandag twee externe netwerk jongens ook eens laten kijken en die konden eigenlijk met 99% zekerheid zeggen dat het geen netwerk issue is.

Wat we wél gecontstateerd hebben is dat als we één van de PVS servers (PVS cluster config) uitzetten het dus eigenlijk consquent goed blijft gaan ... ergo, het TFTP/PXE probleem zit hem ergens in de PVS server die brak is. Ondanks dat we het ding van backup terug gezet hebben, Windows updates er af gegooid en nog meer reboots hebben gegeven dan nodig voor een Windows machine

Enfin, puntje bij paaltje, we stappen van dat hele PVS geneuzel af en gaan naar een MCS config toe, daar wordt nu hard aan gewerkt. Dat is natuurlijk geen oplossing, maar wel een betere manier. Het zit mij nog altijd niet lekker dat er zomaar op tijdstip X _alleen_ maar twee VDI vlan's omvallen.

[ Voor 3% gewijzigd door WhizzCat op 22-05-2019 06:33 ]

[Vorkie]

@WhizzCat Was misschien stiekem wel belangrijke info, 2x PVS i.p.v. 1

Succes met de rest

[Outerspace]

Mijn systeembeheerperiode ligt een beetje achter mij, dus alvast sorry als het er niks mee te maken heeft, maar kan het zijn dat je ergens QoS hebt ingesteld / niet hebt ingesteld?

[Endpoint]

Welke versie van PVS draai je? En hoe staat je load balancer ingericht, Netscaler?

Anders herbouw je de rotte PVS server.

[WhizzCat]

@Endpoint NetScaler is er ondertussen tussenuit en het PVS cluster heeft voor TFTP nu nog maar 1 machine actief die het wel goed lijkt te doen. Denk dat we dus wel redelijk met zekerheid kunnen stellen dat een rotte PVS het probleem is en niet het netwerk

@Vorkie ja klopt We waren onszelf redelijk aan het blindstaren Tnx!

@Outerspace dat is wel zo'n ding, maar we hebben geen QoS ingesteld. Zou wel moeten ivm toekomstig VoIP, maar we gaan begin volgend jaar een nieuw netwerk bouwen, dus dat komt dan.

[Freeaqingme]

Die PVS-servers, klopt het dat dat Citrix-specifieke technologie is? Of moet ik beter googlen?

offtopic:
* Freeaqingme doet nooit iets met Citrix, wellicht steek ik nog wat op

[Equator]

Freeaqingme schreef op woensdag 22 mei 2019 @ 12:05:
Die PVS-servers, klopt het dat dat Citrix-specifieke technologie is? Of moet ik beter googlen?

offtopic:
* Freeaqingme doet nooit iets met Citrix, wellicht steek ik nog wat op

Ja, is Citrix Specifiek. Ooit van Ardense overgekochte techniek om een zogeheten Golden Image via het netwerk te streamen naar lege Citrix Servers. Daarmee houdt je Citrix Servers identiek, en hoef je alleen maar je Golden Image up te daten als er gepatched moet worden.

Techniek heet Provisioning Services, zie https://docs.citrix.com/e...release/architecture.html

[WhizzCat]

Freeaqingme schreef op woensdag 22 mei 2019 @ 12:05:
Die PVS-servers, klopt het dat dat Citrix-specifieke technologie is? Of moet ik beter googlen?

offtopic:
* Freeaqingme doet nooit iets met Citrix, wellicht steek ik nog wat op

Wat @Equator zegt dus. Die dingen zijn, basically, voor onze VDI's de opstart server en er wordt dan via PXE en TFTP wat boot meuk geprovisioned en dan later het image.

Nou ja, voor nu lijkt het probleem opgelost, maar waarschijnlijk was het een combinatie van een bug in een software update van een zéér veel gebruikte applicatie die de SQL server door z'n hoeven joeg, netwerk latency die daar bij hoort (query tijd liep exponentieel op) en een brakke PVS server. Daarnaast gingen wij natuurlijk allemaal herstel werkzaamheden doen als servers rebooten etc.

Soms moet je het gewoon even op z'n beloop laten. Waarschijnlijk zijn door het rebooten o.a. updates geinstalleerd die in een soort cascade effect dingen vernield hebben.

Al met al, een bijzonder ongelukkige samenloop van omstandigheden helaas

[Question Mark]

WhizzCat schreef op woensdag 22 mei 2019 @ 08:48:
@Endpoint NetScaler is er ondertussen tussenuit en het PVS cluster heeft voor TFTP nu nog maar 1 machine actief die het wel goed lijkt te doen. Denk dat we dus wel redelijk met zekerheid kunnen stellen dat een rotte PVS het probleem is en niet het netwerk

Wat was het nut van die Netscaler? Ik heb er al een aantal jaar niets meer mee gedaan, maar HA en Loadbalancing voor PVS werd altijd binnen PVS opgelost, en niet met externe loadbalancers.

Equator schreef op woensdag 22 mei 2019 @ 14:35:
[...]
Ja, is Citrix Specifiek. Ooit van Ardense overgekochte techniek ...

Question Mark mijmert terug naar tijden toen hij Ardense nog uitgerold heeft voordat het gekocht werd door Citrix. Dat project heeft ook nog eens als reference case op de Citrix website gestaan.

[WhizzCat]

Question Mark schreef op vrijdag 24 mei 2019 @ 11:06:
[...]

Wat was het nut van die Netscaler? Ik heb er al een aantal jaar niets meer mee gedaan, maar HA en Loadbalancing voor PVS werd altijd binnen PVS opgelost, en niet met externe loadbalancers.

Geen idee, dat was volgens mij TFTP loadbalancing. Het PVS cluster an sich was ook wel redelijk brak dus dat zal ook niet mee geholpen hebben.

Wat de originele reden is voor de NetScaler kan ik zo even niet verzinnen, maar ik weet wel dat de hele stack van VDI over Backend naar Hyper-V met de huidige config gewoon echt te complex is. Hierdoor wordt het troubleshooten echt lastig omdat je van allerlei dingen tegelijk probeert uit te gaan sluiten.

PVS loadbalancing zal wel gedaan zijn om alles achter 1 IP adres te houden denk ik. Wij hebben onze VDI's ook over 2 verschillende layer3 netwerken hangen. Hierdoor hou je al het backend en streaming verkeer binnen 1 Blade enclosre wat weer ten goede komt aan de snelheid.

[Dafjedavid]

Misschien een optie om om verschillende punten in je netwerk een capture te maken. Je kan dan achterhalen waar de pakketjes worden gedropped. Dat maakt het uitsluiten van componenten een stuk makkelijker.

[WhizzCat]

Dafjedavid schreef op woensdag 29 mei 2019 @ 07:22:
Misschien een optie om om verschillende punten in je netwerk een capture te maken. Je kan dan achterhalen waar de pakketjes worden gedropped. Dat maakt het uitsluiten van componenten een stuk makkelijker.

Dat hebben we dus ook gedaan, maar er was helaas geen sprake van dropped packets. Deze indicatie was voor ons eigenlijk aanleiding om andere zaken te onderzoeken.

Er was ook sprake van grote traagheid in een pakket X. Dit pakket gebruikt een nogal forse MSSQL database en doet iets met authenticatie. Blijkbaar was in die tabel iets grondig mis met de caching.

De betreffende cache tabel wordt nu ieder half uur opgeschoont en daarmee is het probleem eigenlijk uit de wereld. De aanleiding is dus nu vrij duidelijk. Deze aanleiding heeft echter tot acties van ons geleidt zoals rebooten enzo voorts en daarmee is het probleem eigenlijk erger geworden omdat er een cascade effect ontstond en er ook andere dingen al wankel waren die dus net over de rand gingen

[Endpoint]

WhizzCat schreef op maandag 27 mei 2019 @ 11:05:
[...]


Geen idee, dat was volgens mij TFTP loadbalancing. Het PVS cluster an sich was ook wel redelijk brak dus dat zal ook niet mee geholpen hebben.

Wat de originele reden is voor de NetScaler kan ik zo even niet verzinnen, maar ik weet wel dat de hele stack van VDI over Backend naar Hyper-V met de huidige config gewoon echt te complex is. Hierdoor wordt het troubleshooten echt lastig omdat je van allerlei dingen tegelijk probeert uit te gaan sluiten.

PVS loadbalancing zal wel gedaan zijn om alles achter 1 IP adres te houden denk ik. Wij hebben onze VDI's ook over 2 verschillende layer3 netwerken hangen. Hierdoor hou je al het backend en streaming verkeer binnen 1 Blade enclosre wat weer ten goede komt aan de snelheid.

Niet alleen loadbalancing maar ook HA maken van je tftp server.

Welke versie van pvs draai je?

[Equator]

@WhizzCat Bedoel je dat je geen aparte DB server hebt voor je PVS omgeving en dat die dus last had van een DB van pakket X?

[WhizzCat]

Endpoint schreef op woensdag 29 mei 2019 @ 11:29:
[...]


Niet alleen loadbalancing maar ook HA maken van je tftp server.

Welke versie van pvs draai je?

Geen idee, maar ze hebben PVS er nu uitgeschopt en we gaan over op iets wat MCS heet. Blijkbaar staat het master image dan op iedere host. Dit zal allicht een hoop schelen.

Equator schreef op woensdag 29 mei 2019 @ 13:30:
@WhizzCat Bedoel je dat je geen aparte DB server hebt voor je PVS omgeving en dat die dus last had van een DB van pakket X?

Nee ... dat bedoel ik niet. Pakket X veroorzaakte een fuuuuuu hoop traagheid binnen dat pakket en daarop zijn we gaan acteren zonder dat we in de gaten hadden dat het pakket X was dat problemen veroorzaakte. Achteraf bleken onze concullega's ook last te hebben in den lande. Door onze "repareer" acties werd het dus van kwaad tot erger uiteindelijk omdat de situatie niet gelijk was o.a. omdat er Windows updates tussen door kwamen waardoor we niet meer terug konden naar een begin situatie wat erg naar was voor het troubleshoot proces.

[Question Mark]

WhizzCat schreef op vrijdag 31 mei 2019 @ 10:20:
[...]


Geen idee, maar ze hebben PVS er nu uitgeschopt en we gaan over op iets wat MCS heet. Blijkbaar staat het master image dan op iedere host. Dit zal allicht een hoop schelen.

Misschien wat offtopic, maar PVS kan dat native al. Wel in combinatie met Xenserver hosts, maar toch...

[WhizzCat]

Question Mark schreef op vrijdag 31 mei 2019 @ 10:36:
[...]

Misschien wat offtopic, maar PVS kan dat native al. Wel in combinatie met Xenserver hosts, maar toch...

Mwah, off topic is relatief in PNS, n'est ce pas? ;-)

Maar wij draaien met Hyper-V dus. Xen schijnt volgens onze VDI guru ietwat onstabiel te zijn, lol.