顧客サイトでは、独立して動作している ESXi サーバーが 2 台 (+ 1 台はバックアップとテスト用) あります (vSphere なし)。顧客からの要求は、500 GB の SSD RAID を 2 TB のものに置き換えることです。
ESXi はその SSD RAID にインストールされています。ここで説明するように、3 番目のサーバー (テスト 1) を使用してワークフローをテストしました。参考文献
元の RAID を新しい RAID に DD したので、元のハード ドライブの正確なコピーが作成されます。
ESXi を正常に起動しました。データストアのマウントは失われましたが、esxcfg-volume -M は成功しました。つまり、すべてが再び機能しています。
ここで、データストアを含むパーティションとファイルシステムのサイズを変更してみました。
vmkfstools -P /vmfs/volumes/datastore1
この場合、名前とパーティションが与えられます
naa.600605b00e7ef41025b05be20a1ac269:3
partedUtil get /vmfs/devices/disks/naa.600605b00e7ef41025b05be20a1ac269
戻ってきた
243133 255 63 3905945600 1 64 8191 0 128 5 8224 520191 0 0 6 520224 1032191 0 0 7 1032224 1257471 0 0 8 1257504 1843199 0 0 9 1843200 7086079 0 0 2 7086080 15472639 0 0 3 15472640 975699934 0 0
partedUtil getUsableSectors /vmfs/devices/disks/naa.600605b00e7ef41025b05be20a1ac
戻ってきた
34 3905945566
だから私たちは
partedUtil resize /vmfs/devices/disks/naa.600605b00e7ef41025b05be20a1ac269 3 15472640 3905945566
そしてKBによって期待される
partedUtil fixGpt /vmfs/devices/disks/naa.600605b00e7ef41025b05be20a1ac269
パーティションテーブルのバックアップコピー
再度確認したところ、すべてが完璧に正常で、予想どおりでした。拡張されたパーティションを持つ動作中のハード ドライブがあり、最終ステップで vmfs のサイズを変更するため、ESXi は予想どおり ~500 GB の SSD を報告します。
vmkfstools --growfs /vmfs/devices/disks/naa.600605b00e7ef41025b05be20a1ac269:3 /vmfs/devices/disks/naa.600605b00e7ef41025b05be20a1ac269:3
次のように返されます:
Not found Error: No such file or directory
ここで何が問題なのかわかりません。パスを 3 回確認し、代わりに /dev/disks を使用し、ディレクトリに CD で移動し、絶対パスなしでファイルを使用するなどしましたが、出力に違いはありませんでした。" と ' を使用してみましたが、次の場合は問題がないと思います。
スクラッチ パーティションのログを確認しましたが、理由はありませんでした。
オンラインで 1 時間ほど検索しましたが、見つかったヘルプは、応答がないか、どこかで間違いを犯したというヒントとともに KB を参照するかのどちらかでした。
そこで、すべてのアクションを再度確認しましたが、間違いは見つかりませんでした。基本的に、これは他の Linux システムと同じワークフローです -> DD、パーティションのサイズ変更、FS のサイズ変更 (アンマウント)。
(はい、マウントとアンマウントも試しました)
私が気付かない間違いがあったら、教えてください。情報が必要な場合は、お気軽にお尋ねください。
このケースが成功した場合、2 台のライブ サーバーも約 2 週間以内に実行する必要があります。ただし、プロセスが期待どおりに機能することを確認する必要があります。
ご協力ありがとうございました。良い一日をお過ごしください。
答え1
Reddit の投稿全文ここで重要な部分を共有します:
「見つかりません」と表示される場合vmkfstools --growfs "/vmfs/devices/disks/devicename:partition#" "/vmfs/devices/disks/devicename:partition#"、そのパーティション上の vmfs ボリューム UUID が一致しないことを意味します。これがどのように発生するかは誰にもわかりませんが、修正方法はボリュームを再署名することです。
これを行うには、データストア上のすべての VM を移動/登録解除し、データストアをアンマウントする必要があります。CLI からこれを行う方法がわからないため、GUI を使用しました。
[編集] コマンドは次のとおりです:esxcli storage filesystem unmount [-uUUID | -l label | -p path ]
データストアがアンマウントされたら、esxcfg-volume --listUUID/ラベルを検証し、
esxcfg-volume --resignature <VMFS UUID|label>再署名します。
vmkfstools -V
vmkfstools --growfs "/vmfs/devices/disks/devicename:partition#" "/vmfs/devices/disks/devicename:partition#"