Seite 1 von 1
vmdk Datei lässt sich nicht löschen
Verfasst: 10.11.2011, 07:55
von twin850
Hallo an Alle,
ich habe einen neuen Server mit ESxi 4.1 aufgesetzt und testweise einige virtuelle Maschinen erstellt um diverse Tests durchzuführen.
Nun wollte ich diese VM's löschen und den Server für den Produktiveinsatz vorbereiten. Allerdungs bleibt eine .vmdk einer VM auf dem Datastore und lässt sich nicht löschen.
Beim Löschveruch über den Datastorebrowser kommt die Meldung "VON DATEI /VMFS/VOLUMES/........./w2k8.vmdk verursachter Fehler"
Umbennen kann man die Datei jedoch.
Ein Versuch die Datei an der Konsole mittels rm zu löschen scheitert mit der Meldung "rm: cannote remove "w2k8.vmdk": No Such File or directory"
Grundsätzlich kann ich den Server auch noch mal aufsetzen das es ja nur eine Testumgebung war. Würde aber schon gerne wissen was da passiert ist und wie man diese Datei löschen kann.
Danke für Eure Hilfe.
Re: vmdk Datei lässt sich nicht löschen
Verfasst: 10.11.2011, 11:29
von rprengel
twin850 hat geschrieben:Hallo an Alle,
ich habe einen neuen Server mit ESxi 4.1 aufgesetzt und testweise einige virtuelle Maschinen erstellt um diverse Tests durchzuführen.
Nun wollte ich diese VM's löschen und den Server für den Produktiveinsatz vorbereiten. Allerdungs bleibt eine .vmdk einer VM auf dem Datastore und lässt sich nicht löschen.
Beim Löschveruch über den Datastorebrowser kommt die Meldung "VON DATEI /VMFS/VOLUMES/........./w2k8.vmdk verursachter Fehler"
Umbennen kann man die Datei jedoch.
Ein Versuch die Datei an der Konsole mittels rm zu löschen scheitert mit der Meldung "rm: cannote remove "w2k8.vmdk": No Such File or directory"
Grundsätzlich kann ich den Server auch noch mal aufsetzen das es ja nur eine Testumgebung war. Würde aber schon gerne wissen was da passiert ist und wie man diese Datei löschen kann.
Danke für Eure Hilfe.
Hallo,
ich würde die Platten mal testen und mit einem Burnin-Test prüfen ob die Hardware ok ist.
Nicht das die Platte ein Problem hat oder ein Kabel defekt ist.
Gruß
Verfasst: 10.11.2011, 11:41
von twin850
Nun ja, es ist ein Fujitsu Primergy TX300S6 mit LSi Raidcontroller + BBU und 5 SAS Platten im Raid5 Verbund + 1 Hotspare. Der Controller meldet alles sei in Ordnung.
Ich sollte jedoch erwähnen, das ich während der Testversuche eine Platte aus dem Raidverbund gezogen habe um zu sehen ob die Hotspare einspringt. Danach wieder die Platte rein, hat auch wieder ein Copyback gemacht. Ich teste das eigentlich immer um zu sehen das im Ernstfall diese Mechanismen auch funktionieren. Und eigentlcih sollte ein Raid Controller genau das machen.
Ich kann auch weiterhin neue VM erstellen und wieder löschen, nur die eine .vmdk macht Probleme.
Wenn es wirklich ein Problem des Raid-Verbundes sein sollte wäre das schon bedenklich. Will mir dann gar nicht ausmalen was im Ernsfall passieren könnte.
Gruß
Verfasst: 10.11.2011, 11:44
von ideFix
Ich glaube nicht das es ein HW- Defekt ist.
Welche Dateien befinden sich noch im Verzeichnis der VM?
Bitte per ssh/console nachschauen, der DatastoreBrowser ist in dieser Hinsicht nicht immer ganz ehrlich

Verfasst: 10.11.2011, 11:49
von twin850
Es befindet sich nur noch diese w2k8.vmdk im Verzeichnis der virtuellen Maschine. Alle anderen Dateien wurden gelöscht als ich die VM aus der Bestandsliste entfernt habe.
Geprüft via SSH/Putty.
Verfasst: 11.11.2011, 08:02
von twin850
Hallo zusammen,
hat noch irgend jemand ein Idee ? Sonst mach ich den Server heute platt.
Vielleicht kann ma ja mit den VMFSTOOLS etwas erreichen ? Da bin ich aber nicht so fit.
Gruß
Verfasst: 11.11.2011, 09:46
von JustMe
Wie waere es denn mal mit einem 'ls -l' auf der Kommandozeile? Dann haette die Raterei, was denn nun tatsaechlich im Datastore vorliegt, ein Ende
Ansonsten:
Einfach eine Platte aus dem Gehaeuse zu ziehen, ist NICHT dasselbe wie ein Ausfall derselben. Bevor eine Platte aus dem Gehaeuse entfernt werden darf, muss sie beim Controller abgemeldet sein. Das heisst bei einem Fujitsu Primergy, dass die Fehler-LED an der Platte an sein muss, und der Controller sie als "Failed" oder "Fehlerhaft" (oder so) fuehrt.
Eine unkonfigurierte Platte kann allerdings einfach entfernt werden, weil hier sichergestellt ist, dass der Controller nicht gerade darauf zugreift. Bei allen konfigurierten Platten, noch dazu bei laufendem Betriebssystem, wuerde ich saemtliche Daumen und grossen Zehen druecken...
Verfasst: 11.11.2011, 10:07
von twin850
Hallo,
Ein "ls -l" liefert leider auch nicht mehr.
Code: Alles auswählen
/vmfs/volumes/4eba56af-f540e652-1512-001999b8aedf/w2k8 # ls -l
-rw------- 1 root root 12884901888 Nov 9 11:51 w2k8.vmdk
/vmfs/volumes/4eba56af-f540e652-1512-001999b8aedf/w2k8 #
und
Code: Alles auswählen
/vmfs/volumes/4eba56af-f540e652-1512-001999b8aedf/w2k8 # rm w2k8.vmdk
rm: cannot remove 'w2k8.vmdk': No such file or directory
/vmfs/volumes/4eba56af-f540e652-1512-001999b8aedf/w2k8 #
Bezüglich des Plattenziehen: Natürlich ist das nicht die elgegante Variante, aber nichts anderes Passiert doch wenn eine Platte ohne Vorankündigung plötzlich ausfällt ? Da hat der Controller doch auch keine Zeit diese erst als Fehlerhaft zu markieren. Oder verstehe ich da was total falsch ?
Gruß
Verfasst: 11.11.2011, 11:44
von JustMe
Ist im zweiten Code-Schnipsel beim rm das w2k8.vmdk per AutoComplete mit Tab angehängt worden, oder wurde es Buchstabe fuer Buchstabe eingetippt?
Was passiert, wenn man im darueberliegenden Verzeichnis 'rm -rf w2k8' eintippt?
Vielleicht haengt da irgendein unsichtbares Zeichen dran.
Zum Plattenziehen:
Selbstverstaendlich gibt es genau diese EINE Moeglichkeit, dass die komplette Platte sich "on-the-fly" vom Bus abhaengt. Aber genau dann ist die Error-Recovery des Controllers einigermassen unsicher (auch, wenn das unbeabsichtigt passiert). Es gibt aber sehr viel mehr Faelle (auf die dann der Controller mit seiner Firmware vorbereitet ist), wo die Platte Fehler bei der Datenuebertragung ZURUECKMELDET (Medienfehler, Transferfehler, etc.pp.).
Und wenn man nur mal testen will, muss es ja nicht gleich der Worst Case sein...
Wie schon geschrieben: Das geht bestimmt in der Mehrzahl der Faelle gut, aber laut Murphy kommt es dann bei den wichtigsten Daten irgendwann zum Crash.
Verfasst: 11.11.2011, 13:08
von continuum
@ twin850
kannst du mir einen Gefallen tun und folgendes ausprobieren ?
leg eine neue VM an
entfern sie aus dem Inventory
editier die vmx und trag statt der neuen vmdk die problem-vmdk mit vollem Pfad ein
fueg die VM wieder dem Inventory hinzu
starte die VM
poste das vmware.log hier
Verfasst: 11.11.2011, 14:20
von deathrow
Ich würde mal die Agents neu starten, da steht sicher noch ein Prozess drauf...