VMware-Forum

wer derzeit am ueberlegen ist auf VMFS 5 upzudaten sollte sich das 3 mal ueberlegen.

Ich sehe derzeit eine alarmierende Zunahme eines speziellen Fehlers - in vmware.logs taucht der so auf

DISKLIB-VMFS : "/vmfs/volumes/4ebc15b1-f6959917-842f-0019b9eebb39/SBSSERVER.spoka.local/SBSSERVER.spoka.local-flat.vmdk" : failed to open (Invalid argument): AIOMgr_Open failed. Type 3

Ich hatte gedacht das problem betraefe nur VMFS 3 unter ESXi 4.1 - aber es taucht auch unter ESXi 5 mit VMFS 5 auf.
Hat man dieses problem kann man die VM und evtl. auch das Datastore abschreiben denn man kann diese VM weder kopieren, noch konvertieren noch loeschen ....

Bei VMFS 3 kann man wenigstens die Dateien noch retten mit Hilfe einer Linux LiveCD.
Bei VMFS 5 ist man am A....

http://communities.vmware.com/thread/335917?tstart=0

Hallo Ulli,

Du schreibst in den Communities es ist ein echtes Problem, in welchem Umfang ist das aufgetreten?
Was sagt denn VMware selbst dazu?
Gruß Christian

Hallo Zusammen

Mir ist das auch aufgefallen
Habe auf 2 unterschiedlichen Servern genau dieses Verhalten beobachtet.
Konnte zwar dank DPM 2010 mit BareMetal recovery die Disk wieder zurückholen.
Hat aber doch 2 Stunden gefressen.

Nach der formatierung trat der Fehler nicht mehr auf.

war aber alles VMFS3 unter ESXi 4.1U1
BS war Windows Server 2008 R2 SP1

Bei mir war erst eine Maschine betroffen, Konnte nicht mehr per vMotion verschoben werden.
Dann warens plötzlich 4 Maschinen die nicht mehr wollten.

ist aber scho 1 Monat her.
seit dem keine Probleme mehr

continuum hat geschrieben:Bei VMFS 3 kann man wenigstens die Dateien noch retten mit Hilfe einer Linux LiveCD.
Bei VMFS 5 ist man am A....

http://communities.vmware.com/thread/335917?tstart=0

Die Tools auf github (https://github.com/glandium/vmfs-tools) sind um einiges aktueller als die im Ubuntu Repository. Konnte diese das VMFS-5 auch nicht lesen?

Dort enthalten ist ja auch das Tool fsck.vmfs (VMFS file system check utility). Könnte der Datastore mit dem VMFS irgendwie korrupt sein?

EDIT:

Wer es mal versuchen möchte:

Download 64Bit
Download 32Bit

Kompiliert aus den Sourcen vom 24.10.2011

Zum installieren:
dpkg -i <dateiname>

Passiert dies Grundsätzlich nur auf migrierten VMFS Volumes
sprich bei einem Upgrade von ESXi 4.x nach ESXi 5.x

Oder auch bei Neu-Installationen von ESXi 5.x wo die Volumes nicht migriert werden
sondern direkt mit VMFS 5.x formatiert werden.

Ich habe bis jetzt ca 40 neue produktive ESXi 5 installiert und bei allen Volumes
hat es bis jetzt keine Probleme gegeben.
Ich habe bis jetzt auch keine Updates von ESXi 4.x nach ESXi 5.x durch geführt
sondern ich wähle immer den Weg:
> Von der Konfiguration PrintScreens erstellen und dann neu installieren
> VMs auf andere Volumes/Stores moven und dann die Volumes komplett neu erstellen mit VMFS 5.x so dass diese auch mit 1MB Block Size formatiert werden da diese vorher meistens 4MB oder 8MB Block Size hatten.

Gruss Rene

So ich habe gerade erfahren dass die VMFS Entwickler sich der Sache angenommen haben.

Ich halte euch auf dem laufenden

Hi Ulli, jou, die Bande ist dran, hab´s gerade gesehen (endlich)
VG Jörg

Ja - ich hatte gerade einen VMFS engineer am Telefon - die gucken sich jetzt den letzten Fall an - auch ohne das ein SR dafuer aufgemacht werden muss.

Der letzte Fall war uebrigens von gestern - siehe
http://vmware-forum.de/viewtopic.php?t=24730

@Ulli:
Hast du von 3 auf 5 migriert, oder eine neue VMFS5-LUN erstellt?

Eine Migration nach 5 ist ja nur ein modifiziertes 3er soweit ich gehört habe...

der aktuelle Fall war ein frisch aufgesetzter ESXi 5

Sind die vmware.log Files von den VM´s gemeint die am Datastore liegen?
Oder muss ich beim ESXi suchen in \var\log\vmkernel

Mit welchen Tools scannt ihr die Files? Die am Datastore ist ja permanent geöffnet wenn die VM läuft.

Da ich in nächster Zeit auf ESXi 5 umsteigen möchte habe ich jetzt ganz leichtes Unwohlsein in der Magengegend.

Mit welchen Tools scannt ihr die Files? Die am Datastore ist ja permanent geöffnet wenn die VM läuft.

Notepad++ macht sich sehr gut dafür und geöffnete Datei lassen sich häufig trotzdem noch kopieren.

Betrifft das eigentlich VMFS5 generell, also storageunabhängig, oder sind da nur bestimmte Speicherarten (FC, iSCSI, lokaler Storage, ...) betroffen?

Mit FC habe ich selber jetzt noch keine Probleme gesehen - das liegt aber wohl eher daran dass Firmen die FC einsetzen auch Geld fuer Backups ausgeben und von daher bei solchen Problemen eh nicht lange fackeln und Backups einspielen.

continuum hat geschrieben:Mit FC habe ich selber jetzt noch keine Probleme gesehen - das liegt aber wohl eher daran dass Firmen die FC einsetzen auch Geld fuer Backups ausgeben und von daher bei solchen Problemen eh nicht lange fackeln und Backups einspielen.

Das hört sich gut an! Dann werde ich wohl LUN für LUN leer räumen und neu mit VMFS5 formatieren.

@Uli: In den Vmware Communities gibts ja diesbezüglich noch nichts neues,
hast du evtl. schon weitere Informationen von Vmware erhalten?

Ich habe hier z.Zt. zwei 4.1er Cluster laufen und die Planungen einen 3.5er Cluster auf 5 zu heben laufen auch. Selbst habe ich
das beschriebene Problem zwar noch nicht sehen "dürfen", und es wäre schön wenn es dabei bleibt.

Gruß
Stefan

Ich habe das Problem jetzt seit ca 2 Monaten nicht mehr gesehen.

Mach ordentliche backups dann wird alles gut - auch mit VMFS 5

Hallo zusammen,

wir sind seit Januar mit VMFS5 unterwegs. (über 100VM´s, 8 Datastore, FC Storage)

Keine Probleme bisher

Aus solchen und anderen Gründen bin ich froh nicht mehr mit vmfs zu arbeiten sondern nur noch mit den vmdks auf nfs. Sicher, hat auch Vor- und Nachteile..