assimilator
Goto Top

Windows Server 2003 nach Virtualisierung sehr lahm

Hallo,

ich haben einen Windows Server 2003 mit dem VMWare Converter virtualisiert. Das hat prima geklappt.
Anschließend habe ich den physikalischen Server platt gemacht und neu installiert.
Jetzt lasse ich die neue virtuelle Maschine unter VMWare Server laufen.

Obwohl die Hardware ausreichend dimensioniert sein sollte, ist die virtuelle Maschine sehr viel langsamer als als zuvor, als sie direkt auf der Hardware lief. Das Virtualisierung Performance kostet ist mir klar; aber dieser Geschwindigkeitsunterschied ist nicht normal.

Hier die Daten:

Hardware:
- HP Poliant ML350 G3
- 2 Xeon CPUs mit je 2,8GHz
- 3,5 GB RAM
- SCSI RAID 5 mit drei Platten

Host-System:
- Windows Server 2000
- VMWare Server 1.04 (es wird nur die u.g. VM ausgeführt)

Guest-System:
- Windows Server 2003 (DC, Terminalserver, Druckerserver)
- zugesicherter RAM: 2,2 GB RAM (immer mind. 300 MB frei)
- 2 CPUs

Hat jemand eine Idee, warum das System jetzt so langsam sein könnte?

Assimilator

Content-ID: 75736

Url: https://administrator.de/contentid/75736

Ausgedruckt am: 23.11.2024 um 01:11 Uhr

TheDonMiguel
TheDonMiguel 14.12.2007 um 18:54:08 Uhr
Goto Top
Hast du bei der VM die aktuelle Version der VMware Tools installiert? Wie ist die Resource Auslastung beim Host und bei den Guests?

Was hast du denn genau virtualisiert? Bedenke, Applikationen mit viel I/O (Terminal Server, Datenbanken, etc) sind nicht die optimalsten Kandidaten für eine Virtualisierung.

Grüsse
Miguel
Assimilator
Assimilator 14.12.2007 um 20:54:53 Uhr
Goto Top
Ich hab' über den VMware Server 1.04 die mitgelieferten VMware Tols installiert. Diese sind auch aktiv.

Auf dem Server laufen neben den Terminaldiensten in der Tat ein MS SQL 2000 Server, der wohl schon immer recht lahm war. Jetzt ist er aber extrem lahm.
Neben der Datenbankanwendung (Steuerberatungssoftware "Tse:nit") laufen auch noch mehrere DOS-Applikationen und MS Office auf dem Server - mehr nicht. Die DOS-Applikationen werden durch das Programm "TameDOS" beschleunigt, so dass nicht die ganze Rechenpower für die virtuellen 16-bit-Umgebungen drauf geht . Das war auch vor der Virtualisierung so und funktioniert gut.

In der Zwischenzeit habe ich noch ein bisschen Informationen gesammelt. Es sieht so aus, dass der Server extrem durch die Datenbankzugriffe ausgebremst wird (Guest während der Zugriffe bei 100% CPU-Last; Host-Auslastung weiß ich im Moment nicht, da ich derzeit nicht vor Ort bin.).

In Sachen Datenbanken hab' ich wenig Ahnung und bin für jeden Tipp dankbar!

Gruß

Assimilator
TheDonMiguel
TheDonMiguel 15.12.2007 um 08:34:08 Uhr
Goto Top
Du kannst in der VMware Server Console der Virtual Machine eine zweite CPU zuweisen (unter der Hardware Verwaltung). Dies könnte den Zustand einwenig verbessern...

Gruss
Miguel
Assimilator
Assimilator 15.12.2007 um 12:34:50 Uhr
Goto Top
Die VM hat bereits 2 CPUs zugewiesen...

Trotzdem Danke für den Hinweis!

Gruß

Assmilator
gammaplayer
gammaplayer 17.12.2007 um 21:05:31 Uhr
Goto Top
Interessant wäre tatsächlich wann genau die hohe CPU-Last auftritt (und welcher Prozess dann die hohe CPU Last erzeugt) oder ob die hohe Last auch im Leerlauf (keine clients auf der Maschine) auftritt.

Eine andere Idee wäre noch, den Netzwerkkarten-Treiber zu wechseln. Ich hatte letztens ein ähnliches Problem, da lief der "System"-Prozess mit hoher CPU-Last und nach dem Treiberwechsel hat sich das gegeben.

Sorry: Ich hab mich vertan, bin von ESX-Server ausgegangen. Hmm. Weiß nicht, ob die oben genannten Sachen da auch helfen.
Assimilator
Assimilator 19.12.2007 um 11:48:08 Uhr
Goto Top
Es gibt doch nur die "Standardtreiber" für die virtuellen Netzwerkkarten vom VMware; oder?!?

Die physikalischen Netzwerkkarten laufen einwandfrei und liefen bereits vor der Virtualisierung ohne Probleme. Ich glaube aber nicht, dass es an diesen Treibern liegt, da die CPU-Last i.d.R. unter 5% liegt, wenn kein User arbeitet. Andererseits greift dann ja auch niemand über's Netzwerk zu....?!?

Die Auslastung geht hoch, wenn ein User Datenbankabfragen macht. Der ausschlaggebende Prozess ist dann die Anwendung (Tse:nit). Wenn der "sqlagent" aktiv ist, benötigt er stets um die 70% CPU-Leistung; auch wenn niemand arbeitet.

Gruß
Assimilator
darthi
darthi 23.06.2008 um 11:05:28 Uhr
Goto Top
Hallo,

ich habe im Moment genau das selbe Problem.
Auf dem Host Rechner ist OpenSUSE 10.3 installiert und das Guest System ist Windows Server 2008.
Auf dem Windows Server werden hauptsächlich Terminal Dienste ausgeführt. Es verbinden bis maximal 10 Personen über die RDP Verbindung auf das Guest System. Ressourcen sind eigentlich genügend verfügbar und es läuft auch für eine bestimmte Zeit relativ flott. Nur nachdem der Server ein paar Stunden läuft hat man eine konstante CPU Auslastung im Guest System von 100%. Im Host System ist sie nicht so hoch. Einzige Abhilfe ist es das Guest System neu zu starten. Das komische bei der Sache ist, dass laut Taskmanager kein Programm des Guestsystems soviel Ressourcen frisst. Selbst der Taskmanager selbst ist dann schnell mal bei 50% CPU Last.

Weiß jemand wie ich dem Problem begegnen kann oder bleibt mir nichts anderes übrig, als wieder vom virtuellen auf einen physikalischen Server umzuziehen?
78807
78807 29.07.2009 um 08:13:39 Uhr
Goto Top
Hi,
selbes Problem auf mit einem virtualisiertem XP Pro.
Läuft auf einem ESX Server mit aktuellen VMWare Tools installiert.
Habe schon 2 GB RAM und CPU bis 5 GHz zugewiesen (max. stehen 60 GHz) zur Verfügung.
Beim booten werden kurz 4 GHz abgerufen und danach sinkt die CPU Last laut Performance Monitor auf 560 MHz.
Beim öffnen des Taskmanagers ohne auch nur 1 andere gestartete Anwendung verbraucht dieser immer zwischen 60 und 95% CPU Last.
Ein Arbeiten mit der VM ist fast nicht zu denken.
Ein Reboot benötigt etwa 15 Minuten.

Hat evtl. jemand eine Lösung?

greatz
78807
78807 29.07.2009 um 16:19:35 Uhr
Goto Top
so haben heute im laufe des tages den fehler gefunden.
es lag am ide channel der auf pio modus stand.
alles auf udma geändert und reboot ausgeführt und schon rennt die kiste wieder.

hoffe es hilft vielleicht auch anderen

greatz