Viewing the Horizon from the Cockpit

One of my favorite things about technology is seeing what’s next. I often find myself asking, “...what’s on the horizon?” Or, better yet, “...what’s beyond the horizon?” In the case of Red Hat Enterprise Virtualization (RHEV), specifically the hypervisor, “next generation node” is hovering in the distance. I anticipate this advance to be significant  for both Red Hat partners and customers.

Why evolve?

I detest hearing “...well… we’ve always done it this way...” as reasoning for the continuation for a given process or mode of operation as it clearly shows a bias for complacency. Instead of just “falling in line” I think it’s useful to determine why things are still being done in a particular way; often times there is a valid reason! But, if no one can articulate that reason, this is justification enough to question and investigate. Along these lines, allow me to explain exactly what “RHEV-H” is and why it’s evolving.

RHEV-H, the RHEV Hypervisor, has remained fundamentally unchanged in its architecture, build process, and means of management for more than 8 years. It’s been a steady and dependable hypervisor node that has provided an easy appliance-like approach to deployment, security, and management. It is easy to clone and provides a small attack vector because of its limited number of packages and services.

These aforementioned attributes  make it sound fairly solid. In fact it is both functional and dependable. Ultimately, however, some of its assets are also some of its liabilities. The same fixed number of packages and services that serve to limit the attack vector also also play into a somewhat inflexible nature in terms of enabling customers and partners seeking to add a new driver or, for example,  monitoring software. Let’s put it this way: third party driver support is difficult at best.

This also means that hardware support is a subset of Red Hat Enterprise Linux (RHEL), and new hardware enablement typically runs behind the Red Hat Enterprise Linux support schedule. The read only file system that eases deployment and thwarts would be hackers also means that configuration and troubleshooting has long been a point of contention.

Moving Forward

Our partners and customers alike appreciate the appliance approach, but needs it to be more flexible and it needs to be able to be customized. For the next generation node, this means not so much replacing, but evolving. The core idea and end goal they hypervisor appliance remains the same, but the means and architecture has been completely questioned and modernized.

While the static parts of the next generation node will remain read-only, there will be writable areas of the storage. This will allow for customizing of packages, services, kernel tuning, as well as how the next generation node boots. This also allows other changes in the approach to deploying and managing the next generation node. The existing text user interface for deploying RHEV-H will be dropped in favor of the existing RHEL installer, Anaconda. This improvement, in and of itself, will allow for greater control and customization of the next generation node build.

The simple text user interface for administrating RHEV-H is being replaced with a web based interface called Cockpit. This too provides a much clearer picture of what is happening with the hypervisor. Cockpit includes a well-published API that will allow for interacting with the next generation node to trigger events, poll for information, or extend the functionality of Cockpit itself.

All of these changes also mean that the underlying structure must be replaced as well. Specifically, the Linux LVM (logical volume manager)  is replacing the “live cd” approach. Simply put, the next generation node will take advantage of Linux LVM to provide read-only images for the static parts of the build and writable snapshots for the dynamic parts.

Is it still an appliance?

Absolutely, yes, it is still an appliance. The next generation node will still be very much a purpose built hypervisor, and that in and of itself makes it an appliance. It moves beyond the static and inflexible nature of RHEV-H without going into the general purpose server nature of RHEL. This would essentially negate the need to have both “thick” and “thin” hypervisors, greatly simplifying hypervisor deployment and management. Streamlining any operation is almost always better, and that is much more partner and customer friendly.

You can see the next generation node in the oVirt upstream, I've provided links.  Check it out - let me know what you think in the comments section (below).

Hope this clears your view to the horizon,

Jon Benedict / Captain KVM

To learn more:

Cockpit:
http://cockpit-project.org/

oVirt Node Next Get Started:
http://www.ovirt.org/node/

oVirt Node Next FAQ
http://www.ovirt.org/node/faq/

oVirt Node Next How-To
http://dummdida.tumblr.com/tagged/node