Abonnez-vous à notre blog

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


À propos de l'auteur

Parcourir par canal

automation icon

Automatisation

Les dernières nouveautés en matière d'automatisation informatique pour les technologies, les équipes et les environnements

AI icon

Intelligence artificielle

Actualité sur les plateformes qui permettent aux clients d'exécuter des charges de travail d'IA sur tout type d'environnement

open hybrid cloud icon

Cloud hybride ouvert

Découvrez comment créer un avenir flexible grâce au cloud hybride

security icon

Sécurité

Les dernières actualités sur la façon dont nous réduisons les risques dans tous les environnements et technologies

edge icon

Edge computing

Actualité sur les plateformes qui simplifient les opérations en périphérie

Infrastructure icon

Infrastructure

Les dernières nouveautés sur la plateforme Linux d'entreprise leader au monde

application development icon

Applications

À l’intérieur de nos solutions aux défis d’application les plus difficiles

Original series icon

Programmes originaux

Histoires passionnantes de créateurs et de leaders de technologies d'entreprise