VMware-Forum

Hallo Forum,

ich habe einen Server (Windows Server 2K3 SBS) von einem physikalischen PC per vmware converter virtualiesiert.
Bei der virtualiesierung habe ich beide Partitionen der Festplatte vergrößert. Bei der Datenpartition hat das ohne Probleme funktioniert bei der Systempartition leider nicht.

Die Systempartition wird jetzt nur noch mit einer größe von 1GB angezeigt.
In der Datenträgerverwaltung steht sie allerdings mit den gewünschten 30 GB drin.

Der freie Speicher beträgt 500MB. Möchte man mehr auf die Partition schreiben kommt die Fehlermeldung das der Datenträger voll ist.
Komisch ist das schon einzelne Ordner wie z.B. der Windows Ordner größer 1GB sind und unter Eigenschaften auch so angezeigt wird obwohl die Partion angeblich nur 1GB groß ist.

Die .vmdk Datei ist variable konfiguriert und beträgt zur Zeit 160 von max 250GB.

Kann mir jemand helfen wie ich der Systemplatte wieder auf die größe von 30 GB bekommen?

Danke schon mal im vorraus.

Gruß R-EC

Der Gast ist ein Windows? Klingt nach einem Fehler im Dateisystem.

Lass mal m Gast eine entsprechende Datenträgerüberprüfung (wie heißt das unter Windows... chkdsk oder scandisk) laufen. Ich schätze der freie Speicherplatz ist fehlerhaft im Dateisystem hinterlegt.

Die gleichzeitige Konvertierung und Änderung der Plattengröße geht häufiger mal daneben, besonders wenn die Systemplatte beteiligt ist. Speziell den SBS W2k3 mit seinem DC und AD sollte man besser Offline konvertieren, also per Moa oder BartPE von CD starten und dann konvertieren. Das Ändern der Systemplattengröße macht man dann halt erst im Anschluß in zwei Schritten.

In deinem Fall würde ich dir vorschlagen, die VM erstmal aus zu lassen und auf Antwort unseres VMX/VMDK-Guru namens Ulli aka "continuum" zu warten.

Schon mal besten Dank für die Antworten.

Ich werd beides mal ausprobieren.

Die Systempartition wird jetzt nur noch mit einer größe von 1GB angezeigt.
In der Datenträgerverwaltung steht sie allerdings mit den gewünschten 30 GB drin.

Kannst du dass mal etwas genauer erklaeren ?

Hallo,

es ist so das die Systemplatte in er Datenträgerverwaltung mit den gewünschten 30GB drin steht. Öffnet man die Eigenschaften der Festplatte dann wird die Größe nur mit 1GB angezeigt.
Diese Größe scheint auch ausschlaggebend zu sein, denn wenn Daten auf die Platte kopiert werden sollen, welche größer als die freien 500MB sind dann kommt die Fehlermeldung das der Datenträger voll ist.

Inzwischen hab ich schon mehrere versuche gestartet die Platte wieder herzurichten:

defrag > keine Besserung
checkdisk/scan disk beim booten > keine Besserung

virtuelle maschine mit scronis von cd gebootet > größe der Systempartition geändert mit acronis dadurch wurde hard ware neu erkannt von system nach systembedingten neustart > ebenfalls keine besserung

für weitere anregung wär ich wirklich dankbar.

Danke

R-EC

poste mal ein vmware.log besagter VM

hier die aktuellste .log Datei der entsprechenden vm

attachements sind nocht moeglich - lad bei http://ifile.it oder sonst wo hoch

So das Attachment liegt hier

http://ifile.it/pjkv2zb

Das Problem tritt mit dem Converter anscheinend öfter mal auf und ist mir auch immer nur von der System-Platte bekannt. Daher sollte man Konvertierungen auch immer Schrittweise erledigen. Schritt1 wäre die reine Konvertierung und im Schritt2 werden die Datenträger auf die gewünschte Größe aufblasen.
Dir bleiben jetzt in meinen Augen nur die 2 Möglichkeiten entweder die Datenträgerverwaltung anzuschmeißen und dort auch die Systemplatte zu vergrößern (was dir vermutlich nicht gelingen wird, da die Platte ja schon die Schein-Größe von 30GB hat) oder mit einem externen Partitionierungsprogramm die Partition entsprechend hinzubiegen.
Wenn du Glück hast, kann der Converter in einer Rekonfiguration der VM die Datenträgergröße auch hinbiegen.

wenn ich mir das log so ansehe .... fuer meinen Geschmack ist die vmdk kaputt.

Es werden jede menge disklib Meldungen angezeigt - das ist ein sehr schlechtes Zeichen.

Dayworker hat geschrieben:Wenn du Glück hast, kann der Converter in einer Rekonfiguration der VM die Datenträgergröße auch hinbiegen.

Was meinst du damit?

Die physikalische Maschine nochmal virtualisieren oder die virtuelle Maschine über den Converter versuchen reparieren zu lassen?

R-EC hat geschrieben:Jan 07 10:51:33.625: vmx| DISKLIB-LIB : numIOs = 48200000 numMergedIOs = 3360909 numSplitIOs = 80166
Jan 07 14:36:32.220: vcpu-0| DISKLIB-LIB : numIOs = 48250000 numMergedIOs = 3367943 numSplitIOs = 80450

Jetzt wo ich mir dein Log nochmal ansehe und mit meinen vergleiche...

Log1 hat geschrieben:Jan 04 06:38:03: vcpu-0| DISKLIB-LIB :numIOs = 6500000 numMergedIOs = 0 numSplitIOs = 0
Jan 08 15:35:31: vmx| DISKLIB-LIB :numIOs = 6700000 numMergedIOs = 0 numSplitIOs = 0

Log2 hat geschrieben:Jan 01 14:30:12: vcpu-0| DISKLIB-LIB :numIOs = 6750000 numMergedIOs = 0 numSplitIOs = 0
Jan 07 23:27:25: vmx| DISKLIB-LIB :numIOs = 6900000 numMergedIOs = 0 numSplitIOs = 0

Log3 hat geschrieben:Dec 08 00:18:30: vcpu-0| DISKLIB-LIB :numIOs = 7250000 numMergedIOs = 0 numSplitIOs = 0
Jan 09 00:10:14: vmx| DISKLIB-LIB :numIOs = 8550000 numMergedIOs = 0 numSplitIOs = 0

Log4 hat geschrieben:Jan 02 09:18:59: vcpu-0| DISKLIB-LIB :numIOs = 12950000 numMergedIOs = 0 numSplitIOs = 0
Jan 09 05:58:02: vmx| DISKLIB-LIB :numIOs = 13200000 numMergedIOs = 0 numSplitIOs = 0

Log5 hat geschrieben:Dec 10 17:33:08: vcpu-0| DISKLIB-LIB :numIOs = 7350000 numMergedIOs = 0 numSplitIOs = 0
Jan 09 03:46:13: vmx| DISKLIB-LIB :numIOs = 8650000 numMergedIOs = 0 numSplitIOs = 0

...dürfte bei dir echt was daneben laufen. Meine Ausschnitte stammen von VMs, die seit Mitte August laufen und bei weitem nicht deine Werte erreichen. Die Log3-5 sind dabei Volllast-VMs im 24/7-Betrieb und schreiben alle 10min ihre Berechnungen auf den Datenträger. Auffällig sind bei dir die hohen Werte für numMergedIOs & numSplitIOs. Ich hab leider keine Hinweise bei VMware zu deren Bedeutung gefunden.

Ich würde an deiner Stelle jetzt 2 Dinge machen. Erstens die vorhandene VM einfach nochmal durch den Converter jagen, vielleicht erledigen sich ja damit deine Grössen- und Hochwert-Probleme und wir erhalten vielleicht einen Anhaltspunkt zur Bedeutung der Hochwerte. Zweitens die phys.Maschine zur Sicherheit nochmal Virtualisieren und erst nach einem erfolgreichen VM-Start und -Shutdown die v.HDDs aufblasen.

R-EC hat geschrieben:Dec 21 22:09:51.040: vmx| DISK: OPEN scsi0:0 'E:\Virtual Machines\server01.dom-k.local\server01.dom-k.local.vmdk' persistent R[]
Dec 21 22:09:51.823: vmx| DISKLIB-DSCPTR: Opened [0]: "server01.dom-k.local.vmdk" (0xa)
Dec 21 22:09:51.823: vmx| DISKLIB-LINK : Opened 'E:\Virtual Machines\server01.dom-k.local\server01.dom-k.local.vmdk' (0xa): monolithicSparse, 524329470 sectors / 250.0 GB.
Dec 21 22:09:51.823: vmx| DISKLIB-LIB : Opened "E:\Virtual Machines\server01.dom-k.local\server01.dom-k.local.vmdk" (flags 0xa).
Dec 21 22:09:51.823: vmx| DiskGetGeometry: Reading of disk partition table
Dec 21 22:09:51.836: vmx| DISK: OPEN 'E:\Virtual Machines\server01.dom-k.local\server01.dom-k.local.vmdk' Geo (32638/255/63) BIOS Geo (32638/255/63) freeSpace=25881 MB, lsilogic

Die hohen Werte für numMergedIOs & numSplitIOs könnten natürlich auch mit der Einstellung "monolithicSparse" deiner v.HDD zusammenhängen. Da ich prinzipiell nur v.Disks vom Typ "twoGbMaxExtentFlat" also Preallocated in 2GB-Häppchen verwende, bin ich da überfragt. Ulli weiß da bestimmt Rat.

ODER
Da die Version 2.00 bekanntermaßen einige Fehler hatte, installierst du testweise mal die aktuelle Version 2.02

Meiner Erfahrung nach sind vmdks die sowas melden reif fuer den Muell - man kann durchaus noch Daten davon retten - aber eine neue VM auf so einer vmdk aufzubauen ist aehnlich wie mit einem Auto ohne TUEV und abgefahrenen Reifen eine Polar-expedition zu starten

Fang besser nochmal neu an

Hallo,

besten dank für eure Hilfe.
Hab die fehlerhafte einstellung gefunden und behoben.

Auf der Platte war ein Kontingent eingerichtet welches die Platte für jeden Benutzer auf 1 GB begrenzt.

Gruß

R-EC

Hast du die Platte trotzdem nochmal neu erstellt? Das von Ulli monierte Problem ist damit ja trotzdem noch nicht gelöst.