VMFSで使用している領域とボリュームの空き領域が合って無く、空き領域が極端に低くなっています。
恐らく空き領域の管理がおかしくなっていると思われますが、修復の方法が解りません。
~ # df -h
Filesystem Size Used Available Use% Mounted on
VMFS-5 5.5T 4.3T 1.2T 78% /vmfs/volumes/datastore1
vfat 4.0G 23.0M 4.0G 1% /vmfs/volumes/523bda42-256f37a8-ed30-40a8f0759e34
vfat 249.7M 157.0M 92.7M 63% /vmfs/volumes/566d1e72-a0b0496d-cff2-5a9099e3b088
vfat 249.7M 8.0K 249.7M 0% /vmfs/volumes/984e8e7a-67cbca04-b7e2-3612a1e21664
vfat 285.8M 191.3M 94.6M 67% /vmfs/volumes/523bda3a-40e607a0-2067-40a8f0759e34
~ # du -sh /vmfs/volumes/datastore1/
6.9G /vmfs/volumes/datastore1/
宜しくお願いいたします。
こんにちは。
データストアに何か不要なファイルが残ってしまっているのかもしれません。
/vmfs/volumes/datastore1 の配下に、
ls コマンドと du コマンドとで容量表示が異なるファイルが存在したり、
既に削除した仮想マシン名のフォルダ(とファイル)などが残っていたりしませんでしょうか。
ちなみに、ESXi のバージョンは何を使用されていますか?
(SSH でアクセスしている場合は vmware -vl コマンドでも表示できます。)
回答ありがとうございます。
隠しファイルも含めて何か大きなファイルが無いか探したのですが見つかりません。
duコマンドとlsコマンドの差異は仮想ディスクで多少ありますが、シンプロビジョニングしているためと思っていますが、現在残っている仮想ディスクの差異は数GByte程度で、TByte単位で差が出るものでもありません。
以前大きな仮想マシン(ゲストOS)があったのですがそれがすっぽりなくなっていまして、ディレクトリーツリーから表示できなくなっているのではないかとも思えます。
環境を記載忘れ申し訳ありません。
VMware ESXi 5.5.0 build-1331820
VMware ESXi 5.5.0 GA
H/WはHP DL320に3TBディスク3本をRAIDカードでRAID5で組んでいます。
何か他に必要な環境情報があればお教えください。
こんにちは。
データストアでプロビジョニング容量(lsやdf)と実使用容量(du)とで大きな差分があると、やはりvmdkファイルが怪しいかなと思うので、
下記のようなコマンドラインで差分を確認してみるとよいと思います。
# ls -lh /vmfs/volumes/datastore1/*/*vmdk | grep -e delta -e flat
# du -sh /vmfs/volumes/datastore1/*/*vmdk | grep -e delta -e flat
今回のケースで役立つかは微妙ですが、VMFSのメタデータの check / fix 方法もあります。
ただ、ESXi 5.5 だと 「--func」 に fix がなく、check できるだけかもしれません・・・
マニュアル
Checking Metadata Consistency with VOMA
KB
vSphere On-disk Metadata Analyzer(VOMA)を使用して、VMFS メタデータの整合性をチェックする (2095782) | VMware KB
gowatana さん
情報ありがとうございます。
今あるゲストはUPSからの信号でホストをシャットダウンするためのフリーで公開されているvMAだけで、これが大きな領域を使用しているとは考えられません。
大きな領域を使用していたゲストが見た目上なくなってしまった時に何か不整合が起きたのだと思います。
頂いたvomaコマンドを実行してみたところ下記のように5つのエラーが確認できました。
これはVMFSを作り直すしかないのでしょうか?
# voma -m vmfs -f check -d /vmfs/devices/disks/naa.600508b1001c1ec3fa7241f9c4f181d6:3
Checking if device is actively used by other hosts
Running VMFS Checker version 1.0 in check mode
Initializing LVM metadata, Basic Checks will be done
Phase 1: Checking VMFS header and resource files
Detected VMFS file system (labeled:'datastore1') with UUID:523bda42-fd58b010-8688-40a8f0759e34, Version 5:60
Phase 2: Checking VMFS heartbeat region
Phase 3: Checking all file descriptors.
Found stale lock [type 10c00001 offset 212926464 v 19850, hb offset 3719168
gen 149, mode 1, owner 58cf6ce2-461cc7bc-7f85-40a8f0759e34 mtime 118
num 0 gblnum 0 gblgen 0 gblbrk 0]
Found stale lock [type 10c00001 offset 212930560 v 19853, hb offset 3719168
gen 155, mode 1, owner 58cf6f18-4fa1d729-5505-40a8f0759e34 mtime 119
num 0 gblnum 0 gblgen 0 gblbrk 0]
Found stale lock [type 10c00001 offset 213045248 v 18849, hb offset 3719168
gen 121, mode 1, owner 58520de2-c4bf4556-ceda-40a8f0759e34 mtime 1519936
num 0 gblnum 0 gblgen 0 gblbrk 0]
ON-DISK ERROR: <FD c434 r74> : Invalid linkCount 0
Found stale lock [type 10c00001 offset 213127168 v 18742, hb offset 3719168
gen 113, mode 1, owner 58457102-cb5dc46e-b19b-40a8f0759e34 mtime 1857315
num 0 gblnum 0 gblgen 0 gblbrk 0]
ON-DISK ERROR: <FD c434 r114> : Invalid linkCount 0
Found stale lock [type 10c00001 offset 213227520 v 19965, hb offset 3719168
gen 155, mode 1, owner 58cf6f18-4fa1d729-5505-40a8f0759e34 mtime 1944582
num 0 gblnum 0 gblgen 0 gblbrk 0]
ON-DISK ERROR: <FD c434 r163> : Invalid linkCount 0
Found stale lock [type 10c00001 offset 213239808 v 19971, hb offset 3719168
gen 155, mode 1, owner 58cf6f18-4fa1d729-5505-40a8f0759e34 mtime 1989963
num 0 gblnum 0 gblgen 0 gblbrk 0]
ON-DISK ERROR: <FD c434 r169> : Invalid linkCount 0
Found stale lock [type 10c00001 offset 213256192 v 19240, hb offset 3719168
gen 131, mode 1, owner 586bf31c-468f185c-668d-40a8f0759e34 mtime 5620411
num 0 gblnum 0 gblgen 0 gblbrk 0]
ON-DISK ERROR: <FD c434 r177> : Invalid linkCount 0
Found stale lock [type 10c00001 offset 213258240 v 19979, hb offset 3719168
gen 159, mode 1, owner 58dcc82b-716c4fc5-93a7-40a8f0759e34 mtime 112
num 0 gblnum 0 gblgen 0 gblbrk 0]
Found stale lock [type 10c00001 offset 213262336 v 19982, hb offset 3719168
gen 163, mode 1, owner 58dccc23-4e7baf10-3545-40a8f0759e34 mtime 113
num 0 gblnum 0 gblgen 0 gblbrk 0]
Found stale lock [type 10c00001 offset 213284864 v 19841, hb offset 3719168
gen 143, mode 1, owner 58ccf7c5-44b97d1c-43c9-40a8f0759e34 mtime 119
num 0 gblnum 0 gblgen 0 gblbrk 0]
Phase 4: Checking pathname and connectivity.
Phase 5: Checking resource reference counts.
Total Errors Found: 5
こんにちは。
vomaでfixが実行できるのはESXi 6.0 からのようなので、vMA を退避(もしくは UPS 連携用のスクリプトなどを退避して再デプロイ)して、
VMFS を再作成してしまったほうがよさそうと思いました。
あと、ESXi のバージョンが結構古めの ESXi 5.5 GA だったので、VMFS 再作成する前にパッチ適用しておくとよいと思います。
現時点だと、ESXi 5.5 U3 となっていて、パッチであれば ESXi550-201703001 が最新です。
一度VMやその他データを退避し、VMFSを再作成しました。
助言ありがとうございました。
ESXi のパッチレベルが古いことは承知しているのですが、サーバーがものすごい回線が遅く、何かあった場合に行けるような場所でもないリモートにあるので、パッチ当てをためらっています。
そのうちに安全な方法を考えながら対応いたします。
ありがとうございました。