I don’t think anyone would disagree that the documentation for CloudStack still needs work. But all the documentation in the world can’t help if you decide to skip important sections.

Some caveats notes while I was working with 2.2.12 and 2.2.13:

• vSphere 4.1 only, vSphere 5 is not compatible
• Regardless of vSphere licensing used, vSphere vDS is not supported
• vSphere DRS must be turned off so that CloudStack can do its own load balancing (it seems angry if things move)
• No mention of vSphere HA but I enabled HA because the point of using vSphere as the hypervisor was for automated high-availability
• Discussion of vSphere SDRS going on in the forums but so far this also seems like a toggle that needs to be disabled for now
• Secondary storage needs to be accessible by the Secondary Storage VM, vSphere hypervisors, and the CloudStack management system

At first I didn’t read the documentation all the way through – just the networking bits as that was the largest area of the document and initially my largest area of concern. The lack of vDS is a bummer but I’m going to guess that they’ll add this functionality in a later release. I believe vDS would make a few things easier on the users of CloudStack long-term and look forward to this addition.

Since I didn’t read the documentation completely I failed to notice that it states support for vSphere 4.1 and mentions nothing about vSphere 5. Even after I started digging further into the document I assumed that vSphere 5 would be supported. That’s a bad assumption and after a reinstall of the physical servers (and vCenter) I was able to get the initial configuration to pass. Strike one for me – I should know better than to skip portions of an install document.

Next was getting all the networking together with the trunking for VMs, storage network, interconnection between CloudStack and the physical servers. This wasn’t difficult but did need me to actually write everything down as there was a lot going on concurrently. See my last note above for the hint to my biggest hurdle I needed to overcome.

I have some worries about what happens when a physical server fails (and everything fails at some point). I don’t know if CloudStack will initially notice the failure before vSphere ends up bringing the VM back online on a different physical box. And once it is up I don’t know how CloudStack will respond or alert for such items. I bring this up because CloudStack has its own HA system in place but the configuration in the general settings area shows 1800 seconds to trigger (if I am even reading that right). vSphere HA is faster than that. I guess we’ll see what happens if/when it does occur.

And the biggest hurdle for me was the requirement that the secondary storage VM, CloudStack management system, and the hypervisors need to be on the same network for the secondary storage to work. This storage is for holding templates and ISO images for later deployment into a customers’ cloud environment. Once this items a pointed out to me then everything started to go together. This was an area of frustration as it wasn’t clear to me in the documentation that this is the case. The examples flow around an idea of one network for management, VM traffic, and storage. That is not how things are designed in my world as I separate out each of those types of traffic.

I found CloudStack simple to install and once I knew the different restrictions/notes above the process only took 10 minutes to complete.

If you want to read documentation in a browser, I found the cloud.mindtouch.us site to be very helpful. Of course CloudStack has PDF based documentation as well though multi-file searching is either great or abysmal depending on your workstation OS of choice so I opted for the web version to help narrow things down before going back to the PDF editions.

Our customer is still working out a few kinks and should be fully operational soon.

David is a math and statistics expert, implementing many of his solutions using his background in software development and database design. He consults primarily for small to medium-sized businesses and helps his clients with all their computer needs from software installation to network security. He has worked with individuals to setup their home offices with efficient, secure connections to their work places.

David describes himself as being, “vocal and tenacious about raising hell when a client’s vender doesn’t deliver.”  His clients appreciate this dedication. Thus far, all his clients have come from word-of-mouth referrals.

David shared with me that he wants to be equally vocal when a vender does a good job. He thinks that, “Many ISPs do not do good work. ipHouse has delivered. It seems like you guys can do no wrong.”  David is impressed with the breadth of knowledge of ipHouse staff. “It is nice to have a vender whose technical support team is savvy about issues beyond the traditional support call.”