Making the CloudStack "Quick Install" quicker

Jul 8, 2012   //   by Daniel Kranowski   //   Algorithms  //  1 comment

After preparing Apache CloudStack according to the directions in the “Basic Installation Guide”, which is also called the “Quick Install Guide”, you’re supposed to login to the management server web ui and “provision your cloud infrastructure.” The web ui’s Basic Installation wizard takes you through 17 screens before you get to click the Launch button and actually deploy system VMs onto your hypervisor. The Guide is definitely helpful but I think it would be even more helpful to see some concrete examples of what you could enter into the 17-screen wizard. Below are some example values you can enter into the wizard to get some quick satisfaction with CloudStack. These example values will not work for everyone, but for the purposes of a Basic Installation it is assumed you have just a pair of machines on a single network. I tested this with machine#1 = CloudStack 3.0.1 on CentOS 6.2, and machine #2 = XenServer 6.0.2, the hypervisor.

Be advised that CloudStack is running on tomcat with the default 30 minute session timeout. The clicks you make in the wizard to go from screen to screen are not servlet requests (I assume the web ui uses a lot of ajax instead) so after 17 screens if you’ve spent too much time thinking great thoughts about how to answer the wizard’s questions, then when you finally click Launch you will be greeted with the error that your session has expired and you need to login and do it all over again. It’s a bit awkward because this wizard is intended for new users of CloudStack, who are more likely to be taking their time on the initial install. (This is not intended as a slam on the CloudStack web ui, which in general I think is pretty slick.) If you don’t get through the wizard in 30 minutes it won’t break anything though, just do a manual logout and login again.

Ok so with that out of the way, here is a listing of all the screens of the CloudStack Basic Installation wizard, with example values and commentary. Some of these screens are just for informational purposes to help new users learn more about CloudStack.

  1. Login
    • Browse to http://localhost:8080/client, or change ‘localhost’ to wherever you fired up the CloudStack management server. Login with username: ‘admin’; password: ‘password’.
  2. Welcome to CloudStack
    • Click “Continue with basic installation.”
  3. Change your password
  4. Add a zone (informational)
  5. Configure the zone
    • Name: cstkz001
    • DNS 1:
    • DNS 2: (leave blank)
    • Internal DNS 1:
    • Internal DNS 2: (leave blank) is a publicly available DNS server hosted by Google, aka the Google Public DNS, and anyone can use it. You could also use your router gateway IP, e.g., in which case your router will delegate to some other external DNS.

    The name ‘cstkz001′ is just my convention for CloudStack Zone #1. For this name and the others below, use any name you want, but a short one will display better in the ui and will be easier to search for in the logs.

    CloudStack has the notion of a public network (your cloud as seen from the outside) and a private network (your cloud as seen from the inside). For the Basic Installation we’ll assume just one physical network which is why I used for both DNS 1 (public) and Internal DNS 1 (private).

  6. Add a pod (informational)
  7. Configure the pod private network
    • Name: cstkp001
    • Gateway:
    • Netmask:
    • IP Range: ..

    So in a Basic scenario the gateway is your router’s local IP. For a lot of people the gateway will in fact be, but to know for sure, on any of your connected machines run “netstat -rn”. This command will tell you the gateway, and your netmask as well. (For an Advanced scenario you’d have to use the gateway of the hypervisor, not just any machine.)

    As for the IP range, you want to pick a range of IPs that your router has not yet assigned to hosts already. If you are just messing around with CloudStack and don’t have admin rights on your local router then just pick a small range far away from your own IP and hope for the best. If you do have admin rights then login to your router, see what IPs are available and set aside a block if your router permits it.

    How wide should the private IP range be? For a Basic Installation I think 3 IPs is the bare minimum: two private management IPs for the SSVM (Secondary Storage VM) and CPVM (Console Proxy VM), and a third for the SSVM’s “storage NIC”. I showed a range of 10 IPs above just to give some headroom.

  8. Configure the guest public network
    • Gateway:
    • Netmask:
    • IP Range: ..

    As mentioned above we’re assuming the public network uses the same gateway/netmask as the private network.

    How wide should the public IP range be? For a successful launch you need at least 2 IPs, for the public IP of the SSVM and CPVM. To actually fire up a guest instance (which is the sole purpose of running CloudStack) you need at least 2 more, one for the public IP of a virtual router and another for the public IP of your guest. So that’s 4 IPs for the bare minimum to make CloudStack do useful work. As before I showed a range of 10 IPs, and in a big deployment you’d want way more.

  9. Add a cluster (informational)
  10. Identify a cluster
    • Hypervisor: XenServer or KVM
    • Name: cstkc001

    If you got this far and don’t have your hypervisor set up yet, I’m sorry but you’ll have to stop and do that now instead! XenServer and KVM are both free, so take your pick. (I’m not wading into the “which is better” argument today.) And since this is the Basic Installation, they’re assuming you have just one cluster with one hypervisor, and not a zillion of them.

    The name ‘cstkc001′ is just my convention for CloudStack Cluster #1. It does not have DNS resolution semantics like, it’s just a name to choose for display purposes in the web ui.

  11. Add a host (informational)
  12. Configure the host
    • Host Name: myhypervisor
    • Username: root
    • Password: (hypervisor root password)

    Host Name is the DNS name or IP of your hypervisor server. Unlike the cluster name, the host name actually can be a domain name. But if you use a name like “myhypervisor” (as opposed to an IP) then make sure it’s defined in the /etc/hosts of the management server, or set up a nameserver to do it (but that would be a little less “Basic”).

  13. Add primary storage (informational)
  14. Configure primary storage
    • Name: cstks001
    • Protocol: NFS
    • Server:
    • Path: /export/primary

    If you followed the Basic Installation Guide, you defined an NFS share in a dir called /export/primary on the same linux host on which you installed the CloudStack management server and mysql. (In a real deployment your management server might be more physically remote from the cluster and you’d want the primary storage server to be closer, because it can be a tad slow to transfer multi-gigabyte VM images over the lan.) But in case you’re tempted to enter “localhost” for the Server value above, that would be a mistake because the hypervisor will try to make contact with primary storage using this server address. Since the hypervisor is always a different machine than where the management server runs, it would not work for the hypervisor to reach primary storage by connecting to “localhost”. So either specify your management server’s actual IP as shown in ‘ifconfig’, or put its DNS name here and make sure it’s defined in /etc/hosts of the hypervisor. In this example I chose, because I had actually defined ‘hostname’ to this on the management server machine. If you have any doubts just set Server to the actual IP and you can’t go wrong.

  15. Add secondary storage (informational)
  16. Configure secondary storage
    • NFS Server: (IP address of
    • Path: /export/secondary

    Basic Installation instructs you to define a second NFS share called /export/secondary, again on the same host as the management server, which in my case is called HOWEVER unless you have defined the IP resolution of ‘’ in your DNS server or router, you had better use the actual IP instead of the domain name, BECAUSE the server that ends up trying to connect to this NFS Server is the SSVM. Unlike the hypervisor, which you can tweak to your heart’s content before embarking on this 17-screen setup wizard, CloudStack (not you) instantiates the SSVM from a System VM Template and you will not have the chance to tweak it before the Launch starts it for the first time. You will not be able to put in the SSVM’s /etc/hosts before it starts for the first time. The SSVM will wake up, spend 20 minutes unsuccessfully trying to reach (which it cannot resolve to an IP), then timeout and fail. So what I am strongly suggesting here is that you specify the secondary NFS Server as just the actual IP of the machine with /export/secondary.

  17. Prepare to launch
    • Click the Launch button.

That was pretty long for a so-called “Quick Install”. But hopefully still shorter than it would be otherwise!

1 comment

  • Thanks for the wonderful article. It clarified what the network setup is supposed to look like and allowed me to finally add a host to my test cloudstack install. Great job!

Please share your thoughts