ZeroVM Design Summit, Day 1: Digging Into Use Cases, Architecture & More

A couple months ago we acquired the team behind ZeroVM, the lightweight open source application hypervisor. At that time we promised that more was coming soon – and now we have started to say what some of the plans are for this new technology.

This week was our coming-out party at the first ever ZeroVM Design Summit at the University of Texas at San Antonio. Now that the first day is in the books, I can say that it is really fun to be at the start of something big. I was thrilled to see the amount of interest and excitement in the room.

First, let’s get the nuts and bolts out of the way: about 75 people registered for the summit – that’s roughly the same number that attended the first OpenStack Summit in Austin more than three years ago (sensing any similarities?). We also have numerous different organizations represented – Rackspace (of course), but there are also attendees from UTSA, EMC, SwiftStack, FreeFlow Research, and myriad other organizations and independent developers.

What was surprising was the experience level of the attendees. For example, UTSA had a handful of professors attending on the first day, including the head of the Computer Science department. Also attending were about 15 PhD and Masters students, with specialties and research topics varying from security to distributed systems to high-performance computing (HPC) to large-scale image search. We had representatives from many companies looking for ways to build on ZeroVM to create all kinds of new applications.

One of the more interesting conversations that I had was with an associate director at UTSA who just came from Joyent, where he had direct experience with the Manta project. Manta is a computable object store from Joyent that is built on top of Solaris/SmartOS technologies, such as ZFS and Solaris Zones. He saw a lot of similarities between the various ZeroVM use cases and Manta. The difference is in the applicability of the technology to other contexts. Manta only works with the Solaris/SmartOS-specific technologies. ZeroVM is designed to work anywhere there is data.

The morning sessions drilled into the architecture and use cases for ZeroVM. There was extensive discussion about the security guarantees provided by ZeroVM. ZeroVM containers start out empty, with no access to anything. Capabilities are granted on an as-needed basis. From the perspective of a ZeroVM process, resources that have not been allowed simply don’t exist. One way in which it differs from other hypervisors is there is no implicit root access. Other system-level hypervisors need to emulate trusted domains, and so have implicit or explicit root access. ZeroVM is process-level, so it can run as an untrusted user, giving another level of security.

During the afternoon sessions, speakers talked about the networking model for ZeroVM, the various runtimes included with ZeroVM, and the possibilities allowed by static vs. dynamic linking for ZeroVM applications. One hotly-debated topic was whether to have a “big” runtime with many standard pieces, or many “small” runtimes with an emphasis on composability. The general consensus was to focus on composability, because we want to allow as many different uses as possible.

We also heard about some people’s use cases. There were some I had anticipated, like image search, stream processing, and map-reduce analytics. But there were some I never would have thought about. For example, one person wants to compile hardware description languages so that each component can be simulated in an individual ZeroVM container. His vision is large-scale hardware prototyping and testing on the cloud.

One attendee took the time to write up a really nice “Introduction to ZeroVM” blog post and put up a vagrant file to help people start playing with ZeroVM.

My favorite part of the day, though, was when one of the attendees came up to me, visibly excited. “I though ZeroVM was cool, but I had no idea,” he said. “I was involved in virtualization in the early days and I thought that was great, but the possibilities that are created by ZeroVM are endless.

Yes. I couldn’t have said it better myself.

  • Was this article helpful ?
  • Yes   No
Van Lindberg is a Vice President and Associate General Counsel for Rackspace, where he serves in both legal and technical roles. As associate general counsel, Lindberg oversees the Intellectual Property program, directing Rackspace's strategy and policy around patent, copyright, trademark, trade secret and open source matters. He also heads Rackspace's patent reform lobbying efforts. On the technical side, Lindberg co-chairs the company’s Technical Career Track program, or TCT, a leadership development program for the most highly skilled technical Rackers. He also does technical strategy and ecosystem engagement, identifying emerging technologies, separating out differentiating versus non-differentiating product elements and using open source strategies to be more competitive. Previously, Lindberg worked for the international corporate law firm Haynes and Boone, LLP, where he wrote "Intellectual Property and Open Source,” and grew the firm's open source practice. He also did intellectual property transactional work, patent prosecution, litigation and post-grant actions (ex parte and inter partes reexams/reviews). In 2012, the American Bar Association Journal named him one of "America's Top 12 Techiest Attorneys." Lindberg currently serves as chairman of the board of the Python Software Foundation, sits on the board of the OpenStack Foundation, and was the first chair of the Docker Governance Advisory Board.


  1. Looking into how Swift’s RING maps object into partitions. I understand that the HASH uses the following fields: . I want to know the exact location of ROW in table A.

    where attrib_i is the ith value of the ith field in the row.

    Applying the hashing function

    H: {} -> hash#

    Using this hash the row object in written to a disk partition according to the RING mapping. Great!

    But how do I located that ROW if I only know the value of a SINGLE attrib_i ???? We are back to the GREY CODE, because a I need the values of ALL the attributes to located the exact partition. This is the JOIN case, where I need to locate a row in A based upon a KEY. I don’t know a priori which attribute will be used as the key. Using the GREY CODE, at best, I may be able to eliminate partitions????

    I am still stuck with the problem of finding all rows in A, that have a given value for one of its attributes. This still means computing some kind of an INDEX. And the INDEX or hash above unfortunately was computed by CONCATENATING all the attribute values of a row in A.