Failed to create snapshot for SERVER, Fehler -3941

[wolffsed]

Guten Tag. Wir sichern unsere VMs via iSCSI und VMDataRecovery auf ein NAS. In letzter Zeit fällt mir auf, dass es beim Versuch einen snapshot zu erstellen ab und an zu Problemen kommt. Das System bekommt es nicht hin und protokolliert den Fehler 3941. Wenn das einmal passieren würde und der zweite oder wenigstens dritte Versuch wäre erfolgreich, hätte ich damit kein Problem. Es ist aber so, dass die DataRecovery das ganz offensichtlich nicht alleine hinbekommt. Wenn wir das nicht bemerken, gehen die Versuche halbstündig weiter, solange bis tatsächlich der fragliche "Gast" rebootet wird. Dann klappt der snapshot...

Kann mir das jemand erklären?

[ideFix]

Anscheinend machen die VSS/sync Treiber auf der VM Probleme bzw die VMware Tools:
Data Recovery Snapshot Error -3941

[wolffsed]

Vielen Dank für die Hinweise.

[wolffsed]

Ich habe mir die Hinweise angeschaut, komme aber nicht wirklich weiter damit.
Meine Situation ist die, dass nicht immer dieselbe VM Probleme beim Erstellen eines Snapshots macht. Das sind immer wieder andere... Und sobald ich die VM neu gestartet habe klappt die Erstellung des Snapshots...

Mir ist unklar, wo hier die VMWare Tools eine Rolle spielen. Und was könnte ich im Blick auf die Treiber unternehmen? Kann mir da jemand noch konkretere Unterstützung geben? Danke schon mal.

[Dayworker]

Um dir mal einen kleinen Überblick zu geben. Über die Tools fragt der Host den Gast ab, ob dieser alle anstehenden IO-Anforderungen abgearbeitet hat, alle Dateisystem-Caches geleert sind, und somit das Dateisystem in einen konsistenten Zustand ist. Dann wird der Snapshot ausgelöst und alle auflaufenden Schreibzugriffe werden auf das Redo-File umgeleitet sowie der Zugriffs-Lock auf die Ursprungs-v.Disk gelöst und auf den Snapshot (also das Redo-File) gesetzt. Erst nach Lösen dieses Locks kann die v.Disk mit Dateizustand pre-Snapshot gesichert werden. Nach dem Backup werden automatisch alle Änderungen im Redo-File in die Ursprungs-v.Disk eingepflegt, das Redo-File vollständig gelöscht und der Zugriffs-Lock auf die v.Disk mit den eingepflegten Änderungen wiederhergestellt.

Hast du denn wie in dem verlinkten Thread empfohlen, die ESX Netzwerk Info's in die hosts-Datei des VDR-Hosts eingetragen?

[wolffsed]

Hast du denn wie in dem verlinkten Thread empfohlen, die ESX Netzwerk Info's in die hosts-Datei des VDR-Hosts eingetragen?

Nein, das habe ich noch nicht getan...

Was mich wundert ist, dass dieses Phänomen erst in letzter Zeit auftritt. Die Monate davor war das kein Thema, und ich habe keine Idee, was jetzt anders sein sollte...

[Dayworker]

Was mich wundert ist, dass dieses Phänomen erst in letzter Zeit auftritt. Die Monate davor war das kein Thema, und ich habe keine Idee, was jetzt anders sein sollte...

Hast du dabei mal an die normalen Updates oder sogar ein Servicepack gedacht?

[wolffsed]

Hast du dabei mal an die normalen Updates oder sogar ein Servicepack gedacht?

Was willst Du damit sagen?
Dass Dinge durch Updates verschlimmbessert werden?

[Dayworker]

Was willst Du damit sagen?

JA, daß ist doch nichts neues und genau hier macht sich Virtualisierung hervorragend oder was meinst du, wie in Firmen solche Updates/SPs getestet werden?!
Die IT-Abteilung braucht jetzt nur noch im Einzelfall reale HW aufzusetzen, um die Kompatibilität mit vorhandener Hard- und Software abschätzen zu können.

Dass Dinge durch Updates verschlimmbessert werden?

OT:
Hier mal ein paar Beispiele:
Das SP1 für Windows Seven war ausgehend von der "Build-ID 7601.17514.101119-1850" schon am 19.11.2010 um 18.50 Uhr kompiliert worden und brauchte bis Mitte Januar um eine gewisse Stabilität zu erreichen sowie auf ausreichend Systemen getestet zu werden...
Auch im Fall von Windows Phone 7 sind Probleme mit dem dortigen SP1 genauso bekannt geworden wie Probleme mit einigen Firmwares für Apples iPhone/Pad oder Googles Android 2.3 alias Gingerbread. Das sind also keine Einzelfalle und trifft irgendwann mal jeden SW-Hersteller. Man kann halt nicht alle möglichen SW- und HW-Konstellationen durchprobieren und wenn dann sogar noch selbstgeschriebene, ausschließlich intern verwendete SW dazukommt, sind Probleme vorprogrammiert.

Das es dort vermehrt M$ trifft, liegt neben deren Programmreichtum oder schlichter Benutzermehrzahl auch in einigen gemachten Fehlern in der Windows-Geschichte begründet. M$ behandelte Bugs und Sicherheitsprobleme immer stiefmütterlich, damit die Windows-Funktionalität ja nicht beeinträchtigt wurde. Das hat sich jedoch seit Vista mit seiner UAC geändert und momentan ist es sogar so, daß Windows als solches sicherer ist, als die darauf laufende SW!
Schau dir dazu mal die Katastrophe mit Adobe's Acrobat Reader oder auch Flash an. Da wird jede Woche ein neuer Fehler gefunden, der weitreichende Konsequenzen für das darunterlaufende OS hat. Daher weigert sich Apple in meinen Augen völlig verständlich, den Flash-Support in seine iOS-Geräte zu integrieren...

Allerdings betrifft es auch andere Bereiche wie Media-Player, Web-Browser oder Zip-Programme. Diese lassen sich über eine DLL-Lücke austricksen, indem man entsprechend manipulierte DLLs direkt im Programmverzeichnis abspeichert und das Programm dann diese bevorzugt und ohne weitere Überprüfung verwendet. Schau dir dazu mal http://www.chip.de/news/DLL-Hijacking-Luecke-in-Firefox-Office-und-WinZip_44433817.html an.