AzureでWindows仮想マシンを複製する際の注意点
はじめに
Azure Virtual Desktopなどが出たことにより、仮想マシンを複製してデプロイしたいと思うことが増えたと思います。
今回は、仮想マシンを複製する際の注意点について記載いたします。
簡単な結論
取り急ぎ、結論だけ知りたいと言う方向けの情報ですが、Windows仮想マシンを複製する場合は、以下の三つのURLに記載の手順を順番に実施してください。
Windows VMを複製する場合の注意点
AzureでWindows VMを複製する場合の注意点は複数あります。この点について、まとめます。
Windowsの複製はサポートされない
まずは、Windowsのディスクコピーに関する注意点です。
Azureに限らず、Windows VMでは、イメージを一般化(Sysprep)せずに別のPCに移動またはコピーすることはWindowsとしてサポートされない操作となります。
記事抜粋
-----
PC を一般化せずに Windows イメージを別の PC に移動またはコピーすることはサポートされていません。
-----
このため、バックアップからの復元は別として、VMを複製するために、仮想マシンのOSディスクをコピーして、仮想マシンを複製したとしても、動作は保証されません。
必ず、Sysprepを行って一般化をおこなってください。
なお、Sysprep自体にも、いくつかのサポート範囲がある様子です。個人的には、複製を作る際は、新規のOSイメージから必要な設定のみをおこなった上で、Sysprepして複製することがおすすめです。
Azure VMの要件に関しての注意点
Azureでは、仮装マシンから特定のサーバ(IPアドレス)に対しての通信ができない場合、仮想マシンのプロビジョニングやデプロイがうまくできないといったことが発生します。この特定のサーバというのが、IPアドレス168.63.129.16を持つサーバで、DHCPやDNSのサービスのほか、VMの状態をVMゲストエージェントから受け取るような機能を持っています。
こちらのサーバへの通信は、上記ページの記載の通り、NSGなどのAzure上の設定の対象とならないようにAzure側で設定されています。
以下抜粋
----
これらのポート上での 168.63.129.16 との通信は、構成されたネットワーク セキュリティ グループの対象ではありません。
----
上記のように、Azureリソース上では、特別扱いされる168.63.129.16ですが、OS上では、そうはいきません。
すなわち、OS上で、通信がProxy経由になっている場合や、OSのFirewallで遮断されている場合は、この168.63.129.16と正しく通信ができないということが起こります。
このケースでは、仮想マシンのプロビジョニングやデプロイ時に問題が発生し、エラーとなる場合があります。
Azure VMの要件を満たすためには
これは簡単で、以下のサイトの方法を実行するだけで問題ありません。
こちらのページでは、ディスクチェックなども含まれますが、Azure VMの要件を満たすためのFirewall設定やProxy設定についても記載されていますので、こちらの手順通り実施すれば良いです。
ただし、上記に含まれない内容として、複製元のVMに追加したセキュリティソフトなどの設定が起因で、168.63.129.16への通信ができないといったこともありますので、この点はSysprep前にご確認ください。
スナップショットなどからの複製がなぜ良くないのか
こちらに関しては、網羅的には記載できませんが、例えば以下のような問題が発生します。
PCのセキュリティ識別子など、PC固有の情報までコピーされてしまう
例えば、セキュリティ識別子などは、AD参加する際にPCを識別するための情報として使われます。Azure Virtual Desktopなど、ADを前提とするような環境では、同じPCが複数存在すると扱われるため、問題が発生します
Azure上で同一のホスト名を持つVMとなる
スナップショットなど、VMの一般化をしない複製では、ホスト名が同一となります。そのため、同一サブネットに複製したVMをデプロイしようとすると、ホスト名の重複が起き、VMの名前解決ができなかったり、そもそもDNSに名前を登録できずにデプロイできなかったりという問題が発生する可能性があります。
終わりに
AzureやHyper-Vなど、仮想化技術が進歩した結果、ディスクのコピーも簡単にできるようになっています。
一方で、OSディスクのコピーはかなりセンシティブなものとなります。
OSディスクの複製は、きちんと仕様を確認して実施するようにしてください。