VmWare Lese- und Schreibrate virtuelle Maschine
Liebe Community,
ich habe bei einer einzigen virtuellen Maschine auf meinem VmWare ESxi Server ein großes Problem mit der Lese- und Schreibrate der (virtuellen) Festplatten. Laut VmWare Überwachung habe ich eine Durchschnittliche Lese- und Schreibrate von 2,25 MB/s, du kannst auf der virtuellen Maschine defacto nicht arbeiten. Auf dem selben SAS-Speicher läuft auch eine andere virtuelle Maschine bei der dieses Problem nicht auftritt (20,87 MB/s).
Bei der betroffenen virtuellen Maschine handelt es sich um einen Windows 2016 Server mit Exchange 2016. Im Alltag merkt man es nicht, ich muss aber eine der Exchange Datenbanken verschieben und bei der Geschwindigkeit braucht das ewig. Die virtuelle Maschine wurde einst von einer physichen Server mit Hilfe vom VmWare Converter erstellt.
Ich habe die Einstellungen mit der anderen virtuellen Maschine verglichen, keine Unterschiede.
Hatte jemand anderes auch so ein Problem und eine Lösung gefunden?
Liebe Grüße,
Florian
Hinweis: Der Server mit den Problemen nutzt VMware Virtual disk SCSI Disk Device Version 10.0.14393.1613 der problemlos laufende Server 10.0.17763.3232 ist aber auch ein Server 2019.
ich habe bei einer einzigen virtuellen Maschine auf meinem VmWare ESxi Server ein großes Problem mit der Lese- und Schreibrate der (virtuellen) Festplatten. Laut VmWare Überwachung habe ich eine Durchschnittliche Lese- und Schreibrate von 2,25 MB/s, du kannst auf der virtuellen Maschine defacto nicht arbeiten. Auf dem selben SAS-Speicher läuft auch eine andere virtuelle Maschine bei der dieses Problem nicht auftritt (20,87 MB/s).
Bei der betroffenen virtuellen Maschine handelt es sich um einen Windows 2016 Server mit Exchange 2016. Im Alltag merkt man es nicht, ich muss aber eine der Exchange Datenbanken verschieben und bei der Geschwindigkeit braucht das ewig. Die virtuelle Maschine wurde einst von einer physichen Server mit Hilfe vom VmWare Converter erstellt.
Ich habe die Einstellungen mit der anderen virtuellen Maschine verglichen, keine Unterschiede.
Hatte jemand anderes auch so ein Problem und eine Lösung gefunden?
Liebe Grüße,
Florian
Hinweis: Der Server mit den Problemen nutzt VMware Virtual disk SCSI Disk Device Version 10.0.14393.1613 der problemlos laufende Server 10.0.17763.3232 ist aber auch ein Server 2019.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 7562771011
Url: https://administrator.de/forum/vmware-lese-und-schreibrate-virtuelle-maschine-7562771011.html
Ausgedruckt am: 22.12.2024 um 09:12 Uhr
17 Kommentare
Neuester Kommentar
Moin.
Ohne VMWare Profi zu sein:
Du hast die in der GUI sichtbaren Einstellungen verglichen.
M.W. gibt es auch bei bei VMWare noch einige Einstellungen in der Config-Datei die man nicht sieht ... ??
.
Zitat von @florian.rhomberg:
Ich habe die Einstellungen mit der anderen virtuellen Maschine verglichen, keine Unterschiede.
Ich habe die Einstellungen mit der anderen virtuellen Maschine verglichen, keine Unterschiede.
Ohne VMWare Profi zu sein:
Du hast die in der GUI sichtbaren Einstellungen verglichen.
M.W. gibt es auch bei bei VMWare noch einige Einstellungen in der Config-Datei die man nicht sieht ... ??
.
Moin...
also weder 2,25 MB/s noch 20,87 MB/s sind für mich eine akzeptable Schreib oder Lese rate!
wo hast du das abgelesen, und wie hast du das gemessen?
was sind das für HDDs/ SSD / oder was auch immer? CPUs /RAM ?
mach ein Backup deiner VM, erstelle eine neue VM, und mach ein Restore!
wenn es ein Exchange ist, kannst du zur not auch eine Recovery Installation machen, dazu benötigst du nur die aktuelle DB und die orginal installations pfade!
Exchange Server: Neuinstallation ohne Datenverlust
Frank
2,25 MB/s, du kannst auf der virtuellen Maschine defacto nicht arbeiten. Auf dem selben SAS-Speicher läuft auch eine andere virtuelle Maschine bei der dieses Problem nicht auftritt (20,87 MB/s).
also weder 2,25 MB/s noch 20,87 MB/s sind für mich eine akzeptable Schreib oder Lese rate!
wo hast du das abgelesen, und wie hast du das gemessen?
was sind das für HDDs/ SSD / oder was auch immer? CPUs /RAM ?
Die virtuelle Maschine wurde einst von einer physichen Server mit Hilfe vom VmWare Converter erstellt.
ich tippe auf auf einen buslogic Controller in deiner VM und Thin-Provisioning!mach ein Backup deiner VM, erstelle eine neue VM, und mach ein Restore!
wenn es ein Exchange ist, kannst du zur not auch eine Recovery Installation machen, dazu benötigst du nur die aktuelle DB und die orginal installations pfade!
Exchange Server: Neuinstallation ohne Datenverlust
Frank
könntest du das einmal kurz erläutern?
Das mit thin-provisioning sowas passiert, ist ja allgemein bekannt.
Wenn die thin ist: Vielleicht hat er die Möglichkeit die vm auf ein anderes storage zu migrieren (lokale ssd und zurück?) Dabei könnte er dann die Disk ganz einfach in thick umwandeln.
LG
ich muss da @Vision2015 zustimmen, selbst die 20MB/s sind um mindestens Faktor 10 zu gering. Neben den genannten Dingen prüfe auch mal. ob nicht irgendwo eine Snapshot weggestorben ist und die Festplatten konsolidiert werden müssen.
moin...
klar...
Virtual SCSI und vSATA in VMware: BusLogic, LSI oder Paravirtual?
Das mit thin-provisioning sowas passiert, ist ja allgemein bekannt.
Wenn die thin ist: Vielleicht hat er die Möglichkeit die vm auf ein anderes storage zu migrieren (lokale ssd und zurück?) Dabei könnte er dann die Disk ganz einfach in thick umwandeln.
LG
Frank
klar...
Virtual SCSI und vSATA in VMware: BusLogic, LSI oder Paravirtual?
Das mit thin-provisioning sowas passiert, ist ja allgemein bekannt.
Wenn die thin ist: Vielleicht hat er die Möglichkeit die vm auf ein anderes storage zu migrieren (lokale ssd und zurück?) Dabei könnte er dann die Disk ganz einfach in thick umwandeln.
LG
Frank
AD + DNS (+ DHCP) und Exchange auf einem Server? Ganz schlechte Idee. Wenn schon virtualisiert ist, ist doch ein eigener DC schnell aufgesetzt!
Verstehe ich das richtig: es handelt sich NICHT um 2 VMs mit unterschiedlichen Verhalten auf EINEM ESXi. Sondern um 2 VERSCHIEDENE Host mit der jeweiligen VM?
Jürgen
Verstehe ich das richtig: es handelt sich NICHT um 2 VMs mit unterschiedlichen Verhalten auf EINEM ESXi. Sondern um 2 VERSCHIEDENE Host mit der jeweiligen VM?
Jürgen
Trotzdem ist das mit DC und Exchange auf einem System keine gute Idee.
Windows-Server sind nun nicht meine erste Kompetenz, aber wenn ich mich richtig erinnere werden bei einem DC aus Sicherheitsgründen (Datenverlust bei unerwartetem Systemausfall) alle Cache-Funktionen für die Zugriffe auf die Datenträger deaktiviert.
Und du hast doch Win-Server-Lizenzen. Eine Lizenz gilt für eine physische oder 2 virtuelle Instanzen. Warum willst du denn noch auf irgendeine Software-Beschaffung warten?
Jürgen
Windows-Server sind nun nicht meine erste Kompetenz, aber wenn ich mich richtig erinnere werden bei einem DC aus Sicherheitsgründen (Datenverlust bei unerwartetem Systemausfall) alle Cache-Funktionen für die Zugriffe auf die Datenträger deaktiviert.
Und du hast doch Win-Server-Lizenzen. Eine Lizenz gilt für eine physische oder 2 virtuelle Instanzen. Warum willst du denn noch auf irgendeine Software-Beschaffung warten?
Jürgen
Moin...
Es handelt sich um einen ESXi Server mit zwei virtualisierten Maschinen. Einen Windows Server 2016 der vom ehemals physischen Server mirgriert wurde und einen Windows Server 2019 der als Terminalserver konfiguriert ist.
Der W2019 läuft einwandfrei, das sind alle zufrieden.
Der W2016 ist extrem langsam wenn du darauf arbeitest, die Benutzer merken es nicht, weil er so viel RAM hat, dass der Exchange Server (Webmail und Outlook anbindung) ohne Gschwindigkeitseinbußen läuft. Das Problem ist wirklich, wenn ich am Server eine Datei kopiere, ist der Kopiervorgang extrem langsam.
als dein 2016 Virtualisiert wurde, hätten schon die rollen getrennt werden sollen!
erstelle doch eine 2019 VM für den DC, und schiebe die fMSO rollen rüber... das ist doch schnell gemacht, das wirst du sowiso irgendwann machen müssen!
Florian
Frank
Zitat von @florian.rhomberg:
Hallo @chiefteddy,
ich weiß, bis letztes Jahr hat es kein virtualisiertes System gegeben, sondern diesen Windows Server 2016 der alle Aufgaben erfüllt hat. Als der neue Server angeschafft wurde, konnte ich auf Virtualisierung umstellen. Im Prinzip wäre für heuer, nachdem letztes Jahr die Hardware erneuert wurde, die Software dran, da hätte ich das dann auch so gemacht, nur hier liegen wir im Zeitplan weit hinterher, es hätte in Q1 durchgeführt werden sollen, die Entscheidung ist aber bis heute nicht gefallen (es funktioniert eh alles).
DHCP verwende ich nicht am Windows Server die IP-Adressenverteilung macht das UTM.
warum tut man sich sowas an?Hallo @chiefteddy,
ich weiß, bis letztes Jahr hat es kein virtualisiertes System gegeben, sondern diesen Windows Server 2016 der alle Aufgaben erfüllt hat. Als der neue Server angeschafft wurde, konnte ich auf Virtualisierung umstellen. Im Prinzip wäre für heuer, nachdem letztes Jahr die Hardware erneuert wurde, die Software dran, da hätte ich das dann auch so gemacht, nur hier liegen wir im Zeitplan weit hinterher, es hätte in Q1 durchgeführt werden sollen, die Entscheidung ist aber bis heute nicht gefallen (es funktioniert eh alles).
DHCP verwende ich nicht am Windows Server die IP-Adressenverteilung macht das UTM.
Es handelt sich um einen ESXi Server mit zwei virtualisierten Maschinen. Einen Windows Server 2016 der vom ehemals physischen Server mirgriert wurde und einen Windows Server 2019 der als Terminalserver konfiguriert ist.
Der W2019 läuft einwandfrei, das sind alle zufrieden.
Der W2016 ist extrem langsam wenn du darauf arbeitest, die Benutzer merken es nicht, weil er so viel RAM hat, dass der Exchange Server (Webmail und Outlook anbindung) ohne Gschwindigkeitseinbußen läuft. Das Problem ist wirklich, wenn ich am Server eine Datei kopiere, ist der Kopiervorgang extrem langsam.
erstelle doch eine 2019 VM für den DC, und schiebe die fMSO rollen rüber... das ist doch schnell gemacht, das wirst du sowiso irgendwann machen müssen!
Florian
Frank
Da kann ich erstmal nur zustimmen und das gilt für beide Seiten.
Dich als DL muss ich mal "rügen" denn es scheint ein bisschen so als wüstest du da learning by doing machen. Dein oberstes Ziel sollte es sein die Exchange Rolle und die AD Rolle und alles andere sauber zu trennen und auf neue, vernünftig konfigurierte VMs zu bringen (best practice VMware mit Windows ist z.B. paravirtuell, das steht in jeder Anleitung, meist als thick provisioning). Den alten Server erstmal in eine VM zu konvertieren und nicht mehr "anzufassen" wenn nicht nötig ist natürlich okay aber du scheinst das so als Ist-Zustand zu tolierien nach dem Motto "läuft ja auch". Das kann dir und dem Kunden auf die Füsse fallen, es sollte in euer Beider Interesse sein den Zustand zu ändern.
Dein Kunde hingegen scheint eher mit "Geiz ist geil" zu fahren. Wenn es dann irgendwann knallt bist du vermutlich der Sündenbock, ob zu Recht oder nicht. Solche Kunden sind undankbar im besten Fall und brauchen auch mal ne klare Ansage.
Tu dir und deinem Kunden den Gefallen und suche ein Gespräch. Du solltest dem Kunden klar aufzeigen was noch zu tun ist, das es gemacht werden sollte und das es etwas kostet. Eine Exchange-Alternative kann man ja einplanen aber es sollte einen Plan geben wo die Reise hin geht. Tu dir den Gefallen und dokumentiere das. Wenn der Kunde sich nicht klar entscheidet oder das mit jemandem Anderem umsetzen will muss man sich auch mal als DL aus sowas raus halten, dann macht man am besten gar nichts.
PS: Ich würde die VM nicht mehr anfassen und auch nicht konvertieren, restore oder dergleichen machen sondern erstmal das Ziel klar setzen.
Dich als DL muss ich mal "rügen" denn es scheint ein bisschen so als wüstest du da learning by doing machen. Dein oberstes Ziel sollte es sein die Exchange Rolle und die AD Rolle und alles andere sauber zu trennen und auf neue, vernünftig konfigurierte VMs zu bringen (best practice VMware mit Windows ist z.B. paravirtuell, das steht in jeder Anleitung, meist als thick provisioning). Den alten Server erstmal in eine VM zu konvertieren und nicht mehr "anzufassen" wenn nicht nötig ist natürlich okay aber du scheinst das so als Ist-Zustand zu tolierien nach dem Motto "läuft ja auch". Das kann dir und dem Kunden auf die Füsse fallen, es sollte in euer Beider Interesse sein den Zustand zu ändern.
Dein Kunde hingegen scheint eher mit "Geiz ist geil" zu fahren. Wenn es dann irgendwann knallt bist du vermutlich der Sündenbock, ob zu Recht oder nicht. Solche Kunden sind undankbar im besten Fall und brauchen auch mal ne klare Ansage.
Tu dir und deinem Kunden den Gefallen und suche ein Gespräch. Du solltest dem Kunden klar aufzeigen was noch zu tun ist, das es gemacht werden sollte und das es etwas kostet. Eine Exchange-Alternative kann man ja einplanen aber es sollte einen Plan geben wo die Reise hin geht. Tu dir den Gefallen und dokumentiere das. Wenn der Kunde sich nicht klar entscheidet oder das mit jemandem Anderem umsetzen will muss man sich auch mal als DL aus sowas raus halten, dann macht man am besten gar nichts.
PS: Ich würde die VM nicht mehr anfassen und auch nicht konvertieren, restore oder dergleichen machen sondern erstmal das Ziel klar setzen.