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
Recent blog posts

Next Generation High Density App Servers Don't Require Scrapping Your Hypervisor

Recently, I sat in a conference session extolling the seemingly endless virtues of Linux Containers.  I heard claims that hypervisors were old hat: ancient bloated engines which rely on inefficient replication of a large operating system stack in order to serve up applications.  The speaker painted a picture of a future where hundreds of applications are virtualized on each piece of hardware.  "What is really needed," glowed the speaker, "is a lightweight, efficient means of serving up application: containers."

Containers are cool, but not a panacea

Containers share the same kernel as the host, so they are not burdened with the extra memory and CPU cycles it costs to replicate a full operating system stack in a hypervisor scenario.  Compared to hypervisor-generated virtual machines, containers can be fast and lean.  But they are also limited.  

Since Linux containers share the same kernel as the host, it is impossible to run Windows.  Or FreeBSD. Or NetBSD.   Or another version of the Linux kernel.  Or another Linux distribution which requires a different kernel.  All of those scenarios are best handled by a real hypervisor.  And the security aspect of hypervisors is huge, worthy of a separate blog entry of its own.  Still, if you need an environment within your organization where many workloads can leverage a single kernel environment, containers can be a viable solution.

However, some of the most vocal container advocates insist that these problems relating to containers are really application problems in disguise.  Issues about kernel support and security are the results of improper application design, they claim.  When we raise the bar on applications so that they are based solely on access to application servers, then the objections to containers will melt away -- and so will hypervisors, for the most part.  Or that's what some of these advocates claim, at least.

The death of the hypervisor is greatly exaggerated

But is there another scenario which could answer the call for highly responsive and lightweight virtual instances which does not use the container solution?  Maybe one that can actually leverage the flexibility and security which is part and parcel with most hypervisors?

Hits: 3353
Rate this blog entry:
Continue reading Comments

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: 1929
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: 1573
Rate this blog entry:

I am pleased to announce the next Xen Project Hackathon. The Hackathon will be hosted by Rackspace in their London offices, May 29 and 30. I wanted to thank Paul Voccio and Gus Maskowitz from Rackspace for hosting the Hackathon. I also wanted to thank Rackspace for hosting the Xen Project wiki, mailing lists, blog and other services. This is in line with Rackspace’s vision of openness and helping people:

At Rackspace we build and live openness as much as possible and go out of our way to support and nurture open source where we can. We help people achieve success by solving their hybrid hosting and cloud problems. In that same line we are proud to help the Xen Project run a successful Hackathon in London 2014. Rackspace

What to expect at a Xen Project Hackathon?

The aim of the Hackathon is to give developers the opportunity to meet face to face, to discuss development, coordinate, write code and collaborate with other developers. Of course the event will allow everyone to meet in person and build relationships: to facilitate this, we will have a social event on the evening of the 29th. We will cover many hot topics such as the latest Xen Project Hypervisor 4.4 features, planning for the next Xen Project Hypervisor release, Cloud Integration, Cloud Operating Systems, Mirage OS, Xen Project in emerging segments such as embedded, mobile, automotive and NFV. But at the end of the day, the community will chose the topics that are covered.

To ensure that the event runs efficiently, we are following the following process: Each day is divided into several segments. We will have a number of work areas that are labelled with numbers (or other unique identifiers). Each morning starts with a plenary and scheduling session. Every attendee who cares about a topic can announce a topic, which we will map against a work area and time-slot. This makes it easy for other attendees to participate in projects and discussions they care about. Of course we also encourage attendees to highlight projects they plan to share before the event by adding them to our wiki.

We will wrap up each day with another short plenary session: the aim of this session is to summarize what was done, show brief demos and make improvements to the process.

Hits: 16636
Rate this blog entry:
Continue reading Comments

Hands-on CloudStack Session with David Nalley!

Posted by on in Events

First off – a huge thank you goes out to NetApp and Kim White for hosting the CloudStack SF Bay Area Users Group on March 19th! It was a wonderful venue and they were so generous to provide pizza, refreshments, beer and cupcakes to keep the CloudStackers going through the evening.

John Kinsella kicked off the night with a quick introduction and reminder about the CloudStack Collaboration Conference held in Denver, CO April 9-11th, 2014. A few of our very own CloudStackers have submitted talk proposals for the CloudStack Collaboration Conference. Their talks have gotten accepted and they will be speaking at the conference! Congratulations to Amogh Vasekar and Marco Massenzio! There's still time to register for the conference so don't delay! If you're already planning to attend, check out their presentations:

Moving up the Stack with Stacktician by Amogh Vasekar, Software Engineer at Citrix 

Towards an Automated Testing Environment by Amogh Vasekar, Software Engineer at Citrix

Challenges in Developing a True SaaS Cloud Mobility Platform by Marco Massenzio at RiverMeadow

Hits: 1989
Rate this blog entry:
Continue reading Comments


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.