Programme auf Windows Backup langsam
Hallo,
wir haben einen Linux Server (Dell Poweredge R720), dieser hat virtuelle Maschinen. Die Maschinen laufen mit qemu/libvirt. Davon sind 2 virtuelle Maschinen Windows Server 2019, wo eine die Active-Directory ist. Auf den Windows Maschinen benutzen wir unter anderem Programme wie QuarkXPress. Wir haben alle virtuelle Maschinen auf einen gleichartigen Server mit dd geklont. Die Programme auf den geklonten Windows Server starteten 10 x langsamer und QuarkXPress, was normalerweise in 1 Minute fertig war mit starten, brauchte 10 Minuten.
Ich hoffe Ihr könnt uns da weiterhelfen. Vielen Dank im Voraus!
wir haben einen Linux Server (Dell Poweredge R720), dieser hat virtuelle Maschinen. Die Maschinen laufen mit qemu/libvirt. Davon sind 2 virtuelle Maschinen Windows Server 2019, wo eine die Active-Directory ist. Auf den Windows Maschinen benutzen wir unter anderem Programme wie QuarkXPress. Wir haben alle virtuelle Maschinen auf einen gleichartigen Server mit dd geklont. Die Programme auf den geklonten Windows Server starteten 10 x langsamer und QuarkXPress, was normalerweise in 1 Minute fertig war mit starten, brauchte 10 Minuten.
Ich hoffe Ihr könnt uns da weiterhelfen. Vielen Dank im Voraus!
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 4558748610
Url: https://administrator.de/forum/programme-auf-windows-backup-langsam-4558748610.html
Ausgedruckt am: 14.05.2025 um 08:05 Uhr
8 Kommentare
Neuester Kommentar
Hi,
Wäre doch doof, wenn 2x die gleiche SSID im Netz rumschwirrt ;)
Grüße
Wir haben alle virtuelle Maschinen auf einen gleichartigen Server mit dd geklont
habt Ihr anschließend ge'sysprep't?Wäre doch doof, wenn 2x die gleiche SSID im Netz rumschwirrt ;)
Grüße
2
Zitat von @141986:
habt Ihr anschließend ge'sysprep't?
habt Ihr anschließend ge'sysprep't?
Naja kommt drauf an. Bei 1:1 Kopie könnte es auch PROD in TEST Umgebung o.ä. sein. Leider steht nichts davon da. Normal clont man ja mehr "leere" Server, und nimmt die als Grundgerüst für neue Aufgaben.
Ich kennen leider diese Virt. Lösung nicht. Wenn die Hardware gleich ist, wäre die Frage ob die Host gleich konfiguriert sind! Oder ob da etwas den Performance Einschlag verursacht.
Liegen dei VMs auf den Hyperbisor oder auf Storage (NAS/ SAN etc.) Da wäre die Frage, wie hier die Anbindung sich unterscheidet.
Kann leider nicht mehr entnehmen.....
Glaskugel meldet: Die neuen VMs sehen nur eine vCPU.
Vielen Dank für Eure Antworten.
Ich habe das wohl etwas zu ungenau beschrieben, daher möchte ich das noch mal verfeinern:
Die beiden Rechner sind absolut identisch konfiguriert, und immer nur einer davon ist aktiv, das heißt die virtuellen Maschinen, auf denen wir remote arbeiten, laufen darauf, daher kann sich nichts in die Wege kommen (doppelte IPs o.ä.). Der zweite Server ist nur dafür gedacht, dass wir bei einem Hardware-Defekt keine größeren Ausfallzeiten haben, der ist immer ausgeschalten, außer wenn er die Backups zieht.
Die Sicherung vom Server zum Backup-Server läuft in der Nacht automatisch, das passiert bei heruntergefahrenen VMs.
Wenn wir den Notfall-Test machen und die beiden Server vertauschen, d.h. der Backupserver ist der Hauptserver und der normale Server ist aus, funktioniert eigentlich alles super, alle Linux-VMs laufen problemlos, eine Windows7-VM ebenfalls, aber von den beiden Windows-Server-2019-VMs ist die eine, die als Lizenzserver fungiert, extrem langsam, die andere funktioniert normal.
Die Server sind normalerweise nicht mit dem Internet verbunden, aber auch ein Update auf die neuste Version brachte nichts und in der Zeit hätte er ja auch mit Microsoft "telefonieren" können, falls da Lizenzrechtlich was nicht in Ordnung wäre und deshalb der Fehler auftritt....
Wenn die Rechner virtualisiert sind, bekommen sie doch auch die gleiche Hardware vorgegaukelt, so dass es Windows eigentlich nicht merken dürfte, wenn die beiden Maschinen getauscht werden. Scheinbar aber doch und entweder werden die absichtlich verlangsamt, um Piraterie vorzubeugen oder irgendeine Schleife läuft permanent. Wir haben die CPU-Last beobachtet, die ist sowohl im Windows-Taskmanager als auch beim Beobachten der darunterliegenden Linux-Maschine nicht außergewöhnlich hoch, was uns darauf schließen lässt, dass hier wait-States, die die CPU nicht fordern, eingefügt werden.
Hat irgendjemand eine Idee, wonach wir noch suchen könnten?
Vielen Dank!
Gunter
Ich habe das wohl etwas zu ungenau beschrieben, daher möchte ich das noch mal verfeinern:
Die beiden Rechner sind absolut identisch konfiguriert, und immer nur einer davon ist aktiv, das heißt die virtuellen Maschinen, auf denen wir remote arbeiten, laufen darauf, daher kann sich nichts in die Wege kommen (doppelte IPs o.ä.). Der zweite Server ist nur dafür gedacht, dass wir bei einem Hardware-Defekt keine größeren Ausfallzeiten haben, der ist immer ausgeschalten, außer wenn er die Backups zieht.
Die Sicherung vom Server zum Backup-Server läuft in der Nacht automatisch, das passiert bei heruntergefahrenen VMs.
Wenn wir den Notfall-Test machen und die beiden Server vertauschen, d.h. der Backupserver ist der Hauptserver und der normale Server ist aus, funktioniert eigentlich alles super, alle Linux-VMs laufen problemlos, eine Windows7-VM ebenfalls, aber von den beiden Windows-Server-2019-VMs ist die eine, die als Lizenzserver fungiert, extrem langsam, die andere funktioniert normal.
Die Server sind normalerweise nicht mit dem Internet verbunden, aber auch ein Update auf die neuste Version brachte nichts und in der Zeit hätte er ja auch mit Microsoft "telefonieren" können, falls da Lizenzrechtlich was nicht in Ordnung wäre und deshalb der Fehler auftritt....
Wenn die Rechner virtualisiert sind, bekommen sie doch auch die gleiche Hardware vorgegaukelt, so dass es Windows eigentlich nicht merken dürfte, wenn die beiden Maschinen getauscht werden. Scheinbar aber doch und entweder werden die absichtlich verlangsamt, um Piraterie vorzubeugen oder irgendeine Schleife läuft permanent. Wir haben die CPU-Last beobachtet, die ist sowohl im Windows-Taskmanager als auch beim Beobachten der darunterliegenden Linux-Maschine nicht außergewöhnlich hoch, was uns darauf schließen lässt, dass hier wait-States, die die CPU nicht fordern, eingefügt werden.
Hat irgendjemand eine Idee, wonach wir noch suchen könnten?
Vielen Dank!
Gunter
noch was vergessen: Die Server haben jeweils ein internes RAID für die Daten, das gleich konfiguriert ist, die VMs starten von M2e-SSDs, die auch genau gleich groß sind, sie können sich also beim Datenzugriff nicht in die Quere kommen.
Hallo,
ok also so eine Art cold-spare. Verstehe.
Wenn es nur denen einen betrifft, was zeigen die Logs? Sieht man woran es sich fest beißt?
Piraterie kommt nomral Hinweis auf den Bildschirm oder es fährt runter. Du kannst ja einfach die Aktivierung prüfen. Ist die noch gegeben? Würde mal die Ereignisanzeige befragen. Gibt es sowas wie VMware Tools? Was pasiert wenn man den 2019 neustartet? Die Bootreihenfolge der VMs ist auf Host B so wie auf Host A?
ok also so eine Art cold-spare. Verstehe.
Wenn es nur denen einen betrifft, was zeigen die Logs? Sieht man woran es sich fest beißt?
Piraterie kommt nomral Hinweis auf den Bildschirm oder es fährt runter. Du kannst ja einfach die Aktivierung prüfen. Ist die noch gegeben? Würde mal die Ereignisanzeige befragen. Gibt es sowas wie VMware Tools? Was pasiert wenn man den 2019 neustartet? Die Bootreihenfolge der VMs ist auf Host B so wie auf Host A?
Hallo Crusher79,
Danke für die Rückmeldung. Die Aktivierung ist in Ordnung, das sieht normal aus. Wir haben jetzt schon alles wieder auf Normalbetrieb umgeswitcht, so dass ich nicht nachsehen kann. Morgen soll die Frühschicht noch mal testen, da ist auch unser Linux-Profi da. Wir schauen dann noch mal in die Logs und speichern die extern, damit wir die in Ruhe auswerten können und nicht die Produktion im Nacken hängt.
Der Neustart bringt keine Verbesserung, die Bootreihenfolge ist identisch, das wird vom selben Script gesteuert. Das Booten der Maschinen geht auch normal, nur die Programme sind so gähnend langsam...
Ich weiß nicht, ob es für KVM irgendwelche speziellen Tools gibt, aber das dürfte eigentlich auch nicht mehr sein als man auf der Konsole mit virsh und htop sehen kann.
Ich denke, das Problem liegt irgendwo im Windows...
Danke für Deine Mühe!
Danke für die Rückmeldung. Die Aktivierung ist in Ordnung, das sieht normal aus. Wir haben jetzt schon alles wieder auf Normalbetrieb umgeswitcht, so dass ich nicht nachsehen kann. Morgen soll die Frühschicht noch mal testen, da ist auch unser Linux-Profi da. Wir schauen dann noch mal in die Logs und speichern die extern, damit wir die in Ruhe auswerten können und nicht die Produktion im Nacken hängt.
Der Neustart bringt keine Verbesserung, die Bootreihenfolge ist identisch, das wird vom selben Script gesteuert. Das Booten der Maschinen geht auch normal, nur die Programme sind so gähnend langsam...
Ich weiß nicht, ob es für KVM irgendwelche speziellen Tools gibt, aber das dürfte eigentlich auch nicht mehr sein als man auf der Konsole mit virsh und htop sehen kann.
Ich denke, das Problem liegt irgendwo im Windows...
Danke für Deine Mühe!
Problem gelöst.
8 vCPU zu 2 vCPU geändert, dann gestartet. Danach zurückgestellt auf 8 vCPU, gestartet und jetzt sind auch die geklonten VMs wieder vergleichsweise schnell.
8 vCPU zu 2 vCPU geändert, dann gestartet. Danach zurückgestellt auf 8 vCPU, gestartet und jetzt sind auch die geklonten VMs wieder vergleichsweise schnell.
