specify which local ip to give to my vm when I create or attach it.
Specify which local ip to give to my vm when I create or attach it. This way I can specify a series of dns servers and then actually have servers to apply those addresses to. This is also helpful when migrating servers since it will then maintain its addressing structure.
We are looking at this ability in a future release. No specific timeline decided, just yet.
[Deleted User] commented
This would also be very useful for non-permanent environments.
For example - to keep costs down, I don't want to run my test environment 24x7 since it is only used during office hours.
The environment is running within its own VNET and I have my own DNS resolver in the environment that each VM dynamically registers with when its IP changes (via a dhcpd hook).
However, I still have some problems that come about when I stop/deallocate the entire environment (which is the state I have to take it to in order to stop being billed):
1) If the DNS server is restarted on a different IP, the VNET configuration needs to be updated with the new IP. I _could_ write a startup job on the DNS server to perform this update via the Azure API.
2) When the environment comes back up, a race condition occurs - for example, I have a 3-node MongoDB cluster, and replication uses the hostnames of each of the members of the replica set. If the nodes come back up in a different order to what they did originally I've seen the equivalent of the following happen:
- The original IP addresses were:
- node3 is rebooted first and gets ******** - when it looks for its replication set members, a DNS lookup of "node1" still returns ******** (as node1 hasn't updated DNS yet). So node3 attempts to replicate with itself. I _could_ get round this by deleting DNS records on shutdown of each VM to prevent stale ones existing, but then I'd need to handle NXDOMAIN responses elsewhere
3) We also deploy Redis, which, when deployed in a master/***** setup writes the master's IP rather than hostname to its config files. I'm currently working around this by replacing IPs with hostnames in my Redis shutdown script, but if I implemented my solution to point (2) above I'd potentially not be able to look up the hostnames if those DNS records had already been removed.
So while I can work around all these problems, it would be way easier if I could set DHCP reservations within my VNET. After all, it is our own private DHCP scope!
Apologies for the long comment, but I think its valuable to give real-world examples of these issues.