Generic Cluster Management + Virtualization Flavor

oVirt is managing a cluster of machines, which form the infrastructure to run virtual machines on top.

Yes - That’s true. We can even formulate this - without any form of exaggeration and you can probably even find a proof for this - mathematically:

  Generic Cluster Knowledge
+ Virtualization Specific Cluster Knowledge
--------------------------------------------------------
  Absolutely Complete Virtualization Management Solution

You might disagree with this view, that’s fine - it is just one of many views on this topic. But for the sake of discussion, let’s take this view.

{width=”640” height=”291”}

What I consider to be generic cluster knowledge is stuff like:

• Host maintenance mode
• Fencing
• To some degree even scheduling
• Upgrading a cluster
• Deploying a cluster (i.e. the node lifecycle, like joining a cluster)

Besides of that even broader topics are not specific to virtualization like i.e. storage - regardless of what is running on a cluster - you do need to provide storage to it, or at least run it of some storage (don’t pull out PXE now …). The same is true for networking - Workloads on a cluster are usually not isolated, and thus need a way to communicate.

And then there are workload specific bits, i.e. in oVirt it is all about virtualization:

• Specific metrics for scheduling
• Logic to create VMs (busses, devices, look at a domxml)
• Different scheduling strategies
• Hotplugging
• Live Migration
• Specifics on network on storage related to virtualization
• Host device passthrough

… to name just a few. These (and many more) form the virtualization specific knowledge in oVirt.

So why is it so important to me to separate the logic contained in oVirt in this particular way? Well - oVirt is interesting to people who want to manage VMs (on a data center scale and reliability level). This is pretty specific. And it’s all tightly integrated inside of oVirt. Which is good on the one hand, because we can tune it at any level towards our specific use-case. The drawback is that we need to write every level in this stack mostly by ourselves.

Wit this separation at hand, we can see that this kind of generic cluster functionality might be found in other cluster managers as well (maybe not exactly, but to a some degree). If such a cluster manager exists, then we could look and see if it makes sense to share functionality, and then - to tune it towards our use-case - just add our flavor.

{width=”640” height=”426”}

“Yes, but …”

Yes, so true - but let’s continue for now.

A sharp look into the sea of technology reveals a few cluster managers. One of them is Kubernetes (which is also available on Fedora and CentOS).

It describes itself as:

Kubernetes is an open-source platform for automating deployment, scaling, and operations of application containers across clusters of hosts, providing container-centric infrastructure.

Yes - the container word was mentioned. Let’s not go into it this right now, but instead, let’s continue.

After looking a bit into Kubernetes it looks like there are areas - the generic bits - in which there is an overlap between Kubernetes and oVirt.

Yes - There are also gaps, granted, but that is acceptable, as we always start with gaps and find ways to master them. And sometimes you are told to mind the gap - but that’s something else.

Getting back to the topic - If we now consider VMs to be just yet another workload, and that VM management is actually just an (in oVirt a Java) application (excluding the exceptions), then the gap might not be that large anymore.

… until you get to the exceptions - and the details. But that is something for next year.

::: {#footer} [ December 22nd, 2016 10:23pm ]{#timestamp} [ovirt]{.tag} [kubernetes]{.tag} [fedora]{.tag} [centos]{.tag} [cluster]{.tag} [manager]{.tag} [virtualization]{.tag} [kubevirt]{.tag} :::