Azureには、ユーザーに何も言わずに 仮想マシンのハードウェア構成をランダムに変更する という習慣があるようです。
もちろん、これは documentation で言及されていますが、やや漠然としています。
Can I manually assign IP addresses to NICs in virtual machines?
No. You must not change any interface properties of VMs. Any changes may lead to
potentially losing connectivity to the virtual machine.
そして:
Will the MAC address remain the same for my virtual machine once it has been created?
No. A virtual machine’s MAC address can change for a few different reasons. If the
VM is put in the status Stopped (Deallocated), if you change the virtual machine size,
or if there is service healing or planned maintenance of the Host server, the MAC
address is not retained.
実際に発生しているように見えるのは、何らかの「サービス」が行われているときはいつでも、既存の仮想NIC for a VMが削除され、新しいものに置き換えられることです。 、MACアドレスを変更し、allネットワーク構成をデフォルトにリセットします。
ただし、ゲストオペレーティングシステムで悪名高いよく知られている ゴーストNIC の急増につながることは別として、これはあらゆる種類の問題につながる可能性もあります。
1つは、もちろん、ハードウェアベースのライセンスにMACアドレスを使用するアプリケーションを実行するなど、何らかの目的で実際にMACアドレスに依存している場合です。
ここ で説明されているもう1つの方法は、WindowsシステムでDHCP構成されたNICがDNSにPTRレコードを登録しないことです。 Use this connection's DNS suffix in DNS registration
はTCP/IPの詳細設定で有効になっています。そしてもちろん、AzureはDHCPを使用するために仮想NICを明示的に要求します...そしてこのオプションはデフォルトでnot有効になっており、notは、Azureが既存のNICを新しいものに置き換えることを決定した場合、有効になりません。つまり、さようなら、PTRレコードです。
つまり、Azureが仮想NICをランダムに新しいものに置き換えたり、仮想NICで行った構成の調整をすべて失ったり、MACアドレスを変更したり、ゴーストNICをゲストシステムに残したりするのを防ぐ方法はありますか?
いいえ、これはできません。したがって、MACアドレスのライセンスまたはPTRレコードに依存するものは、Azureを検討している場合は避けたいものです。