WSL2にRocky Linux環境を作る【手動導入とvmmem制御】

前回記事

【VirtualBoxからWSL2へ】移行を考えた理由と運用課題の整理

前回のログでは、VirtualBox運用で発生していた静的メモリ占有の課題を整理し、次期基盤としてWSL2を採用する方針を定義しました。

本記事では、その方針に基づき、WSL2上へRocky Linuxを手動導入し、vmmemのリソース制御を含めた初期構築プロセスを記録します。

1. 仮想マシンの静的メモリ占有からの脱却

Minecraft（Pixelmon）サーバーの旧運用基盤であるVirtualBoxにおいて、ホストマシンのリソース管理に課題が観測されました。

最大の要因は、Type-2ハイパーバイザーに伴う「静的なメモリ占有」です。VirtualBoxは起動時に設定したメモリ領域をホストから完全に切り離して確保する仕様のため、Linux側での実際の消費量にかかわらず、ホストOSのメモリが恒常的に圧迫される状態でした。

VirtualBoxプロセス単体で約8.2GB、OpenJDKを合わせると11GB以上のメモリを常時占有している状態

2. 動的メモリ割り当てとRocky Linuxの採用

次期環境としてWSL2を採用した主な根拠は、ホストOSとメモリを柔軟に共有する「動的メモリ割り当て」アーキテクチャにあります。OSはエンタープライズ用途で実績のあるRocky Linux 9を継続採用しました。

しかし、WSL2の標準ストア（Microsoft Store）にはRocky Linuxが提供されていないため、公式のコンテナイメージをベースとした「手動インポート」手順によるプロビジョニングを実施します。

3. 手動インポートにおけるエラー解消プロセス

手動インポートのプロセスにおいて、参照元のリポジトリ仕様変更や配布形式に伴う複数のインシデントに対応しました。

以降のログでは、実際に実行する操作を COMMAND、発生したエラーを ERROR LOG、正常に返った実行結果を OUTPUT として分けて記録します。

// 1. 404 Not Found：GitHubリポジトリ名の変更

WSL用のインストーラーを取得する際、参照していたリポジトリのパスが変更されており、Invoke-WebRequest が 404 Not Found を返す事象が発生しました。

# Rocky Linux 9 の WSL 向けパッケージを固定URLから取得する
Invoke-WebRequest -Uri "https://github.com/mishamosher/RockyLinux-WSL/releases/latest/download/RockyLinux9.zip" -OutFile "$env:USERPROFILE\Desktop\RockyLinux9.zip"

# ダウンロードした zip を展開する
Expand-Archive -Path "$env:USERPROFILE\Desktop\RockyLinux9.zip" -DestinationPath "C:\WSL\RockyLinux" -Force

# 展開されたインストーラーを実行する
C:\WSL\RockyLinux\RockyLinux9.exe

PS C:\Users\user>
PS C:\Users\user> Invoke-WebRequest -Uri "https://github.com/mishamosher/RockyLinux-WSL/releases/latest/download/RockyLinux9.zip" -OutFile "$env:USERPROFILE\Desktop\RockyLinux9.zip"
Invoke-WebRequest : Not Found
発生場所 行:1 文字:1
+ Invoke-WebRequest -Uri "https://github.com/mishamosher/RockyLinux-WSL ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebException
    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

PS C:\Users\user>
PS C:\Users\user> Expand-Archive -Path "$env:USERPROFILE\Desktop\RockyLinux9.zip" -DestinationPath "C:\WSL\RockyLinux" -Force
Expand-Archive : パス 'C:\Users\user\Desktop\RockyLinux9.zip' が存在しないか、または有効なファイル システム パスではありません。
発生場所 行:1 文字:1
+ Expand-Archive -Path "$env:USERPROFILE\Desktop\RockyLinux9.zip" -Dest ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidArgument: (C:\Users\user\Desktop\RockyLinux9.zip:String) [Expand-Archive], InvalidOperationException
    + FullyQualifiedErrorId : ArchiveCmdletPathNotFound,Expand-Archive

PS C:\Users\user>
PS C:\Users\user> C:\WSL\RockyLinux\RockyLinux9.exe
C:\WSL\RockyLinux\RockyLinux9.exe : 用語 'C:\WSL\RockyLinux\RockyLinux9.exe' は、コマンドレット、関数、スクリプト ファイル、または操作可能なプログラムの名前として認識されません。
名前が正しく記述されていることを確認し、パスが含まれている場合はそのパスが正しいことを確認してから、再試行してください。
発生場所 行:1 文字:1
+ C:\WSL\RockyLinux\RockyLinux9.exe
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (C:\WSL\RockyLinux\RockyLinux9.exe:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

この時点では、参照していたリポジトリURLの変更により、ダウンロード対象のzipファイルを取得できていません。その結果、後続の展開処理とインストーラー実行も連鎖的に失敗しました。

// 2. アーカイブ形式の仕様変更と自動取得スクリプトの実装

さらに、公式イメージが .tar.xz 形式で配布されていたため、標準のWSLインポートコマンドで展開できない課題が判明しました。この仕様変更に対し、GitHub API経由で最新版のURLを動的に取得・展開するPowerShellスクリプトを実装し、ダウンロードプロセスを自動化・解決しました。

# GitHub APIから最新のリリース情報を取得し、自動ダウンロードを実行
$api = Invoke-RestMethod -Uri "https://api.github.com/repos/mishamosher/RL-WSL/releases/latest"
$zipUrl = ($api.assets | Where-Object { $_.name -match "9" -and $_.name -match "\.zip$" }).browser_download_url
Invoke-WebRequest -Uri $zipUrl -OutFile "$env:USERPROFILE\Desktop\RockyLinux9.zip"

PS C:\Users\user>
PS C:\Users\user> New-Item -Path "C:\WSL\RockyLinux" -ItemType Directory -Force

    ディレクトリ: C:\WSL

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d-----        2026/04/12     10:18                RockyLinux

PS C:\Users\user>
PS C:\Users\user> $api = Invoke-RestMethod -Uri "https://api.github.com/repos/mishamosher/RL-WSL/releases/latest"
PS C:\Users\user> $zipUrl = ($api.assets | Where-Object { $_.name -match "9" -and $_.name -match "\.zip$" }).browser_download_url
PS C:\Users\user> Invoke-WebRequest -Uri $zipUrl -OutFile "$env:USERPROFILE\Desktop\RockyLinux9.zip"
PS C:\Users\user>
PS C:\Users\user> Expand-Archive -Path "$env:USERPROFILE\Desktop\RockyLinux9.zip" -DestinationPath "C:\WSL\RockyLinux" -Force
PS C:\Users\user>
PS C:\Users\user> $exe = Get-ChildItem -Path "C:\WSL\RockyLinux" -Filter "*.exe" | Select-Object -First 1
PS C:\Users\user> & $exe.FullName
Using: C:\WSL\RockyLinux\rootfs.tar.gz
Installing...
Installation complete
Press enter to continue...
PS C:\Users\user>

最終的には、固定URLではなく GitHub API から最新リリースを取得し、対象のzipファイルを動的に抽出する方式へ変更しました。これにより、配布URLやファイル名の変更に追従しやすくなり、Rocky Linux の WSL2 環境展開まで完了できました。

4. OSの起動確認とリリース情報の取得

OSイメージの展開完了後、WSL2環境下でRocky Linuxが正常に起動し、対話型シェルへアクセス可能であることを確認します。リリース情報を出力し、状態の健全性を担保します。

# WSL2へアタッチし、OSのリリース情報を出力
wsl -d Rocky9
cat /etc/os-release

WSL2環境下における Rocky Linux 9.5 (Blue Onyx) の起動確認ログ

5. .wslconfigによるリソース制限の実装

WSL2はデフォルト設定において、ホストメモリの50%以上を動的に確保しようとする挙動（vmmemプロセスの肥大化）が確認されています。この過剰なリソース消費を制御するため、ホスト側の .wslconfig ファイルを生成し、明示的なリソース制限（メモリ/CPU）を実装しました。

# %USERPROFILE%\.wslconfig を作成し、割り当てメモリとCPUコア数を制限
$configContent = @"
[wsl2]
memory=6GB
processors=4
"@
Set-Content -Path "$env:USERPROFILE\.wslconfig" -Value $configContent -Encoding UTF8

この設定とWSL2の動的メモリ管理機構の相乗効果により、OS起動直後のメモリ占有量は意図した範囲まで大幅に最適化されました。

vmmemプロセスのメモリ占有量が約779MBへ最適化された状態

6. 次世代フェーズ「IaC化」への移行

VirtualBoxからWSL2へのインフラ移行を完了した結果、ホストOSにおけるメモリリソースの圧迫が解消されました。8GBの静的確保から解放され、プロセス実行に必要なリソースのみを動的に消費するモダンなアーキテクチャが確立されました。

これにより、クリーンなRocky Linux基盤が整いました。次回のログでは、本環境に対してAnsibleを用いた構成管理（IaC）を適用し、DockerエンジンのデプロイからMinecraftサーバーのコンテナ化に至る自動構築プロセスを記録します。