ネストされたハードウェア仮想化：要件、用途、および構成

インフォマテックデジタル » Recursos » ネストされたハードウェア仮想化：要件、用途、および構成

最新のハードウェアにおけるネスト型仮想化は、複雑なラボ環境、テスト環境、またはセキュリティシナリオを構築する必要があるITチーム、開発者、トレーナーにとって、データセンターを物理サーバーで埋め尽くすことなく、ほぼ不可欠なツールとなっています。簡単に言えば、仮想マシン内で別の仮想マシンを実行することで、許容可能なパフォーマンスを維持し、リソース管理をきめ細かく調整できる機能です。

一般的な「仮想マシンを別の仮想マシンの中に入れ替える」という単純な方法にとどまらず、ネストされた仮想化は、柔軟なDevOpsパイプライン、現実的なトレーニング環境、隔離されたセキュリティテスト、そしてオンプレミスのHyper-VからAzureやVMware ESXi上の仮想マシンまで、さまざまなプラットフォームにわたるIoT Edgeの展開を可能にします。ただし、すべてが期待どおりに機能するためには、ハードウェアとハ​​イパーバイザーの構成が非常に具体的な要件を満たしている必要があります。

ネスト型仮想化とは一体何なのか、そしてなぜそれが重要なのか？

ネストされた仮想化とは、仮想マシンが他の内部仮想マシンの仮想化ホストとして機能する機能を指します。つまり、物理ハードウェア上に最上位のハイパーバイザー（例えば、Windows ServerのHyper-VやAzure Localなど）があり、そのハイパーバイザー内の仮想マシン（VM）にHyper-Vまたは互換性のある別のハイパーバイザーをインストールして、さらに多くのVMを作成するということです。

Hyper-Vの場合、ネストされた仮想化により、Hyper-Vロールをゲスト仮想マシン内にインストールできます。このゲスト仮想マシンは、Hyper-Vが動作する物理ホスト上で実行されます。この「中間」仮想マシンは、プロセッサの仮想化拡張機能を内部の仮想マシンに公開します。内部の仮想マシンは、実際には複数のレイヤーが存在するにもかかわらず、ハードウェアにより近いかのように動作します。

この機能は当初、Intelプロセッサ搭載のWindows Server 2016とWindows 10で導入され、その後、Windows Server、Windows 11、AMDプロセッサといったより新しいバージョンにもサポートが拡大されました。現在では、Microsoftが公式ドキュメントに組み込んでいるだけでなく、サードパーティ製ソリューションでも利用されている成熟した機能となっています。

その実用的な価値は明らかです。ネスト型仮想化を用いることで、新たなラックへの投資やデータセンターのスペース確保なしに、本番環境の複製、クラスター全体の構築、リスクの高い構成のテスト、多層ネットワークのシミュレーションなどが可能になります。多くの企業にとって、わずかなパフォーマンス低下を補って余りあるコスト削減と俊敏性が得られるのです。

ネストされた仮想化の一般的な使用例

最も一般的なシナリオの1つは、複雑なテスト環境を構築することです。開発チームとQAチームは、単一のメイン仮想マシン内で、多層構造のアプリケーションスタック（データベース、ミドルウェア、フロントエンドなど）を完全に構築し、その仮想マシン内で、本番環境を再現するために必要なすべての内部仮想マシンをホストできます。

技術研修や開発環境においても非常に役立ちます。講師はホストVMを設定し、各受講生が独自のゲスト仮想マシンを作成したり、ネットワークを構成したり、サーバーロールをテストしたり、コンテナをデプロイしたりすることができます。しかも、企業の「実際の」インフラストラクチャには一切触れる必要がありません。すべてが簡単に破棄できるサンドボックス内に収まります。

もう一つの典型的な用途は、新しいソフトウェアバージョンの評価とテストです。管理者は、物理ホスト上で機密性の高い設定を直接変更する代わりに、ネストされた仮想化VM上でシナリオを再現し、本番環境に展開する前にパッチ、新リリース、またはセキュリティ変更を検証できます。

ネストされた仮想化は、仮想化ベースセキュリティ（VBS）や、異なるレベルのハイパーバイザー機能に依存する特定の分離など、高度なセキュリティ機能を実現する上で重要な役割を果たします。これにより、追加のハードウェアを必要とせずに特定の環境を強化することが可能になります。

IoT分野では、ネストされた仮想化は、Windows上のLinux向けAzure IoT Edgeシナリオにおいて重要です。このシナリオでは、Windows、Linuxコンテナ、ハイパーバイザーの機能を、ローカル環境とVMware ESXiなどのサードパーティ製プラットフォーム、またはAzureの仮想マシンなど、さまざまな仮想化レイヤー上で組み合わせる必要があります。

ネストされた仮想化のためのハードウェアおよびソフトウェア要件

これらすべてが正しく機能するためには、まず互換性のあるハードウェアと最小オペレーティングシステムバージョンが条件となります。たとえば、Azureオンプレミス環境では、バージョン2411.3以降と、構成バージョンが10.0以上の仮想マシンが必要です。これにより、必要な仮想化拡張機能のサポートが確保されます。

プロセッサレベルでは、Intel製プロセッサを使用する場合、 BIOS/UEFIでIntel VT-x仮想化テクノロジーを有効にすることが不可欠です。AMDアーキテクチャの場合は、AMD-Vのサポートが必要であり、高度なシナリオでは、仮想マシンに暗号化を追加し、分離性と低レベルのセキュリティを向上させるSecure Encrypted Virtualization（SEV）テクノロジーを有効にする必要があります。

ホストオペレーティングシステムは、最新のパッチで適切に更新された最新バージョンのWindows ServerまたはWindows 10/11である必要があります。ネストを有効にする前に、物理マシンにHyper-Vをインストールする必要があります。互換性のあるCPUを搭載しているだけでは、この機能は標準で利用できるわけではありません。

もう一つの重要なポイントは、仮想マシンの状態です。プロセッサパラメータを変更したり、仮想化拡張機能を公開したりするには、ネストされたホストとして機能する仮想マシンは、一時停止状態や保存状態ではなく、完全に電源がオフになっている必要があります。そうして初めて、Hyper-V は高度な仮想プロセッサオプションの変更を許可します。

最後に、ネットワーク接続は慎重に計画する必要があります。ネストされた仮想マシンは外部アクセスや他のレイヤーへのアクセスを必要とする場合があるため、通信やフィルタリングの問題を回避するために、内部スイッチ、NAT、MACアドレススプーフィング、またはその他の仮想ネットワーク技術を使用するかどうかを最初から定義しておくことをお勧めします。

PowerShell を使用して Hyper-V でネストされた仮想化を有効にする

Hyper-V でネストされた仮想化を有効にする最も直接的かつ詳細な方法は、PowerShell コマンドレットを使用することです。この方法は、Windows Server と互換性のあるクライアントエディションの両方で機能し、複数のホストまたは仮想マシンにわたって一貫した構成を自動化できます。

最初のステップは、Hyper-Vをゲストとしてインストールする仮想マシンが Hyper-V マネージャーからオフにしました （シャットダウンオプション）またはPowerShellで適切なコマンドを使用する、例： Stop-VM -Name 'NombreVM'処理が中断状態または保存状態のままになっている場合、プロセッサの変更は正しく適用されません。

VMが停止した状態で、Set-VMProcessorコマンドレットを使用してプロセッサ仮想化拡張機能をゲストオペレーティングシステムに公開し、ExposeVirtualizationExtensionsオプションをtrueに設定する必要があります。この設定により、システムはVM内からハイパーバイザーロールのインストールに必要な機能を参照できるようになります。

操作が正しく適用されたことを確認するには、Get-VMProcessor コマンドレットと Select コマンドレットを組み合わせてExposeVirtualizationExtensions フィールドを使用します。これにより、対象の仮想マシンの仮想プロセッサ構成で値が true に設定されているかどうかがチェックされ、部分的に構成された環境が起動されるのを防ぎます。

診断タスクの実行中や、ネストされた仮想マシンが不要になった場合など、構成を元に戻す必要が生じた場合は、同じプロセッサコマンドレットを再度実行し、値を false に変更してください。これにより、仮想化拡張機能がゲスト仮想マシンに公開されなくなります。

仮想プロセッサの設定が完了したら、Start-VM コマンドレットまたは Hyper-V マネージャーを使用して仮想マシンを起動します。ゲスト オペレーティングシステム内で、通常の方法（サーバー マネージャー（役割と機能の追加）、DISM、PowerShell など）を使用して、Hyper-V の役割全体をインストールします。その後、管理者の視点からは、仮想マシンは追加の Hyper-V ホストとして動作します。

ネストされた環境におけるネットワーク構成とMACスプーフィング

プロセッサ部分が完了したら、次のステップはネストされた仮想マシンのネットワーク接続です。内部の仮想マシンが他のネットワーク、インターネット、または上位層のコンピュータと通信できるようにするには、中間仮想マシンの仮想アダプタの特定のパラメータを調整する必要があります。

Hyper-Vでは、ネストされたホストとして機能する仮想マシンのネットワークアダプタでMACアドレススプーフィングを有効にするのが一般的な方法です。この機能により、内部仮想マシンは自身のMACアドレスを使用して同じアダプタ経由でトラフィックを送信できるため、物理ホストの仮想スイッチにおけるブロックやフィルタリングを回避できます。

この調整は、PowerShell のSet-VMNetworkAdapter コマンドレットを使用し、MacAddressSpoofing パラメーターをOn に設定して、VM の対応するネットワーク アダプターに適用することで行えます。これにより、下位の VM からのトラフィックが最上位のハイパーバイザーによって破棄されないようにすることができます。

より高度な構成の場合、各レイヤーにおける仮想スイッチとNATインスタンスのトポロジーを事前に設計しておくことをお勧めします。例えば、内部スイッチを組み合わせてラボを分離したり、レイヤー間でルーティングルールやファイアウォールを設定したり、中間ホストでNATを使用して複数のネストされた仮想マシンを直接インターネットに公開することなくアクセスを提供したりすることができます。

複数の仮想化レイヤーを扱う場合、接続の問題は、MACアドレスの偽装が無効になっている、NATルールが正しく連鎖していない、またはファイアウォールが過度に制限的であるといったことが原因であることが多いです。これらの点を確認し、各レイヤーでネットワークアダプタやサービスを再起動することで、ネストされた環境におけるほとんどの接続問題は解決します。

関連タスクにグラフィカルインターフェースを使用する

ネストされた仮想化の厳密な有効化はPowerShellから完全に制御できますが、実際には、特に複数のホストを管理している場合や構成を視覚的に確認したい場合は、 Hyper-Vマネージャーのグラフィカルインターフェイスを使用する方が多くの関連タスクが便利です。

一般的なワークフローでは、Hyper-V マネージャーを開き、対象の仮想マシンを見つけて、シャットダウンオプションを使用して電源がオフになっていることを確認します。これは PowerShell の使用を補完し、すべてのパラメーターが正しく構成されていない仮想マシンを誤って起動してしまうことを防ぎます。

仮想化拡張機能を公開するために必要なコマンドレットが実行されたら、グラフィカル環境に戻り、VM構成ウィンドウを開くことができます。そこから、ネットワークアダプタのプロパティ、割り当てられた仮想プロセッサの数、ネストされたホストVMで使用可能なメモリなどを簡単に確認および変更できます。

MACアドレススプーフィングを有効にするオプションは、ネットワークアダプタの詳細設定にあります。グラフィカルインターフェイスを使用して有効にすると、視覚的なアプローチを好む管理者や、すべてのコマンドレットパラメータを記憶していない管理者にとって、迅速かつ簡単に操作できます。

この構成が完了すると、物理ホスト上の Hyper-V コンソール、またはネストされた VM 内から、標準ツールを使用して新しい VM の作成、スイッチの構成、役割の追加、スナップショットの取得など、各ラボのニーズに応じて、日常的な環境管理を相互に行うことができます。

AzureオンプレミスおよびIoT Edgeシナリオにおけるネストされた仮想化

Azure オンプレミス環境では、ネストされた仮想化は同じ原理に基づいていますが、特定のバージョン要件と、AMD SEV やセキュリティ拡張機能などの高度な機能のサポートが追加されています。最小システムバージョン (2411.3 以上) が必要であり、VM は互換性のある構成バージョン (10.0 以降) を使用する必要があります。

Windows上でAzure IoT Edge for Linuxを使用する場合、サポートされているネストされた仮想化デプロイメントオプションは3つあります。それぞれ異なるインフラストラクチャのニーズと、組織が基盤となる環境およびハイパーバイザーに対して維持したい制御レベルに対応しています。

最初の方法は、Hyper-V を搭載したローカルホスト上の Windows 仮想マシンに IoT Edge をデプロイすることです。これは最も簡単な方法です。まず、その Windows VM 上でネストされた仮想化を有効にし、次に Microsoft の専用ドキュメントに従って、Windows 上に Azure IoT Edge for Linux をインストールして構成します。

この場合、ローカルホスト（Windows ServerまたはAzure Local）にHyper-Vロールが正しくインストールされていることを確認することが非常に重要です。ホスト上でHyper-Vがアクティブになっていないと、ゲストVMはネストされたハイパーバイザーとして機能したり、IoT Edgeに必要な機能を追加レイヤーで公開したりすることができません。

このようなデプロイメントは、既存のWindowsインフラストラクチャ内にIoTデバイス、Linuxコンテナ、Azureサービスを統合する必要がある場合に非常に便利で、柔軟性、パフォーマンス、管理の容易さの間で適切なバランスを維持できます。

VMware ESXiとAzure IoT Edgeを使用したネストされた仮想化

VMware ESXi上でホストされているWindows仮想マシン内で、Windows上でLinux版Azure IoT Edgeを実行したい場合も、興味深いシナリオとなります。この場合、ネストされた仮想化は、ハードウェア上のHyper-Vではなく、VMwareハイパーバイザーの機能に依存します。

VMware ESXi バージョン 6.7 および 7.0 では、ゲストOSにおけるハードウェア支援仮想化が明示的にサポートされており、Windows VM を Hyper-V ホストにするために必要なネスト構造を実現できます。VMware はこの機能について、要件と潜在的なパフォーマンス上の考慮事項を詳細に説明したナレッジベースを提供しています。

一般的な手順としては、まずESXiホスト上にWindows仮想マシンを作成します。この際、VMwareの標準的な推奨事項に従って、プロセッサ、メモリ、ストレージ、ネットワークアダプタを設定します。作成後、仮想マシンをシャットダウンし、CPUの詳細設定を変更できるようにします。

ESXiまたはvSphere Clientのインターフェイスから、Windows VMを選択し、「設定の編集」に進みます。CPU設定セクション内で、ハードウェア仮想化セクションを探します。そこで、「ハードウェア支援仮想化をゲストオペレーティングシステムに公開する」オプションを有効にします。これにより、WindowsがESXi内で実行されている場合でも、VT-x/AMD-V拡張機能を認識できるようになります。

変更を保存して仮想マシンを再起動したら、Windows 上に Hyper-V ハイパーバイザーをインストールします。インストール先は、クライアント エディション (Windows 10/11) または Windows Server のいずれかです。その際、IoT Edge で使用するコンテナまたはサービスに必要な管理ツールと追加コンポーネントを必ず含めてください。

Azure仮想マシンにおけるネストされた仮想化

シナリオをさらに発展させて、Azure の仮想マシンをネストされた仮想化ホストとして直接操作する場合、特に仮想スイッチや Azure VM で使用されるデフォルトのネットワークに関して、プラットフォーム特有の問題が生じます。

Windows 上の Linux 版 Azure IoT Edge は、適切な仮想スイッチを有効にするための特定のスクリプトを実行しない限り、サーバー SKU を実行している Azure VM 上でネイティブにサポートされているとはみなされません。このスクリプトは、IoT Edge 環境が追加の仮想化レイヤーと正しく連携して動作できるようにするデフォルトのスイッチを開きます。

Microsoftの公式ドキュメントでは、Azure環境においてWindows上でLinux用の仮想スイッチを作成および構成する手順が説明されており、コンテナやエッジサービスのネットワーク要件をクラウドネットワークインフラストラクチャの特性に合致させることができます。

このようなデプロイメントでは、VM SKU、ストレージの種類、CPUとRAMの割り当て量を特に確認することが重要です。ネストされた仮想化は独自のオーバーヘッドを追加し、セット全体が適切にサイジングされていない場合、内部VMがリソースを大量に消費する可能性があるためです。

こうした複雑さはあるものの、そのメリットは大きい。Azure VMは、IoT Edgeソリューションのテスト、開発、またはプレプロダクションプラットフォームとして、後に現場に展開される物理的なエッジデバイスや産業用ゲートウェイに再現されるのと同じ条件下で使用できる。

専用ソリューションを使用したネストされたHyper-V仮想マシンのバックアップ

ネストされた仮想化環境を設計する際にしばしば見落とされがちなのが、バックアップと災害復旧戦略です。ここで、複数の仮想化レイヤーと複数のプラットフォームが並行して動作するHyper-V環境を適切に管理できる、エンタープライズレベルのバックアップソリューションが重要になります。

こうしたソリューションの中には、 Vinchin Backup & Recoveryのようなツールがあり、VMware、Proxmox、oVirt、OLVM、RHV、XCP-ng、XenServer、OpenStack、ZStack、そしてもちろんHyper-Vなど、15種類以上の仮想化プラットフォームをサポートしています。この種のソフトウェアは、様々なメーカーのハイパーバイザーが共存する異種混在環境向けに設計されています。

継続的な増分バックアップ、データ重複排除と圧縮、きめ細かな復元といった機能により、ストレージ消費量が大幅に削減され、個々のマシン、特定のファイル、あるいは重要なアプリケーションからの特定のオブジェクトの復旧に必要な時間も短縮されます。

さらに、スケジュールされたバックアップポリシーと、テープまたはクラウドへのアーカイブオプションにより、各組織の規制要件や内部要件に合わせてバックアップ戦略をカスタマイズでき、高性能アレイのストレージコストを増加させることなく、長期保存期間を維持できます。

ウェブベースの管理コンソールを使用すると、ネストされた仮想マシンを含む Hyper-V 環境の保護が大幅に簡素化されます。保護対象の仮想マシンを選択し、バックアップリポジトリを選択し、実行戦略（時間枠、バックアップの種類、保持期間）を定義して、ジョブを起動するだけです。これらのソリューションの多くは、パフォーマンスと既存のインフラストラクチャとの統合を評価するための、数週間にわたる包括的な試用期間を提供しています。

ネストされた環境における制限事項とベストプラクティス

ネスト型仮想化の可能性は広範に及ぶものの、ハイパーバイザ自体の設計によって課される技術的な制約も存在するため、本番環境や高可用性シナリオで予期せぬ事態が発生しないよう、これらの制約を最初から理解しておく必要がある。

明確な例として、ネストされた仮想化を使用した仮想マシンのライブマイグレーションが挙げられます。現状では、アクティブなネストに依存するゲストを含む仮想マシンが稼働しているプラ​​イマリホストのライブマイグレーションは実行できません。マイクロソフトはこの制限について文書化しており、このような環境では、アップデートやホストの移動を計画する際には、シャットダウンを段階的に行うことを推奨しています。

複数のレイヤーにわたるリソース消費量を監視するには、複合的な戦略が必要です。最上位ホストではHyper-Vマネージャー、パフォーマンスカウンター、Get-VMなどのコマンドレットを使用し、同時にネストされたホスト内でも同様のツールを使用して、CPU、メモリ、ネットワーク、ストレージへの負荷の分散状況を明確に把握することをお勧めします。

内部仮想マシンが突然ネットワーク接続を失う場合、通常はファイアウォールルールの変更、NATの問題、または関係するアダプタのいずれかでMACアドレス偽装設定が無効になっていることが原因です。すべてのレベルを確認し、構成を検証し、影響を受けているネットワークサービスを再起動することで、これらの障害のほとんどは解決します。

一般的なベストプラクティスとして、ネストされた仮想化を導入する前に、環境の目的、レイヤー数、実行するワークロードの種類、およびバックアップポリシーを明確に定義することをお勧めします。この初期設計によって、ラボ環境またはテスト環境が長期的に持続可能であり、保守が困難な複雑な状態にならないかどうかを判断できます。

要するに、Hyper-Vやその他のプラットフォームのネストされた仮想化により、CPU要件、システムバージョン、ネットワーク構成が遵守され、かつ適切な監視およびバックアップ戦略が伴う限り、既存のハードウェアを最大限に活用し、ラボ、テスト、セキュリティ、IoTエッジのシナリオを非常に柔軟に構築することが可能になります。