sehr schlechter Netzwerkdurchsatz

[thomasha]

Hallo,

ich bin neu hier im Forum und deshalb erst mal schönen guten Morgen/ guten Tag.

Zum Thema:
Ich habe redundante physikalisch Server auf denen Win Server 2000 läuft,
Netzwerk mit 100 Mbit-Switch. Die Netzwerk-Übertragung läuft normal.
Nun habe ich die Server virtualisiert per Konvertierung, die VMWare-Tools funktionieren leider nur bis 7.1, vermutlich wegen Win2000.
Nun zum Problem:
Wenn ich auch nur einen virtualisierten Server einsetze und mit dem anderen über Netzwerk verbinde, ist die Netzwerkgeschwindigkeit der Applikation (ein Leitsystem) ca. gefünftelt im Vergleich gegenüber der Geschwindigkeit zwischen den physikalischen Servern.
Dabei ist es egal mit welcher VMWare-Version (7.1, 8, und 10.01 habe ich getestet), welcher Hardware und Windowsversion (Win7-Notebook 8 GB RAM, Fujitsu Server mit WIN 2008 Server, 16 GB RAM) ich arbeite.
Rein über Windows-Explorer ist alles in Ordnung. Leider komme ich an die Entwickler der Applikation nicht ran.
Folgendes habe ich schon probiert:
- Netzwerksende- empfangs- und übertragungspuffer vergrößert (entweder in der Registry
oder in den Netzwerkadaptereigenschaften)
- Feste Netzwerkgeschwindigkeit eingestellt.
- Alle unnötigen virtuellen Netzwerkadapter entfernt.
- der VM so viel wie möglich RAM und Prozessoren/Kerne zugeordnet.

Ich hoffe, dass mir hier geholfen werden kann, bisher hab ich nichts entscheidendes gefunden.

Vielen Dank und
Gruß Thomas

[Dayworker]

Einer VM soviel RAM, Kerne und DISK zu geben wie möglich, ist absolut unproduktiv. Eine VMware-VM bekommt nur dann Rechenzeit zugeteilt, wenn die in einer VM angegebene Anzahl an Kernen auf dem Host auch frei ist. In dieselbe Schiene geht auch zuviel RAM, was je nach genauer WS-Version zwischen 768-1536MB vRAM liegt. Ab dieser von der WS-Version abhängigen vRAM-Grösse wird nur noch ein kleiner Teil, meist 400-500MB, wirklich im pRAM des Host vorgehalten, der Rest wird direkt als Auslagerungsfähig beim Host-OS gekennzeichnet und dem kommt das Host-OS umgehend nach. Somit liegt der Großteil des vRAM nachher eh im virtuellen Arbeitsspeicher des Hosts sprich Auslagerungsdatei unter Windows oder Swap-Partition unter Linux.

Wenn du viel Schreib-IOs in der VM hast, spielt auch noch der Typ der vDISK sprich Preallocated oder Sparse/Thin bzw angelegter Snapshot eine Rolle.


Meine Empfehlung lautet der W2k-VM einfach mal nur 1x vCPU mit 1GB vRAM zu geben.
Verlinke mal bitte noch das "vmware.log" aus dem VM-Ordner auf einen Freehoster, vielleicht sehen wir dann noch weitere Bremsen.

[thomasha]

Hallo dayworker,

danke erst mal für die Antwort.
komme am Montag wieder an die Server.
Der alte physikalische Server hatte auch zwei xeon-Prozessoren mit hyperthreading und 2 GB RAM.
Der neue Host-Server hat 16 GB RAM und zwei xeon-Prozessoren mit jeder Menge Kernen.
Ich hatte 3 GB RAM und 2 Prozessoren mit jeweils 2 Kernen zugeordnet.
Ich werde trotzdem der VM mal nur so wenig Ressourcen zuordnen, wie von dir vorgeschlagen.
Wie verlinke ich das "vmware.log" auf einen Freehoster?
Kann ich die Datei nicht einfach anhängen, über Attachment hinzufügen?

Gruß Thomas

[Dayworker]

Wenn unser Forum noch Dateianhänge gestatten würde, stände nicht in jedem zweiten Thread, daß man auf einen Freehoster verlinken möge und daran wird sich auch zukünftig nichts ändern. Ist zwar traurig, aber wahr und erspart dem Foreninhaber auf der anderen Seite aber auch unliebsame Post wegen unlauterer Dateiablage. Such dir halt einen Freehoster aus oder nutze eigenen Webspace und verlinke die Datei dann.


Wenn du bei Win2k die Kernanzahl herabsetzt, solltest du für optimale Leistung auch den HAL austauschen. Dafür hat VMware den KB-Eintrag Modifying the Hardware Abstraction Layer (HAL) for a Windows virtual machine (1003978) verfaßt. Eine durchklickbare Anleitung findet sich unter http://www.ehow.com/how_6324658_change-windows-hal-vmware.html. Nach dem Reboot läuft dann unvermeidbar die automatische HW-Erkennung komplett durch.
Den HAL-Tausch kannst du dir sparen, wenn die VM als Dualcore konfiguriert bleibt. Selbst damit sollte die VM in Abhängigkeit zur Host-Kernanzahl schon wesentlich runder laufen.
Falls sich auch dadurch nicht die Leistung erhöht, kommen auch noch sowohl TOE auf der Host-Nic als auch das VMnet-Interface des Gasts infrage, aber letzteres wird dann schon aus dem "vmware.log" ersichtlich.

[thomasha]

Hallo Dayworker,

leider komme ich erst jetzt dazu die log-Dateien hochzuladen.
Das Problem ist aber immer noch akut.

Ich habe mal die log-Dateien beider VMs zwischen denen der Datetrasfer läuft hochgeladen.

Hoffentlich funktioniert der link zu meiner drop-box?!
wenn nicht, bitte melden.
Ansonsten schon mal schönen Dank für die Hilfe

Gruß Thomas

https://www.dropbox.com/sh/yrtu84rb2fra0xf/9_4EyyaIZZ

[Dayworker]

Deine beiden VMs können keine grosse Performance entwickeln, da du immer noch mit Dualsockel samt Dualcore und 3072MB vRAM pro VM unterwegs bist und dazu kommt on-top dann noch der Bridge-Adapter.

Die Workstation ist nicht ESXi und demzufolge wird jede Multicore-VM mit zuviel vRAM noch langsamer als sie es auch unter ESXi sein würde. Mit in die Gleichung spielt auch noch rein, daß nur der ESXi überhaupt einen oder mehrere vSWITCH unterstützt. In den Desktopprodukten sind das aber immer Hubs, daß bedeutet das jede beteiligte Netzwerkkarte jedes vorbeikommende Netzwerkpaket überprüfen muß, ob es für sie bestimmt und daher entsprechend langsam ist. Das das VMware-Bridge-Interface über den "Promiscuous_Mode" auf der Host-Nic angeflanscht wird, bei dem die Host-Nic im Endeffekt in einen Hub verwandelt wird, damit dieser alle VMware-Netzwerkinterfaces erreichen kann, sorgt bereits für deutlich längere Grund-Latenzzeiten. Mit dem Bridge-Interface in einer VM sind daher dauerhaft kleinere Latenzen als 50ms nicht realisierbar. Das kannst du ggf nur mit Host-only oder NAT erreichen.

[Dayworker]

2013-12-02T14:06:03.347+01:00| Worker#0| I120: DISK: OPEN scsi0:0 'E:\zeig1a1\thomas2-cl2.vmdk' persistent R[]
2013-12-02T14:06:03.347+01:00| Worker#1| I120: DISK: OPEN scsi0:1 'E:\zeig1a1\zeig1a1-0.vmdk' persistent R[]
2013-12-02T14:06:03.425+01:00| Worker#0| I120: FILE: FileLockScanDirectory discarding M31757.lck from E:\zeig1a1\thomas2-cl2.vmdk.lck': invalid executionID 1992-130300266519922771(vmware-vmx.exe).
2013-12-02T14:06:03.425+01:00| Worker#1| I120: FILE: FileLockScanDirectory discarding M14224.lck from E:\zeig1a1\zeig1a1-0.vmdk.lck': invalid executionID 1992-130300266519922771(vmware-vmx.exe).
2013-12-02T14:06:03.503+01:00| Worker#0| I120: DISKLIB-SPARSE: "E:\zeig1a1\thomas2-cl2.vmdk" : failed to open (14): Disk needs repair.
2013-12-02T14:06:03.503+01:00| Worker#0| I120: DISKLIB-LINK : "E:\zeig1a1\thomas2-cl2.vmdk" : failed to open (The specified virtual disk needs repair).
2013-12-02T14:06:03.503+01:00| Worker#0| I120: DISKLIB-CHAIN : "E:\zeig1a1\thomas2-cl2.vmdk" : failed to open (The specified virtual disk needs repair).
2013-12-02T14:06:03.503+01:00| Worker#0| I120: DISKLIB-LIB : Failed to open 'E:\zeig1a1\thomas2-cl2.vmdk' with flags 0xa The specified virtual disk needs repair (14).
2013-12-02T14:06:03.612+01:00| Worker#1| I120: DISKLIB-SPARSE: "E:\zeig1a1\zeig1a1-0.vmdk" : failed to open (14): Disk needs repair.
2013-12-02T14:06:03.612+01:00| Worker#1| I120: DISKLIB-LINK : "E:\zeig1a1\zeig1a1-0.vmdk" : failed to open (The specified virtual disk needs repair).
2013-12-02T14:06:03.612+01:00| Worker#1| I120: DISKLIB-CHAIN : "E:\zeig1a1\zeig1a1-0.vmdk" : failed to open (The specified virtual disk needs repair).
2013-12-02T14:06:03.612+01:00| Worker#1| I120: DISKLIB-LIB : Failed to open 'E:\zeig1a1\zeig1a1-0.vmdk' with flags 0xa The specified virtual disk needs repair (14).
2013-12-02T14:06:03.643+01:00| Worker#0| I120: DISKLIB-DSCPTR: Opened [0]: "thomas2-cl2.vmdk" (0xa)
2013-12-02T14:06:03.643+01:00| Worker#0| I120: DISKLIB-LINK : Opened 'E:\zeig1a1\thomas2-cl2.vmdk' (0xa): monolithicSparse, 51729300 sectors / 24.7 GB.
2013-12-02T14:06:03.643+01:00| Worker#0| I120: DISKLIB-LIB : Opened "E:\zeig1a1\thomas2-cl2.vmdk" (flags 0xa, type monolithicSparse).
2013-12-02T14:06:03.643+01:00| Worker#0| I120: DISK: Disk 'E:\zeig1a1\thomas2-cl2.vmdk' has UUID '60 00 c2 94 11 d2 4c d1-66 f5 9b 17 2b 78 1c 0f'
2013-12-02T14:06:03.643+01:00| Worker#0| I120: DISK: OPEN 'E:\zeig1a1\thomas2-cl2.vmdk' Geo (3220/255/63) BIOS Geo (3220/255/63)
2013-12-02T14:06:03.706+01:00| Worker#1| I120: DISKLIB-DSCPTR: Opened [0]: "zeig1a1-0.vmdk" (0xa)
2013-12-02T14:06:03.706+01:00| Worker#1| I120: DISKLIB-LINK : Opened 'E:\zeig1a1\zeig1a1-0.vmdk' (0xa): monolithicSparse, 104857600 sectors / 50 GB.
2013-12-02T14:06:03.706+01:00| Worker#1| I120: DISKLIB-LIB : Opened "E:\zeig1a1\zeig1a1-0.vmdk" (flags 0xa, type monolithicSparse).

Deine Log von Server-A zeigt auch noch eine Beschädigung der VMDK-Datei an.
Meldungen mit invalid executionID sagen mir, daß irgendetwas die VM hart abgeschaltet hat. Entweder war das eine Security-Lösung der Firmen Kaspersky, Avast, Avira, Comodo, Norton etc oder du hast die VM selbst hart abgeschaltet. Eine VM ist wie ein physischer Rechner zu behandeln und den schaltet man auch nicht über Reset oder ziehen des Stromsteckers aus. Die Folgen für eine VM sind dann dieselben wie auf Echtblech, vom Datenverlust bis zum Verlust der kompletten Partitionierung ist alles möglich und in deinem Fall kommt noch hinzu, daß die Workstation seit der Version 7 keinen vollfunktionalen "vmware-vdiskmanager" mehr mitbringt, damit man eine VMDK sprich vDISK auf CMD oder ba$h mit folgender Eingabe wieder reparieren könnte:

Code: Alles auswählen

vmware-vdiskmanager -R /path/to/*.vmdk

Da man VMDKs nicht einfach per Workstation-GUI wieder verkleinern kann, stellt sich mir auch die Frage, weshalb man mit den bekanntermaßen, aufgrund des inneren Aufbaus fehleranfälligen Sparse-Disks arbeitet und nicht auf Platten vom Typ Preallocated setzt. Bei deinen vDISK-Grössen von 24.7 und 50GB kommt noch eine weitere Gefahr hinzu, wenn kein freier Platz mehr auf dem Host vorhanden ist und kein OS mag vollgeschriebene Bootdatenträger. Die Meldung invalid executionID könnte also auch da herkommen und mit Sparse-Disks vergißt man diesen Zusammenhang, da Sparse-Disks für gewöhnlich nur den in einer VM geschriebenen Datenbestand enthalten. Falls du jedoch die Platte bei der Installation nicht schnellformatiert oder mal eine Defragmentierung im Gast-OS vorgenommen hast, wurde die Sparse-Disk sowieso auf die eingestellte, maximale VMDK-Grösse von 24.7 bzw 50GB aufgeblasen. Sparse-Disks bedürfen der regelmäßigen Pflege namens Shrinken, bei der die Luft aus der vDISK rausgelassen wird, indem alle freien Bereiche ausgenullt und aus der VMDK gelöscht werden. Je nach Schreib-IO deiner VM kann das monatlich, wöchentlich oder auch täglich erforderlich sein.

[thomasha]

Ich hatte die Prozessorzahl nicht reduziert, da dann die vm nicht mehr sauber lief.
Auf welchen Wert sollte ich den RAM reduzieren?
Wie kann ich die disk in der jetzigen Konfiguration repariern.
Kann ich irgendwelche tools anwenden?

Mich hatte auch kürzlich die vmware aufgefordert, die vm zu defragmentieren, was ich auch tat. Welche von beiden weiß ich nicht mehr.

[Dayworker]

Die VM läuft deswegen nicht mehr sauber, weil der für Multicore optimierte HAL eingespielt ist. Den mußt du selbstverständlich wechseln oder falls der Multicore-HAL wegen Dualcore-VM erhalten bleiben soll, mußt du im Gerätemanager einfach mal sämtliche CPUs "deinstallieren" und dann einen Gast-Reboot machen. Erst nach dem Reboot findet sich deine Win-VM mit der geänderten Kernanzahl ab und proviert nicht irgendwelche nicht mehr vorhandenen CPU-Kerne zu finden. Du kannst alternativ auch einen Parameter in die "boot.ini" eintragen und Windows damit zwingen, eine geringere Kernanzahl zu nutzen, obwohl mehr Kerne vorhanden sind. Dazu mußt du den vorhandenen Booteintrag erweitern:

Code: Alles auswählen

 /NUMPROC=2

Damit nutzt dein Win-OS nur 2 CPU-Kerne, auch wenn du eine Quadcore-VM erstellt hast. Zum Testen wird das ausreichen. Für den produktiven Einsatz ist das aber nur wenig tauglich, da die VM trotzdem 4 freie CPU-Kerne vom Host bekommen will und nachher aufgrund des boot.ini-Eintrags trotzdem nur 2 nutzen wird.

Als Gast-RAM würde ich es mit 1GB probieren. Win2000 ist deutlich genügsamer und auch die Server-Version wird damit auskommen. Wenn du mehr vRAM einsetzen willst, macht das nur mit einer SSD im Host einen Sinn. Sämtliche aktuellen VMware-Desktopprodukte lagern aus Stabilitätsgründen seit der Win7/Server2k8-Veröffentlichung fast sämtlichen vRAM in den virtuellen Arbeitsspeicher des Hosts aus. Dieses Prinzip wurde bei allen WS-Veröffentlichungen seit Version 7 beibehalten.


VMware hat dir garantiert nicht gesagt, daß du die vDISK defragmentieren sollst oder das geschah in einem völlig anderen Kontext. Dieser liegt in internen Aufbau von Sparse-Disks begründen. Bei anstehendem Schreib-IOs muß erst das Host-OS um freie Datenträgersektoren in 4KB-Grösse anfragen werden, diese können dann logischerweise über den gesamten Host-Datenträger verteilt sein, was wiederum eine starke und für die Datensicherheit nachteilige Fragmentierung der Gast-vDISK zur Folge hat. Die Daten sind zwar sicher, aber eine Wiederherstellung im Fehlerfall gelingt nur für Dateien kleiner als 4KB. Preallocated Disks werden dagegen schon bei der Erstellung enbloc auf den Host-Datenträger geschrieben. Dadurch kann sich die VMDK-Datei nicht über den gesamten Host-Datenträger verteilen, wenn dafür genügend grosse, freie Bereiche vorhanden sind. Selbst für den Fall das der freie Bereich nicht ausreicht, wird eine preallocated vDISK immer noch in grösseren Blöcken auf dem Host-Datenträger abgelegt, als es eine Sparse-Disk jemals könnte. Dafür ist eine Sparse-Disk immer nur so groß, wie das in der VM geschriebene Datenvolumen umfaßt. Die Ausnahmen sind keine Schnellformatierung oder Defragmentierung im Gast-OS, bei der die Grösse der Gast-VMDK immer auf die konfigurierte Grösse der vDISK anwächst und Snapshots egal ob Preallocated- oder Sparse-Disks zum Einsatz kommen. Snapshots werden immer vom Typ Sparse angelegt. Da aber Snapshots kein Backup sind, sondern nur zum Backup oder zur schnellen Wiederherstellung für Tests in einer VM dienen, besteht eigentlich wenig Grund für den dauerhaften Einsatz eines oder mehrerer Snapshots.

In deinem Fall dürfte daher höchstwahrscheinlich gemeint sein, daß du den Host-Datenträger bei abgeschalteter VM mal defragmentieren solltest. Aber auch davon muß man Abstand nehmen, wenn der Host-Datenträger eine SSD ist. Deren Flashzellen überstehen für gewöhnlich nur geringe Mengen an Schreibvorgängen.

Da der "vmware-vdiskmanager" seit mehreren Version keine VMDKs mehr reparieren kann, bleibt dir eigentlich nur die VM per Imager innerhalb der VM zu sichern und mit der Restore-CD eine Wiederherstellung in eine VM vorzunehmen. Falls du Acronis als Imager hast, könntest du auch in eine kleine, zum Datenbestand der VM besser passende vDISK restaurieren. Den Weg finde ich im Thread Virtualisierung tib-Image in VMware Player ohne Converter ganz gut beschrieben. Die für gültigen Schritte darin sind die Nummern 2 und 3.

Als Alternative bleibt dir noch, eine ältere WS-Version bei VMware runterzuladen und dort den "vmware-vdiskmanager" zu entnehmen. Allerdings könnte sich dieser auch über eine zu hohe v.HW-Version der VMDK beschweren.

[thomasha]

Du has rech, die Aufforderung zur Defragmentierungn kam bei abgeschalteter vm.
Den "Rest" deiner Infos muss ich dann mal auswerten, wenn ich wieder an die Server komme.

Bis dann

[thomasha]

Hallo Dayworker,

auf Grund deiner Hinweise habe ich die VMs von einem Kollegen neu konvertieren lassen.

Da auf den Rechnern sehr viele Prozesse laufen (Leitsystem), hatten die Blechserver 2 Xeon-Prozessoren und 3 GB RAM, sowie ein Raidsystem mit SCSI-Platten.

Die jetzigen Host-Server haben wieder 2 Xeon-Prozessoren (neueren Typs), 16 GB RAM und ein RAID-System mit SAS-Platten (RAID 1 der RAID 5)

Wenn ich jetzt VMware neu installiere, würde ich die Version 6.5.5 nehmen.
Mit dieser Version könnte ich doch dann der VM (Win2000 Server) auch 2 oder 3 GB RAM zuweisen?
Wieviel Prozessoren/Kerne sollte ich für höchste Leistung der VM zuweisen?
Der Host wird für nichts anderes gebraucht, als der VM zu "dienen".
Ich würde die VMware-tools aus der Version 6.5.5 installieren?
Ich versuche auch erst mal netzwerkmäßig zu bridgen, falls nötig würde ich NATen.

Was ist deine Meinung zu dem neuen Plan.

vielen Dank schon mal, auch für die von dir schon genannten wichtigen Randpukte, die ich leider auf Grund meiner wenigen Erfahrung auf dem Gebiet der Virtualisierung so nicht gewusst habe.

Gruß Thomas

[Dayworker]

Also die WS6.5.4 hatte bei 1500MB ihren Punkt, ab dem nur noch 400-500MB des vRAMs im pRAM verblieben, weil der Rest als auslagerungsfähig gekennzeichnet wurde. Die 6.5.5 war meiner Erinnerung nach nur veröffentlicht, weil entweder ein gravierendes Sicherheitsproblem aufgetreten war oder das SP1 von Win7 schwerwiegende Bluescreens im Zusammenspiel mit der Workstation produzierte.

Inzwischen sind die aktuellen CPUs so weit von der WS6.5.5 entfernt, daß es fraglich ist, ob diese Version auch die CPU richtig erkennt und somit auch alle vorhandenen CPU-Kerne nutzen kann. Wenn du wirklich 2 oder 3GB RAM in einer VM brauchst und diese zudem auch noch performant sein soll, machen sämtliche VMware-Desktopprodukte nur wenig Sinn. Das VMware inzwischen 8 oder mehr vRAM nebst 16 oder noch mehr vCPUs bei seinen Desktopprodukten unterstützt, sind reine Marketingentscheidungen, damit keine Kunden zu anderen Virtualisierungslösungen abwandern.


Wenn du also Anwendungen hast, die dauerhaft mehr als 1GB vRAM benötigen und dabei auch noch performant sein sollen, bleibt dir nur noch der vSphere Hypervisor. In allen anderen Fällen wird das VMware-Desktopprodukt aus Stabilitätsgründen immer nur einen geringen Anteil des vRAMs im pRAM vorhalten und den restlichen vRAM im virtuellen Arbeitsspeicher des Hosts vorhalten. Somit entscheidet für die Schwubdizität in einer VM dann nur noch die Geschwindigkeit des Host-Datenträgers bzw Datenträgers, worauf die Auslagerungsdatei bzw Swap-Partition zum Liegen kommt.

Falls deine Anwendung nur manchmal die 2 oder 3GB RAM braucht, kann man sich jedoch mit der nicht verhinderbaren Auslagerung auch arrangieren. Probier es einfach aus und wenn die Performance unterhalb des Wunschlevels bleibt, hast du die Erklärung dafür bereits erhalten.

[thomasha]

d.h. wenn ich der VM 1499 MB RAM zuweisen würde, dann kommt nichts auf die Auslagerungsdatei des hosts.
Kann ich das irgendwie kontrolieren?
Vielleicht reichen ja auch die 1,5 GB für die VM, dann wäre ja die 6.5.5 die richtige Wahl, oder?
Mit vsphere wollte ich nicht auch noch anfangen.

[Dayworker]

Mach das jetzt nicht an den 1500MB fest. Je nach WS-Version gibt es noch weitere Abstufungen und die WS6.5.5 wurde auch erst nach der WS7.X hauptsächlich als Sicherheitsupdate veröffentlicht. Allerdings wurde die 6.5.5 von einem anderen Team programmiert. Outsourcing läßt grüssen...

[thomasha]

heißt das, dass ich unter den genannten Bedingungen besser die Version 6.5.4. nehmen sollte?
Und kann man die Benutzung von echtem RAM des hosts kontrollieren?

[Dayworker]

Die 6.5.4 bekommt unter Win7-SP1 ein schwerwiegendes Problem und dies lies sich meiner Erinnerung nach nur über ein VMX-Eintrag lösen. Ob sich diese alte Version prinzipiell überhaupt noch vernünftig unter einem neueren OS als Win7 installieren läßt, ist dann ggf noch so eine ganz andere Geschichte. Jedes aktuell gepflegte Host-OS wird aber auf die eine (lahme VM) oder andere Weise (BSODs) immer mit älterer Software ein Problem haben und ganz besonders, wenn diese wie bei der Virtualisierung sehr tief im System ansetzen muß.


Wieviel vRAM einer VM im pRAM des Hosts verbleiben, kannst du mit dem Taskmanager auf dem Host kontrollieren. SysInternals Process Explorer leistet hierbei auch gute Dienste. "Einfach" den vRAM erhöhen und bis zu einem gewissen vRAM-Wert plus PCI-Adressbereich plus Grafikspeicher einer VM (den jeweiligen RAM-Overhead kann man im WS-Manual nachschlagen und richtet sich auch nach dem vRAM-Wert einer jeweiligen VM) wird auch die Belegung des Host-Arbeitsspeichers ansteigen, ab einem gewissen Wert X an VM-RAM fällt dann dieser Wert wieder ab und es verbleiben nur noch 400-500MB einer VM im Host-Arbeitsspeicher. Dieser Abfall ist sowohl unter 32bit als auch 64bit bei Windows und Linux feststellbar. Solange dann keine RAM-intensiven Programme laufen, fällt diese Auslagerung auch nicht weiter auf. Falls dann ein Programm doch mehr RAM braucht, muß der Host notgedrungen anfangen zu Swappen und die Bedienung innerhalb der VM wird hakelig. Deswegen und wegen weiterer hier nur am Rande erwähnter Gründe sollte man auch eine strikte Trennung sprich getrennte Platten für OS plus Programmen und VMs vorsehen.

Die Workstation bietet unter ihren Host-Settings auch die Möglichkeit, diese Auslagerung in gewissen Grenzen zu beeinflussen und auch einen für die VMs reservierten RAM vorzumerken. Die Frage dazu lautet dann "How should the system allocate memory for virtual machines?" und bietet drei Wahlmöglichkeiten:

• "Fit all virtual machine memory into reserved host RAM" = Null Prozent solange der Wert X nicht überschritten wird
• "Allow some virtualmemory to be swapped" = 30 Prozent des vRAMs werden von vornherein ausgelagert *1
• "Allow most virtual machine memory to be swapped" = 70 Prozent des vRAMs werden immer ausgelagert *1

*1 Das ist wichtig, wenn mehr vRAM an VMs vergeben werden soll als pRAM im Host vorhanden ist. Mit einer SSD als Host-Datenträger kann man damit aber trotzdem relativ gut arbeiten.

[thomasha]

danke soweit o.k., dann werde ich doch die 6.5.5 nehmen, da mein Betriebsystem des hosts ja Win 2008 Server R2 ist und das is ja näher an Win 7 als an älteren Versionen.

Wo kann ich denn den Eintrag "Fit all virtual machine memory into reserved host RAM" in den Host-Settings machen?

[thomasha]

Hallo Dayworker,

habe jetzt alle Server "umgstellt".
Das Ergebnis überzeugt:
- ausreichende Performance (keine Probleme/timeouts mehr)
- besserer Netzwerkdurchsatz

Vielen Dank nochmal für deine fundierten Tips.

Gruß Thomas

[Dayworker]

Ausgehend von Tuning guide - setup the host for expected usage ... findest du die Einstellung in der Workstation unter "menu > edit > preferences > memory" und sieht wie folgt aus: