satis egitimisatis


Discussion on the state of cloud computing and open source software that helps build, manage, and deliver everything-as-a-service.

  • Home
    Home This is where you can find all the blog posts throughout the site.
  • Categories
    Categories Displays a list of categories from this blog.
  • Tags
    Tags Displays a list of tags that has been used in the blog.
  • Bloggers
    Bloggers Search for your favorite blogger from this site.
  • Login


David Nalley is currently employed by Citrix as the Community Manager for the CloudStack project. In addition he's a long time contributor to the Fedora Project, where among other things he is currently serving on the Fedora Project Board. He's also contributed to in various forms to Cobbler, Zenoss,, OLPC Math4, and Sahana. He is a frequent speaker at Free Software conferences around the nation, and writes for a number of technical and open source media publications including Linux Pro Magazine and

I had a recent discussion with some folks wondering why there was now an option for 32 or 64-bit System VMs with CloudStack 4.3. I provided an answer, and linked back to some mailing list discussions. I figured this might be of general interest, so I’d document in the short term with a blog post.

For background, system VMs provide services like dealing with snapshots and image templates, providing network services like load balancing, or proxying console access to virtual machines. They’ve historically been 32-bit. The reason for this is that the 32-bit arch has been very efficient with memory usage, and since these are horizontally scalable it’s easy to just spin up another.

But you can have either – which do you pick?

Depending on the workload you might have a different answer. Some hypervisors work better with one arch over the other; and that might be a factor; but ignoring hypervisors lets examine the reason you’d want to use either. 32-bit: 32-bit operating systems are pretty efficient with their use of memory compared to 64-bit. (e.g. the same information typically occupies less space in memory). However there are limits on memory. (Yes, you could use PAE with a 32-bit kernel to get more addressable memory, but there is considerable CPU overhead to do so – which makes it inefficient given that all of this is virtualized) The 32-bit kernels also have a limit on how much memory is used by the kernel. This is really where the use case of 64-bit System VMs evolved from. Because one of the system VM functions is providing load balancing, the conntrack kernel module had a practical limit of ~2.5M connections – and that left precious little room for the kernel to do other things. CloudStack orchestrates HAProxy as the default virtual LB, which in turn uses conntrack. Having a heavily trafficked web property behind CloudStack’s 32-bit virtual load balancer might run into that limitation.

64-bit: Not nearly as efficient with memory usage; however it can address more of it. You’ll actually tend to need more memory for the same level of functionality; but if you need to push the envelope further than a 32-bit machine, then at least you have an option to do so.

Hits: 2107
Rate this blog entry:
Continue reading Comments

ApacheCon approaches

Posted by on in Open Source

It doesn't seem possible, ApacheCon is less than a week away. CloudStack Collaboration Conference follows shortly. I am excited about seeing ApacheCon this year, the schedule is huge and contains a ton of interesting content. That actually may be a detriment - so much content it will make deciding what talks to see difficult.

Particularly interesting to me is the ton of big data talk. There are plenty of big data projects at the ASF, and those projects have managed to bring 5 days worth of big data content to ApacheCon, coupled with 3 days worth of Lucene/Solr content. Keeping in mind that the ASF is the home for the majority of open source big data projects and ApacheCon becomes a must-attend event if you care about big data.

But ApacheCon is more than just big data, there are tracks for cloud and mobile development, as well as perennial favorites like Traffic Server, and Tomcat. 28 tracks in total.

All of this content is great; and I look forward to learning a lot while I am at ApacheCon, but it ignores the most valuable reason that I am attending: the hallway track. Being able to converse with  many members of various Apache project communities is invaluable.

I hope to see you there.

Hits: 1744
Rate this blog entry:

Thoughts from FOSDEM

Posted by on in Open Source

I had the pleasure of attending FOSDEM, the Free/Open Source Developers European Meeting this year. There are always interesting folks in attendance, and getting to meet folks you only know via IRC or or a mailing list is great. I also always pick up lots of interesting information.


In short, if you can make FOSDEM, you should do so. That isn't really what I wanted to write about though. FOSDEM always has a lot of related conferences; this year they included the CentOS Dojo, CfgMgmtCamp, and Each of those could easily fill several blog posts, but the most poignant thing in my trip this year happened at


 I often cite John Vincent with his 'Monitoring sucks' tagline. Not because monitoring sucks as a practice, but because the tools for monitoring are generally comparatively archaic, and painful to use. As a recovering sysadmin, I understand the pain behind 'Monitoring Sucks' well; and thanks to a conversation from Kris Buytaert I realized that many of John's complaints around monitoring, aren't monitoring specific at all, and that caused me to go back and reread John's original post from 3 years ago. These truths should be evident, but I think it's all too easy to forget them, and see plenty of software that ignore them. Specifically, any systems management software should keep these items in mind and avoid them:

Hits: 4356
Rate this blog entry:
Continue reading Comments

Building CloudStack RPMs with Ansible

Posted by on in Open Source
I've been hearing a lot about Ansible lately. First I've seen folks like Paul Angus building tooling around installing CloudStack with Ansible. Ansible intrigues me a bit; first it's largely being shepherded by Michael DeHaan, who originally wrote Cobbler and really eased a lot of pain for sysadmins needing to provision machines; so his work has some immediate credibility because of how awesome Cobbler was to use. Second, the entire decentralized config management angle is interesting. I like how minimalistic it is; and while I don't think that's necessarily a good fit for every environment, it is compelling for some. Finally, I see the blurring of lines between config management and workflow/job automation and that makes Ansible pretty versatile in my mind.   I tend to learn best when I have a concrete project to actually apply new tools to, so when the hosted puppet master service I had been using went permanently offline, I decided to recreate some of the tooling around building CloudStack RPMs in Ansible. I started out with a very basic playbook, which worked reasonable well.

Playbooks, in Ansible parlance, are a place to both define system configuration, as well allowing a known order for workflow automation. I first started with just defining a build environment for building CloudStack RPMs.

Then I had the chance to listen to Michael DeHaan showing off Ansible at a DevOps DC meetup in November, and one of his code snippets had an unknown-to-me built in variable that cut my playbook length in half (as well as the number of ssh calls as a result.)  Specifically I went from a playbook like:

  - name: Install wget
    yum: pkg=wget state=latest
  - name: Install rpm-build
    yum: pkg=rpm-build state=latest


  - name: Install deps and niceties
    yum: pkg={{ list }} state=latest
     - wget
     - rpm-build

This made things much more efficient, and I pushed further from merely configuring the environment to also using Ansible as a bit of a workflow automation tool. So I added the entire build portion as well.

Things weren't 100% happy though - a number of the Maven dependency downloads failed, which caused compilation to fail. I really need to setup a Nexus mirror for CloudStack dependencies both to speed things up as well as to ensure they are reliably available for building. But this failure isn't the fault of Ansible, so can't really fault it here.

The end result is being able to spin up a fresh machine, point Ansible to it, applying the playbook and coming back (admittedly building the RPMs takes a long time) after a long cup of coffee and finding RPMs done. You can see my admittedly beginning attempts at this playbook here:

If you need to build CloudStack RPMs, or want to  see a very basic Ansible playbook you can look at:

Hits: 15234
Rate this blog entry:

Usenix LISA: Still the best value in Sysadmin Training

Posted by on in Events
It's almost time for Usenix LISA(Large Installation System Administration) and I recently was thinking back to my first LISA conference. There are a ton of good tech conferences out there; DevOpsDays, Strata, Structure, and plenty of others. Where I think LISA is different is really in the training section. Most conferences have talks for 30-60 minutes. That typically gets you deep enough to make you realize you want to know more. And then it's time to move on to the next talk, and you have ~4-6 per day, and 2-3 days of content. 12-18 things competing for your attention.

LISA's training is a bit different. It's typically either a 1/2 day or full day. That's 3 or 6 hours worth of content after you get take care of the breaks and lunch. It may even be part of a track that gets you focused on the same topic for 2-3 days. That dramatically changes things in my opinion. First, as a presenter, having to talk about a subject for 3 or 6 hours means I can't fake it - you really have to know the content, and be able to deal with the class taking you in a direction you didn't expect. It also means I can spend time and go deep into a subject - I don't have to rush over things. And that length means the instructor gets your attention - at most the class is 1 of 2 things you'll focus on during the entire day. As an instructor though - it also means an engaged audience - people who actually want to hear and learn about the content. No one wants to sit through 3 hours of content they aren't interested in, much less pay to do so.

 Despite the similarities LISA training isn't product training; it's more likely to be 3 hours of training in a class called: "Advanced Time Management: Team Efficiency" by the inimitable Tom Limoncelli, or learning about Linux Performance Tuning from Ted Ts'o. While there may be product related talks - LISA tends to focus on the practical, getting folks something beneficial that benefits their worklife, it might be tools, or it might be techniques - but the bottom line is that it is educating and building up folks in the sysadmin world. To that end, I maintain that LISA is still the best sysadmin conference out there. If you are a sysadmin the benefits for attending LISA are far larger than just the training program. The hallway track, tech sessions, and the rest of the conference are the best value you can get in sysadmin training in my opinion.

In full disclosure though, I am humbled that I get to present some cloud tutorials. 'Building a Big IaaS Cloud' and a tutorial with Chiradeep Vittal dealing with next generation networking. I'll be at LISA all week trying to soak up as much content as possible, though I'll also be hanging out at the Apache CloudStack booth.
Hits: 12823
Rate this blog entry:


Citrix supports the open source community via developer support and evangeslism. We have a number of developers and evangelists that participate actively in the open source community in Apache Cloudstack, OpenDaylight, Xen Project and XenServer. We also conduct educational activities via the Build A Cloud events held all over the world.