v14.0 Optimized Builds - Part 3: Xen and OpenStack

Following the release of Optimized Builds part 1 and part 2; it is with great pleasure (and quite a bit of relief) that I announce the third and final instalment of the optimized builds: Xen and OpenStack. As per all our other builds, individual 14.0 Xen and OpenStack optimized builds can be downloaded from their respective appliance pages (eg. LAMP, WordPress Node.js etc). Alternatively the entire library can downloaded via one of our mirrors.


Firstly I must admit that the announcement of the Xen builds is well overdue. Avid Xen users have probably already realized that Xen builds have been available for some time. I just neglected to announce them. Apologies to any users who didn't already realise and have been waiting for this announcement.

Once again, with the assistance of the ever-helpful Marc Warne (from Gigatux - see his more timely announcement here) we have built, tested and released the v14.0 Xen builds. Beyond the underlying changes that affect all of the v14.0 builds, there are no substantial changes to the Xen builds for v14.0. The notes that apply to previous TurnKey Xen builds (see the original blog post) still apply so there is probably not a lot to add. Thanks again Marc! :)

Users who are pre-seeding will need to add the security alerts (SEC_ALERTS) preseed. It can be skipped or preseeded with the user's email. This doesn't just apply to Xen builds; it applies to any v14.x release that is preseeded.


I must admit that the OpenStack builds have been a thorn in my side for a while now. The significant issue has been testing. I do not have OpenStack and have never really played with it. I don't have enough spare hardware for a proper install either. I was tempted to just build the images, cross my fingers and hope for the best. But releasing without at least basic testing didn't sit comfortably with me (needless to say, Alon was not keen either!)

Stefan (@OnGle - my son) looked into installing OpenStack in a VM. He discovered DevStack and installed that (a few times in the end). It didn't go smoothly but long story short; we got it working. Stefan confirmed that Core boots and the services are running and accessible within the subnet. However that was only after swapping out SystemD for SysVInit (as we did with container builds).

Everytime we booted TurnKey OpenStack with SystemD installed, at best it failed to cleanly boot. At least twice it managed to crash the host as well! And on both of those occasions the DevStack VM was left broken. I'm still not sure what the dramas we had with SystemD are related to. It remains a mystery whether it was a problem with OpenStack/DevStack, TurnKey, Debian, SystemD, Proxmox (my VM host) or just running in nested virtuazation. The fact that I found no clear indication that anyone else was having the same issues makes me think that PEBCAK (see cartoon strip below) may have been a factor (at least on my behalf)!

After spending WAAAY too much time on it, we decided to publish the images with SysVInit init system (rather than SystemD). We figured that at least we know that they boot and the basic functionality works. On the upside of this whole experience, Stefan is now quite handy with OpenStack. I suspect that he'll revisit it when he has time. Perhaps we might be able to produce a TurnKey DevStack appliance and help make life easier for others that just want a quick easy OpenStack environment?

I hope you have an opportunity to try out these builds and let us know how you go. As per usual if you have feedback, please comment (below), start a thread on our forums and/or post bug reports and/or feature requests on our GitHub Issue tracker. If you have OpenStack and/or OpenStack expertise I would especially love to hear from you! If you want to help make the v14.1 OpenStack build better please make sure you let us know!


I am quite happy with the new 14.0 builds LXC. I am testing now Proxmox 4.1.

A great combination of Proxmox and Turnkey. Thank you for that.

The Turnkey 14.0 lxc 's work well on Proxmox4.1 so I will dump my openvz containers (Turnkey off course!) for the new Lxc after testing in a few months

Two questions

Will Tendenci be upgraded to 14.0 lxc? And: Wille there be a new Zimbra 14.0 lxc?




Jeremy Davis's picture

We have a few finishing touches before we make the announcement post but they are actually already available via the Hub. The delay in supporting them has been the fact that we need to redesign our AMIs to be inline with AWS' HVM specs.

We will no longer be supporting the old instance sizes (Amazon will be retiring them at some point anyway). Existing AWS servers will be unaffected but users are no longer able to launch new servers of the old types...

The bonus side effect of all this is that we will now be able to support the newer AWS regions within the Hub (all new regions only support the new instance types).

L. Arnold's picture

I have had pretty good success putting XEN builds into Linode Sessions (Linode.com).  Doing so however I pretty much abandon much of what Linode builds into their default images.

I would be interested in some level of merging -basically keeping some of the original Linode intellegence.

One message that Linode thows me is:  Network Helper did not run: could not reliabily determine distribution or distribution

My guess is this is just for their info, but it might be so that Linode, rather than TKL handles updates. In every event, that error shows up every time I reboot the system.

One small irritation, once I have used the XEN image, the Linode system reboots much slower  (1 min 30 Seconds slower to be precise).  Something is being searched for during that time, and when not found, the system reboots.

Any thoughts, or experience there would be appreciated.

Thx in advance.



Add new comment