Nach einem Missglücktem Snapshot hab ich das system ( SBS Server 2008 64 ) kaltgestartet ( hat nicht mehr reagiert )
Nun hab ich folgendes Problem, start bricht mir mit folgendem Fehler ab:
msg.vmxaiomgr.retrycontabort.rudeunplug:Operation on file "/var/lib/vmware/Virtual Machines/SBS/ATMIKOSV01neu.miko.local-000003-s086.vmdk" failed. If the file resides on a remote file system, please make sure your network connection and the server where this disk resides are functioning properly. If the file resides on removable media, reattach the media. Choose Retry to attempt the operation again. Choose Abort to terminate this session. Choose Continue to forward the error to the guest operating system.
ICh hoffe ihr könnt mir helfen ansonsten hab ich mehr als ein Problem
Mfg Andreas
Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!
Riesenproblem beim Start
-
continuum
- UNSTERBLICH(R.I.P.)
- Beiträge: 14759
- Registriert: 09.08.2003, 05:41
- Wohnort: sauerland
- Kontaktdaten:
Hi
wenn es eilig ist schick mir ne PN mit Telefonnummer - dann melde ich mich morgen.
Ansonsten brauchen wir eine Dateiliste
die kleinen vmdks und die vmware.logs
am besten alles zippen und bei http://ifile./it hochladen
wenn es eilig ist schick mir ne PN mit Telefonnummer - dann melde ich mich morgen.
Ansonsten brauchen wir eine Dateiliste
die kleinen vmdks und die vmware.logs
am besten alles zippen und bei http://ifile./it hochladen
-
stefan.becker
- Guru
- Beiträge: 2237
- Registriert: 21.09.2005, 00:12
-
Dayworker
- King of the Hill
- Beiträge: 13561
- Registriert: 01.10.2008, 12:54
- Wohnort: laut USV-Log am Ende der Welt...
Warum startest du eine VM mehrfach, wenn diese schon beim ersten Start ihre Probleme hatte 
Der VMserver speichert immer nur die letzten 4 Log's und deine enthalten alle den Eintrag mit "/var/lib/vmware/Virtual Machines/SBS/ATMIKOSV01neu.miko.local-000003-s086.vmdk", da die Datei genau Null Byte groß ist.
Eine VMDK-Dateigrösse von 320KByte ist bei neu erstellten vDisks vom Typ 'Sparse-Disk' (mitwachsend) auch normal.
Hattest du eigentlich schon etwas in der VM gemacht?? In Summe 212MByte sind eindeutig zu wenig selbst für W2k und erst recht für einen SBS. Die VM enthält daher vermutlich keinerlei Daten mehr.
Je nach Größe des Snapshots dauert es von Minuten bis zu mehreren Stunden um diesen in die vorhandenen vDisks einzupflegen. Mit dem harten Abschalten hast du dir in jedem Fall keinen Gefallen getan.
Beim Durchsehen der Logs fielen mir neben den Sparse-Disks mit Snapshot und ~512GByte Größe auch noch mehrere völlig widersprüchliche Einträge auf:
Zusammen mit den an den SBS vergebenen "Oct 07 23:35:51.168: vmx| DICT memsize = 7000" bzw "Oct 07 23:06:16.338: vmx| DICT memsize = 2500" macht das aber eh nur wenig Sinn. Der VMserver kennzeichnet spätestens ab 2048MByte VM-RAM diesen zum größten Teil als auslagerungsfähig und behält je nach OS nur noch ~500MByte des VM-RAMs im Arbeitsspeicher vor. Selbst auf der kostenpflichtigen Workstation bis zur Version 7.1.4 (einige Versionen auch schon wesentlich früher) sorgen daher mehr als 2GByte vRAM pro VM nur für mehr Swapping auf dem Host und das unabhängig davon ob Linux oder Windows als Host-OS zum Einsatz kommt.
Linux als Host-OS verschlimmert die Lage nur noch weiter, da alle Linux-Versionen des VMserver2 mit einem üblen Auslastungsbug behaftet sind. Trotz leerlaufender VMs steigt deren Last auf dem Host immer weiter an. Siehe auch den Thread Hohe Load auf Host.
Der VMserver speichert immer nur die letzten 4 Log's und deine enthalten alle den Eintrag mit "/var/lib/vmware/Virtual Machines/SBS/ATMIKOSV01neu.miko.local-000003-s086.vmdk", da die Datei genau Null Byte groß ist.
Eine VMDK-Dateigrösse von 320KByte ist bei neu erstellten vDisks vom Typ 'Sparse-Disk' (mitwachsend) auch normal.
Hattest du eigentlich schon etwas in der VM gemacht?? In Summe 212MByte sind eindeutig zu wenig selbst für W2k und erst recht für einen SBS. Die VM enthält daher vermutlich keinerlei Daten mehr.
Je nach Größe des Snapshots dauert es von Minuten bis zu mehreren Stunden um diesen in die vorhandenen vDisks einzupflegen. Mit dem harten Abschalten hast du dir in jedem Fall keinen Gefallen getan.
Beim Durchsehen der Logs fielen mir neben den Sparse-Disks mit Snapshot und ~512GByte Größe auch noch mehrere völlig widersprüchliche Einträge auf:
Du reservierst (*2) 7228MByte für VMware, gestattest aber die (*1) 50%ige Auslagerung des von den VMs genutzten RAMs und verbietest gleichzeitig sowohl die variable Anpassung des für (*3) VMware reservierten als auch den für die (*4) VMs genutzten Arbeitsspeichers.Oct 07 23:06:16.338: vmx| DICT prefvmx.minVmMemPct = 50 (*1)
Oct 07 23:06:16.338: vmx| DICT prefvmx.allVMMemoryLimit = 7228 (*2)
Oct 07 23:06:16.338: vmx| DICT prefvmx.useRecommendedLockedMemSize = TRUE (*3)
Oct 07 23:06:16.338: vmx| DICT mainMem.partialLazySave = TRUE
Oct 07 23:06:16.338: vmx| DICT mainMem.partialLazyRestore = TRUE
Oct 07 23:06:16.338: vmx| DICT MemTrimRate = 0 (*4)
Zusammen mit den an den SBS vergebenen "Oct 07 23:35:51.168: vmx| DICT memsize = 7000" bzw "Oct 07 23:06:16.338: vmx| DICT memsize = 2500" macht das aber eh nur wenig Sinn. Der VMserver kennzeichnet spätestens ab 2048MByte VM-RAM diesen zum größten Teil als auslagerungsfähig und behält je nach OS nur noch ~500MByte des VM-RAMs im Arbeitsspeicher vor. Selbst auf der kostenpflichtigen Workstation bis zur Version 7.1.4 (einige Versionen auch schon wesentlich früher) sorgen daher mehr als 2GByte vRAM pro VM nur für mehr Swapping auf dem Host und das unabhängig davon ob Linux oder Windows als Host-OS zum Einsatz kommt.
Linux als Host-OS verschlimmert die Lage nur noch weiter, da alle Linux-Versionen des VMserver2 mit einem üblen Auslastungsbug behaftet sind. Trotz leerlaufender VMs steigt deren Last auf dem Host immer weiter an. Siehe auch den Thread Hohe Load auf Host.
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 9 Gäste