いまさら聞けないHyper-V仮想マシンの構成詳細（1）：ハードウェア設定［前編］：今だからこそ学び直すHyper-V再入門（4）
前回は、Hyper-V仮想マシンの新規作成からゲストOSのインストールまでのステップを見てきました。今回から3回に分けて、仮想マシンを作成後に変更可能な項目、追加で設定できる項目を確認し、仮想マシンの詳細設定を学び直していきます。今回は、Hyper-V仮想マシンのハードウェア設定の前半部を見ていきます。
この記事は会員限定です。会員登録（無料）すると全てご覧いただけます。
仮想マシンを管理するツール
「Hyper-V」で仮想マシンを管理するツールは、Hyper-Vホストの管理と同様、GUI（グラフィカルユーザーインタフェース）ツール「Hyper-Vマネージャー」とHyper-V用のWindows PowerShell（以下、PowerShell）コマンドレットです。
仮想マシン設定の詳細を確認したい場合には、Hyper-Vマネージャーで仮想マシンを選択した状態で、操作ウィンドウの「設定」を選択することで設定画面が開きます（画面1）。画面1は第2世代仮想マシンの設定画面になります。
PowerShellコマンドレットで仮想マシンの構成情報を取得する場合は、「Get-VM」コマンドレットを使用します。別連載「Windows PowerShell基本Tips」の第118回「Get-VM」コマンドレットの回を参照してください。
- 【 Get-VM 】コマンドレット――コンピュータ上の仮想マシンの情報を取得する（連載：Windows PowerShell基本Tips 第118回）
設定画面を確認することで、仮想マシンに対してどのような設定ができるのか、またその設定がどのHyper-Vの機能にひも付くのかを理解できるので、設定項目を1つ目から順番に確認してきます。
仮想マシンのハードウェア：ハードウェアの追加
先頭にある設定項目「ハードウェアの追加」は、この仮想マシンに対して追加できるハードウェアを示しています。
画面2は第1世代仮想マシン（上）と第2世代仮想マシン（下）の同じ項目を並べたものになりますが、ここでの違いは第1世代仮想マシンでサポートされている「レガシーネットワークアダプター」が第2世代仮想マシンでは表示されていない点です。
「レガシーネットワークアダプター」は「IDEコントローラー」とともに第2世代仮想マシンでサポートされなくなったレガシーデバイスであり、「統合サービス」が導入されていないレガシーOSでネットワーク接続が必要となるシナリオ以外には、基本的には出番はないと思われます。「レガシーネットワークアダプター」については、別項にて取り上げます。
なお、画面2は仮想マシンが停止中の状態であるため、選択できる全てのハードウェアが追加できます。仮想マシンが電源オンの状態の場合、基本的にはハードウェアは追加できません。ただし、第2世代仮想マシンでは、ネットワークアダプターのみ、電源オンの状態でも追加できるようになっています（画面3）。
仮想マシンのハードウェア：BIOS／ファームウェア
2つ目の項目は世代によって異なり、第1世代仮想マシンでは「BIOS」、第2世代仮想マシンでは「ファームウェア」が表示されます（画面4）。
第1世代仮想マシンはBIOS（Basic Input/Output System）ベースで、第2世代仮想マシンはUEFI（Unified Extensible Firmware Interface）ベースであることは本連載第3回で解説しました。ここは、その違いが表れている項目になります。
本項目はブートデバイスの設定および順番設定となり、CD/DVDからのブートやプリブート実行環境（PXE）からのネットワークブートを実施したい場合には、ここでブート順序を設定します。
画面4の仮想マシンは両方ともゲストOSが「Windows Server 2022」ですが、第2世代仮想マシンの場合、ブートマネージャーとして「bootmgfw.efi」が指定されているところからもUEFIベースであることが分かります。
仮想マシン作成後、テンプレート用の仮想ハードディスクを後付けした場合などは、デフォルトではネットワークアダプターからブートする順番になっています。仮想ハードディスクを接続後には、起動順序を修正することを忘れないようにしてください。
Hyper-Vマネージャーで起動順序を変更する場合は、起動したいデバイスをリストの一番上位に移動します。PowerShellの場合は「Set-VMFirmware」コマンドレットを使用します。
仮想マシンのハードウェア：セキュリティ
3つ目の項目「セキュリティ」は、第2世代仮想マシンで機能が拡充されたセキュリティ機能となります。
画面5も第1世代仮想マシンと第2世代仮想マシンで同じ項目を参照していますが、「セキュアブート」や「トラステッドプラットフォームモジュール」（Trusted Platform Module〈TPM〉）をサポートしている第2世代仮想マシンの方が、より多くの設定が可能です。
このようなセキュリティ機能的な側面からも、ゲストOSの問題がなければ原則的には第2世代仮想マシンを使用する方がよいでしょう。
なお、セキュアブートなどは明示的に無効化できますし、Windowsだけではなく、Linuxでもセキュアブートが可能となるように、Linux OS向けのテンプレート（Microsoft UEFI 証明機関）も用意されています（画面6）。
また、TPMを有効化することで、仮想マシンに対して仮想TPMを提供可能です。これにより、TPMを必須要件とする「Windows 11」もHyper-V上の仮想マシンとして稼働させることができます。
セキュアブートやTPMは画面5のようにHyper-Vマネージャーで簡単に設定できますが、PowerShellコマンドレットでも有効化が可能です。セキュアブートの有効化は「Set-VMFirmware」コマンドレットで、TPMの有効化は「Enable-VmTpm」コマンドレットを使用します。なお、PowerShellでTPMを有効化する際は「Set-VMKeyProtector」コマンドレットの併用が必要なことを覚えておきましょう。
セキュリティの項目の最下段にある「セキュリティポリシー」は、「シールドを有効にする」チェックボックスをオンにすることで、第2世代仮想マシンで利用可能なセキュリティオプションが全て適用され、Hyper-Vマネージャーでのコンソール接続が不可になります（画面7）。
「シールドされた仮想マシン」は「Windows Server 2016」で導入された機能の一つで、仮想基盤レベルからの攻撃、例えばHyper-Vの管理者権限を奪った攻撃者が仮想マシンのVHDファイルをコピーし、マウントしてファイルを奪取する、仮想マシンにコンソール接続してネットワークレベルでの保護を回避するといった攻撃などから、仮想マシンを保護するための仕組みとなります。
シールドされた仮想マシンはHyper-Vホスト単体でも使用できますが、仮想マシンをエクスポートして他のHyper-Vホストにインポートしたり、他のHyper-Vホストにライブマイグレーションをしたりすると、仮想マシンが起動しなくなる恐れがあります。これはセキュリティキーが各Hyper-Vホストに存在するためで、セキュリティキーが一致せずに不正起動と見なされるからです。
こうした冗長化構成を含むエンタープライズ環境下でのセキュリティ保護の仕組みを有効化するため、Windows Server 2016では「ホストガーディアンサービス」と呼ばれるサービスが実装されました。
ホストの構成を証明する外部サービスとHyper-Vホストを組み合わせることで、仮想マシンが正当なホストでのみ起動できることを保証していました。こうすることで複数台のHyper-Vホスト間でのエクスポート／インポートやライブマイグレーションを可能にしています。ホストガーディアンサービスについては、以下の公式ドキュメントを参照してください。
- 保護されたファブリックとシールドされたVMの概要（Microsoft Learn）
なお、「保護されたファブリック」とシールドされた仮想マシンは、「Windows Server 2022」で「開発されていない機能」の一つとなり、積極的な機能開発が進められなくなりました。しかし、機能開発が進められていないだけで、機能としては「Windows Server 2025」でも問題なく使用可能です。
シールドされた仮想マシンはHyper-Vホスト単体でも使用可能と述べましたが、これだけでなく、TPMを有効化した仮想マシンも異なるホストへインポートすると、画面8のようなエラーが発生して起動できません（画面8）。
TPMを削除すると他のHyper-Vホストでも起動できるようになりますが、TPM由来の機能は使用できなくなります。
TPMやシールドされた仮想マシンをHyper-Vホスト単体で使用する場合には、このような事象が起きることをあらかじめ理解した上で使用する必要があります。
回避策としては、シールドされた仮想マシンやTPMを有効化したHyper-Vホストからシールドされた仮想マシン用の証明書を秘密鍵込みでエクスポートし、動作させたいHyper-Vホストに秘密鍵とともにインポートすることで起動可能になります（画面9）。だたし、本回避策を利用する場合はMicrosoftのサポートに確認した方がよいでしょう。
- ［参考］Windows 2016 Hyper V Cluster Live Migration Fails with TPM enabled［英語］（Microsoft Learn）
仮想マシンのハードウェア：メモリ
「メモリ」は、仮想マシンに割り当てるメモリの設定項目になります（画面10）。この項目は、第1世代仮想マシンでも第2世代仮想マシンでも同じ設定となります。
「RAM」の項目で設定する値が、仮想マシンの電源投入時に割り当てるメモリ量となり、画面10の設定であれば仮想マシンのOSから見たメモリ量となります。
画面10の仮想マシンである「Gen2-VM」を起動してゲストOSからメモリ量を確認しても4GBと認識しています。また、Hyper-Vマネージャーから見ても4096MB（4GB）が割り当てられていることが分かります（画面11）。
画面10はいわゆる「静的メモリ」（Static Memory）と呼ばれる設定であり、仮想マシンが起動するタイミングでメモリを静的に割り当て、稼働中は変わらずメモリの割り当てを変更しない設定となります。
画面10の中ごろに「動的メモリを有効にする」というチェックボックスが確認できますが、こちらがHyper-Vの機能の一つである「動的メモリ」（Dynamic Memory）となります。
動的メモリは「起動メモリ」「最小メモリ」「最大メモリ」の3つのメモリ設定から構成され、「起動メモリ」はその名の通り仮想マシンが起動するタイミングで割り当てられるメモリ量となります。この値は「RAM」で定義された値となり、静的メモリと変わりありません。
動的メモリでは、仮想マシンが要求するメモリ量に応じてHyper-Vが仮想マシンに割り当てているメモリを追加／回収します。この際、追加上限と回収下限が設定可能で、最大まで拡張した際の割り当て上限を「最大メモリ」、回収の際に仮想マシンに残さなければならない必要最低限のメモリ量を「最小メモリ」として定義します。この一連の仮想マシンに対するメモリ割り当てを動的に変化させる機能こそが「動的メモリ」となります。
【注】「起動メモリ」「最小メモリ」「最大メモリ」はHyper-Vマネージャーのメモリタブでの表記となり、仮想マシン設定画面では「RAM」「最小RAM」「最大RAM」という表記になります。表記は異なりますが、同じものを指していることに留意してください。
例えば、以下のようなメモリ量で動的メモリを設定した場合を考えてみましょう。
- 起動メモリ：4096MB（4GB）
- 最小メモリ：2048GB（2GB）
- 最大メモリ：8192MB（8GB）
仮想マシンが起動するタイミングでは4096MBのメモリが割り当てられ、仮想マシンが起動後、メモリの利用が落ち着いてくるとゲストOSレベルで空きメモリが増加します。仮想マシンのゲストOSが要求するメモリ利用が減少すると、Hyper-Vは仮想マシンからメモリを回収し、結果としてホストの空きメモリが増加します。回収するメモリ量はゲストOSのメモリ需要に応じてとなりますが、最小メモリとして設定されているメモリ量、すなわち2GBが下限値となります。仮想マシンが2GB以下のメモリ（例えば1269MB）しか要求しなかったとしても、Hyper-Vは2GBを割り当てます。
この状態をゲストOSの「タスクマネージャー」、およびHyper-Vマネージャーの仮想マシンのメモリタブで見ると画面12のようになります。
画面12では4.0GBのメモリが割り当てられているように見えますが、実際のところは2.0GBしか使えません。残りの2.0GBはどこに行ったのでしょうか。ゲストOSのタスクマネージャー上で確認すると「ハードウェア予約済み」として2.0GBが予約されており、ゲストOSからは使用できなくなっています。
では、この状態でアプリケーションを実行してメモリ要求を増やしてみます（画面13）。
画面13がメモリ要求を増やした結果となりますが、Hyper-Vマネージャー上ではメモリ要求が3.8GBまで増加して、割り当てメモリが4.6GBとなりました。起動メモリ4.0GBを超えてしまいますが、ゲストOS上では4.0GBを超える4.6GBのメモリが割り当てられていることがタスクマネージャーで確認できます。
また「ハードウェア予約済み」は0.0PBになっていることが画面上確認できます。つまりハードウェアで予約されて使用できなかったメモリが使用可能になった上、不足分は追加で割り当てられていることが分かります。
メモリ需要がさらに拡大した場合は、本設定であれば最大8GBまで追加割り当てされることになります。
続いてメモリを要求しているアプリケーションを終了し、メモリ需要を3.0GB程度にします（画面14）。
結果、ゲストOSが要求しているメモリが3.2GB程度まで落ち込み、Hyper-Vにてメモリ回収が実行され、割り当てメモリ量が4.0GBを下回りました。ゲストOSから見ると、割り当てられているメモリ量が4.0GBとなった上「ハードウェア予約済み」が149MBとなり、結果として3.9GBのメモリが使用可能となりました。
メモリ要求と割り当てメモリの関係ですが、要求されるメモリに対してどの程度の余裕（バッファー）を持って割り当てるかは、動的メモリの「メモリバッファー」の設定に依存します。デフォルト（既定値）では「20％」となっており、画面14の例ではメモリ要求3355MBに対して3948MBが割り当てられているので約17％のバッファーを見込んでメモリが割り当てられています。
このメモリバッファーを5％まで下げた場合は、画面15のようにメモリ要求2787MBに対して2904MBの割り当てと、4.2％のバッファーを見込んでメモリが割り当てられています。
メモリバッファーの値は、動的メモリを有効化した仮想マシンごとに5％刻みで設定可能です。ただ、あまりにもバッファーが少な過ぎると、ゲストOSのメモリ需要の都度Hyper-Vにメモリ割り当てを要求することになるので、場合によってはパフォーマンスに影響を与えることも予想されます。
また、バッファーが少な過ぎることで急激なメモリ需要に対してメモリ不足に陥る可能性もあるので、Hyper-Vホスト全体のメモリ需要を勘案してメモリバッファーの値は設定すべきです。
動的メモリを有効化することで、ある意味Hyper-Vホストの搭載メモリ量以上のメモリを仮想マシンに「設定」することが可能（各仮想マシンの「最大メモリ」の合計値がHyper-Vホストの搭載メモリ量を超えることが可能）ですが、「設定」通りにメモリを割り当てることはできません。仮想マシンに割り当て可能なメモリ量は、Hyper-Vホストで管理している仮想マシン用のメモリ量となります。
複数の仮想マシンが同時にメモリを要求し、Hyper-Vが仮想マシンに割り当てるメモリ量が枯渇することも予想できます。そういった事態に備え、Hyper-Vではメモリ割り当ての優先順位を仮想マシン単位で設定することが可能で、メモリ設定の中の「メモリの重み」がそれに該当します（画面16）。
例えば、複数の仮想マシン起動時に、各仮想マシンから要求される起動メモリ量がHyper-Vホストの割り当て可能メモリ量を超えたとします。その場合は「メモリの重み」に従って優先順位の高い仮想マシンから順にメモリを割り当て、枯渇した段階で割り当てを終了します。結果、優先順位の低い仮想マシンはメモリ不足で起動しません。
動的メモリによってメモリが仮想マシン間で融通できる一方、優先順位を決めないと仮想マシンのパフォーマンスに影響を与えることも予想されますので、慎重に設定する必要があります。
なお、動的メモリ使用時のメモリ不足で仮想マシンが起動できない状況を回避するために「スマートページング」と呼ばれる設定がありますが、こちらについては第6回で触れます。
このように、ゲストOSに割り当てるメモリ量を需要に応じて増減させ、より効果的なメモリ割り当てを実施する機能が動的メモリですが、ゲストOSと連携しながら動作するため、ゲストOSもHyper-Vの動的メモリをサポートする必要があります。本連載第3回で紹介した「ゲストOSのサポート一覧」に記載のある条件を満たしていれば、基本的には動的メモリを使用できるので、使用するゲストOSのサポート状況を確認してください。
現在サポート期間中のOSであれば、基本的には特に追加のソフトウェアを導入することなく利用可能ですが、古いカーネルバージョンのLinuxや「Windows Server 2003」といったレガシーOSでは、「統合サービス」をインストールする必要があります。また、「Windows Server 2008」や「Windows Server 2008 R2」では所定のService Pack（SP）の適用も必要になります。
画面17は、Windows Server 2008 R2 Standard EditionをゲストOSとしてインストールした仮想マシンに対し、動的メモリを有効化したものになります。
画面17の通り、「メモリ要求」が空白であり、ゲストOSが要求しているメモリを取得できていません。この状態では、動的メモリが動作せずに静的メモリと同様の状態となります。
この状態から、動的メモリをサポートするために必要なSP1を適用します。適用後は画面18の通り、ゲストOSと連携可能となって動的メモリが正常に動作するようになります。
このように、動的メモリは仮想マシンのゲストOSとHyper-Vが連携して動く機能になり、一部のレガシーOSでは「統合サービス」と呼ばれる追加ソフトウェアのインストールが必要になります。「統合サービス」については、本連載第6回で改めて解説します。
メモリ設定に関しても、もちろんPowerShellでの変更が可能です。既存の仮想マシンに対するメモリ設定変更は「Set-VM」コマンドレットを使用します。別連載「Windows PowerShell基本Tips」の第120回「Set-VM」コマンドレットの回を参照してください。
- 【 Set-VM 】コマンドレット――Hyper-V仮想マシンの設定を変更する（連載：Windows PowerShell基本Tips 第120回）
なお、稼働中の仮想マシンに対してもメモリサイズの設定変更が可能です。これは動的メモリ設定の仮想マシンだけではなく、画面19のように静的メモリ設定の仮想マシンでも変更可能です。
しかしながら、稼働中の仮想マシンに対する静的メモリのサイズ変更がサポートされていない古いゲストOSの場合は画面20のようなエラーが発生するので、ゲストOSでのサポートの確認が必要です。
筆者紹介
後藤 諭史（ごとう さとし）
Microsoft MVP for Cloud and Datacenter Management（2012-2025）。現業の傍ら、コミュニティーイベントでの登壇や著作にてMicrosoftテクノロジーに関する技術情報の発信、共有を続けている。ネットワークやハードウェアといった物理層に近いところが大好きな、昔ながらのインフラ屋さん。得意技はケーブル整線。近著は『詳解! Windows Server仮想ネットワーク』（日経BP社）。
関連記事
Copyright © ITmedia, Inc. All Rights Reserved.
注目のテーマ
ITmediaはアイティメディア株式会社の登録商標です。