Win7x64 VM auf 2008R2 Hyper-V freezed in unregelmäßigen abständen

[Assassin 13]

MoinMoin,

 

hat hier eventuell noch jemand tips für mich, wie man einem sehr kurriosen fehler auf die schliche kommen kann?

 

Und zwar, es geht um einen Server2008R2 welcher als Hypervisor dient, darauf laufen ca 6 VMs (Server2008R2, ein paar 2012R2, und eine Win7x32bit VM) - alles läuft wunderbar.

Jetzt haben wir eine weitere VM installiert, Windows7 aber als 64bit maschine. Alles durchgepatcht was Updates angeht, auch die integrationstools nochmal drüber installiert - alles bestens.

Doch irgendwann bleibt die VM einfach stehen, ist weder anpingbar noch bedienbar über die Console. Über die Console sehe ich nur das letze bild als Standbild wo die VM eingefrohren ist, auch die Uhrzeit ist dann stehen geblieben.

Die VM wurde von uns sauber an den kunden "übergeben" also fertig eingerichtet - bis dahin lief alles bestens. Nun ist darauf eine kundenspeziefische software installiert worden (eine Monitoring-Software welche diverse Geräte im Netzwerk überwachen soll) - erst seit dem tritt dieses Problem auf.

Dieselbe Monitoring Software (allerdings etwas ältere version) läuft auch auf der 32bit VM - und da problemlos.

 

Versucht haben wir schon: HyperV Host auf aktuellen Updatestand gebracht, Bios des Host's aktualisiert, Bios auf hochleistung umgestellt statt ausbalanciert (C-States natürlich aus).

VM ist auf dem letzten Update stand von Microsoft. Es wurden durch diese Monitoring-Software einige schnittstellentreiber mitinstalliert wie z.B. 1Wire Netzwerk, oder USB zu Serial Adapter Treiber (was es aber garnicht gibt und nie geben wird  - da VM) auch das wurde zum test deinstalliert von der VM.

Ergebnisslos. Die VM friert einfach nach einer undefinierbaren zeit ein. Manchmal 4x am tag, manchmal aber auch erst nach 3-4 tagen - also wirklich absolut willkürlich. Wir haben noch nichts gefunden um das fehlverhalten zu provozieren. Die Monitoring-Software ist auch noch NICHT aktiv, diese ist nur installiert, aber noch nicht eingerichtet (qualifizierung nicht überstanden wegen den abstürzen)

Auch habe ich der VM eine andere, eigene Netzwerkkarte zugeordnet zum testen.

Zu dem Zeitpunkt wo die VM steht, ist die VM wie gesagt weder anpingbar, noch über RDP erreichbar. Über die HyperV Console sehe ich wie gesagt nur ein standbild - da wo die VM eben stehen geblieben ist, also vom Desktop mit der Uhrzeit des einfrierens.

 

Was allerdings über die HyperV Console zu sehen ist: die VM erzeugt dann wenn sie abgestürzt ist eine konstante dauer CPU last von 8-16% (auch immer unterschiedlich) wobei 16% die maximalauslastung der 4 vCPUs darstellt. (Host hat 24 CPUs).

 

In den Ereignissprotokollen vom HyperV host konnte ich überhaupt nichts finden was darauf hindeuten könnte, da HyperV anscheinend selber nicht mitbekommt, das die VM eingefrohren ist.

Auch die Ereignissprotokolle innerhalb der VM sind ergebnisslos. Steht eben nur drin, das die Maschine zu dem und dem zeitpunkt unerwartet beendet wurde.

Habe probehalber mal den ProcessExplorer in der VM laufen lassen auf hoffnung zu sehen, welcher Prozess die CPU auslastung verursacht welche die VM zum einfrieren bringt - aber auch da nichts zu sehen. Man sieht halt als letztes bild den Idle-Prozess mit 96,11%, darunter der processexplorer selber welcher aller 0.5sekunden aktualisiert, und darunter die Interrupts mit 0,21% CPU last.

 

Langsam gehen mir die Ideen aus was das noch sein könnte oder wie man die fehlerursache weiter eingrenzen könnte, oder wo es sonst noch Logs vom HyperV gibt, die mir mehr details ausspucken als die Windows Ereignis-Logs.

 

 

 

 

der Host hat 2 E5-2620 CPUs (also 24 Threads) - davon werden mit der Win7x64 VM 21 verwendet für VMs.

128GB Ram, davon 111GB verwendet (win7x32 hat 3GB)

Plattenplatz steht zu genüge zur verfügung

 

also der Host hat noch genügend Resourcen für sich selber.

[NilsK 2.957]

Moin,

 

das klingt deutlich danach, dass die Treiber in der VM das Problem verursachen. Leider habe ich darüber hinaus keine konkreten Hinweise.

 

Eurem Kunden ist bekannt, dass er eine spezielle Lizenz braucht, um ein Desktop-Betriebssystem in einer VM zu betreiben? Eine normale Windows-7-Lizenz reicht dafür nicht aus.

 

Gruß, Nils

[Doso 77]

Was sagt der Hersteller der Monitoring Software dazu?

[Assassin 13]

Die Hersteller der Monitoring-Software kennen dieses problem nicht. Diese Software läuft auch auf vielen anderen Kundenservern, mitunter auch auf VMs, und das problemlos.

Treiberproblem...aber welcher Treiber dann? Ich habe wie gesagt schon diese Integrationstools, bzw. treiber nochmal deinstalliert und neu installiert. Im Gerätemanager innerhalb der VM scheint auch alles sauber zu sein :-/

 

Meinst du die VECD Lizenz für Windows7?

[MKdrei 1]

Hi,

 

soweit ich weiß gibt es genau zwei Möglichkeiten Windows 7 korrekt lizensiert, virtuell laufen zu lassen.

 

1. VECD (gibt es ja nicht mehr) -> VDA 

 

2. Software Assurance for Windows

 

OEM/Retail fällt in deinem Fall aus.

 

 

Gruß

[Assassin 13]

Ok, die VDA geschichte schau ich mir mal an. Aber hier gehts nicht direkt um die lizenzierung, sondern eher um eine einfrierende VM und was was möglicherweise sein könnte, bzw. was man noch überprüfen könnte, oder in welche Logfiles man sont noch schauen könnte :-/

[MKdrei 1]

Ok, die VDA geschichte schau ich mir mal an. Aber hier gehts nicht direkt um die lizenzierung, sondern eher um eine einfrierende VM und was was möglicherweise sein könnte, bzw. was man noch überprüfen könnte, oder in welche Logfiles man sont noch schauen könnte :-/

 

Ja, sorry..das ist richtig :)

 

Also für michj stellt sich die Frage warum ihr jetzt auf x64 umgestiegen seid. Ja, klar...die Vorteile kenne ich. Aber wenn die Software unter x86 sauber lief, könnte es damit ja zusammen hängen. D.h. ist die besagte Software wirklich x64 fähig? Was sagt der Hersteller?

 

Auf der anderen Seite würde ich die funktionierende x86 Maschine einfach direkt mit der x64 vergleichen. Sind die gleichen Feautres installiert etc. (dotnet z.B.)...gibt es da gravierende Unterschiede.

 

Vielleicht hilft das ja...

 

Gruß

bearbeitet 2. November 2016 von MKdrei

[Assassin 13]

Soviel ich weiß wird die 64bit maschine nur genutzt weil mehr Ram... das Programm soll halt noch mehr maschinen überwachen und auswerten, was wohl etwas mehr System-resourcen nutzt.

[testperson 1.707]

Hi,

 

setz doch mal einen entsprechenden Windows Server x64 auf und teste die Monitoring Software darauf.

Ist ein Client OS nicht sogar auf X gleichzeitige Verbindungen limitiert (falls nicht technisch dann zumindest per EULA?)?

 

Gruß

Jan

[Sunny61 807]

Soviel ich weiß wird die 64bit maschine nur genutzt weil mehr Ram... das Programm soll halt noch mehr maschinen überwachen und auswerten, was wohl etwas mehr System-resourcen nutzt.

 

Wenn es trotzdem ein 32-Bit Programm ist, kann es mit dem zusätzlichen RAM aber nichts anfangen. Ein 64-Bit OS kann mehr RAM verarbeiten bzw. zur Verfügung stellen. Ein 32-BIT Programm kann trotzdem nicht mehr nutzen.

[NilsK 2.957]

Moin,

 

möglicherweise liegt da das Problem. Wenn das Programm eine 32-Bit-Anwendung ist, die auf eine nicht erwartete Umgebung (64-Bit-System) trifft, dann kann es zu solchen Phänomenen kommen. Zudem scheint die Software ja, dem Eröffnungspost nach zu urteilen, eine Reihe von Treibern mitzubringen (dort "Schnittstellentreiber" genannt), die dann vermutlich auch in 32-Bit-Implementierung vorliegen. Solche Treiber können auf 64-Bit-Systemen laufen, müssen aber nicht. Und sie können dann eben auch undefinierte Fehler verursachen.

 

In solchen Situationen habe ich durchaus schon erlebt, dass die Deinstallation solcher Komponenten nicht sauber arbeitet und diese Komponenten eben doch noch das System beeinflussen.

 

Darauf würde ich den Hersteller mal ansprechen - oder es selbst verifizieren: Neue 32-Bit-VM mit der neuen Version der Software aufsetzen und sehen, ob die Probleme da auch auftreten. Ziemlich sicher ist es jedenfalls kein Hyper-V-Problem (auch wenn sich sowas in der IT nie vollständig ausschleßen lässt).

 

Gruß, Nils

[Jim di Griz 13]

Hallo,

nur als sidekick: worauf basiert die Monitoring-Software? Evtl. Java? andere Details? Bringt sie einen Webserver mit? Nutzt sie eigene Treiber?

Ich vermisse den klaren Satz des Herstellers das die SW andernorts definitiv auch auf 64 Bit läuft.

Mag Pfennigfuchserei sein aber ich tendiere dazu bei solchen Unklarheiten in der Kommunikation hellhörig zu werden.

[Assassin 13]

*update*

Es liegt nicht an der Monitoring-Software. Wir haben jetzt eine komplett neue Win7 VM installiert von einer Win7 x64 CD (also nichtmal von einem downloadbarem Iso). Diese maschine voll durchgepatcht was Windows-Updates angeht, und auf die Domäne gehoben.

Zusätzlich haben wir noch den GData AV Business Client installiert (14er version).

Nach ein paar Tagen stand auf einmal auch diese VM still, also war eingefroren, auch wieder mit CPU last (allerdings diesmal nur 8% lt. Host) - wobei die CPU last immer unterschiedlich ist wenn die VM steht ist mir aufgefallen.

Ich habe jetzt den Gdata client nochmal runtergenommen und beobachte das ganze jetzt nocheinmal^.

 

 

Viel schlimmer ist aber: Die Exchange-VM (Server 2008R2) ist ebenfals jetzt schon 2x fest gefahren, auch mit CPU Last laut Host. Man kann die VM nicht mehr anpingen und auch nicht über die Hyper-V Console darauf zugreifen. Auch da - keine fehler im Ereignisprotokoll was darauf hindeuten könnte :-/ Darauf läuft ebenfalls der GData AV Client - mal schauen, am ende liegt es daran.

Das ist aber dennoch sowas von nervenaufreibend wenn man nichts in dden protokollen stehen hat, was vorher vieleicht probleme macht und die VM zum einfrieren zwingt...

[NilsK 2.957]

Moin,

 

falls es nicht am Virenscanner liegt, würde ich die Hardware in den Kreis der Verdächtigen nehmen.

 

Gruß, Nils

[Assassin 13]

der Host selber läuft aber Stabil, er zeigt keine anzeichen von Fehlern. Habe das Raid nochmal überprüfen lassen (integritätstest & chkdsk), und auch auf dem Host mitlerweile alle Windows updates nochmal gezogen. Der Host selber hat kein internet, auch kein Virenscanner oder soetwas, aber für diesen fall haben wir dem kurzzeitig Internet gegeben um updates zu laden. Der Windows-Update dienst ist sont auch deaktiviert.

 

 

Kann ECC Speicher (DDR3) theoretisch fehler verursachen, ohne das die Hardware, bzw. das ECC es mitbekommt? Ist soetwas möglich? 

 

 

Wie gesagt, ich habe den Virenscanner jetzt von der W7 VM runtergenommen, und kann jetzt nur ein paar Tage abwarten um zu sehen wie es läuft.