VMware ESXiでのScratch Partition構成：ログ消失とコアダンプ問題を解決するテクニック – ITFROMZERO

Table of Contents

vSphere Clientを使用した5分でできるクイック設定

「System logs are stored on non-persistent storage」という警告に悩まされていたり、SDカードにインストールしたホストを再起動するたびにエラーの痕跡が消えてしまったりする場合は、すぐに以下の手順を実行してください。

vSphere Clientにログインします。
対象のESXiホストを選択し、Configure（設定）タブに切り替えます。
System（システム）項目を探し、Advanced System Settings（システムの詳細設定）を選択します。
Edit（編集）をクリックし、キーワード ScratchConfig.ConfiguredScratchLocation でフィルタリングします。
Value（値）フィールドに、データストア上のディレクトリパスを入力します。例：/vmfs/volumes/HDD_DATA_01/.locker-ESXi01。
OKをクリックし、変更を有効にするためにホストをReboot（再起動）します。

重要な注意点： パスを入力する前に、データストアブラウザを使用してディレクトリ（例：.locker-ESXi01）をあらかじめ作成しておく必要があります。ディレクトリが存在しない場合、ESXiは設定を無視し、以前と同様にRamdiskを使用し続けます。

なぜScratch Partitionを無視してはいけないのか？

現場での経験上、数年間デフォルト設定のまま運用されているシステムを多く見てきました。以前、SDカード（32GB）にESXiをインストールしたDell R740の8台構成クラスターを管理していた際、ホストがPSOD（パープルスクリーン）になったことがありました。原因を調査しようとしたところ、Scratch Partitionが構成されていなかったため、ログが空っぽでした。

大容量のローカルハードディスクにESXiをインストールすると、システムは自動的に4GBのパーティションをScratchとして作成します。ここは以下の「住処」となります：

System Logs: エラーを特定するための運用ログ。
Core Dumps: ホストがクラッシュした際の極めて重要なデータ。
Temporary Files: パッチ（VIB）インストール時の一時ファイル。

しかし、USBやSDカードを使用している場合、ESXiはカードの寿命を保護するためにScratchをRamdisk（/tmp/scratch）に配置します。Ramdiskの最大容量は約512MBしかなく、停電や再起動が発生するとすべて消去されます。これにより、過去のエラーのトラブルシューティングが不可能になります。

プロフェッショナルのためのコマンドライン（CLI）による構成

SSHを使用すると、特に複数のホストに同じ設定をコピー＆ペーストする必要がある場合に、より迅速かつ正確に作業できます。これは私が新しいプロジェクトをデプロイする際によく使う手順です。

ステップ1：データストアの正確なUUIDを取得する

データストア名にスペースが含まれているとエラーが発生することがあります。UUIDを使用するのが最も安全な方法です。

ls -l /vmfs/volumes/

5eb1a2f3-7c8d9e0f... のようなIDの羅列が表示されます。これをコピーしてください。

ステップ2：ホスト識別用のディレクトリを作成する

ログの書き込み競合を避けるため、各ホストに個別のディレクトリが必要です。

mkdir /vmfs/volumes/5eb1a2f3-7c8d9e0f-1a2b-3c4d5e6f7a8b/.locker-Host01

ステップ3：新しいScratchパスを割り当てる

esxcli system settings advanced set -o /ScratchConfig/ConfiguredScratchLocation -s "/vmfs/volumes/5eb1a2f3-7c8d9e0f-1a2b-3c4d5e6f7a8b/.locker-Host01"

コマンド実行後、reboot と入力して、すぐに新しい設定を反映させます。

大量のホストを管理する際のPowerCLIによる自動化

50台以上のホストを抱える銀行のプロジェクトを担当した際、一台ずつクリックして回るわけにはいきませんでした。以下のPowerCLIスクリプトを使用すれば、ホスト名に基づいてディレクトリの作成と設定を自動的に行えます。

# vCenterへの接続
Connect-VIServer -Server vcenter.yourdomain.com

$DatastoreName = "SAN-LOG-DATASTORE"
$Hosts = Get-VMHost

foreach ($VMHost in $Hosts) {
    $Directory = ".locker-" + $VMHost.Name
    New-DatastoreItem -Datastore $DatastoreName -ItemType Directory -Path $Directory
    
    $ScratchPath = "/vmfs/volumes/$DatastoreName/$Directory"
    Set-VMHostAdvancedConfiguration -VMHost $VMHost -Name "ScratchConfig.ConfiguredScratchLocation" -Value $ScratchPath
    Write-Host "完了したホスト: $($VMHost.Name)" -ForegroundColor Cyan
}

実務経験：泥棒を見て縄をなわない（事前の備えが肝心）

深夜の「トラブル対応」を何度も経験して得た3つの注意点を紹介します：

1. 絶対にフォルダを共有しない： 2つのホストを同じディレクトリに指定すると、vmksummary.log ファイルが絶えず上書きされます。その結果、ログが破損し、有用な情報を読み取ることができなくなります。

2. ローカルストレージを優先する： サーバーにローカルSSDがある場合は、SANではなくそこにScratchを配置してください。ストレージネットワーク（iSCSI/Fibre Channel）に障害が発生しても、ホストはエラーログを記録できます。SANに配置していてSANがダウンした場合、何が起きたのか全く分からなくなります。

3. 容量の確保： ログ自体は軽量ですが、コアダンプは数GBを占有することがあります。データストアに少なくとも20GBの空き容量があることを確認してください。ログがいっぱいになったことで、同じデータストア上の他の仮想マシン（VM）の動作に影響を与えることは避けたいはずです。

おわりに

Scratch Partitionの構成は基本的な操作ですが、管理者のプロ意識が試される部分でもあります。これにより、システムトラブルが発生した際に、より主体的に対応できるようになります。ESXiクラスターを管理している方は、すべてが永続的に保存されるよう、今日中に確認してみてください。