Server 2019 Hyper-V VM
Hallo zusammen,
ich habe an verschiedensten Servern/ Workstations folgendes Problem in folgender Konstellation.
Server 2019 Hyper-V Host + Server 2019 VM
-> Hardwarebasis entweder Fujitsu Server oder HP Workstations ( bei kleineren Umgebungen )
-> Leistung: Immer SSDs / ausreichend Cores und RAM
- Server 2019 VM fungiert i.d.R. als DC, Problem besteht aber auch unabhängig der installierten Server Rollen.
Problem:
Diverse Client Server Installationen die mit dem alten Server ( keine VM ) geschmeidig liefen benötigen jetzt ein vielfaches an der Zeit um zu starten
-> Wenn einmal gestartet, normales arbeiten möglich
-> Zeiten variieren von Client zu Client
-> Das entsprechende Programm wir im Taskmanager teilweise mit "Keine Rückmeldung" angezeigt nur um dann irgendwann doch zu starten
-> Es sind z.B. betroffen, "Geocon" "Profi Cash" "Orca AVA" "Archicat"
-> Nicht alle Programme sind betroffen, z.B. "KWP" "Sage" diese brauchen eine SQL Server Installation, aber auch welche ohne SQL laufen normal
-> Denke das Problem hatte ich noch nicht mit Server 2016, obwohl ich damals noch nicht oft Server virtualisiert habe
-> Virenscanner scheint keinen Unterschied zu machen, deaktiviert / deinstalliert
-> Daten hin und her kopieren funktioniert normal !
Meine Versuche bisher :
-> verschiedenste Workarounds durchgearbeitet die im Netz so gefunden werden
-> Hardwareeinstellungen an den VMs geändert
-> 1000 Kleinigkeiten die ich nicht mehr alle aufzählen kann da ich das Problem an sich schon seit ca. 2 Jahren habe und es immer umgangen habe wenn möglich
Performancebeispiel:
HP Z2 G5 Workstation als Hyper-V Host mit Server 2019
- i9-10900
- 32 GB RAM
- 2x 4TB Samsung SSD Raid 1
->Server 2019 VM
- 6 Cores
- VHDX feste Größe
- 16 GB RAM
- keine extra Rolle installiert, liegen einfach nur Files drauf
- Programm Archicat an Client XY öffnet einen Plan der auf der VM liegt und den selben Plan der auf dem Host liegt und dann nochmal lokal
- Plan Größe ca 300 MB
- Beim schließen des Programms wird der Plan anscheinend "zurückgesichert" auch wenn nichts geändert wurde
VM:
Öffnen des Plans zwischen 1:10 - 1:50 ( Minuten:Sekunden)
Schließen des Plans zwischen 2:40! - 1:20
( Taskmanager teileweise "keine Rückmeldung" wie oben angesprochen...anscheinend mal mehr mal weniger "keine Rückmeldung" )
Hyper-V Host ( vermutlich gleich egal auf welchem Rechner im LAN Hauptsache keine 2019 VM )
Öffnen des Plans zwischen 39-40 ( Sekunden )
Schließen des Plans 5 ( Sekunden )
Lokal
Öffnen des Plans zwischen 35-38 ( Sekunden )
Schließen des Plans 5 ( Sekunden )
Es war weiter nichts los im Netzwerk oder Server.
So ich denke das wars im groben zusammengefasst.
Interessant ist das dieses Verhalten Hardware Übergreifend vorhanden ist und ich nicht glauben kann das ich dazu nicht wirklich viel im Netz finde.
Eine Möglichkeit wäre natürlich das ich seit jeher die Hyper-V / VM Konfiguration verkacke, nobody is perfect
Vielleicht hat ja der eine oder andere einen Gedanken dazu.
Schöne Woche noch und danke im voraus.
ich habe an verschiedensten Servern/ Workstations folgendes Problem in folgender Konstellation.
Server 2019 Hyper-V Host + Server 2019 VM
-> Hardwarebasis entweder Fujitsu Server oder HP Workstations ( bei kleineren Umgebungen )
-> Leistung: Immer SSDs / ausreichend Cores und RAM
- Server 2019 VM fungiert i.d.R. als DC, Problem besteht aber auch unabhängig der installierten Server Rollen.
Problem:
Diverse Client Server Installationen die mit dem alten Server ( keine VM ) geschmeidig liefen benötigen jetzt ein vielfaches an der Zeit um zu starten
-> Wenn einmal gestartet, normales arbeiten möglich
-> Zeiten variieren von Client zu Client
-> Das entsprechende Programm wir im Taskmanager teilweise mit "Keine Rückmeldung" angezeigt nur um dann irgendwann doch zu starten
-> Es sind z.B. betroffen, "Geocon" "Profi Cash" "Orca AVA" "Archicat"
-> Nicht alle Programme sind betroffen, z.B. "KWP" "Sage" diese brauchen eine SQL Server Installation, aber auch welche ohne SQL laufen normal
-> Denke das Problem hatte ich noch nicht mit Server 2016, obwohl ich damals noch nicht oft Server virtualisiert habe
-> Virenscanner scheint keinen Unterschied zu machen, deaktiviert / deinstalliert
-> Daten hin und her kopieren funktioniert normal !
Meine Versuche bisher :
-> verschiedenste Workarounds durchgearbeitet die im Netz so gefunden werden
-> Hardwareeinstellungen an den VMs geändert
-> 1000 Kleinigkeiten die ich nicht mehr alle aufzählen kann da ich das Problem an sich schon seit ca. 2 Jahren habe und es immer umgangen habe wenn möglich
Performancebeispiel:
HP Z2 G5 Workstation als Hyper-V Host mit Server 2019
- i9-10900
- 32 GB RAM
- 2x 4TB Samsung SSD Raid 1
->Server 2019 VM
- 6 Cores
- VHDX feste Größe
- 16 GB RAM
- keine extra Rolle installiert, liegen einfach nur Files drauf
- Programm Archicat an Client XY öffnet einen Plan der auf der VM liegt und den selben Plan der auf dem Host liegt und dann nochmal lokal
- Plan Größe ca 300 MB
- Beim schließen des Programms wird der Plan anscheinend "zurückgesichert" auch wenn nichts geändert wurde
VM:
Öffnen des Plans zwischen 1:10 - 1:50 ( Minuten:Sekunden)
Schließen des Plans zwischen 2:40! - 1:20
( Taskmanager teileweise "keine Rückmeldung" wie oben angesprochen...anscheinend mal mehr mal weniger "keine Rückmeldung" )
Hyper-V Host ( vermutlich gleich egal auf welchem Rechner im LAN Hauptsache keine 2019 VM )
Öffnen des Plans zwischen 39-40 ( Sekunden )
Schließen des Plans 5 ( Sekunden )
Lokal
Öffnen des Plans zwischen 35-38 ( Sekunden )
Schließen des Plans 5 ( Sekunden )
Es war weiter nichts los im Netzwerk oder Server.
So ich denke das wars im groben zusammengefasst.
Interessant ist das dieses Verhalten Hardware Übergreifend vorhanden ist und ich nicht glauben kann das ich dazu nicht wirklich viel im Netz finde.
Eine Möglichkeit wäre natürlich das ich seit jeher die Hyper-V / VM Konfiguration verkacke, nobody is perfect
Vielleicht hat ja der eine oder andere einen Gedanken dazu.
Schöne Woche noch und danke im voraus.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1759233013
Url: https://administrator.de/contentid/1759233013
Ausgedruckt am: 22.11.2024 um 05:11 Uhr
15 Kommentare
Neuester Kommentar
Tach Hansdampf,
1.: prüfe er alle Kabelverbindungen, ob da wirklich alle Gigabit haben, oder der eine oder andere wegen schlechter Kabel nur 100MBit.
2.: Gruppenrichtlinien. Werden bei allen die gleichen Gruppenrichtlinien abgearbeitet, oder sind da User/Hardeware-Bedingt unterschiedliche abzuarbeiten. das kann su unterschiedlichen Login-Verhalten führen.
3.: sind alle Clients auf gleichem Update-Stand und haben alle das gleiche Funktionsupdate/Windows-Release? Ist das dann wirklich vergleichbar?
4.: Flaschenhals. Eine mögliche Engstelle könnte die Netzwerkanbindung des Servers sein, wenn gerade zwei oder mehrere auf ihn zugreifen. Das kann man ggf mit Link Aggregation abmildern.
Grüße
Kreuzberger
1.: prüfe er alle Kabelverbindungen, ob da wirklich alle Gigabit haben, oder der eine oder andere wegen schlechter Kabel nur 100MBit.
2.: Gruppenrichtlinien. Werden bei allen die gleichen Gruppenrichtlinien abgearbeitet, oder sind da User/Hardeware-Bedingt unterschiedliche abzuarbeiten. das kann su unterschiedlichen Login-Verhalten führen.
3.: sind alle Clients auf gleichem Update-Stand und haben alle das gleiche Funktionsupdate/Windows-Release? Ist das dann wirklich vergleichbar?
4.: Flaschenhals. Eine mögliche Engstelle könnte die Netzwerkanbindung des Servers sein, wenn gerade zwei oder mehrere auf ihn zugreifen. Das kann man ggf mit Link Aggregation abmildern.
Grüße
Kreuzberger
Ich würde mal die üblichen Admin Werkzeuge anwenden
Auf dem Client:
nslookup <servername>
ping <servername>
ping <domainname>
tracert <servername>
wireshark analyse
SMB Performance zum Server testen
Auf dem Server:
Datenträger Performance testen
Netzwerk Performance testen
CPU Belastung kontrollieren
tracert <hostname vom client>
Auf dem Client:
nslookup <servername>
ping <servername>
ping <domainname>
tracert <servername>
wireshark analyse
SMB Performance zum Server testen
Auf dem Server:
Datenträger Performance testen
Netzwerk Performance testen
CPU Belastung kontrollieren
tracert <hostname vom client>
Hallo,
Dem Fehlerbild nach zu urteilen würde ich auch erstmal das Netzwerk prüfen, vor allem
DNS - Auflösung: Wie werden die Server aufgelöst, DNS, FQDN?
Kannst du doppelte IPs sicher ausschliessen?
Beim Hyper-V fällt mir grad nichts ein, was so falsch eingestellt sein könnte, um das Verhalten zu erklären.
Evtl. massiv zu wenig Leistung für die VM, also mal CPU-Last, RAM-Auslastung, Festplattenauslastung während dem Öffnen / Speichern kontrollieren.
Dem Fehlerbild nach zu urteilen würde ich auch erstmal das Netzwerk prüfen, vor allem
DNS - Auflösung: Wie werden die Server aufgelöst, DNS, FQDN?
Kannst du doppelte IPs sicher ausschliessen?
Beim Hyper-V fällt mir grad nichts ein, was so falsch eingestellt sein könnte, um das Verhalten zu erklären.
Evtl. massiv zu wenig Leistung für die VM, also mal CPU-Last, RAM-Auslastung, Festplattenauslastung während dem Öffnen / Speichern kontrollieren.
Hallo hansdampf
wenn du auf dem Server eh nur FileSharing machst, warum nimmst du da nicht einfach ein Gutes NAS (SYNOLOGY, QNap, FreeNAS) und wo dann die NAS-Hardware mit mehreren NICs ausstattest. Die NICs dann als Link Aggregation an einem Switch, der das auch kann, und du hast weniger solche Probleme.
Wie du schreibst öffnen die Clients direkt auf der Share 300MB Dateien. Die Dateien werden also NICHT vorher auf den Client kopiert um dort bearbeitet zu werden. (Würde ich anders machen, und immer mit einer Lokalen Kopie arbeiten.).
Zudem verbrätst du dann nicht Serverlizenzen nur für FileSharing, eine schicke Workstation hast du dann auch noch dazu frei. (Nur für FileSharing kannst du auch den kostenlosen Windows CoreServer nehmen)
Für DHCP, DNS etc. reicht in kleinen Netzen meist der Router oder ein RASPI.
Kreuzberger
wenn du auf dem Server eh nur FileSharing machst, warum nimmst du da nicht einfach ein Gutes NAS (SYNOLOGY, QNap, FreeNAS) und wo dann die NAS-Hardware mit mehreren NICs ausstattest. Die NICs dann als Link Aggregation an einem Switch, der das auch kann, und du hast weniger solche Probleme.
Wie du schreibst öffnen die Clients direkt auf der Share 300MB Dateien. Die Dateien werden also NICHT vorher auf den Client kopiert um dort bearbeitet zu werden. (Würde ich anders machen, und immer mit einer Lokalen Kopie arbeiten.).
Zudem verbrätst du dann nicht Serverlizenzen nur für FileSharing, eine schicke Workstation hast du dann auch noch dazu frei. (Nur für FileSharing kannst du auch den kostenlosen Windows CoreServer nehmen)
Für DHCP, DNS etc. reicht in kleinen Netzen meist der Router oder ein RASPI.
Kreuzberger
Kannst du in deinem Versuchsaufbau von oben (Archicat, 300MB), in Achicat als Serveradresse anstatt den DNS-Namen die Server-IP eingeben? Oder in einem anderen der problematischen Programme?
Wichtig wäre, dass die Verbindung ohne DNS direkt auf die IP (V4!) geht.
Wird es dann besser?
Wenn du das Verhalten bei mehreren Kunden hast wird wahrscheinlich überall die Ursache gleich sein...
Gerade wenn du das schon oft gemacht hast, machst du mit Sicherheit immer alles gleich, eben auch die Problemursache.
Mir sind auch schon Einstellungen auf die Füße gefallen, die ich mir Anfang der 2000er mal angewöhnt hatte. Die waren damals sinnvoll, verursachen heute aber leichte "Nebenwirkungen".
Wichtig wäre, dass die Verbindung ohne DNS direkt auf die IP (V4!) geht.
Wird es dann besser?
Wenn du das Verhalten bei mehreren Kunden hast wird wahrscheinlich überall die Ursache gleich sein...
Gerade wenn du das schon oft gemacht hast, machst du mit Sicherheit immer alles gleich, eben auch die Problemursache.
Mir sind auch schon Einstellungen auf die Füße gefallen, die ich mir Anfang der 2000er mal angewöhnt hatte. Die waren damals sinnvoll, verursachen heute aber leichte "Nebenwirkungen".
Zitat von @hansdampf:
Ja wenn ichs mal nicht vergesse deaktiviere ich das selbstverständlich auch an den Clients
Ja wenn ichs mal nicht vergesse deaktiviere ich das selbstverständlich auch an den Clients
Spielt an sich keine Rolle, wenn der Server kein v6 anbietet, stört die "v6-Fähigkeit" des Clients nichts. Davon abgesehen ist es eigentlich best practise, v6 in seinen Netzen vernünftig zu konfigurieren, anstatt es abzuschalten.
Dein Problem wirst Du vermutlich über das Abarbeiten dieser Maßnahmen los. Vor allem "DirectoryCacheLifetime Dword=0" auf neueren Windows 10-Versionen, ich glaube seit 1803, kann einiges bewirken. Ich hatte da auch schon so meine Freude mit...
Ja, aber Du kannst auch links im Menü auf "SMB-Dateiserver" klicken und bekommst dann noch einige PArameter, die auf dem Server angepasst werden können. Du musst sicherlich systematisch durchtesten, welcher Wert eine Veränderung bewirkt. Wenn Du den oder die "Übeltäter" gefunden hast, würde ich die Registry-Keys per Gruppenrichtlinie ausrollen.