Install CloudStack 4.5.1

Apache CloudStack 4.5.1

Rather than upgrade i have decided to rebuild my CloudStack to version 4.5.1 and thought i would document the installation process.

The Physical CloudStack Environment looks like this:

3 x KVM Nodes
1 x Management Node
1 x NFS Node
1 x Deployment Node


CloudStack Physical Diagram


Enable Snapshot with KVM on CloudStack

How to enable Snapshot with KVM on CloudStack

If you have chosen KVM as your hypervisor in CloudStack then you probably know that Snapshot is not supported by KVM, only VMware and XenServer. This is refering to Snapshots which capture state of the machine much like a VMware Snapshot.

What is supported is Volume Snapshot which is basically a snapshot of individual volumes. A copy of your volume is backed up to secondary storage. It does have some limitations of course, you can not just roll back to this backup.

But before you can use Volume Snapshot you will have to do a couple of things.

Logon to CloudStack and from Global settings select kvm.snapshot.enabled set it to true and restart the management server (kvm.snapshot.enabled = true)

Enable Snapshot with KVM on CloudStack


Install Open vSwitch on CentOS

Installing Open vSwitch on CentOS 6.6

I would like to use Open vSwitch on my KVM nodes in my CloudStack deployment. I will download and build the Open vSwitch rpms on my deployment server, which is just a CentOS VM which i use for deploying packages etc.

Create a directory to download the Open vSwitch tar to (You can find the most recent OVS here:

cd ~
mkdir -p rpmbuild/SOURCES

mkdir -p rpmbuild SOURCES


Cloning a CentOS VM requires network modification

When cloning a CentOS VM the networking will need to be reconfigured. First of all you will probably need to edit the IP settings in ifcfg-eth0:

vi /etc/sysconfig/network-scripts/ifcfg-eth0

But even after this you won’t be able to ping anything on the network. We have made a change to the network so restart the network service. Restarting the network service will return the following error:  “Bringing up interface eth0: Device eth0 does not seem to be present, delaying initialization.”

Device Eth0 does not exist


Square Peg in a Round Hole

Are Windows workloads suitable for AWS?

With so much buzz about moving workloads to the public cloud, to save money and improve scalability I think we have forgotten something. The public cloud is not the same thing as a private cloud.

I recently attended AWS training, Architecting for high availability and the instructor said something that I had to think about. He said that hosts will fail and bring down your instances, as a matter of fact. And that we should be architecting to allow for this type of outage.
I’ve been working with VMware for so long that I don’t need to architect my instances or VMs for Host failure. With HA turned on I can be fairly certain that if a Host does fail, the VMs will power up on another host and service will resume. And VMware vSphere is a mature product that Hosts only fail when there is a hardware problem.

So this raises the question, as an example, can I move my Windows File Servers to AWS with confidence? What happens when a Host fails, my file server instance goes down and I have to restore from S3? Sure I could add redundancy at the application level, using Microsoft clustering but that is just adding complexity and cost.

There are some cases that Windows workloads can fit AWS, for example an RDS or a Citrix Farm, as there is some application layer redundancy.
I guess there are solutions to replace file servers, but in the rush to save money and move workloads to the public cloud we are just lifting and shifting. This isn’t taking advantage of the public clouds capabilities and is possibly costing us more for an inferior product.
Public cloud makes sense for applications written for the public cloud. Applications architected with the “Everything fails all the time” mentality. But is it a better solution for our existing Windows workloads?

Maybe we should delineate the two by just maintaining the old and nurturing the new.