Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!

W2K8 VMs booten zu schnell in neuem Cluster

Moderatoren: irix, Dayworker

Profi
Beiträge: 503
Registriert: 08.08.2008, 10:45

W2K8 VMs booten zu schnell in neuem Cluster

Beitragvon pirx » 25.07.2013, 21:25

Hallo,

das Thema kling komisch und das ist es auch. Wir haben einen neuen Cluster aufgebaut, der auf aktuellen IBM Flex System mit Blades basiert, als Storage kommen 2 HP EVAs zum Einsatz, dazwischen liegt noch ein EMC VPLEX und darüber ESXi 5.1 U1 mit VMware Tools 9.0.5 und vHardware 9 (wegen SCSI unmap).

Am Anfang ist es nicht aufgefallen, aber nach dem jetzt rund 80 VMs im neuen Cluster aktiv sind, fallen W2K8 und W2K12 VMs auf, die nicht sauber booten. W2K3 scheint nicht betroffen zu sein. Nicht sauber booten bedeutet, dass im Eventlog Netlogon/Group Policy/NTP/DNS Fehler zu finden sind. Die VM kann noch nicht über das Netz kommunizieren wenn die Dienste gestartet werden. Das betrifft neu angelegte VMs, P2V VMs und VMs die schon lange existieren und nun in den Cluster migriert wurden. vHardware 9 schließe ich als Ursache aus, da auch VMs mit vH 8 betroffen sind. Die Tools ebenfalls, da wir als Test eine VM von der DVD installiert und die Tools komplett weggelassen haben. VMXNET3 / E1000 scheint auch keinen
Unterschied zu machen.

Einer der ersten Fehler im Log kommt von netlogon. Dafür habe ich Debugging aktiviert und man kann sehen, dass das System zu der Zeit keine IPv4 IP hat.

Winsock Addrs: (0) List is now empty.

Wir konfigurieren statische IPs, am DHCP kann es also nicht liegen. Die VM ist nach einem Reboot auch schnell wieder pingbar, sie ist nur wenige Sekunden nicht erreichbar. Grundsätzlich geht der Boot sehr fix. Aktiviere ich DHPC treten die Probleme nicht auf... Ich kann nur vermuten, dass DHCP dem gesamten Bootvorgang etwas verzögert und dadurch das Problem verschwindet.

Verschieben wir betroffene VMs in andere Cluster, sind die Probleme der VMs weg. Dabei ist die Hardware dort auch nicht viel "schlechter".

Als Test habe ich ein VM im betroffen Cluster gedrosselt, d.h. VMware Limits für CPU/MEM/Disk vergeben. Damit tritt das Problem auch nicht mehr auf. 10x gebootet, 10x ohne Fehler. Beim ersten Boot ohne Limit sind die Probleme dann wieder da.

Ich vermute ein Windows Timing Problem beim Booten, kann dazu aber nichts konkretes finden. Im netlogon Debug kann man ja sehen, dass die VM keine IP hat. Damit hat die virtuelle Infrastruktur ja erst mal nichts zu tun.

Hat jemand sowas schon einmal gesehen? Ich bin kein Windows Experte, meine Kollegen meinen aber, dass der Bootvorgang bei Win undurchsichtig ist und man so einfach nichts daran ändern kann.

Ich bin ratlos, wir können doch nicht die ersten mit einigermaßen performanter Hardware sein...

Profi
Beiträge: 503
Registriert: 08.08.2008, 10:45

Beitragvon pirx » 25.07.2013, 22:46

Das Problem scheint nicht so selten zu sein, nach dem ich die Änderungen bei 2 VMs durchgeführt hatte, traten bei 8 Reboots keine Probleme mehr auf.

Wenn ich die Beiträge richtig verstehe, passt aber irgendwas im Netzwerk nicht. Mal mit den Netzwerk Kollegen sprechen, wobei die wieder nicht die LAN Switches in den Blade Chassis verwalten...


http://communities.vmware.com/message/2170893#2170893

1. Click Start, type regedit in the Start Search box, and then press ENTER.

2. Locate the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

3. On the Edit menu, point to New, and then click DWORD Value.

4. Type ArpRetryCount

5. Right-click the ArpRetryCount registry entry, and then click Modify

6. In the Value data box, type 0 and then click OK.

7. Exit Registry Editor.

8. Restart the machine.

Profi
Beiträge: 503
Registriert: 08.08.2008, 10:45

Beitragvon pirx » 26.07.2013, 10:58

Blöd, mit ArpRetryCount = 0 werden duplicate IPs nun nicht mehr angezeigt. Nach der Beschreibung des Keys hätte ich ja vermutete, dass es nur um die Funktion beim Booten geht, aber auch im laufenden Betrieb meldet das W2K8 nun keine duplicates mehr. Man erhält auch keine Warnung mehr, wenn man auf dem System selber eine bereits im Netz vorhandene IP Einträgt.

http://technet.microsoft.com/en-us/libr ... 57526.aspx

Determines how many times TCP sends an Address Request Packet for its own address when the service is installed.

Profi
Beiträge: 503
Registriert: 08.08.2008, 10:45

Beitragvon pirx » 26.07.2013, 16:28

Ganz großes Kino. Auskunft von MS: das Problem ist seit Jahren bekannt, kommt nun aber immer stärker hoch. Lösung: keine. Vom Workaround den ArpRetryCount Parameter zu ändern wird stark abgeraten.

King of the Hill
Beiträge: 13561
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 26.07.2013, 19:48

Das Problem dürfte sein, daß sowohl die CPUs immer schneller werden und das Booten durch die M$-Zeitvorgaben für den Erhalt des M$-Stickers immer kürzer wird.
Schon jetzt spielen einige Controller oder auch ältere GPUs da nicht mit. Ihnen fehlt es an Anpassungen für Secure Boot sprich das Gerät wird nicht mehr zur Bootzeit sondern erst vom OS initialisiert und auch das veraltete BIOS wird dann gerne vom OS nicht mehr akzeptiert. Da steht also noch weiterer Ärger ins Haus...

Profi
Beiträge: 503
Registriert: 08.08.2008, 10:45

Beitragvon pirx » 27.07.2013, 12:32

Wir sind momentan etwas ratlos. Da es keinen richtigen Fix gibt, bleibt nur die Empfehlung von MS unterschiedliche Abhängigkeiten der Services auszuprobieren. Das ist etwas dürftig. Wenn man etwas länger sucht, findet man auch genügend Beiträge bei denen solche Probleme bei aktueller Hardware auftreten, MS kann es also auch nicht auf VMware schieben.

King of the Hill
Beiträge: 13561
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 27.07.2013, 13:52

Kannst du ausschliessen, daß der Bootprozess zu schnell durchläuft bzw einige Punkte überspringt oder das es wirklich an M$ liegt?
Keine Ahnung was ein vBIOS unter vSphere5 da anbietet, aber ein deaktiviertes UEFI könnte dem Bootprozess mehr Zeit verschaffen.

Profi
Beiträge: 503
Registriert: 08.08.2008, 10:45

Beitragvon pirx » 27.07.2013, 14:07

Ich gehe ja davon aus, dass der Prozess zu schnell ist. MS hat das mehr oder weniger auch bestätigt. Ich sehe es aber als MS Problem an, wenn Netzwerkdienste initialisiert werden, bevor W2K8 das Netz komplett konfiguriert hat. Selbst ein W2K8 das direkt von DVD installiert wird, verhält sich so.

Profi
Beiträge: 503
Registriert: 08.08.2008, 10:45

Beitragvon pirx » 30.07.2013, 10:51

Es ist wirklich zum Mäuse melken.

Boot Delay für die VMs auf 5000ms -> kein Unterschied; gefühlte 83249 regkeys getestet -> kein Unterschied; mit DependOnService für den netlogon Dienst gespielt -> bisher keine Abhängigkeit/Reihenfolge gefunden, die den zu frühen Start verhindert.

Man sieht in den ESXi Logs das der vds Port der VM nach einem Reboot schnell wieder oben ist. Sofern die Zeit auf dem Host und in der VM identisch sind, kommt der Port etwas vor dem netlogon Dienst hoch, das sieht also ok aus.

Man findet im Netz schon einige Hinweise auf das Problem und MS kennt es anscheinend auch. Wenn es uns in unserer neuen Umgebung trifft, dann müsste das Problem aber eigentlich weiter verbreitet sein. So viel Raktentechnik setzten wir auch wieder nicht ein.

Experte
Beiträge: 1337
Registriert: 25.04.2009, 11:17
Wohnort: Thüringen

Beitragvon Supi » 30.07.2013, 11:30

Vielleicht hilft ja diese HF Paket?
http://forums.guru3d.com/showthread.php?t=376183

Profi
Beiträge: 993
Registriert: 31.03.2008, 17:26
Wohnort: Einzugsbereich des FC Schalke 04
Kontaktdaten:

Beitragvon kastlr » 30.07.2013, 11:47

Hallo,

es gibt die Möglichkeit, den Boot Vorgang protokollieren zu lassen.
Damit bekommst du schon mal den ersten Eindruck, in welcher Reihenfolge Windows bootet.

Und dann könntest du noch mit ARP spielen, denn bevor deine Kommunikation über TCP/IP läuft muß ARP sauber funktionieren.
Es existiert die Möglichkeit, statische ARP Einträge zu konfigurieren.
Darüber findet die Zuordnung zwischen physikalischer MAC Adresse einer NIC und der von ihr verwendeten IP Adresse statt.

Ich würde daher einfach mal versuchen, die ARP Adressen der kritischen Systeme wie AD, DNS usw manuell einzutragen, damit diese sofort zur Verfügung stehen.

Kann dir zwar nicht garantieren, das das nun die Lösung ist, aber TCP/IP setzt nunmal auf ARP auf.

Viel Erfolg,
Ralf

Member
Beiträge: 206
Registriert: 09.09.2010, 14:12

Beitragvon Sven_B1982 » 30.07.2013, 12:22

mhm so ein ähnliches problem hatte ich bis jetzt nur mit Windows XP Rechnern die zu schnell booteten, dafür gibts aber extra eine Gruppenrichtline(die man auch manuell am rechner setzen kann) zu finden ist das ganze über:
Computerkonfiguration \ Administrative Vorlagen \ System \ Anmeldung
"Beim Neustart des Computers und bei der Anmeldung immer auf das Netzwerk warten" = aktiviert


eventuell hilft ja das, bei uns war es so das beim Starten das AD nicht erreichbar war für die Richtlinen und das klingt so ein bischen ähnlich.

Profi
Beiträge: 503
Registriert: 08.08.2008, 10:45

Beitragvon pirx » 30.07.2013, 14:27

Supi hat geschrieben:Vielleicht hilft ja diese HF Paket?
http://forums.guru3d.com/showthread.php?t=376183


Den Rollup KB2775511 mit den 90 Fixes haben wir schon installiert.

Profi
Beiträge: 503
Registriert: 08.08.2008, 10:45

Beitragvon pirx » 30.07.2013, 15:34

kastlr hat geschrieben:es gibt die Möglichkeit, den Boot Vorgang protokollieren zu lassen.
Damit bekommst du schon mal den ersten Eindruck, in welcher Reihenfolge Windows bootet.


"bcdedit /set bootlog yes" habe ich ausprobiert, in dem erzeugten Log werden aber nur die geladenen Treiber gelistet. Was das Protokollieren des gesamten Boot Prozess angeht, bin ich noch nicht weiter.

"BCDEdit /bootdebug" habe ich auch noch gefunden, aber die Auswertung davon scheint sich nicht auf eine simple Logdatei zu beschränken.


Und dann könntest du noch mit ARP spielen, denn bevor deine Kommunikation über TCP/IP läuft muß ARP sauber funktionieren.
Es existiert die Möglichkeit, statische ARP Einträge zu konfigurieren.
Darüber findet die Zuordnung zwischen physikalischer MAC Adresse einer NIC und der von ihr verwendeten IP Adresse statt.

Ich würde daher einfach mal versuchen, die ARP Adressen der kritischen Systeme wie AD, DNS usw manuell einzutragen, damit diese sofort zur Verfügung stehen.

Kann dir zwar nicht garantieren, das das nun die Lösung ist, aber TCP/IP setzt nunmal auf ARP auf.


Du meinst auf den betroffenen VMs mit netsh die ARP Einträge der DCs statisch zu setzen? Ich habe das mal gemacht und die 5 DCs auf der VM fix eingetragen. Das hat aber auch keine Änderung gebracht. Es hätte mich auch gewundert. Nach den Logs hat das Interface ja noch nicht mal seine statische IP bekommen, wenn netlogon schon loslegt.

Profi
Beiträge: 503
Registriert: 08.08.2008, 10:45

Beitragvon pirx » 30.07.2013, 15:35

Sven_B1982 hat geschrieben:mhm so ein ähnliches problem hatte ich bis jetzt nur mit Windows XP Rechnern die zu schnell booteten, dafür gibts aber extra eine Gruppenrichtline(die man auch manuell am rechner setzen kann) zu finden ist das ganze über:
Computerkonfiguration \ Administrative Vorlagen \ System \ Anmeldung
"Beim Neustart des Computers und bei der Anmeldung immer auf das Netzwerk warten" = aktiviert


eventuell hilft ja das, bei uns war es so das beim Starten das AD nicht erreichbar war für die Richtlinen und das klingt so ein bischen ähnlich.


Ne, hat leider nichts geändert.

Experte
Beiträge: 1362
Registriert: 30.03.2009, 17:13

Beitragvon UrsDerBär » 30.07.2013, 18:43

Und wenn du statische Adressen per DHCP vergibst? Ist dann halt vom DHCP abhängig, seit 2012 aber auch nicht soooo ein Problem wenn man den Redundant auslegen kann.

Ansonsten: Was passiert wenn man die Netzwerkadapter ins LAN deaktiviert beim herunterfahren und zbsp. mit nem Start-Script aktiviert? Ziemlich hässlicher Workaround, aber zum testen? Sowohl VmWare seitig als auch Windows.

Profi
Beiträge: 993
Registriert: 31.03.2008, 17:26
Wohnort: Einzugsbereich des FC Schalke 04
Kontaktdaten:

Beitragvon kastlr » 30.07.2013, 19:23

Hallo,

die Startreihenfolge der Treiber und Dienste ist in der Registry festgelegt.
How To Control Device Driver Load Order

Leider ist es nicht ganz trivial zu ermitteln, in welcher Gruppe sich der jeweilige Dienst befindet.
Die Zugehörigkeit eines Treiber/Dienstes zu einer Gruppe ist im "Group" Eintrag, die Position innerhalb der Gruppe über den "Tag" Eintrag definiert.

Da das ganze ziemlich blöd zu erklären ist, hier mal am Beispiel von Tcpip

Code: Alles auswählen

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip]
"BootFlags"=dword:00000001
"DisplayName"="@%SystemRoot%\\system32\\tcpipcfg.dll,-50003"
"Group"="PNP_TDI"   <----------
"ImagePath"=hex(2):53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,64,00,\
  72,00,69,00,76,00,65,00,72,00,73,00,5c,00,74,00,63,00,70,00,69,00,70,00,2e,\
  00,73,00,79,00,73,00,00,00
"ErrorControl"=dword:00000001
"Start"=dword:00000000
"Tag"=dword:00000003   <----------
"Type"=dword:00000001
"NdisMajorVersion"=dword:00000006
"NdisMinorVersion"=dword:00000014
"Description"="@%SystemRoot%\\system32\\tcpipcfg.dll,-50003"


Auf meinem Windows 7 System werden die Gruppen in folgender Reihenfoge gestartet, verantwortlich dafür ist der Inhalt von List unter [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ServiceGroupOrder\]

Code: Alles auswählen

System Reserved
EMS
WdfLoadGroup
Boot Bus Extender
System Bus Extender
SCSI miniport
Port
Primary Disk
SCSI Class
SCSI CDROM Class
FSFilter Infrastructure
FSFilter System
FSFilter Bottom
FSFilter Copy Protection
FSFilter Security Enhancer
FSFilter Open File
FSFilter Physical Quota Management
FSFilter Virtualization
FSFilter Encryption
FSFilter Compression
FSFilter Imaging
FSFilter HSM
FSFilter Cluster File System
FSFilter System Recovery
FSFilter Quota Management
FSFilter Content Screener
FSFilter Continuous Backup
FSFilter Replication
FSFilter Anti-Virus
FSFilter Undelete
FSFilter Activity Monitor
FSFilter Top
Filter
Boot File System
Base
Pointer Port
Keyboard Port
Pointer Class
Keyboard Class
Video Init
Video
Video Save
File System
Streams Drivers
NDIS Wrapper
COM Infrastructure
Event Log
CSActrl
AudioGroup
ProfSvc_Group
UIGroup
MS_WindowsLocalValidation
PlugPlay
Cryptography
PNP_TDI   <----------
NDIS
TDI
iSCSI
NetBIOSGroup
ShellSvcGroup
SchedulerGroup
SpoolerGroup
SmartCardGroup
NetworkProvider
MS_WindowsRemoteValidation
NetDDEGroup
Parallel arbitrator
Extended Base
PCI Configuration
MS Transactions
CSADrivers


Im folgenden betrachte ich ausschließlich die Gruppe PNP_TDI.
Wenn ich auf meinem Windows 7 System die Registry nach dem Wert PNP_TDI durchsuchen lasse erhalte ich insgesamt 9 relevante Treffer.

Code: Alles auswählen

      AFD
      csafilt
      mfewfpk
      NDProxy
      NetBT
      Smb
      Tcpip
      tdx
      ws2ifsl


Die Startreihenfolge der Dienste wird unter dem jeweiligen Gruppen Eintrag unter [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\GroupOrderList] festgelegt.
Zur besseren Lesbarkeit habe ich nach jedem DWord einen Zeilenumbruch eingefügt.

Code: Alles auswählen

"PNP_TDI"=hex:
0a,00,00,00,   <---------- Anzahl der Dienste in dieser Gruppe
05,00,00,00,   <---------- Dienst mit dem Tag 05 wird gestartet
01,00,00,00,   <---------- Dienst mit dem Tag 01 wird gestartet
02,00,00,00,   <---------- Dienst mit dem Tag 02 wird gestartet
03,00,00,00,   <---------- Dienst mit dem Tag 03 wird gestartet, unser Tcpip
0a,00,00,00,   <---------- Dienst mit dem Tag 0a wird gestartet
04,00,00,00,   <---------- Dienst mit dem Tag 04 wird gestartet
06,00,00,00,   <---------- Dienst mit dem Tag 06 wird gestartet
07,00,00,00,   <---------- Dienst mit dem Tag 07 wird gestartet
08,00,00,00,   <---------- Dienst mit dem Tag 08 wird gestartet
09,00,00,00    <---------- Dienst mit dem Tag 09 wird gestartet


Das Problem ist nun, das
  • nicht alle Dienste einen Tag Eintrag haben,
  • beim Deinstallieren diese Schlüssel nicht immer sauber aufgeräumt werden
  • Windows diese Gruppen durchaus parallel anstarten kann (so ein System Startup soll heute ja ratz fatz erledigt sein)
Das macht das Ganze ziemlich kompliziert und wahrscheinlich weigert sich MS deshalb standhaft, das Problem anzugehen ;-).

Aber den Mutigen gehört die Welt, ich selbst habe damit vor Jahren mal ein ähnliches Problem bei einem unserer Kunden lösen können.

Also, ich drück die Daumen, viel Erfolg.

Gruß,
Ralf

Profi
Beiträge: 503
Registriert: 08.08.2008, 10:45

Beitragvon pirx » 31.07.2013, 09:41

Danke für deine ausführliche Antwort. Ich diesen Bereich haben wir auch schon rein geschaut, bisher aber noch nicht so tief. Wobei MS auch gesagt hat, dass es teilweise auch einfach zufällig sein kann, wie die Dienste hoch kommen.

Profi
Beiträge: 993
Registriert: 31.03.2008, 17:26
Wohnort: Einzugsbereich des FC Schalke 04
Kontaktdaten:

Beitragvon kastlr » 31.07.2013, 10:25

Hallo,

damit hat MS auch nicht ganz unrecht, da über dieses Konstrukt nur die generelle Startreihenfolge der Treiber und Services festgelegt werden.
Allerdings kann ich beim Anpassen dieser Registry Keys schon dafür sorgen, das z. B. ein Service in der Reihenfolge vor einem anderem Service startet.
Wann er dann wirklich verfügbar ist steht auf einem anderem Blatt.

Ein weiteres Problem besteht auch darin, das Abhängigkeiten von Services nicht wirklich zuverlässig funktionieren.
Zwar wird ein abhängiger Service erst dann gestartet, wenn der erste Service bereits auf "running" steht.
Allerdings heißt das noch lange nicht, das dieser Service dann auch schon vollständig initialisiert ist.

Denn ein Service im "running" Status bedeutet nur, das der zugehörige Prozeß erfolgreich gestartet wurde.
Es bedeutet nicht, das dieser Service zu 100% funktionsfähig ist.

Nimm einfach mal eine große Datenbank, die Services dürften relativ zügig gestartet werden, aber bis die ersten User wirklich damit arbeiten können dauert normalerweise deutlich länger.

Gruß,
Ralf

Profi
Beiträge: 503
Registriert: 08.08.2008, 10:45

Beitragvon pirx » 20.08.2013, 11:03

Da es von MS keine Lösung zu dem Thema gibt - bekannt sei das Problem schon seit Vista - ignorieren wir die netlogon Fehler erst einmal. Erst wenn sich zeigt das Applikationen dadurch Probleme haben, werden wir uns überlegen welcher work around der mit den geringsten Schmerzen ist. Auch bei W2K12 R2 wird sich am Verhalten nichts ändern. Das könnte noch lustig werden in den kommenden Jahren.

King of the Hill
Beiträge: 12942
Registriert: 02.08.2008, 15:06
Wohnort: Hannover/Wuerzburg
Kontaktdaten:

Beitragvon irix » 20.08.2013, 21:21

Danke fuer die Infos.

Gruss
Joerg

Guru
Beiträge: 2731
Registriert: 23.02.2012, 12:26

Beitragvon ~thc » 21.08.2013, 15:14

Ich bin auf dieses Problemgemenge gestoßen, als ich meinen ersten 2K8-Server auf einer SSD eines ESXi 5 installiert hatte. Bei der Erstdurchsicht der Ereignisanzeige fielen mir diverse Fehlermeldungen auf, die bei genauer Betrachtung daher rühren, dass sich Komponenten beim Start beschweren, dass andere noch nicht laufen.

Einer dieser Fehler betraf den "Netlogon"-Dienst. In der Voreinstellung ist dieser nur von "LanmanWorkstation" abhängig. Da meine 2K8-Server alle "Server" sind, habe ich unter

Code: Alles auswählen

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Netlogon

den Wert "DependOnService" auf den Wert "LanmanWorkstation LanmanServer" eingestellt. Wichtig bei diesem Wert (REG_MULTI_SZ) ist der abschließende Zeilenumbruch.

Danach meldete sich "Netlogon" nicht mehr. Es waren darüber hinaus noch mindestens vier andere Fehler oder Warnungen, die mich eine Weile beschäftigten. Zwei davon (KDC, DNS Client) muss man einfach ertragen ("by design").

Profi
Beiträge: 503
Registriert: 08.08.2008, 10:45

Beitragvon pirx » 23.08.2013, 15:20

Ich habe mit verschiedenen Abhängigkeiten bei den Diensten gespielt, bin auch relativ sicher den Lanman ausprobiert zu haben. Nächste Woche werde ich es trotzdem noch mal ausprobieren.


Zurück zu „vSphere 5 / ESXi 5 und 5.1“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 7 Gäste