Azure Virtual Machines and DNS settings
Posted from Shan McArthur’s Blog
The Windows Azure fabric controller will service your Azure virtual machines from time to time. This blog article will outline the impact this will have on your virtual machines and what you have to do to ensure that your virtual machines remain healthy in the Azure data centers.
There are many events that can occur in the Azure data centers that will result in a ’service operation’ being performed on your virtual machine. These could be related to actual hardware failures, or could be as simple as Microsoft performing data center maintenance or upgrading the host machines that are running your virtual machines. It is important to understand the impact of what these types of service operations will have on your virtual machine so that you can configure the virtual machines properly to survive these service operations.
What changes and what does not change? The hard drive that is used to host your virtual machine is store in Azure blob storage and will not be affected during a service operation. Stated another way – you won’t lose your virtual machine. The same can be said for all of the data drives that are attached to your virtual machine. The only exception to this is the temporary drive that is mounted as the D: drive when you create the virtual machine. Data on this drive is only persisted on the host machine and is not migrated to new hardware when the machine is moved to another host. A service operation will result in your virtual machine having a brand spanking-new D: drive with no files or custom security applied to it. As such, do not put anything that you want persisted on this drive, and make sure that if you are using this drive for temporary storage, that your application can automatically recreate the folders when it is rebooted and started.
Windows Azure will also not change the IP address of your server when it is associated to a virtual network. Read this carefully. It has to be associated to a virtual network AND the only guarantee is that the IP address will not change. That said, the MAC address of the virtual network card may change and that will have some important consequences on your virtual machine configuration.
It is probably best to give a quick description of how IP addresses and network cards work in an Azure environment. You start out by defining a virtual network in Azure, then you provision services inside that virtual network. Windows Azure will then give out appropriate IP addresses and DNS server settings from your virtual network definition when it dishes out a DHCP address. If you are hosting an Active Directory domain in Azure (with domain controllers), it is important that you set the dns server settings properly in your virtual network configuration. I would like to point out that it is an unsupported configuration to set your IP addresses manually in your virtual machine without using DHCP. The problem is that if you do this, the IP address will be associated to that specific network card, but when an Azure service operation occurs, your virtual machine will loose that network card and get another one. Windows Server will do its thing and automatically pick up the new network card and will automatically use DHCP for the IP address and DNS address and you will lose your network configuration that you made on your old network card. This has specific implications for Active Directory domains. If the IP address of your machine changes because DHCP is giving you a different IP address than you manually set on the machine, domain members may not locate the domain controller and the network may start to fail. If this is a domain controller and its DNS server is set to the Azure external dns servers or another server other than itself, the domain controller itself will have problems using the ntds portions of DNS and within a few days the netlogon service will fail and no authentication to the domain will be possible until you reboot the server and rectify the problem. The bottom line is that a service operation in Azure will give your virtual machine a new network card, so you should only use the DHCP provided IP address and dns settings to ensure that your machine will be healthy after a service operation.
Some network administrators will want to ensure that their domain controllers use their own dns server on the local machine, and they do this by specifying 127.0.0.1. This configuration is not mandatory, but if you want to do this, the only way to do this in a supported manner is to set up your virtual machine using PowerShell and specifying the dns server IP in the creation script. This will ensure that the Azure DHCP server will serve the appropriate dns setting to that local virtual machine.
So how do you recognize if you have a problem? The easiest thing to do is to log into all of the virtual machines in your network and ensure that you have the network configuration set to using DHCP for the IP address and the dns server address. If you find that you have a machine that normally works and then starts to fail when nobody has made a change to it, check the event logs for network events and the last reboot. If your failure follows an unscheduled restart, you could be seeing the impact of a service operations – just go and double check that the dns server and IP address are set appropriately using IPCONFIG /ALL.
If you notice that your dns servers are set to an external IP address, this is an indication that your dns servers are not set in your virtual network, or that you may not even have a virtual network. If this is the case, make the change and reboot all servers, ensuring that they pick up their dns server settings.
If you are not using a virtual network and you are using a domain controller, you will experience problems. You may use this type of configuration in a temporary dev or demo environment. If you want to use this configuration, your only other choice is to add a loopback adapter to the virtual machine and configure the IP address on that NIC to use its own IP address. I have used this configuration in the past, but with the latest version of the Azure portal, it is so easy to manage virtual networks that I highly recommend just setting up a virtual network, even for these temporary environments.
