Some interesting conversation around this topic came up during our Disaster Recovery for vCloud testing, and they also rang true when I visited the vCloud Director Bootcamp at Partner Exchange a few weeks ago. The challenge has to do with how to deal with vApps that are getting IP Addresses from a Static IP Pool within vCloud Director. In turn, what if those IP Addresses are part of a vShield Edge Firewall rule? First, we need to understand one major thing.
Static IP Pools are just that. A pool of IP addresses that vCloud Director assigns as a Static IP to the Operating system. However, these are not something you can designate to any particualr VM. It’s like a pool of phone numbers for that matter. Have you ever gotten a new phone number and had calls from people looking for the previous number owner? That’s because the number you got went BACK into the pool when the original owner gave it up. Static IP pools work the same way. The key is this can also affect how you create or handle operational aspects of the vShield Edge firewall rules. Here is a simple Scenario:
Static IP Pool Range = 192.168.0.10 – 192.168.0.20
Virtual Machines are deployed that get assigned static IP’s from this pool in the following order:
VM1 = 192.168.0.10
VM2 = 192.168.0.11
VM3 = 192.168.0.12
VM4 = 192.168.0.13
VM5 = 192.168.0.14
VM6 = 192.168.0.15
Now, let’s say that VM3 has is a web server and has firewall rules for the inbound ports of 80,443,and 22 but the others in the list have no incoming rules. We can also assume that VM3 has a NAT for an external address through vShield Edge. Now, let’s pretend that VM3 is determined to need a rebuild and is removed from vCloud Director.
What do you think happens to its IP address?
If you answered “It goes back into the pool” you are correct! Also, we must assume there is more than one user in this organization creating Virtual Machines. Do you think before you can re-create your VM3 that the .12 address could be re-issued to a new VM and your re-deployment can get a new address of 192.168.0.16? The answer is absolutely! That also means that your original firewall rules are now open to the virtual machine that some other user created which they may not want or even know about. You can see how this would also translate to a Disaster Recovery Scenario where IP addresses could change based on the recovery site’s different Static IP Pool configuration and why it came up in those discussions.
Possible Work Around
Everyone Out of the Pool…..
So how can we work around this? Really the anser is to select “Static – Manual” for the IP addresses if your cloud Virtual Machines are going to be around for some time. Now in a Public cloud you may not have this option especially on external IP’s you do not control directly. I have seen this situation happen to me real-time in my public cloud as I was building some vApps. I grabbed an external IP, but had to rebuild and when I did I got a new external IP. I had to update my DNS and firewall rules accordingly. Now I will never delete the vApp so I can keep the IP address it has since the provider does everything with pools.
Another possible way to deal with this is through orchestration. I could see ways to leverage a custom portal and orchestration to assign the IP addresses based on the usage of the VM. For example, pools are great for test/dev that is not going to need firewall rules, but having that question as part of the workflow might be useful before the VM is created. Many providers have put the firewall rule capability into their custom portals today.
The point here is simple. You need to know that anything pool based, like IP addresses could be re-assigned over time as virtual machines are created and destroyed. In a private cloud however, you have the option of controlling this through the use of manually assigning an IP Address in vCloud Director. Don’t get frustrated if you see your IP change when you delete and re-create a vApp. It can and will happen, you just need to be aware of it and understand you need to deal with it operationally. Play with this yourself and you will see IP Addresses get used and re-inserted back into the pool. The best I can tell in my testing is that vCloud Director will always use the lowest IP available in the pool when it assigns one through a “Static – IP Pool”.