かつて山市良と呼ばれたおじさんのブログ

セイテクエンジニアのブログ  かつて山市良と呼ばれたおじさんのブログ  vol.18 ラボ環境 on Azureを作る(6) - VMテンプレートを作成する

 

 

vol.18 ラボ環境 on Azureを作る(6) - VMテンプレートを作成する

2024年06月13日配信
2024年07月12日更新
執筆者:山内 和朗

 前回までのラボ環境の構築作業で、Azure仮想マシン(Azure VM)の中にHyper-Vホスト環境をセットアップし、クローズドな仮想ネットワークにHyper-V仮想マシン(Hyper-V VM)を作成できる環境が出来上がりました。今回はこのHyper-Vの環境に、新規にHyper-V VMを作成し、ゲストOSとしてWindows Serverをインストールします。そして、そのインストールを一般化して、Hyper-V VMのテンプレートイメージを作成します。テンプレートイメージを作成しておけば、ゲストOSがインストール済みのHyper-V VMを複数、すばやく作成できるようになります。

 

ゲストOSのインストールメディア(ISO)を準備する

 

 Hyper-Vでは、さまざまなバージョンのWindows、Windows Serverと、Linuxディストリビューションを実行することができます(参考:サポートされているゲスト オペレーティング システム≪外部サイト≫)。

 

 今回は、Windows Server 2022をゲストOSとしてインストールします。評価、検証目的での利用のため、以下のサイトで提供されている180日評価版「Windows Server 2022 Evaluation」のISOイメージを使用します。評価期間は180日で切れますが、その期間は最大6回リセットできます(cscript slmgr.vbs /rearm)できます。そのため、うまくリセットを繰り返せば、最長で丸3年(180日×6回)は利用可能です。

Windows Server 2022 | Microsoft Evaluation Center
https://www.microsoft.com/ja-jp/evalcenter/evaluate-windows-server-2022

 

 今回はWindows Server 2022(Evaluation)を使用しますが、製品版(Standard、DataCenter)はもちろんのこと、Windows Server 2019やWindows Server 2016の場合も手順は変わりません。

 

Hyper-V VMの(仮想)ハードウェアを準備する

 

 まず、「Hyper-Vマネージャー」を開き、「操作」ペインから「新規>仮想マシン」をクリックして、「仮想マシンの新規作成ウィザード」を開始します。ウィザードの指示に従って、名前や格納先を指定します(画面1)。前回、既定の場所として仮想ハードディスク「D:¥VM¥Virtual Hard Disks」と仮想マシン「D:¥VM¥Hyper-V」を設定しましたが、私としては、仮想マシンごとにフォルダーを分けたいので、「D:¥VM」のように個別に設定するのが好みです。この場合、仮想マシンのVHD(x)と構成は、「D:¥VM¥<仮想マシン名>¥Virtual Hard Disks」と「D:¥VM¥<仮想マシン名>¥Virtual Machines」に格納されることになります。

画面1
画面1 Hyper-Vに仮想マシンを新規作成し、名前と格納先を指定する

 あとは、ウィザードに従って「世代」でUEFIベースの「第2世代」(推奨)を選択し、「メモリの割り当て」でメモリサイズを指定します。「ネットワークの構成」では、前回準備した内部タイプのNATが構成された仮想ネットワーク「NATSwitch」を選択します。「仮想ハードディスクの接続」では、ディスクサイズを調整し(既定の127GBから64GBに変更しました)、「インストールオプション」で「ブートイメージファイルからオペレーティングシステムをインストールする」を選択して、Windows ServerのインストールメディアのISOイメージを指定します。最後に、「完了」をクリックして仮想マシンの作成を完了します。

 仮想マシンを作成したら、すぐ開始(起動)したいところですが、仮想マシンの「設定」を開き設定内容の確認やカスタマイズを行うことをお勧めします。例えば、既定では仮想プロセッサの数は「1」なので、「2」や「4」に変更します。また、評価や検証では、実行中の状態をチェックポイントで保存したいことがよくあります。Windows Server Hyper-Vの既定のチェックポイントの種類は「運用チェックポイント(Production)」であり、ディスク状態のみのチェックポイントだけが取得されます。稼働中のメモリ状態を含むチェックポイントを作成するには、「標準チェックポイント(Standard)」(Windows 10/11 Hyper-Vの既定はこちら)に変更します(画面2)。

画面2
画面2 仮想プロセッサの数や、チェックポイントの種類の変更を行う

 

(オプション)Hyper-V VM on Hyper-V VMを可能にする

 

 Hyper-V VMのゲストOSでハイパーバイザー関連機能(Hyper-V、コンテナー、Windows Subsystem for Linux≪WSL 2≫、仮想化ベースのセキュリティ≪VBS≫など)を利用する予定がある場合は、Hyper-V VMがオフの状態で、PowerShellで以下のコマンドラインを実行して、Hyper-V VMで入れ子になった仮想化を有効化します。

PS C:\> $vmname = "<仮想マシン名>"
PS C:\> Set-VMProcessor -VMName $vmname -ExposeVirtualizationExtensions $true
PS C:\> Get-VMNetworkAdapter -VMName $vmname | Set-VMNetworkAdapter -MacAddressSpoofing On


 このラボ環境も入れ子になった仮想化をサポートするVMシリーズのAzure VM(Azure IaaSのプラットフォームはHyper-Vベース)で構築したものですが、その中でさらに入れ子になった仮想化を利用することができます。これを「Hyper-V VM上のHyper-V VM(Hyper-V VMs on Hyper-V VMs)」(外部サイト)と呼びます。

 

 Hyper-V VMの(仮想)ハードウェアの準備ができたら、起動してゲストOSのインストールを開始します(画面3)。

画面3
画面3 Hyper-V VMを作成し、設定を調整し終えたら、Hyper-V VMを起動する

 

Hyper-V VMにゲストOSをインストールする

 

 Hyper-V VMを起動し、「仮想マシン接続(vmconnect.exe)」でそのコンソールに接続します。インストールメディアから起動するには起動直後の“Press any key to boot from CD or DVD...”と表示されている数秒間の間に何かキーを押す必要があるのですが、間に合わなかった場合次の起動順に進んでいるか(>>Start PXE over IPv4.)、さらにそれも失敗して「Microsoft Hyper-V UEFI」メニュー画面(「Restart now」で再起動できそうに見えますが、マウスもキーボードも聞かない画面です)に進んでしまっているかもしれません。その場合は、「仮想マシン接続」ウィンドウの「|>(リセット)」ボタンをクリックして、起動し直して再チャレンジしてください。

 Windows Server 2022 Evaluationのインストールメディアからは、以下の4つ(2つのエディションと2つのインストールの種類の組み合わせ)から選択できます。Windows Serverの導入に慣れていないと、選択を誤り、意図せずGUIの無い状態(Server Core)でインストールされてしまうので注意してください。既定で選択されているものは、「Windows Server 2022 Standard」のServer Coreです。GUIを利用したい場合は、「(デスクトップ エクスペリエンス)」が付いたものを選択してください。製品版のインストールメディアを使用する場合も同様です。

 

  • Windows Server 2022 Standard Evaluation
  • Windows Server 2022 Standard Evaluation(デスクトップ エクスペリエンス)
  • Windows Server 2022 Datacenter Evaluation
  • Windows Server 2022 Datacenter Evaluation(デスクトップ エクスペリエンス)


 Windows Server 2022を新規インストールする際には、「vol.4 推奨パーティション構成でクリーンインストールするには」の手順で行うことをお勧めします(画面4)。このブログではお馴染みのあの更新エラーを回避するためです。

画面4
画面4 vol.4で説明した手順で、推奨パーティション構成にしてから、インストール先としてWindowsパーティションを選択する

 

しばらく続く待ち時間、ラボ環境のネットワークをチェックしてみよう

 

 Windows Serverのインストールにはしばらく時間がかかりますが、その間に、ラボ環境のネットワークがちゃんと機能することをチェックしてみましょう。

 WindowsやWindows Serverのインストール中、最初の再起動が始まるまでは、いつでも「Shift」+「F10」キーでWinPEのコマンドプロンプトを呼び出せます。コマンドプロンプトが出現したら、「startnet」と入力してWinPEのネットワーク機能を有効化し、「ipconfig」を実行し、IPアドレスを確認します。

X:\Sources> startnet
X:\Sources> ipconfig

 このラボ環境はHyper-VホストがDHCPサーバーを兼ねて、NATが有効な内部ネットワークにIPアドレスやDHCPオプションを提供します(前回を参照)。スコープ内のIPアドレスが自動的に割り当てられ、デフォルトゲートウェイが適切に構成されていることが分かるでしょう(画面5)。ラボ環境のクローズドなネットワークはちゃんと機能しているようです。ゲストOSのインストールが完了すれば、追加設定することなく、ネットワーク機能をすぐに利用できることになります。

画面5
画面5 WinPEのコマンドプロンプトを呼び出し、ネットワークがちゃんと機能している(DHCPで構成されている)ことを確認しておいた

 

OSアップデートと環境のカスタマイズを行い、イメージを一般化する

 

 OSのインストールが完了したら、Windows Updateを実行して、最新の更新プログラムが検出されなくなるまで、インストールと再起動を繰り返します。標準のブラウザーであるMicrosoft Edgeも最新状態に更新しておきましょう。

 また、評価や検証で用いることがある標準的なツールやアプリ、Windows Serverの役割や機能(例えば、Hyper-Vの役割やTelnetクライアントの機能)があれば、この段階でインストールまたは有効化、またはコピーしてます(ただし、Sysprepによる一般化の影響を受けないもの)。

 テンプレート化の準備ができたらコマンドプロンプトを開いて、次のコマンドラインを実行します。これにより、イメージが一般化され、新しいHyper-V VMのデプロイに再利用できるようになります(画面6)。なお、「/mode:vm」パラメーターは、仮想ハードディスク(VHD(x))を一般化して、VHD(x)を同じVM(Hyper-V VMまたはAzure VM)としてデプロイできるようにする、VMからのSysprepの実行でのみ利用可能なオプションです(ハードウェア構成の検出がスキップされるため、Sysprep後の初回起動時にかかる時間が短縮されます)。また、Sysprep /generalizeの実行は、評価期間のリセット回数を1つ消費することになることにも留意してください。

C:\> cd C:\Windows\System32\sysprep
C:\Windows¥System32¥Sysprep> sysprep /oobe /generalize /shutdown /mode:vm

画面6
画面6 Sysprepを実行して、イメージを一般化する

 

 Hyper-V VMのゲストOSがシャットダウンされ、オフの状態になったら、仮想マシンを右クリックして「エクスポート」を選択し、データディスクのボリューム上のパスを指定してエクスポートします。エクスポート先には、仮想マシンのVHD(x)、仮想マシンの構成、チェックポイント(作成してある場合)が格納されます。

 

画面7

画面7 Hyper-V VMをエクスポートして、再利用可能なVMテンプレートにする


 このテンプレートイメージをHyper-V環境にインポート(インポートの種類:仮想マシンをコピーする)すれば、ゲストOSがインストール済みのHyper-V VMをすばやくデプロイできます。あるいは、テンプレートイメージの仮想ハードディスク、VHD(x)を共通の親ディスクとする、差分(子)ディスクを複数作成して、新規作成した複数のHyper-V VMに割り当てることで、ディスク使用を効率化しながら、複数のHyper-V VMを用意することができます。

 Sysprepで一般化したイメージから起動すると、Windowsセットアップの最終段階(Mini-Setup)の「設定のカスタマイズ」まで進みます。Windows Serverの場合はAdministratorのパスワードの設定のみでOSのセットアップが完了します。Mini-Setupを自動化する応答ファイル(unattend.xml)」(外部サイト)を作成し、既定の検索パス(C:ドライブのルート、C:¥unattend.xmlなど)に配置しておけば、設定のカスタマイズを含めて自動化できます。応答ファイル(unattend.xml)はSysprepを実行する前にコピーしておくこともできますし、エクスポート後のVHD(x)をローカルマウントしてコピーすることもできます。

 応答ファイル(unattend.xml)は作成するのが難しそうですが、私の旧ブログ(外部サイト)でWindowsやWindows Serverにそのまま使えるサンプルがいくつか見つかりるでしょう。次に示す応答ファイル(unattend.xml)は64ビットWindows 10の応答ファイルを少しカスタマイズしたもので、Windows Server 2022の設定のカスタマイズ(コンピューター名はランダム、ワークグループ構成、AdministratorのパスワードはP@ssw0rdなど)を完全に自動化できます。

 

Windows Server 2022で検証済みの応答ファイル(Unattend.xml)のサンプル

<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
    <settings pass="specialize">
        <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <ComputerName>*</ComputerName>
        </component>
        <component name="Microsoft-Windows-UnattendedJoin" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <Identification>
                <JoinWorkgroup>WORKGROUP</JoinWorkgroup>
            </Identification>
        </component>
    </settings>
    <settings pass="oobeSystem">
        <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <OOBE>
                <HideEULAPage>true</HideEULAPage>
                <HideLocalAccountScreen>true</HideLocalAccountScreen>
                <HideOnlineAccountScreens>true</HideOnlineAccountScreens>
                <HideWirelessSetupInOOBE>true</HideWirelessSetupInOOBE>
                <ProtectYourPC>3</ProtectYourPC>
            </OOBE>
            <UserAccounts>
                <LocalAccounts>
                    <LocalAccount wcm:action="add">
                        <Password>
                            <Value>P@ssw0rd</Value>
                            <PlainText>true</PlainText>
                        </Password>
                        <Group>Administrators</Group>
                        <Name>Administrator</Name>
                    </LocalAccount>
                </LocalAccounts>
            </UserAccounts>
            <TimeZone>Tokyo Standard Time</TimeZone>
        </component>
        <component name="Microsoft-Windows-International-Core" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <InputLocale>ja-JP</InputLocale>
            <SystemLocale>ja-JP</SystemLocale>
            <UILanguage>ja-JP</UILanguage>
            <UserLocale>ja-JP</UserLocale>
        </component>
    </settings>
</unattend>

 

  これでラボ環境 on Azureの環境は一通り整いました。いつでも、必要な数だけ、VMテンプレートからHyper-V VMをデプロイして、すばやく評価環境を準備することができるようになりました。このブログの第2シーズン、名付けて“雲の上の帝国”編の終了です。

 

 次回からはこの環境を利用して、評価、検証でよく必要になる電子メール環境、それもインターネットに転送されないクローズドな電子メール環境を、いつでもすばやく準備できる方法を検討します。それには、Windows Subsystem for Linux(WSL 2)の環境を利用するつもりです(4月後半にメモとしてチラ見せしました)。次回、第3シーズン、“暗闇のWSL 2、攻略戦”編のスタートです。

 

 

追記:

 この連載では、Hyper-Vの入れ子になった仮想化(Nested Virtualization)を評価、検証環境のために使用していますが、オンプレミス、Azureの両方とも、Hyper-Vの入れ子になった仮想化は、いくつかのシナリオおよび制約(Azure VMではNATネットワークを使用など)の下、運用環境での使用がサポートされてます。

 

次のシナリオでは、運用環境での入れ子になった Hyper-V VM の使用が、Azure とオンプレミスの両方でサポートされています。 また、サービスとアプリケーションもサポートされていることを確認することをお勧めします。
 入れ子になった仮想化の概要(Microsoft Learn)
Azure 仮想マシンに対する Microsoft サーバー ソフトウェアのサポート(Microsoft Learn)

blog_subscribe

blog_comment

最新記事