OpenShift virtualization (upstream project - Kubernetes: KubeVirt, see here and here ), as a Container-native Virtualization, It was introduced as a functional platform OpenShift, which is designed to deploy and manage virtual machines (VMs), as the basic entities of Kubernetes. This kind of task is technically difficult, due to the fundamental differences in technology. In order to achieve this goal, we used the familiar technologies based on Red Hat Enterprise Linux and KVM, which have been with us for more than a year and have proved their effectiveness.

ITKarma picture

In this article, we will examine the technical aspects of OpenShift virtualization that make VMs and containers coexist within a single platform that manages them as a whole.

Computing tasks


Containers use Linux kernel mechanisms, such as namespaces and cgroups, to isolate processes and manage resources. Usually, processes are understood as Python, Java applications or executable files, but in fact they can be any processes, the same bash, Emacs or vim.

What is a virtual machine? From the point of view of the hypervisor, this is also a process. But not just the application process, but the KVM process responsible for executing a specific VM.

ITKarma picture


The container image contains all the tools, libraries, and files needed for the KVM virtual machine. If we inspect the pod of a running VM, we will see helpers and qemu-kvm processes there. In addition, we have access to KVM tools for managing virtual machines, such as qemu-img, qemu-nbd and virsh.

ITKarma picture


Since the virtual machine is a pod, it automatically inherits all the pod’s functionality in Kubernetes. For VM pods, just like regular pods, scheduler schemes and criteria like taints, tolerations, affinity, and anti-affinity apply. You also get the benefits of high availability, etc. However, there is one important difference: regular pods don’t migrate from host to host in the usual sense. If the node is disconnected, then the pod on it is interrupted and reassigned to another node in the cluster. And in the case of a virtual machine, we expect to see a live migration.

To address this gap, a custom resource definition (CDR) was created that describes a live migration mechanism that is responsible for initializing, monitoring, and managing live VM migrations between work nodes.

apiVersion: kubevirt.io/v1alpha3 kind: VirtualMachineInstanceMigration metadata: name: migration-job spec: vmiName: fedora 

When a node is deactivated for those virtual machines that have Live Migration set as the eviction strategy, migration tasks are automatically created. Thus, it is possible to control the behavior of virtual machines when moving between cluster nodes. You can configure Live Migration as well as manage the VM, as well as all other pods.

Network


Any Kubernetes system provides communication between nodes and pods using software SDN networks. OpenShift is no exception and, starting with version 3, it uses OpenShiftSDN by default. In addition, OpenShift 4 has another new feature called Multus, which allows you to make several networks available and connect pod to them at the same time.

ITKarma picture


Using Multus, the administrator can specify additional CNI networks, which will then be deployed and configured on the cluster by the special Cluster Network Operator.Then pod’s connect to one or more of these networks, usually the standard OpenShiftSDN and an additional interface. SR-IOV devices, standard Linux Bridge, MACVLAN and IPVLAN devices - all this can also be used if your VM needs it. The figure below shows how to set Multus CNI for a bridge network on eth1:

apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec: additionalNetworks: - name: multus1 rawCNIConfig: '{ "cniVersion": "0.3.1", "type": "bridge", "master": "eth1", "ipam": { "type": "static", "addresses": [ { "address": "191.168.1.1/24" } ] } }' type: Raw 

In relation to OpenShift virtualization, this means that VMs can be connected to an external network directly, bypassing SDN. This is important for virtual machines migrated to OpenShift from Red Hat Virtualization or VMware vSphere, since there is no change in network settings if you have access to the second level of OSI. This also means that the VM can have a network address that is accessed bypassing the SDN. Thus, we can effectively use specialized network adapters, or connect directly to the storage system via the network...

You can learn more about how to create and connect OpenShift virtualization virtual machines to the network here . In addition, the nmstate operator , deployed as part of the OpenShift virtualization, offers another way you are familiar with creating and managing network configurations on physical nodes that are used under hypervisors.

Storage


OpenShift virtualization connects and manages virtual machine disks using Kubernetes concepts such as StorageClasses, PersistentVolumeClaims (PVC) and PersistentVolume (PV), as well as storage protocols standard for Kubernetes. Thus, Kubernetes administrators and application-specific teams receive a single and familiar management mechanism for both containers and virtual machines. And for many virtualization administrators, this concept may seem familiar, because it uses the same principle of separating VM configuration files and disks that is used by OpenStack and many other cloud platforms.

However, you can’t just create a new disk for VM every time, because when migrating from the hypervisor to OpenShift, we need to save the data. Yes, even when we deploy a new VM, it is always faster to make from a template than to create from scratch. Thus, we need the functionality to import existing disks.

To simplify this task, OpenShift virtualization is deploying the Containerized Data Importer (CDI) project, which reduces the import of disk images from multiple sources to create a record in PVC.

apiVersion: v1 kind: PersistentVolumeClaim metadata: name: "fedora-disk0" labels: app: containerized-data-importer annotations: cdi.kubevirt.io/storage.import.endpoint: "http://10.0.0.1/images/Fedora-Cloud-Base-31-1.9.x86_64.qcow2" spec: storageClassName: ocs-gold accessModes: - ReadWriteOnce resources: requests: storage: 20Gi 

It is this record that activates the CDI, starting the sequence of actions shown in the figure below:

ITKarma picture


After the CDI works, the PVC will contain the virtual machine disk ready for use and converted to the standard format for OpenShift...
When working with OpenShift virtualization, OpenShift Container Storage (OCS), a Red Hat solution based on the Ceph file system that implements persistent storage functionality for containers, is also useful. In addition to the standard PVC access methods - RWO (block) and RWX (file) - OCS provides RWX for raw block devices, which is very useful when organizing shared block access for applications with high performance requirements. In addition, OCS supports the new Object Bucket Claim object group query standard, which allows applications to use object storage directly.

Container Virtual Machines


If you are interested in checking how this works, then know that OpenShift virtualization is already available in the Tech Preview option as part of OpenShift 3.11 and higher. Owners of a valid OpenShift subscription can use OpenShift virtualization for free and without any additional gestures. At the time of the release of this post, OpenShift 4.4 and OpenShift virtualization 2.3 are relevant, if you use previous versions, then to get the latest features it is worth updating. A fully supported version of OpenShift virtualization is due out in the second half of 2020.

For more information, see the OpenShift documentation for installation instructions, including Multus Setup Section , which provides information on configuring external networks.

Source