CloudStack is highly flexible when it comes to the infrastructure it manages. It supports multiple hypervisors and network features, and even provides network services itself. The result is complexity which makes it difficult to troubleshoot network issues. This talk will identify the top 10 CloudStack network issues, as well as explain troubleshooting techniques to troubleshoot and resolve them.
Apache CloudStack runs on Tomcat and uses a MySQL database, and a typical environment will have one or two servers running CloudStack and one or two servers running MySQL. As long the CloudStack servers can reach each other and the database servers, there shouldn’t be any problems or significant complexity with the networking of CloudStack itself.
The complexity will primarily be focused in the configuration of the virtualization environment (hypervisor hosts, storage devices, switches, routers, and so on) managed by CloudStack, along with the configuration for the environment that must be performed in CloudStack. Besides configuring CloudStack and the virtualization environment, the VM guest OS may need
There are many areas of the environment configuration where people can run into trouble, including:
VLANs - One of the ways CloudStack can provide isolation for VMs is by using VLANs to separate traffic onto separate logical networks. The implementation of VLANs in the virtualization environment has proven to be difficult for many people implementing CloudStack.
Security Groups - Another way CloudStack provides isolation is with Security Groups. The behavior and implementation of Security Groups varies by hypervisor, and many CloudStack users run into trouble.
Connectivity to and from hypervisor hosts - CloudStack requires the ability communicate with hosts, and vice versa, to enable management of said hosts. How the connectivity works varies by hypervisor, but it is critical to understand and implement correctly.
Once the environment is built, CloudStack must be configured to manage it. There are several aspects of this configuration that are difficult, including:
Physical networks - In CloudStack 3.0 the concept of physical networks was introduced, but this configuration is commonly misunderstood. It is critical to configure physical networks correctly
Console proxy - CloudStack provides convenient, web-based access to the “physical” consoles of VMs. Access to these consoles depends on certain conditions being met. Additionally, the consoles are secured by SSL which can introduce additional complexity.
The last areas of networking that prove to be difficult include the network services provide by CloudStack, and the configuration of the guest OS running in VMs managed by CloudStack. Considerations include:
Templates - CloudStack makes heavy use of the concept of templates. A template is a disk image prepared with an OS to allow very quick deployment of VMs. There is no way way to generalize (e.g. “sysprep”) the images through CloudStack, and network issues can be the result of not carefully preparing templates.
Password resets - CloudStack provides useful functionality that allows the resetting of a root or administrator password on a VM. This functionality is enabled by a script that must be installed and configured in a VM, plus a daemon that runs on a CloudStack-managed virtual appliance. This script has dependencies and can fail, and the daemon can potentially fail as well.
User- and meta-data - By default CloudStack provides several pieces of information via meta-data that is accessible to VMs, and an end-user can provide additional custom information user-data containing the information of their choice. This data must be accessed in a particular way, and it may be difficult to troubleshoot if the functionality is not working.