satis egitimisatis egitimitengda.pro

Open@Blog

Discussion on the state of cloud computing and open source software that helps build, manage, and deliver everything-as-a-service.

  • Home
    Home This is where you can find all the blog posts throughout the site.
  • Categories
    Categories Displays a list of categories from this blog.
  • Tags
    Tags Displays a list of tags that has been used in the blog.
  • Bloggers
    Bloggers Search for your favorite blogger from this site.
  • Login
Subscribe to this list via RSS Blog posts tagged in cloud computing

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.

You can find this FAQ and many others in the Cloudstack Knowledgebase.

Hits: 8092
Rate this blog entry:
Continue reading Comments

Open@Citrix

Citrix supports the open source community via developer support and evangeslism. We have a number of developers and evangelists that participate actively in the open source community in Apache Cloudstack, OpenDaylight, Xen Project and XenServer. We also conduct educational activities via the Build A Cloud events held all over the world. 

Connect