This month's tip is an issue that has come up repeatedly in the Cloudstack IRC channel, particularly when people are first starting to play with CloudStack or setting up a proof of concept environment. The situation is that CloudStack is being setup, often with Basic Networking on a portion on a subnet that already has a DHCP server in place.
CloudStack operates it's own DHCP server and that often conflicts, and wreaks havoc both on the 'native' DHCP server and the VMs in CloudStack. So why does CloudStack need to operate it's own DHCP server? Well there are a number of reasons, but lets quickly go over a few. CloudStack provides a number of networking services, such as basic firewalling, loadbalancing, etc, and some generally less vital services such as the console proxy. A lot of those require knowledge of the IP address assigned to the virtual machine.To be sure, there are ways to determine what IP address was handed out by an external DHCP server, such as sniffing all the traffic coming over the bridged network interface looking for DHCP offers and acks. That method however is a bit expensive from a resource standpoint, and at scale, using CloudStack's DHCP server works well anyway. CloudStack also needs to keep track of the resources (IP addresses in this instance) so that it can properly choose when to allocate an address from a different network.
So what is one to do when two DHCP servers need to inhabit the same network? The easiest way to do so is to have the address ranges assigned to CloudStack be excluded from the range handed out by the external server. In addition, you should exclude the MAC addresses that CloudStack provisions machines from. All CloudStack provisioned machines have a MAC address that begins with 06 in the first octet. So having the external DHCP server ignore any MAC address with 06 in the first octet will make it easy for an external DHCP server to cohabitate on the same network CloudStack inhabits.