Consolidation von Vm schlägt fehl

[Gad]

Hi,

eine meiner VM meldet sich mit "Virtual Machine disks Consolidation is needed"

Wenn ich versuche eine Consolidierung durchzuführen kommt bei etwa 25% die Fehlermeldung "Unable to Access file <unspecified filename> since it is locked"

Ich habe versucht einen neuen Snapshot anzulegen und dann mit Delete All zu löschen, aber das Problem tritt danach immer noch auf.

Die VM hat keine Snapshots im Snapshot Manager, die zweite Festplatte verweist jedoch auf [SVC_SAS2] srv-name/srv-name_1-000022.vmdk

Jemand ne Idee ich noch tun kann um das Problem zu lösen?

[Dayworker]

Kannst du die VM runterfahren?

[Gad]

Kannst du die VM runterfahren?

Frühestens morgen früh.

Edit: Ich hoffe nicht, das der Fehler darauf hindeutet das das System jederzeit ausfallen kann, dann kann ich das System natürlich auch sofort ausschalten, dann ist der geplante Ausfall besser als der unkontrollierte.

[continuum]

Hallo
das Problem kenne ich - es kommt in unterschiedlichen Schweregraden vor - von "behebbar ohne Reboot der VM" bis hin zu "Datastore still legen und Recovery mit Linux-CD"

Falls du dies heute nachmittag siehst - oder heute abend - ruf mal eben an.

Ansonsten lad alle vmware*.logs der VM runter und grep alle logs auf den String "AIOMgr_Open failed, Type 3"

Damit kann ich dann abschätzen ob es ein einfacher oder ein schwerer Fall ist.


Ich tippe mal die naheliegenden Rettungsversuche hast du schon gemacht ?

1.vmkfstools -i kaputt-00000x.vmdk heile.vmdk
2. hot-convert mit VMware Converter
3.VM aus Inventory entfernen - alle automatischen Backuptools abstellen - ESXi-Host neustarten - dann nach neustart direkt Option 1

Wenn Option 1 nicht funktioniert und einen I/O error meldet dann hilft es manchmal bei heruntergefahrener VM einen weiteren snapshot von Hand zu erstellen und den zu clonen.

Meine Nummer: 0298fünf 90874zwei

[Dayworker]

Poste mal bitte eine komplette Verzeichnisauflistung per "ls -alh" und den Inhalt der VMSD-Datei sowie verlinke das soweit vorhanden, ungekürzte "vmware.log" auf einen Freehoster.


[edit]
War ja klar, daß der Ulli bei sowas direkt anspringt...

[continuum]

Na ja - die letzten Wochen war ich nur selten hier - das ich gerade mal einen nachmittag etwas Luft habe ist eher die Ausnahme in der letzten zeit

[irix]

Besagte Meldung kann aber auch banale Gruende haben. Wir hatten frueher das Problem als wir VMs vor der Sicherung ausgeschaltet hatten das DRS die VM auf einem anderen Host starten wollte aber ein anderer Host noch den Lock drauf hatte. Auch dann kommt besagte Meldung.

Aber die hohe Anzahl -0000022 deutet eigentlich in Richtung Snapshotkatastrophe.

Gruss
Joerg

[mbreidenbach]

Es kommt manchmal vor daß ein Backupserver noch irgendwas gelockt hat - dann kann es helfen den Backupserver mal runterzufahren und dann die Konsolidierung zu versuchen.

[Gad]

Guten Morgen,

Danke für die Hinweise

es war der BackupServer, nachdem ich den heute früh auch abgeschaltet hatte, ging die Konsolidierung.

>Ich tippe mal die naheliegenden Rettungsversuche hast du schon gemacht ?
>1.vmkfstools -i kaputt-00000x.vmdk heile.vmdk

Reicht der genannte Befehl oder muss man die neue vmdk dann noch irgendwie umbenennen bzw. der VM sagen das das jetzt die neue Datei ist? Hab leider mit der Console noch nicht viel gemacht, arbeite fast ausschließlich mit der GUI. Nur interessehalber, falls ich es doch mal benötigen sollte.

[Dayworker]

Wenn du keine Meldung mehr über die Consolidierung bekommst, brauchst den Rettungsversuch eigentlich nicht. Falls du die VMDK trotzdem mal über die "vmkfstools" überprüfen willst, ändert sich der VMDK-Name ja auf "heile.vmdk" und du kannst entweder den VMDK-Eintrag in der VMX-Datei passend abändern oder du benennst die VMDK einfach über "vmkfstools -E heile.vmdk alter-name.vmdk" wieder um.


Ich würde in jedem Fall aber den Backup-Server im Auge behalten. Im Normalfall sollten Snapshots nach dem Backup wieder aufgelöst werden. Wenn du also bereits 22 Snapshots im Verzeichnis rumliegen hattest, dürfte das Problem je nach Backuphäufigkeit schon länger bestanden haben.