Sziasztok,
Adott egy ESX 6.7 host ami iSCSI -n csatlakozik egy NAS -hoz, ezen a VMFS "storage" -on vannak a VM -ek, az egyik VM torolve lett, de maradt utana egy xy_1-flat.vmdk file, amit nem lehet torolni, sokmindent probaltam mar, shellbol rm -f stb...ez meg annyira nem is zavarna, ha a file nem 1,5TB -ot foglalna...sajnos a torolt elem egy file szerver volt, ezert a nagy meret...a file -t nem lockolja semmi, az ESX hoszt es a NAS is ujra lett mar inditva.
Esetleg valaki talalkozott mar ilyennel? Ha igen, hogyan oldotta meg? Neten sokmindent talaltam, de egyelore egyik megoldas sem jott be... :(
ilyeneket kapok:
rm -f /vmfs/volumes/DataStore/xy_1.vmdk
rm: can't remove '/vmfs/volumes/DataStore/xy_1.vmdk': Invalid argument
vmkernel.log
[type 1] clusterNum: 3755 invalid inUseResources: 512 rcMeta inUseResources: 5082025-02-04T21:26:35.987Z cpu13:2113214)WARNING: FS3J: 3132: 'DataStore': Aborting txn (0x430c122762f0) callerID: 0xc1d0000c due to inconsistent txn resources: Invalid metadata
[type 1] clusterNum: 3755 invalid inUseResources: 512 rcMeta inUseResources: 5082025-02-04T21:26:36.030Z cpu13:2113214)WARNING: FS3J: 3132: 'DataStore': Aborting txn (0x430c122762f0) callerID: 0xc1d0000c due to inconsistent txn resources: Invalid metadata
Koszi!
Hozzászólások
1 host van?
Nem fogja-e valami mentési megoldás (Veeam stb.)?
Próbáltad-e átnevezni a vmdk-t más kiterjesztésre (mondjuk .vmx), majd utána megpróbálni törölni?
trey @ gépház
1 host, nem fogja semmi, athelyezni at tudom, torolni nem...probaltam az atnevezos dolgot, sajnos ugysem tudom torolni.
FBK
Leállítva a gépeket, próbáltad umount-olni a datastore-t, majd vissza? az megy?
trey @ gépház
igen az megy, gond nelkul.
FBK
Hát, innentől kezdve ez már lehet akár vmfs sérülés is, van VOMA, de hát ahhoz illene leszedni mindent róla. Ha meg leszedtél mindent, akkor lehetne már újraformázni is az egész LUN-t, szóval ...
https://knowledge.broadcom.com/external/article/382692/use-voma-to-chec…
Ha valamit talál, akkor VMware support, ticket stb.
trey @ gépház
Nézd meg mit ír ki az
Ha van rajta "i" -immutable, akkor az le kell venni
paranccsal.
fölötte levő directory permissionjei?
Gábriel Ákos
És ezeket mi állítaná el? Vagy mi tenne egy vmdk fájlra immutable-t? Hacsak nem kézzel piszkálta valaki ...
trey @ gépház
Okozhatja egy file letörölhetetlenségét ha a tartalmazó könyvtárról levesszük a w permission-t?
Gábriel Ákos
a permission -ok is rendben, kezdek tanacstalan lenni, lassan tenyleg marad a lun -rol lekoltoz --> format --> visszakoltoz, csak ezt konnyu leirni :D
FBK
Ingyenes Veeam-mel gyerekjáték. Csak legyen hova menteni.
trey @ gépház
De ki vette volna le róla? Ha GUI-n, esxicli-n, API-n keresztül vagy egyéb támogatott módon kezeled csak, akkor azért elég nehéz ezt elképzelni. Ha meg volt kézzel túrás, akkor arra csak emlékezne :D
trey @ gépház
Ez az a típusú kérdés amire nincsen jó válasz.
Gábriel Ákos
A jó válasz az, hogy ez a legkevésbé valószínű, de szerencsére könnyen ellenőrizhető. Viszont akkor kérdés, hogy a virtuális gép törlésekor miért pont ez az egy fájl maradt csak ott, a többit hogy sikerült letörölnie a rendszernek.
Ez arra utal inkább, hogy valami - mentési rendszer, snapshot, folyamat stb. - fogja a fájlt, vagy sérült lett a VMFS a datastore alatt. Ha a könyvtár jog, akkor más fáljt sem lehetett volna belőle törölni.
trey @ gépház
A "valami fogja"-t viszont az teszi valószínűtlenné, hogy egy host van csak és megvolt a host és NAS reboot is. Szóval hajlok az FS korrupcióra.
trey @ gépház
Nem erre utal a "...inconsistent txn resources: Invalid metadata" is a topicindítóban?
De ...
trey @ gépház