Looking at virtualisation, containers, VMWare and Openshift
When you first hear of virtualisation it is not clear why it exists. Ok, so you can put a hypervisor on a real machine and under that you can run an operating system. Your applications run under that operating system. But why on earth would you want to do a darn fool thing like that? Why not just have the operating system? Is there really any advantage in being able run different versions of the same operating system, or to have Windows on one VM and Mac OS in another?
The answer becomes clear when you consider many people using the same machine. For any particular user, VMs can be created as needed. Not just for a user, but also for an application. Rather than being built for a monolithic machine, an application can spawn VMs as it needs them. This works best when the applications for a VM are architected so that a given VM has a defined job, e.g. this one does a certain kind of processing but doesn't access a database.
The question was: "how can I get a machine big enough for my giant application?". Then it turned into something else, a different question: "How can I architect my application so that it exists in pieces that can be allocated to virtual machines as the need arises?"
This means an application, or part of one, has to be able to jump into a VM and run reliably. This has to be true in test environments and production environments. But how can we be sure that all the system software and components that the app needs are present in the VM? Enter containerisation.
A container has all the systesm software elements the app needs.
Then, how can we be sure, when there are very large demands, either at the scale of the large enterprise, or beyond, that we can create all the VMs we want, maybe in groups of some kind. Simple groups can scale against a temple, but larger and more complex challenges that depend on many containers can benefit from orchestration tools. That's why Google came up with its container orchestration tool Borg, and its public cousin, Kubernetes.
Next problem: we are now dealing with collections of virtual machines, and separately groups of containers. It is significant that Kubernetes is constructed to deal with containers rather than VMs.
Red Hat started noticing this in 2016 and its answer was to create a new tool based on Kubernetes that would orchestrate both VMs and containers. That tool comes in two flavours: KubeVirt and the Enterprise ready version, OpenShift Virtualisation.
KubeVirt manages both containers and VMs. Open Shift among other things adds a graphical front end to KubeVirt. Both allow use of commands familiar to Kubernetes users such as KubeCtl.
The migration job getting from a VMware environment, or come to that, any environment, to OpenShift, is potentially very very complex and liable to generate errors.
In VMware, virtual machines are often treated like "pets" - long lived servers that you log into, patch manually and modify over time. OpenShift is not like that. VMs can disappear quickly so VM changes will vanish if they are not encoded in YAML.
There is a danger of too many layers. There are worker nodes working under Red Hat Linux. There is OVN-Kubernetes. There is a new world of permissions because OpenShift is locked down tightly by default. YAML manifests could be a nighmare because almost everything in OpenShift is defined by them.
At lest the commands are not too confusing. There core set is grouped under OC - Open Shift Commands
Here are some examples for controlling clusters, vms and pods:
oc login https://api.your-cluster.com:6443 --username=admin
oc get vms -A
oc get pods -n openshift-mtv
So, quite close to kubernetes, but lots of room for error.
The task of migrating to Open Shift is large and complex. That is a subject for another post.