r4pt0x

Speicherproblem ist mittlerweile gelöst: durch die Windows-Updates letzten Montag wurde das Balooning unbrauchbar. Treiber dafür sind aktuell, auf R2 läuft es weiterhin problemlos, "R1" kann aber nun kein Balooning mehr - freigegebener Speicher wird nicht mehr neu belegt und der nutzbare Speicher schrupft immer weiter... Absturzproblem und fehlende dumps unverändert vorhanden.

Ja, habe ich. Seit den letzten Updates die am Montag installiert wurden hat sich die Kiste aber wieder was neues einfallen lassen: Es wird immer weniger RAM genutzt... 16GB stehen zur Verfügung, am Dienstag wurden nur noch 7,8GB genutzt, gestern waren es 4,6GB jetzt sind wir bei 3,87GB und die Kiste wird von Tag zu Tag langsamer weil er an ständigen Schreib/Lesevorgängen auf die Platte erstickt... Mal schauen wann er sich endgültig verabschiedet :rolleyes: Die pagefile schrumpft ebenfalls proportional zum genutzten Speicher (~4100MB aktuell).

So, zurück aus dem Urlaub, einige Crashes gab es in der Zeit wieder - aber kein einziger Minidump wurde geschrieben...

Nein, überhaupt nichts. Die letzten infos davor sind normale Statusmeldungen, meistens schon Stunden älter, dann nichts und mit Zeitpunkt nach dem Neustart wird die Fehlermeldung "unerwartet Heruntergefahren" geschrieben. Den manuellen STOP-Fehler werde ich noch ausprobieren. Bin zwar jetzt erstmal im Urlaub, aber spätestens in 2 Wochen wird das dann getestet - werde zwischendurch die test-VMs zwischen den nodes austauschen, dann habe ich in 2 Wochen auch hier Ergebnisse. Upgrade auf R2 wurde auch schon in Erwägung gezogen - allerdings ist das auch wieder ein Kostenfaktor, da es ja unverschämterweise kein Update gibt und damit wieder eine volle Lizenz fällig wird. Die erst vor 2 Jahren gekaufte 2008 Lizenz liegt dann ungenutzt rum... Zur Liste der supporteten Hypervisors: Dass in einer liste von Microsoft KVM oder andere FLOSS-Lösungen nicht auftauchen wundert mich nicht ;) Windows 2008 in allen Varianten wird aber in der Kompatibilitätsliste für KVM ohne bekannte Fehler oder Einschränkungen (ausser mangelhafter support für reboot) gelistet: http://www.linux-kvm.org/page/Guest_Support_Status Edit: http://blogs.technet.com/b/core/archive/2012/10/03/howto-manuelle-ausl-246-sung-eines-memory-dumps-schutzfehlers.aspx Der Hinweis sollte sinnvollerweise bei den Einstellungen zum Memorydump angezeigt werden (wenns schon nicht ohne manuelles gefrickel funktioniert) Daran dürfte es wohl liegen dass kein Dump erstellt wird - auch wenn ich IIRC die pagefile erst vor ~3 Wochen auf eine andere Partition verlegt habe und auch davor kein dump erstellt wurde...

Der TM ist wegen anderen Fehlern seit einigen Tagen deaktiviert (erhöht über ~2-3h immer weiter die CPU-last bis das system unbrauchbar ist). Dass 2008 und 2008 R2 komplett untershciedliche Systeme sind (vista <-> w7 basis) ist mir bekannt. Der VMWare Converter wandelt die VM auch sauber um, sie lässt sich auch starten, nur bleibt das System beim Bootversuch bei diversen Treibern hängen. Lässt sich beim protokollierten Bootvorgang deutlich beobachten - mit jeder ersetzen Treiberdatei kommt man ein paar schritte weiter und dann gibts bei einem der nächsten Treiber nen bluescreen oder das system friert ein... Aussichtslos so ein halbwegs stabiles System zu bekommen. Beim ACPI gab es keine änderungen - habe das wohl etwas falsch ausgedrückt. Die änderungen die nach dem Setup durchgeführt werdne müssen dass der Gast auf befehl auch herunterfährt sind:

Der RAM ist definitiv in ordnung - es wurde beim letzten kernelupdate sogar extra ein memtest durchgeführt. Zumal bei fehlerhaftem Speicher eher zuerst der Host probleme machen würde... Als Virenscanner läuft der Trend Micro Business drauf (inkl Serverdienst) - den hatte ich vergessen. Von Hostseite aus gibt es keine großartigen Konfigurationsabweichungen vom default ausser der Hardwarevarianten die dem Gast vergelegt werden (HDD-Controller, NICs, CPU-Typ) - Hier wurden schon die NIC und Speichercontroller von virtio auf e1000 und SCSI oder IDE geändert, was aber am Problem nichts ändert. Die einzigen "Gastspezifischen" änderungen betreffen direkt den Gast, da Win Vista/2003/2008 nicht korrekt auf ACPI reagiert und nicht auf Hostanfrage herunterfährt - das sind aber nur 2 Registryeinträge im Gast, sonst nichts. Wortlaut des "Log"eintrages (ich kann diese Ereignisprotokollierung einfach nicht als vollwertige Syslog ansehen, sorry...) ist einfach nur "Das System wurde am XXX unerwartet heruntergefahren". Beobachtet man den Bootvorgang via VNC wird vor dem Windows-Start die Auswahl für abgesicherten modus oder Normalen start angezeigt - es handelt sich also nicht um ein normales "Herunterfahren" sondern die Maschine ist einfach schlagartig weg und startet neu. Passierte gestern auch währrend ich im WSUS Updates freigeben wollte. Bild ist für ~3 sec eingefroren, dann wird neu gestartet. ESXi steht nicht zur Verfügung, übertragen der VM in eine VirtualBox VM scheiterte an Windows, da ja (noch immer..) nur ein stupf generischer bootvorgang durchläuft -> andere hardware und nichts mehr geht... (optimal für desaster recovery - deshalb ja auch KVM virtualisiert) Auch systemreparatur usw brachte nichts, die VM fror ständig beim booten ein - selbst wenn das dann irgendwann bootet wäre das ein dermaßen wackeliges Setup, dass man das kaum als Vergleichswert nutzen könnte um zu beurteilen ob es an der darunter liegenden virtualisierung liegt. Wie schon geschrieben: am meisten helfen würde es mir, wenn ich endlich irgend eine Art von verwertbarem dump und/oder vernünftigem fehlerlog bekommen würde. Alles andere ist bunt in den Himmel raten und sinnloses rumgeteste ohne Anhaltspunkt...

R2 läuft wie gesagt einwandfrei, 2008 x32 ebenfalls - es ist einzig die x64 Maschine und auch erst seit ~6 Wochen... Auf dem Server läuft ein MSSQL 2008 R2 server, der aber relativ wenig zu tun hat. Auf dem R2 am anderen Server läuft ebenfalls MSSQL 2008 R2, allerdings aktuell als kalter fallback - sprich es werden einfach nur immer die nächtlichen dumps an diesen server übertragen sodass im falle eines falles hier relativ schnell ein SQL-Server laufen kann. WerbasWeb ist die Anwendung die diesen MSSQL Serverdienst benötigt. Ansonsten wäre eigentlich nur noch SilverDAT als häufig genutzter Dienst installiert sowie ein WSUS. Sämtliche wichtigen Dienste (DNS, DHSP, Gateway, VNP-Routing etc) sowie Fileserver werden von debian-Servern übernommen. Updatestand ist aktuell. An der Gastkonfiguration hat sich nichts geändert, auch gab es keine Updates am Kernel oder dem pve-dienst der Zeitlich direkt mit dem autreten des Problems zusammenhängt. Ich habe vorhin auch noch ein altes Abbild des 2008 x64 Servers (direkt nach Windows-installation + MSSQL Server) auf beiden Proxmox-Systemen aktiviert. Der eine installiert jetzt seit knapp 2h Updates, der andere bleibt völlig unangetastet. Werde beide VMs einfach mal laufen lassen und ggf in 1-2 Wochen jeweils auf den anderen Host übertragen. Dann werde ich nach und nach alle Dienste (soweit möglich) nachinstallieren bis das Problem auftritt. Einfacher wäre natürlich wenn mir die aktuell betroffene Installation einfach einen sauberen dump oder zumindest Logeinträge erzeugen würde... Wenn das system bei deaktiviertem "Neustart bei Fehlern" einfriert lässt sich logischerweise auch nicht herausfinden welcher Prozess die ursache war - das System reagiert auf überhaupt nichts, Bildschirm bei VNC-Verbindung ist schwarz (ich hatte hier auf einen Bluescreen gehofft, daher wurde der automatische Neustart deaktiviert!). Wiederbeleben ist nur durch einen hardreset durch den Host möglich - also auch keine reaktion auf ctrl-alt-del! Dateisystemprüfung wurde im Gast und am Host durchgeführt - alles sauber. Die Proxmox/KVM-Spezifischen Probleme mit 2008 als Gast habe ich schon sehr ausführlich abgegrast - mit den Lösungen für die wenigen Problemfälle die ähnlich geartet waren stellte sich keine Besserung ein bzw trafen hier nicht zu. Da es aber auch bedeutend mehr solcher Probleme mit 2008 als bare-metal Installation gibt, wage ich jetzt einfach mal zu behaupten dass es auch nicht an der Virtualisierung liegt. Zumal ja die x32 und R2 x64 Installationen anstandslos laufen (wie auch die x64 bisher) und diese bekommen alle die selbe KVM-Umgebung als Unterlage... Wie gesagt: Ich will die Kiste jetzt primär erstmal "zwingen" mir endlich einen dump oder brauchbare Logs zu geben damit ich überhaupt einen Anhaltspunkt habe wo gesucht werden muss... Ein kompletter memorydump (16GB) der eingefrorenen VM wäre auch ziemlich sinnfrei...

Hallo. Wir haben in einer RHEL-Kernel basierten Virtualisierung (Proxmox VE) 2 Windows 2008 Server als KVM laufen - 32 und 64 bit. Währrend die 32bit Maschine normal läuft, startet die 64bit Maschine seit einiger Zeit ca 2-5x pro Woche zufällig einfach neu. Wird der automatische Neustart bei Fehlern deaktiviert, friert die Maschine mit voller CPU-Auslastung ein. Es wird keine Fehlermeldung oder Bluescreen angezeigt, kein Memorydump erstellt und es gibt keinerlei Fehlereinträge - in der Ereignisanzeige findet sich nur der Eintrag "Das System wurde unerwartet neu gestartet" Die Abstürze sind völlig unabhängig von der Systemlast, das Muttersystem und die anderen VMs laufen einwandfrei. Ein zeitlicher Zusammenhang zwischen dem auftreten des Problems und Installation oder Update von Diensten die auf dem Server laufen oder Treibern konnte nicht gefunden werden. Die virtio-Treiber wurden schon in zig verschiedenen Versionen ausprobiert, auch mit Versionen die definitiv einwandfrei liefen. Auch Wechsel von virtio auf IDE als Schnittstelle für die Laufwerke brachte keine Änderung (ausser deutlich reduzierte HDD IO-Leistung) Auf einem Zweiten Server (ebenfalls Proxmox VE) läuft ein 2008 R2 x64 ohne Probleme. Diverse Suchen in der microsoft-knowledgebase brachten zwar einige pasende Ergebnisse, aber praktisch alle Hotfixes lassen sich nicht installieren ("Nicht für dieses System geeinet"). Google spuckt logischerweise ebenfalls haufenweise Ergebnisse (Foren/Blogeinträge) zu crashendem Win 2008 aus, allerdings gibt es dann meistens entweder keine Lösung oder es wird auf die hardware geschoben, was hier ausgeschlossen werden kann. Auch die Standardantwort "Neuinstallation" ist keine Option - zumindest nicht solange die Fehlerursache nicht geklärt ist, da auf der Maschine diverse Software läuft die nur vom jeweiligen Anbietersupport installiert werden kann/darf - das wären dann zum 2. mal innerhalb von 12 Monaten ca 1000€ Kosten für Softwareinstallation - Das erste mal beim Umstieg vom x32 auf den x64 Server im Herbst letzten Jahres. Zudem lief es in dieser Konfiguration mehrere Monate problemlos; nur 3 der Dienste die Installiert sind, werden - in relativ großen intervallen - geupdated (die beiden anderen bekommen nur alle ~2 Monate aktualisierte Datenbankdateien eingespielt) und alle 3 wurden auch auf dem R2 Server installiert und verursachen hier keine Probleme. Ziel ist also primär die Ursache zu finden - daher bitte keine "Empfehlungen" dass einfach alles neu Installiert werden soll, zumindest nicht bis die Ursache gefunden ist und damit ggf der entsprechende Anbieter für die Kosten geradestehen darf.. Welche Möglichkeiten neben den - nicht funktionierenden - Memory- und Minidumps gäbe es noch einen Anhaltspunkt zu finden was für die abstürze Verantwortlich ist? Brauchbare Logs gibt es ja ebenfalls nicht... Schonmal danke für jede Hilfe!

Die aktuellen Backuproutinen sehen folgendermaßen aus: Das Hostsystem erstellt nächtliche snapshots von 2 OpenVZ containern und 2 KVM VMs, Snapshot für Windows-Server in KVM ist nicht konsistent möglich, daher sichert die W2k8-VM per WSS und zusätzlich nach dem fullbackup auch noch dei MSSQL-Datenbanken. Zudem schreiben die linux-VMs Backups von Kundendatenbanken und einer firebird-Datenbank. Backups werden 1 Tag lokal auf seperaten Platten im Hostsystem und 5 Tage auf einem dedizierten NAS vorgehalten, Datenbanken-Backups werden zusätzlich gepackt und zwischen den Standorten ausgetauscht, dabei muss bei Störung der VPN-Verbindung deren Status abgefragt werden und ggf per openvpn eine backup-verbindung aufgebaut werden. Schlägt das fehl, werden die Backups auf einen externen Server geladen und vom Server am anderen Standort sobald verfügbar abgeholt (so sichert bei Internet-Ausfall an einem Standort zumindest die andere Seite, die noch eine Anbindung hat nach draussen) Die Windows-Server sind hier nur ein kleiner Teil der Serverstruktur (und trotzdem der Wartungs- und Nervenintensivste!), daher werde ich mich hüten diesen die Backup-aufgaben zu übertragen. WSS tut seinen dienst und das auch recht gut da die Sicherungen sehr schnell und einfach wiederherzustellen sind. Ebenso sind die Backups aus MSSQL Server sauber und funktionieren, da lasse ich keine andere Software in den Datenbankserver fummeln, die beim nächsten Update dann wahrscheinlich nicht mehr sauber kompatibel ist. Das gesamte "backend" für die restliche Verarbeitung der Backups läuft schon lange absolut zuverlässig und wird daher auch nicht ausgetauscht. Es ging einzig und allein darum, dass die Windows-VMs die Laufwerke nur verbinden wenn sie sie auch benötigen (während dem Backup!) und dann wieder trennen. Für die "Hilfestellung" "Kauf dir ne Software" hätte ich nicht nach einer Skriptlösung für das verbinden/trennen von iSCSI targets gefragt...

Problem gelöst - bin zufällig auf iscsicli gestoßen, das lässt sich zeitgesteuert per batchscript ausführen... Zum Thema gebastel: Ein System auf dem tonnenweise Drittanbietersoftware verteilt rumliegt ist für mich eher eine Bastelbude (und eine Katastrophe bei der Wiederherstellung) als ein schlankes System das über gescriptete events eigenständig arbeitet. Und eine Software die alle Anforderungen ins Detail unterstützt gibt es nicht - deshalb laufen die Backups über die debian-server per shellscript. Da kann ich auch sämtliche sicherheiten und feedbacks einbauen die ich benötige.

Aus mehreren Gründen: 1. die Geschwindigkeit auf ein iSCSI target ist um einiges besser und da kein seperates Dateisystem dazwischen liegt werden potentielle Fehlerquellen deutlich reduziert. 2. Die Fullbackups sollen direkt aufs Ziel geschrieben werden, nicht erst auf den share und dann nochmal übers Netz auf das NAS. 3. Ist das mit dem share ja auch keine wirklich saubere Lösung sondern war eigentlich als provisorisches Workaround gedacht. 4. wird die Zeit irgendwann knapp - der Backupaustausch zwischen den Standorten dauert so schon bis kurz vor Arbeitsbeginn (und da wird dann die Bandbreite des VPN für den normalen Betrieb benötigt!), ich kann also nicht noch länger warten bis ich damit anfangen kann, sondern sollte eher sogar noch früher anfangen, da bleibt keine Zeit auch noch Backups mit 200GB mehrfach durchs Netz zu schieben... Ich könnte zwar auch den umständlichen weg gehen und das target vom NAS am debian-server zur Backupzeit einhängen und diesen Mountpunkt wieder als iSCSI-target für Windows bereitstellen, aber die Performance dürfte grausig sein, das Verhalten von Windows wenn das target tagsüber "ins leere Zeigt" ist auch ungewiss und gerade bei Backups sollte ja die Kette so kurz wie möglich sein... Es muss doch eine Möglichkeit geben, per script auch unter Windows ein iSCSI-target zu verbinden und zu trennen!?

Auf den Windows-Servern wir die Windows Server Sicherung verwendet (ausschließlich Fullbackups), da diese einfach wiederherstellbar und bare-metal fähig sind. Nur leider kann WSS eben nur eins: Sichern. Ansonsten ist das ganze ja leider dumm wie Brot (keine vernünftige Rotation, Auslagerung oder sonstiges...) Die Datenbankbackups werden direkt aus MSSQL-Server 2008 heraus geschrieben.

Unsere Windows 2008 Server schreiben an 2 Standorten abends um 21:00 ihre Full-backups auf ein iSCSI-Target (jeweils ein NAS lokal am Standort). Diese Backups sollen dann später zusammen mit den Datenbankbackups rotiert und zum jeweils anderen Standort übertragen werden, sodass an jedem Standort alle Backups verfügbar sind. Die Rotation, Auslagerung und zusätzliche Rotation der Datenbank-Backups auf ein DVD-RAM Laufwerk übernimmt jeweils ein debian-Server. Bei Backups die von den debian-servern geschrieben werden, werden die iSCSI-targets (oder NFS-shares) ausschließlich zur Backupzeit eingehängt und sind ansonsten unangetastet (so wie es sein soll...). Für Windows habe ich hier noch keine zufriedenstellende Lösung gefunden... Bei den Datenbank-backups des MSSQL Servers ist das kein Problem, da diese auf einen SMB-Share auf dem debian-Server geschrieben werden, der auch die Rotation und Auslagerung übernimmt. Der Share und die Backup-Dateien wird zu beginn des Rotationsskripts (startet mit ausreichend Verzögerung zu den Backups der DB-Server) auf Zugriffe geprüft, wenn negativ wird der Share nach aussen read-only und die Rotation kann sicher mit konsistenten Daten durchlaufen. Danach wird das Laufwerk ausgehängt, der Share bleibt readonly, damit keiner "ins leere schreibt" und erst kurz vor den geplanten Backups des nächsten Tages wird das Dateisystem neu eingehängt und der share auf RW gesetzt. Den share nur zu Backup-Zeit überhaupt zu aktivieren funktioniert leider nicht, da die W2k8-Server dann nach gewisser Zeit das Laufwerk trennen und einfach überhaupt keine Backups mehr schreiben anstatt zu versuchen das Ziel neu zu verbinden. Ich kann nun zwar das iSCSI Target vom debian-Server auch mounten ohne dass die W2k8-VM vorher die Verbindung trennt, aber das ist alles andere als sauber und führt zu ständigen Fehlereinträgen in den Logs beider Server: Debian moniert natürlich unsauberes Trennen von Windows (da nicht getrennt...), W2k8 wirft gleich ~10-15 Fehler in die Logs, dass das die Deteisystemstruktur angeblich defekt wäre (schreibt darauf dann aber trotzdem das neue Backup :schreck:) Ich suche deshalb nach einer sauberen Lösung, damit auch die Windows-Server ihre Backup-Ziele NUR zum Backup einbinden und nicht dauerhaft offen stehen lassen (und dann doch drauf herumschreiben währrend eine Rotation läuft...) Gibt es da eine brauchbare Lösung am besten ohne Drittanbietersoftware? Die Server sind sowieso schon aufgedunsen genug da für jede Kleinigkeit Fremdsoftware benötigt wird :rolleyes: Schonmal danke für alle Anregungen!