SolidFire Enhancements in CloudStack 4.5.1

ccchanges What’s new in CloudStack 4.5.1

 It appealed to my perverse side to spend some playing with CloudStack while at the OpenStack conference in Vancouver last week.

 Ultimately I am a fan of anything that brings data centre automation and CloudStack and OpenStack I both enjoy working with.

 Having built my earlier series of posts on building a lab setup for CloudStack and noticing that 4.5.1 is now released I thought it time to dust down my CloudStack lab.


Lab Setup Changes

The first change I made was to rebuild my template for XenServer to use XenServer 6.5. I bumped into Tim Mackey in Vancouver and thanks for his USB stick I had a fully Service Pack 1 version of XenServer 6.5 ready to deploy.

There are no installation changes for XenServer 6.5 ultimately. It installed smoothly and I simply tagged the CLOUD and MANAGEMENT networks, changed from OpenvSwitch back to Bridged networking as per my original notes and blog post. 

The next step was to modify the auto install script for CloudStack to change this over to use 4.5.1. In the CloudStack release notes it does not yet appear that the location for the usual packages is ready. Luckily ShapeBlue to the rescue – – and I switched my repository for my RPMs and also the System VM templates.

In the interests of time I modified the script to just deploy 4.5 for now. Some day I will look at modifying what I borrowed for multiple versions however I tend to just go forward with versions.

Again the build went well and the combination of BT Cloud performance and ShapeBlue know-how gets the packages downloaded quickly.

Ch Ch Ch Changes 

I did the initial CloudStack configuration manually this time just to see how different things were, if at all. Once I had a working environment I then performed a VMware snapshot of the management server and Virtual XenServer so I could roll back and go  again I wanted.

The first point I noticed was CloudStack now builds the System VMs after the initial configuration completes. 

Personally I am fine with this, as running System VMs is always a sign of a happy CloudStack. 

SolidFire Plug-In Mods

Firstly we have now added a user interface to add the SolidFire plug-in. Also as part of our “Google Summer of Code” student’s last year we added an ability to search through Storage Tags rather than having to remember what you added in – personally for me this is a benefit as I always forget how I tagged my plug-in. So taking a look at this, in Home-> Infrastructure -> Primary Storage click Add Primary Storage.


















Note, the scope needs to be set as Zone-Wide – it needs a name and you select SolidFire within that. Enter an amount of capacity and IOPS you want to dedicate to the plug-in overall and a tag. The URL is then the details to access the storage as we used to do with the API call. An example is below:


I now build my Compute Service and build a VM which gives a fully automated LUN created on SolidFire as before. But no API calls this time needed….































































Shared Plug-In 


The other new addition is a totally new plug-in called “SolidFire Shared.” This for instances when you want to share 1 LUN with many root disks but still have the benefit of automatic provisioning. Again most of the parameters are the same however a static min, max and burstIOPS setting are applied and the LUN/volume is created immediately for this.

This is specified at the Cluster level as it is an individual LUN that will be one pod and cluster. The settings are slightly different in the URL and the capacityIOPS must have the minIOPS you specify in the URL.

The url looks like below:

























The LUN is then immediately built and provisioned:


Spread the word. Share this post!

Leave A Reply

Your email address will not be published. Required fields are marked *