Hallo,
ich habe ein sehr komisches Problem bei einem Kunden. Dort gibt es eine Reihe von ESX 3.5U5 Servern (Build 317866). Auf den Servern laufen diverse Gäste, darunter auch mehrere Windows 2008 R2. Seit dem 01.12 haben wir an zwei Gästen das Problem, dass dort die taskmgr.exe 100% der verfügbaren CPU Zeit zieht. Andere W2K8 R2 Maschinen laufen problemlos. Was wurde bereits versucht:
- vMotion auf anderen Host
- Dienste deaktiviert
- VMware Tools neu deinstalliert/ neu installiert
- Virenscanner entfernt
Wir haben eine der Maschinen per VMware Converter auf einen Client mit VMware Workstation gezogen und gestartet: Die taskmgr.exe bleibt friedlich! Wir haben die Maschine zurück geschoben und gestartet: taskmgr.exe flippt wieder total aus.
Die Resourcen auf den Servern sind ausreichend. Die Maschinen haben zwei vCPUs und 8 GB RAM. Wir haben es auch schon mit einer vCPU und 4 GB RAM getestet. Kein Erfolg. Hat jemand eine Idee??[/b]
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!
[GELÖST] taskmgr.exe zieht 100% CPU
Noch ein paar Infos:
- es ist nicht unbedingt die taskmgr.exe, sondern offenbar alle Prozesse im Benutzerfokus. Öffnet man eine MMC, zieht die CPU Zeit. Schaut man sich die Last mit procxp an, dann zieht der Process Explorer Zeit etc.
- Konvertiere ich die Maschine in eine vSphere 4.1 Umgebung, dann funktioniert sie (Quelle: Die funktionierende VM auf meinem Notebook, die per VMware Converter aus der VI3.5 Umgebung kam und dort unter dem Problem litt)
- es ist nicht unbedingt die taskmgr.exe, sondern offenbar alle Prozesse im Benutzerfokus. Öffnet man eine MMC, zieht die CPU Zeit. Schaut man sich die Last mit procxp an, dann zieht der Process Explorer Zeit etc.
- Konvertiere ich die Maschine in eine vSphere 4.1 Umgebung, dann funktioniert sie (Quelle: Die funktionierende VM auf meinem Notebook, die per VMware Converter aus der VI3.5 Umgebung kam und dort unter dem Problem litt)
-
Tschoergez
- Moderator
- Beiträge: 3476
- Registriert: 23.02.2005, 09:14
- Wohnort: Burgberg im Allgäu
- Kontaktdaten:
Nope. Kein Anzeigeproblem. Ich sehe auch bei ESXTOP dazu passende Werte unter %USED.
Hole ich die VM per Converter in eine VMware Workstation, ist alles entspannt. Schiebe ich diese VM zurück auf den ESX, habe ich wieder den gleichen Fehler. Schiebe ich die VM in eine vSphere 4.1, ist der Fehler wieder weg.
Vier andere W2K8 R2 Gäste im gleichen Cluster haben das Problem nicht. Wenn ich eine neue VM erstelle und mir dort das VMDK der "kaputten" VM einbinde, dann tritt der Fehler auch in der neu erstellten VM auf.
Hole ich die VM per Converter in eine VMware Workstation, ist alles entspannt. Schiebe ich diese VM zurück auf den ESX, habe ich wieder den gleichen Fehler. Schiebe ich die VM in eine vSphere 4.1, ist der Fehler wieder weg.
Vier andere W2K8 R2 Gäste im gleichen Cluster haben das Problem nicht. Wenn ich eine neue VM erstelle und mir dort das VMDK der "kaputten" VM einbinde, dann tritt der Fehler auch in der neu erstellten VM auf.
Hier mal Output aus ESXTOP einer der betreffenden Maschinen. Maschine frisch hochgefahren und nur Taskmanager und Servermanager geöffnet:
Code: Alles auswählen
1560 111 vmware-vmx 1 0.09 0.10 0.00 100.00 0.21 0.00 0.01 0.00 0.00
1561 111 vmm0:VM-MS-INFR 1 109.80 110.12 0.04 7.99 1.84 3.75 0.08 0.00 0.00
1562 111 vmware-vmx 1 0.00 0.00 0.00 100.00 0.00 0.00 0.00 0.00 0.00
1563 111 mks:VM-MS-INFRA 1 1.62 1.68 0.07 100.00 1.50 0.00 0.01 0.00 0.00
1564 111 vcpu-0:VM-MS-IN 1 0.10 0.03 0.00 100.00 0.11 0.00 0.00 0.00 0.00
1565 111 Worker#0:VM-MS- 1 0.02 0.01 0.00 100.00 0.01 0.00 0.00 0.00 0.00
-
Tschoergez
- Moderator
- Beiträge: 3476
- Registriert: 23.02.2005, 09:14
- Wohnort: Burgberg im Allgäu
- Kontaktdaten:
ok. Wenn möglich, mach mal parallel ein Ticket bei VMware auf, ich bin gespannt...
Kannst Du mal versuchen, die betreffende VM auf verschiedene ESXen mit unterschiedlicher CPU zu migrieren (alle 3.5, natürlich, nachdem bei 4.1 der Fehler weg ist)?
Bringts was, in den "options" der VM-settings bei der CPU/MMU virtualisierung was anderes einzustellen?
(falls das bei 3.5 überhaupt schon geht, ist ne weile her, dass ich das letzte mal mein Maus dran hatte)
Kannst Du log-Auszüge machen:
- vom vmware.log der VM beim starten (für die genaue konfig)
- vom vmware.log bei den 100% (nur falls was interessantes dringsteht)
- vom vmkernel-log bei den 100%
Kannst Du das problem bei einer neu-installierten W2k8-VM auf dem gleichen Host nachvollziehen?
Anti-viren software, komische firewalls, Data Execution Protection, debugging programme, Virtualisierungserkennungssoftware (such mal nach "spiel läuft nicht" hier im Workstation bereich des forums
) wären dann so die nächsten vermutungen...
Viele Grüße,
Jörg
Kannst Du mal versuchen, die betreffende VM auf verschiedene ESXen mit unterschiedlicher CPU zu migrieren (alle 3.5, natürlich, nachdem bei 4.1 der Fehler weg ist)?
Bringts was, in den "options" der VM-settings bei der CPU/MMU virtualisierung was anderes einzustellen?
(falls das bei 3.5 überhaupt schon geht, ist ne weile her, dass ich das letzte mal mein Maus dran hatte)
Kannst Du log-Auszüge machen:
- vom vmware.log der VM beim starten (für die genaue konfig)
- vom vmware.log bei den 100% (nur falls was interessantes dringsteht)
- vom vmkernel-log bei den 100%
Kannst Du das problem bei einer neu-installierten W2k8-VM auf dem gleichen Host nachvollziehen?
Anti-viren software, komische firewalls, Data Execution Protection, debugging programme, Virtualisierungserkennungssoftware (such mal nach "spiel läuft nicht" hier im Workstation bereich des forums
) wären dann so die nächsten vermutungen...
Viele Grüße,
Jörg
Hallo Jörg,
Das wird am Montag entschieden. Wie natürlich üblich ist ein zentrales Kundensystem betroffen. Allein der Gedanke den Fehler mit Wiederherzustellen, hält uns vom Restore ab. Ein Ticket wäre wohl eher nachgelagert um den Grund zu erfahren. In erster Linie geht es jetzt darum, die Kiste wieder ins Leben zu holen.
Habe ich schon. Waren DL360 G5 und G6 mit unterschiedlichen CPUs. EVC ist im Cluster aktiv.
Muss ich noch testen.
Muss ich dann für den Support eh. Werde ich am Montag mal machen.
Nee, das ist es ja. Alle Kisten liefen problemlos. Was dann an einem Abend passiert ist, können wir nicht mehr genau nachvollziehen. Wir tappen da ein wenig im Dunkeln. Fakt ist: Einer der beiden Server hatte das Problem erst nach einen vMotion, die bei 89% hängen blieb. Aktuell gehen wir davon aus, dass ein zu forsch eingestelltes DRS dafür gesorgt hat, dass die zweite W2K8 R2 Kiste die betroffen ist, migriert wurde. Diese Büchse ist das vCenter. -.- Wir gehen aktuell davon aus, dass die hohe CPU Last die Migration angetriggert hat.
AV (McAfee) wurde schon entfernt. Firewall ist nur die Windows Firewall aktiv (nur der Dienst, keine Policies). Debugging wäre mir aufgefallen. DPE muss ich noch mal prüfen. Andere Virtualisierungssoftware kann ich ausschließen.
Das kuriose ist halt: Ich habe zwei exakt identische VMs (habe die VMX Files vergleichen, bis auf die üblichen Abweichungen identisch) auf dem gleichen Host: Die eine rennt, die andere nicht. Maschinen kommen aus dem gleichen Template. Ich habe ja viele abgefahrene Probleme in meinem Berufsleben gesehen, aber das is echt extrem strange.
Tschoergez hat geschrieben:ok. Wenn möglich, mach mal parallel ein Ticket bei VMware auf, ich bin gespannt...
Das wird am Montag entschieden. Wie natürlich üblich ist ein zentrales Kundensystem betroffen. Allein der Gedanke den Fehler mit Wiederherzustellen, hält uns vom Restore ab. Ein Ticket wäre wohl eher nachgelagert um den Grund zu erfahren. In erster Linie geht es jetzt darum, die Kiste wieder ins Leben zu holen.
Kannst Du mal versuchen, die betreffende VM auf verschiedene ESXen mit unterschiedlicher CPU zu migrieren (alle 3.5, natürlich, nachdem bei 4.1 der Fehler weg ist)?
Habe ich schon. Waren DL360 G5 und G6 mit unterschiedlichen CPUs. EVC ist im Cluster aktiv.
Bringts was, in den "options" der VM-settings bei der CPU/MMU virtualisierung was anderes einzustellen?
(falls das bei 3.5 überhaupt schon geht, ist ne weile her, dass ich das letzte mal mein Maus dran hatte)
Muss ich noch testen.
Kannst Du log-Auszüge machen:
- vom vmware.log der VM beim starten (für die genaue konfig)
- vom vmware.log bei den 100% (nur falls was interessantes dringsteht)
- vom vmkernel-log bei den 100%
Muss ich dann für den Support eh. Werde ich am Montag mal machen.
Kannst Du das problem bei einer neu-installierten W2k8-VM auf dem gleichen Host nachvollziehen?
Nee, das ist es ja. Alle Kisten liefen problemlos. Was dann an einem Abend passiert ist, können wir nicht mehr genau nachvollziehen. Wir tappen da ein wenig im Dunkeln. Fakt ist: Einer der beiden Server hatte das Problem erst nach einen vMotion, die bei 89% hängen blieb. Aktuell gehen wir davon aus, dass ein zu forsch eingestelltes DRS dafür gesorgt hat, dass die zweite W2K8 R2 Kiste die betroffen ist, migriert wurde. Diese Büchse ist das vCenter. -.- Wir gehen aktuell davon aus, dass die hohe CPU Last die Migration angetriggert hat.
Anti-viren software, komische firewalls, Data Execution Protection, debugging programme, Virtualisierungserkennungssoftware (such mal nach "spiel läuft nicht" hier im Workstation bereich des forums
AV (McAfee) wurde schon entfernt. Firewall ist nur die Windows Firewall aktiv (nur der Dienst, keine Policies). Debugging wäre mir aufgefallen. DPE muss ich noch mal prüfen. Andere Virtualisierungssoftware kann ich ausschließen.
Das kuriose ist halt: Ich habe zwei exakt identische VMs (habe die VMX Files vergleichen, bis auf die üblichen Abweichungen identisch) auf dem gleichen Host: Die eine rennt, die andere nicht. Maschinen kommen aus dem gleichen Template. Ich habe ja viele abgefahrene Probleme in meinem Berufsleben gesehen, aber das is echt extrem strange.
-
Tschoergez
- Moderator
- Beiträge: 3476
- Registriert: 23.02.2005, 09:14
- Wohnort: Burgberg im Allgäu
- Kontaktdaten:
aber das is echt extrem strange.
In der Tat! (Drum bin ich auch so an den weiteren Ergebnissen interessiert
)
Noch ein quick-test: CPU-Affinity für die VM einstellen => ändert sich was?
und diese Hyperthreading-Settings für diese VM auch unter Advanced CPU...
Ein prinzipielles Problem im Gast kannst Du sicher ausschließen?
(die migration auf 4.1 ware mit vMotion, nehme ich an?)
mit EVC im Cluster sollte das keine Rolle spielen, aber:
Läuft irgendne besondere Applikation drauf, die evtl. die SSE-Features der CPU nutzt?
kannst Du in den vmkernel-logs noch nachvollziehen, warum der eine vMotion-Vorgang bei 89% stehengeblieben ist?
Fragen über Fragen....bin mal gespannt...
Viele Grüße,
Jörg
Hallo Jörg,
Das muss ich in der Tat mal testen.
Nee, die Migration war per VMware Converter. Vielleicht kurz zum besseren Verständnis.
- VM per Converter in eine VMware Workstation gebracht und gestartet: Problem verschwunden.
- VM in der VI3.5 gelöscht und per VMware Converter vom Notebook (also nun die VM ohne Probleme) in die VI3.5 migriert. VM dort gestartet: Problem tritt wieder auf!
Eine Maschine ist ein quasi nacktes W2K8 R2 (eigentlich der vCenter Server, aber alle Dienste deaktiviert). Andere Maschine ist ein SQL 2008 R2. Die Nutzung irgendwelcher SSE Features kann man wohl ausschließen.
Leider nicht mehr. Das da Kisten lustig per vMotion umgezogen werden, haben wir auch erst im Nachgang entdeckt. Dem Kunden war es nicht aufgefallen, die Logs sind alle soweit rolliert, dass ich bei ersten Checks nichts gefunden habe. Die vMotion ist aber offenbar nur in der Anzeige bei 89% stehen geblieben (kurz zur Erinnerung: Das vCenter ist eine der Maschinen, die so zickt. Die zweite Maschine ist ein SQL 2008, auf dem u.a. die vCenter DB liegt... tolle Wurst). Die VM war auf dem Ziel ESXer angekommen und lief. Daher gehe ich davon aus, dass die vMotion durch war und nur die Anzeige hing.
Und ich erst... Treiber kann ich mittlerweile ausschließen. Auch irgendwelche Applikationen kann ich wohl ausschließen. Das Problem trat auf den ersten Blick und bei heutigem Wissensstand spontan auf. Der Mitarbeiter des Kunden, der das Problem als erstes entdeckt hat, konnte bisher nicht befragt werden. Auch eine komplett neu erstellte VM mit alten VMDK zeigt das gleiche Problem. Daher mag ich auch ein Problem mit der VM-Config ausschließen.
Was wird mit der VM gemacht, wenn sie per VMware Converter auf einen Client umgezogen wird? Okay, es liegt auf einmal andere Hardware drunter (Core i5 statt Xeon X5550) und ein anderen VMware Produkt. Aber was noch? Andere virtuelle Hardware? Die defekte VM leidet bei VMware Workstation 7 und vSphere 4.1 offenbar nicht unter dem Problem. Aber sie wurde per VMware Converter dahin umgezogen. Ideen?
Tschoergez hat geschrieben:Noch ein quick-test: CPU-Affinity für die VM einstellen => ändert sich was? und diese Hyperthreading-Settings für diese VM auch unter Advanced CPU...
Das muss ich in der Tat mal testen.
Ein prinzipielles Problem im Gast kannst Du sicher ausschließen?
(die migration auf 4.1 ware mit vMotion, nehme ich an?)
Nee, die Migration war per VMware Converter. Vielleicht kurz zum besseren Verständnis.
- VM per Converter in eine VMware Workstation gebracht und gestartet: Problem verschwunden.
- VM in der VI3.5 gelöscht und per VMware Converter vom Notebook (also nun die VM ohne Probleme) in die VI3.5 migriert. VM dort gestartet: Problem tritt wieder auf!
mit EVC im Cluster sollte das keine Rolle spielen, aber:
Läuft irgendne besondere Applikation drauf, die evtl. die SSE-Features der CPU nutzt?
Eine Maschine ist ein quasi nacktes W2K8 R2 (eigentlich der vCenter Server, aber alle Dienste deaktiviert). Andere Maschine ist ein SQL 2008 R2. Die Nutzung irgendwelcher SSE Features kann man wohl ausschließen.
kannst Du in den vmkernel-logs noch nachvollziehen, warum der eine vMotion-Vorgang bei 89% stehengeblieben ist?
Leider nicht mehr. Das da Kisten lustig per vMotion umgezogen werden, haben wir auch erst im Nachgang entdeckt. Dem Kunden war es nicht aufgefallen, die Logs sind alle soweit rolliert, dass ich bei ersten Checks nichts gefunden habe. Die vMotion ist aber offenbar nur in der Anzeige bei 89% stehen geblieben (kurz zur Erinnerung: Das vCenter ist eine der Maschinen, die so zickt. Die zweite Maschine ist ein SQL 2008, auf dem u.a. die vCenter DB liegt... tolle Wurst). Die VM war auf dem Ziel ESXer angekommen und lief. Daher gehe ich davon aus, dass die vMotion durch war und nur die Anzeige hing.
Fragen über Fragen....bin mal gespannt...
Und ich erst... Treiber kann ich mittlerweile ausschließen. Auch irgendwelche Applikationen kann ich wohl ausschließen. Das Problem trat auf den ersten Blick und bei heutigem Wissensstand spontan auf. Der Mitarbeiter des Kunden, der das Problem als erstes entdeckt hat, konnte bisher nicht befragt werden. Auch eine komplett neu erstellte VM mit alten VMDK zeigt das gleiche Problem. Daher mag ich auch ein Problem mit der VM-Config ausschließen.
Was wird mit der VM gemacht, wenn sie per VMware Converter auf einen Client umgezogen wird? Okay, es liegt auf einmal andere Hardware drunter (Core i5 statt Xeon X5550) und ein anderen VMware Produkt. Aber was noch? Andere virtuelle Hardware? Die defekte VM leidet bei VMware Workstation 7 und vSphere 4.1 offenbar nicht unter dem Problem. Aber sie wurde per VMware Converter dahin umgezogen. Ideen?
-
Tschoergez
- Moderator
- Beiträge: 3476
- Registriert: 23.02.2005, 09:14
- Wohnort: Burgberg im Allgäu
- Kontaktdaten:
Hm, so lngsam gehen die kreativen Ideen aus....
Schau doch mal mit "Dependency Walker", wann/wo genau die hohe CPU-Last auftritt...
http://www.dependencywalker.com/
oder filemon, regmon und wie sie alle heißen
Viele Grüße,
Jörg
Schau doch mal mit "Dependency Walker", wann/wo genau die hohe CPU-Last auftritt...
http://www.dependencywalker.com/
oder filemon, regmon und wie sie alle heißen
Viele Grüße,
Jörg
Wie hoch ist denn die Grundlast? Also wenn alle "unwichtigen" Dienste ausgeschaltet sind. Hast Du dann auch 100 % ?
Ich hatte mal ein ähnliches Problem in einem DRS-Cluster, dort betroffen war ein SQL-Server der schon eine Grundlast von rund 50-60 % hatte. Nach 24 Stunden war dann alles wieder normal.
Schalte mal das DRS aus und starte die Maschine neu. Es gab mal ein Problem in einer VMware-Version, ich weiß bloß gerade nicht in welcher.
Gruß
Thorsten
Ich hatte mal ein ähnliches Problem in einem DRS-Cluster, dort betroffen war ein SQL-Server der schon eine Grundlast von rund 50-60 % hatte. Nach 24 Stunden war dann alles wieder normal.
Schalte mal das DRS aus und starte die Maschine neu. Es gab mal ein Problem in einer VMware-Version, ich weiß bloß gerade nicht in welcher.
Gruß
Thorsten
Thorsten hat geschrieben:Wie hoch ist denn die Grundlast? Also wenn alle "unwichtigen" Dienste ausgeschaltet sind. Hast Du dann auch 100 %
Ein Problem mit der Grundlast kann ausgeschlossen werden. Eine konvertierte VM leidet nicht unter dem Problem. Die Installation ist ja die gleiche, nur läuft die eine VM in einer VI3.5 und die funktionierende VM in einer WS 7.1.
Tschoergez hat geschrieben:Hm, so lngsam gehen die kreativen Ideen aus....
Schau doch mal mit "Dependency Walker", wann/wo genau die hohe CPU-Last auftritt...
http://www.dependencywalker.com/
oder filemon, regmon und wie sie alle heißen
procmon, regmon, filemon - alle durch. Auch der Dependency Walker zeigt nichts brauchbares.
Was halt total verstörend ist: In der VI3.5 tritt das Problem auf, unter WS und vSphere 4.1 nicht. Überführung der VM mittels VMware Converter.
Evtl. habe ich was. Ich habe noch mal die VMX Files verglichen.
Maschine die funktioniert:
Maschine die nicht funktioniert.
Auch bei der zweiten VM, die nicht funktioniert, haben wir hier minimale Abweichungen entdeckt - und die Maschinen laufen alle auf dem gleichen Host. Die guestCPUID.1 unterscheidet sich.
Leider können wir die Änderungen gerade nicht testen. Aber wäre ein Zusammenhang denkbar?
Maschine die funktioniert:
Code: Alles auswählen
evcCompatibilityMode = "TRUE"
guestCPUID.0 = "0000000b756e65476c65746e49656e69"
[b]guestCPUID.1 = "000006f800010800000022010febfbff"[/b]
guestCPUID.80000001 = "00000000000000000000000120100000"
hostCPUID.0 = "0000000b756e65476c65746e49656e69"
hostCPUID.1 = "000106a500100800009ce3bdbfebfbff"
hostCPUID.80000001 = "00000000000000000000000128100000"
scsi0:0.redo = ""
tools.remindInstall = "FALSE"
userCPUID.0 = "0000000b756e65476c65746e49656e69"
userCPUID.1 = "000106a500100800000022010febfbff"
userCPUID.80000001 = "00000000000000000000000120100000"Maschine die nicht funktioniert.
Code: Alles auswählen
evcCompatibilityMode = "TRUE"
guestCPUID.0 = "0000000b756e65476c65746e49656e69"
[b]guestCPUID.1 = "0001067800010800000822010febfbff"[/b]
guestCPUID.80000001 = "00000000000000000000000120100000"
hostCPUID.0 = "0000000b756e65476c65746e49656e69"
hostCPUID.1 = "000106a500100800009ce3bdbfebfbff"
hostCPUID.80000001 = "00000000000000000000000128100000"
scsi0:0.redo = ""
tools.remindInstall = "FALSE"
userCPUID.0 = "0000000b756e65476c65746e49656e69"
userCPUID.1 = "000106a500100800000822010febfbff"
userCPUID.80000001 = "00000000000000000000000120100000"Auch bei der zweiten VM, die nicht funktioniert, haben wir hier minimale Abweichungen entdeckt - und die Maschinen laufen alle auf dem gleichen Host. Die guestCPUID.1 unterscheidet sich.
Leider können wir die Änderungen gerade nicht testen. Aber wäre ein Zusammenhang denkbar?
PROBLEM GELÖST
Die guestCPUID Einträge in der VMX waren es. Kurz zur Erklärung:
VM1: MS SQL 2008
VM2: vCenter
Bei beiden Maschinen liefen Prozesse im Usercontext mit unfassbar hoher CPU Last. DIe Maschinen hatten immer 100% Auslastung, selbst wenn nichts lief. vCenter DB liegt auf dem MS SQL 2008. Der SQL wurde neu gestartet. Vorher wurden die vCener Diente gestoppt. Nach dem Neustart muschelte die vCenter Maschine rum. Einen Tag später wurde durch DRS eine vMotion angetriggert und der SQL wurde verschoben. Nach der vMotion muschelte die Maschine auch rum. Offenbar war vCenter/ DRS nicht in der Lage die korrekten EVC Informationen während der vMotion einzubringen. Nach dem händischen Anpassen der guestCPUID bei beiden Maschinen auf Werte, die aus einer VMX eines auf dem gleichen Host laufenden W2K8 R2 genommen wurden, funktionieren beide Maschinen wieder.
Die guestCPUID Einträge in der VMX waren es. Kurz zur Erklärung:
VM1: MS SQL 2008
VM2: vCenter
Bei beiden Maschinen liefen Prozesse im Usercontext mit unfassbar hoher CPU Last. DIe Maschinen hatten immer 100% Auslastung, selbst wenn nichts lief. vCenter DB liegt auf dem MS SQL 2008. Der SQL wurde neu gestartet. Vorher wurden die vCener Diente gestoppt. Nach dem Neustart muschelte die vCenter Maschine rum. Einen Tag später wurde durch DRS eine vMotion angetriggert und der SQL wurde verschoben. Nach der vMotion muschelte die Maschine auch rum. Offenbar war vCenter/ DRS nicht in der Lage die korrekten EVC Informationen während der vMotion einzubringen. Nach dem händischen Anpassen der guestCPUID bei beiden Maschinen auf Werte, die aus einer VMX eines auf dem gleichen Host laufenden W2K8 R2 genommen wurden, funktionieren beide Maschinen wieder.
-
Tschoergez
- Moderator
- Beiträge: 3476
- Registriert: 23.02.2005, 09:14
- Wohnort: Burgberg im Allgäu
- Kontaktdaten:
Tschoergez hat geschrieben:Wenn Du Lust und Geduld hast, kannst Du ja trotzdem noch ein Ticket bei VMware aufmachen, und schauen, ob das ein Bug ist... Allerdings ist das angesichts 3.5 wohl eher akademischer natur.
Da hat der Kunde (leider oder glücklicherweise) genug Elan um den HP Support (über den der VMware Support beschafft wurde) zu nerven. Wobei mich schon interessieren würde, ob der VMware oder HP Support den Fall überhaupt gelöst hätte. Das ist ja schon eine etwas... ähh.. abgefahrene Sache.
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 5 Gäste