VMware-Forum

Hi!

1. Was Du machen willst:
Ich will machen, dass der Server von meinem Arbeitskollegen wieder problemlos User-Anmeldungen zulässt.

2. Worin Dein Problem besteht:
Es gibt 1 Host, und 2 VMs. Die eine VM ist ein Terminal-Server. Dieser bekommt (u.a.) die Event ID 333:
An I/O operation initiated by the Registry failed unrecoverably. The Registry could not read in or write out or flush one of the files that contain the system's image of the Registry.
Die User können sich teilweise nicht mehr anmelden. Außerdem rattert es noch weitere Fehlermeldungen, die laut Microsoft Folgen von ID 333 sind. 333 lässt darauf schließen, dass das System nicht damit nachkommt, Daten zu schreiben.
Nun ist es so, dass es auf dem Host-System recht seltsam aussieht:
- Host hat 8 GB RAM.
- VM1 hat 2 GB zugewiesen, braucht aber nur knapp 200 MB
- VM2 (der TS mit den Problemen) hat 4 GB zugewiesen, braucht aber nur kanpp 500 MB
- Wenn ich nun in der Konsole aber auf den Host selbst klicke, zeigt er mir beim RAM volle Auslastung.
- Im Task-Manager des Hosts sind 2 Prozesse mit dem Namen: vmware-vmx.exe
- Der 1. davon braucht ca. 4 GB RAM, der 2. etwa 450 MB
- Zusätzlich kat mein Kollege da noch eine PostGres-DB laufen, die auch ca. 400 MB schluckt
- Zudem halt noch einige andere Prozesse, klar.
Es erscheint mir recht schlüssig, dass das Gast-System Probleme mit dem Hinterherkommen des Schreibzugriffs hat, wenn der RAM vom Host bis zum Anschlag voll ist.

3. Alles zum Host (da wo der Server installiert wurde) wichtige wie:
- Windows Server 2003 Standard x64 SP2
- Intel Xeon E5420 @2,50GHz (quad core), 8 GB RAM

4. wie unter Punkt 3, aber alles zum Gast (Deine VM) und zusätzlich:
Relevante VM:
- Windows Server 2003 Standard x86 SP2
- 2 CPUs, 4 GB RAM
- VMtools installiert, ja

5. Poste Deine Einstellungsdatei zur VM namens *.vmx, zu finden im Ordner dieser VM:
.encoding = "windows-1252"
config.version = "8"
virtualHW.version = "7"
memsize = "4096"
MemAllowAutoScaleDown = "FALSE"
displayName = "JPHHSRV.jphh"
guestOS = "winnetstandard"
numvcpus = "2"
floppy0.present = "TRUE"
floppy0.autodetect = "TRUE"
floppy0.filename = "auto detect"
parallel0.present = "TRUE"
parallel0.fileType = "device"
parallel0.fileName = "auto-detect"
parallel0.autodetect = "TRUE"
serial0.present = "TRUE"
serial0.fileType = "device"
serial0.fileName = "auto-detect"
serial0.autodetect = "TRUE"
usb.present = "TRUE"
ethernet0.present = "TRUE"
ethernet0.addressType = "generated"
ethernet0.connectionType = "bridged"
ethernet0.startConnected = "TRUE"
ide0:0.present = "TRUE"
ide0:0.autodetect = "TRUE"
ide0:0.filename = "auto detect"
ide0:0.deviceType = "cdrom-raw"
scsi0.present = "TRUE"
scsi0.virtualDev = "lsilogic"
scsi0:0.present = "TRUE"
scsi0:0.fileName = "JPHHSRV.jphh.vmdk"
mks.enable3d = "TRUE"
vmci0.present = "TRUE"
lsilogic.noDriver = "FALSE"
ehci.present = "TRUE"
annotation = ""
pciBridge0.present = "TRUE"
tools.upgrade.policy = "useGlobal"
pciBridge4.present = "TRUE"
pciBridge4.virtualDev = "pcieRootPort"
pciBridge5.present = "TRUE"
pciBridge5.virtualDev = "pcieRootPort"
pciBridge6.present = "TRUE"
pciBridge6.virtualDev = "pcieRootPort"
pciBridge7.present = "TRUE"
pciBridge7.virtualDev = "pcieRootPort"

extendedConfigFile = "JPHHSRV.jphh.vmxf"
virtualHW.productCompatibility = "hosted"

checkpoint.vmState = ""
ethernet0.networkName = "Bridged"
ethernet0.features = "1"
ethernet0.generatedAddress = "00:0c:29:2c:d1:f8"
tools.syncTime = "FALSE"
uuid.location = "56 4d ba 3e f5 d3 ea 05-8d cd 84 74 e4 2c d1 f8"
uuid.bios = "56 4d ba 3e f5 d3 ea 05-8d cd 84 74 e4 2c d1 f8"
scsi0:0.redo = ""
vmotion.checkpointFBSize = "134217728"
pciBridge0.pciSlotNumber = "17"
pciBridge4.pciSlotNumber = "21"
pciBridge5.pciSlotNumber = "22"
pciBridge6.pciSlotNumber = "23"
pciBridge7.pciSlotNumber = "24"
scsi0.pciSlotNumber = "16"
usb.pciSlotNumber = "32"
ethernet0.pciSlotNumber = "33"
ehci.pciSlotNumber = "34"
vmci0.pciSlotNumber = "35"
usb:0.present = "TRUE"
usb:1.present = "TRUE"
ethernet0.generatedAddressOffset = "0"
vmci0.id = "545851059"
usb:1.deviceType = "hub"
usb:0.deviceType = "mouse"

Ich hoffe ihr könnt meinem Kollegen weiterhelfen.
Vielen Dank.

Joe-A-Kim

Hallo,

hat die 2. VM auch 2 vCPUs, dann würde es knapp werden mit den Rechenzeiten, da die VMs erst an die Reihe kommen wenn 2 Cores auf dem Host frei sind. Das könnte auch schon jetzt passieren. Versuch' mal, auf 1 vCPU umzustellen.

edit: Braucht ihr in der VM wirklich das Floppy, die parallele und serielle Schnittstelle und das CD-Rom (als autodetected)?

- Die 1. VM hat nur eine CPU.
- Mit der anderen Hardware hast du recht, das kann man rausnehmen.

Zudem sollte ich noch erwähnen, dass es vorher ca. 2 - 3 Monate gut funktionierte.
Mich wundern halt die 4 GB für einen Prozess.

die 4 Gb fuer vmware-vmx koennten so konfiguriertsein - lad doch mal ein vmware.log bei ifile.it hoch - dann koennen wir mal sehen ob deinen vmdks schnell genug sind

Eventuell schlägt unter Windows auch der schon von der Linux-Version des VMserver2 bekannt Bug zu, daß trotz leerlaufender VM der zugehörigen Prozeß "vmware-vmx" eine stetig ansteigende Auslastung des Hosts erzeugt. Siehe auch Thread Hohe Load auf Host.
Eine Lösung ist dafür jedoch nicht direkt bekannt, außer auf den VMserver1.10 zu Upgraden...

Hi Ho.
Erstmal danke für die Antoworten. Hier die Logs:
http://ifile.it/2mjq8ul

So, dann die Frage wegen dem Update auf 1.10? Wir sind gerade auf 2.0.0 und das neuste ist ja 2.0.2
In dem anderen Post den du mir gelinkt hast hat er ja ein Update auf 2.0.2 gemacht und dann wurde es ein wenig besser.

Allgemein:
Denkt ihr, dassdas Windows Terminal Server Problem mit der ID333 mit dem Host-Problem zusammenhängen könnte?

Das Log hab ich mir noch nicht angesehen, aber das Problem ist zumindest unter Linux mit der 2.02 nicht behoben und daran wird sich durch die Abkündigung der VMserver im Januar 2010 auch nichts mehr ändern oder hattest du einen Supportvertrag abgeschlossen? Dann hättest du noch max bis zum 30.Juni 2011 eine Möglichkeit dazu...

Mit dem Downgrade auf den VMserver2 hättet ihr vielleicht noch warten sollen oder rechtfertigen mehrere Multicore-VMs auf dem Host, mehr als 3.6GByte RAM und USB2.0 in einer VM, den Verlust der Consolen-Anwendung unter halbseidenem Ausgleich per inzwischen weitestgehend zur Nichtfunktion verdammtem Browser-Plugin (nur IE6/7 und FF2-3.5) oder dem aufgrund einiger unvollständiger XML-Dateien auf dem VMserver2 ebenfalls nur bedingt nutzbaren Vi-/vSphere-Client bei VMs mit der v.HW-Version=7
Eine der kommenden WS-Versionen soll angeblich weitestgehend auch die Funktionalität des VMserver's mitbringen, aber es gibt dazu wie immer bei VMware keinen Zeitplan dazu.

Mh, denkst du also dass ich 1.0.8 installieren sollte, und dann wahrscheinlich weniger Probleme habe?
Muss ich irgendwas bei den VMs beachten? Tools vorher deinstallieren, dann erst unter 1.0.8 wieder installeiren.

.... warum denn 1.0.8, 1.0.10 ist die letzte Version, und die Tools kannst du lassen.

OK, also:
- 1.0.10 und die VMware Tools lassen.
- Unnötig virtuelle Hardware raus.

Auf jeden Fall ein Versuch wert.
Danke.
Zusätzlich noch irgendjemand eine Idee?

Hattest du der VM schon ein v.HW-Upgrade gegönnt oder habt ihr dort noch die v.HW-Version=4 beibehalten?

So, dachte ich geb mal ein Feedback:
Keine Lösung!
Nichts hatte etwas gebracht (naja, außer dass ich jetzt zig Überstunden mehr auf meinem Zettel habe).
Im Endeffekt habe ich also einen ESXi 4.1 installiert, die VMs rüberkonvertiert. Lief alles bestens. Dann hat Kollege noch ein paar seiner eigenen Windows-Probleme behoben, jetzt ist alles wunderbar und stabil.
Übrigens schon das 2. Mal, dass nur eine Migration auf ESXi erfolgreich war, macht ja aber auch Sinn^^

Vielen Dank für eure Hilfe!

Joe-A-Kim hat geschrieben:So, dachte ich geb mal ein Feedback:
Keine Lösung!
Nichts hatte etwas gebracht (naja, außer dass ich jetzt zig Überstunden mehr auf meinem Zettel habe).
Im Endeffekt habe ich also einen ESXi 4.1 installiert, die VMs rüberkonvertiert. Lief alles bestens. Dann hat Kollege noch ein paar seiner eigenen Windows-Probleme behoben, jetzt ist alles wunderbar und stabil.
Übrigens schon das 2. Mal, dass nur eine Migration auf ESXi erfolgreich war, macht ja aber auch Sinn^^

Vielen Dank für eure Hilfe!

Das ist nichts neues für mich. Der VMserver war eh nur als Anreiz für die ESX(i)-Server gedacht. Das bei Version 2 allerdings so an der Schraube im Bezug auf den VM-RAM gedreht wurde, hab ich nie verstanden. Die meisten Prozesse werden je nach Host-OS extrem langsam, wenn sie mehr als 2GB RAM en-bloc alloziieren. Für mich lautet daher die Devise, mehr als 2GB VM-RAM machen auf Host-based Virtualisierungslösungen (zumindest bei VMware) keinen Sinn. Das der Vmserver2 überhaupt bis zu 8GB VM-RAM bereitstellen kann, lag allein an der damaligen Code-Nähe zur WS6.5.2 und seitdem wurde ja nichts mehr aktualisiert.