前回は、筆者のHyper-V上のテスト/評価環境に残っていたWindows Server 2016ベースの2台の仮想マシン(ドメインコントローラーとMicrosoft Configuration Manager)をインプレースアップグレードして、最新のWindows Server 2022にしました。これで毎月のWindows Update作業の時間が大幅に短縮できると期待しています。一方で、OS仮想ハードディスク(VHDX)が100GB(実際の使用量の倍)を超えてしまうという別の課題に直面することになりました。
この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。
「Windows Server 2016」の「Windowsセットアップ」による既定のインストールでは、ディスクの最初の方に「回復パーティション」があり(BIOS/MBRベースの場合はシステムパーティションと兼用)、WindowsがインストールされるC:ドライブはディスクの後ろの方に配置されるようにパーティションが区切られました。
例えば、UEFI/GPTベースの場合は、ディスクの初めの方から「450MBの回復パーティション」「100MBのEFIシステムパーティション(ブート構成を格納)」「16MBのMSR(Microsoft予約)パーティション」となり、ディスクの残りの領域に「Windowsパーティション(C:)」といった具合です。
一方、現在サポートされている「Windows 10」や「Windows 11」「Windows Server 2019」以降のWindows Serverにおける「既定のパーティション構成」は、回復パーティションがディスクの最後に配置されるように変更されました。現在の推奨パーティション構成は、以下のドキュメントで説明されているように、回復パーティションがディスクの後ろに配置されている構成です(画面1)。
以前の「既定のパーティション構成」のシステムにインストールされたOSを、最新バージョンのWindowsにインプレースアップグレードした場合、現在の回復パーティションのサイズが「Windows回復環境(Windows Recovery Environment、WinRE)」のイメージ「winre.wim」を配置するのには足りず、新たに回復パーティションがディスクの最後に配置されることがあります。新たに作成される回復パーティション領域は、Windowsパーティション(C:)を縮小(Shrink)することで確保されます。
前回は、Windows Server 2016ベースで構築したActive Directoryのドメインコントローラーと「Microsoft Configuration Manager」サイトサーバのOSを、「Windows Server 2022」にインプレースアップグレードしました。
しかし、この「既定のパーティション構成」の変更について、すっかり忘れていました。そのため、アップグレードした2台の仮想マシンのどちらにも、2つ目の回復パーティションが追加されてしまいました。
ディスクの最初の方にもともとあった回復パーティションはただ存在するだけで、何の役にも立ちません。無駄なパーディションがディスクの最初の方に残ったわけですが、実害があるわけではありません。無視すればよいのですが、Microsoft Configuration Managerサイトサーバの容量可変タイプの仮想ハードディスク(VHDX)に、そうしてはいられない状況が生じました。
無視してはいられない状況とは、ゲストOS側から見たディスク使用は50GB程度にもかかわらず、仮想ハードディスクのファイルサイズが100GB以上に肥大化してしまったのです。ゲストOS側での「ディスククリーンアップ」とホストOS側での「仮想ハードディスクの最適化」を実施しても、数GBくらいしか小さくなりません。実際のディスク使用に対して肥大化し過ぎた仮想ハードディスクは、ディスク領域を無駄に消費するだけでなく、仮想マシンのバックアップに多くの時間とバックアップ領域を浪費します。
おそらく、OSのアップグレード前に既に肥大化していて、仮想ハードディスクの最適化による縮小を試みることなく、インプレースアップグレードを実施したことで、仮想ハードディスク内の後方の場所に追加の回復パーティションが作成され、新たな回復パーティションが最適化を阻んでいるようなのです(画面2)。
肥大化してしまった仮想ハードディスクを最大限に最適化する方法の一つは、新しい稼働ハードディスクに移し替えてしまうことです。「DISM」コマンドの「/Capture-Image」および「Apply-Image」オプションを使用すると、Windowsイメージ形式(WIM)のファイルを介してそれを実現できます。
具体的には、問題の仮想マシンをシャットダウンして全てのチェックポイントを削除し、オリジナルの仮想ハードディスクに完全にマージします。その後、ホストOSの「ディスクの管理」スナップイン(Diskmgmt.msc)を使用して仮想マシンの仮想ハードディスクのファイルを「読み取り専用」で接続し、Windowsパーティションをローカルドライブにマウントしたら、コマンドプロンプトまたはPowerShellで以下のコマンドラインを実行します(画面3)。
DISM /Capture-Image /ImageFile:パス\ファイル名.wim /CaptureDir:ドライブ文字:\ /Name:"イメージの説明"
イメージのキャプチャーが完了したら、「ディスクの管理」スナップインを使用して仮想ハードディスクを切断します。出来上がったWIMファイルは、新しい仮想ハードディスクを作成し、適切にパーティションを作成、フォーマットした上で、WindowsパーティションをホストOSにマウントして、以下のコマンドラインで展開します。その後、ブート構成(「BCDBOOT」コマンドを使用)と回復イメージの構成(「REAGENTC」コマンドを使用)を行えば完了です。
DISM /Apply-Image /ImageFile:パス\ファイル名.wim /Index:1 /ApplyDir:ドライブ文字:\
とはいえ、パーティションの作成からの作業は面倒です。具体的な手順は、以下の公式ドキュメントを参考にしてください。
ものぐさな筆者は、既存のWindows Server 2022をインストールしてある仮想マシンの仮想ハードディスクをコピーし、「ディスクの管理」スナップインを使用して接続して、WindowsパーティションをNTFSでフォーマットし、そこにWIMファイルを適用しました(画面4)。
仮想マシンを新しい仮想ハードディスクを優先して起動するようにブート順を調整し、一度、仮想マシンを起動すればほぼ完了です(画面5)。起動後は、回復イメージの再構成が必要でしたが、Windows回復環境はインストールメディアから簡単に開始できるので、省略してしまっても何とかなるでしょう。
もう1つのドメインコントローラーの仮想マシンの仮想ハードディスクはアップグレード後42GB程でそんなに肥大化していないようでしたが、ゲストOS側から見たディスク使用は16.9GBであり、やはり倍以上に肥大化していました。こちらも、同じ方法で約17GBまで縮小することができました。
岩手県花巻市在住。Microsoft MVP 2008 to 2023(Cloud and Datacenter Management)。SIer、IT出版社、中堅企業のシステム管理者を経て、フリーのテクニカルライターに。Microsoft製品、テクノロジーを中心に、IT雑誌、Webサイトへの記事の寄稿、ドキュメント作成、事例取材などを手掛ける。個人ブログは『山市良のえぬなんとかわーるど』。近著は『Windows版Docker&Windowsコンテナーテクノロジ入門』(日経BP社)、『ITプロフェッショナル向けWindowsトラブル解決 コマンド&テクニック集』(日経BP社)。
Copyright © ITmedia, Inc. All Rights Reserved.