I had a freshly deployed Red Hat OpenShift cluster on which I had set up OpenShift Virtualization (KubeVirt). When I tried to create my first data volume so I could start creating VMs, nothing happened. The ISO file upload would fail.
Running oc describe dv {name} -n {namespace} showed the below event/error.
DataVolume.storage spec is missing accessMode and volumeMode, cannot get access mode from StorageProfile managed-nfs-storage
The Cause
This is caused by default created StorageProfile used by KubeVirt, which will be created from your default StorageClass, not setting the correct values, as per this git issue comment.
Previously virtctl (CLI for KubeVirt) used ReadWriteOnce if accessMode was not specified. But now, as we want to use possibilities provided by StorageProfiles, it does not set accessMode.
The Fix
Run the following command to update your StorageProfile with the correct settings, pay attention to whether you needReadWriteOnce or ReadWriteMany.
Recently, I’m seeing more and more queries about migrating to Cilium within an existing Red Hat OpenShift cluster, due to Cilium’s advanced networking capabilities, robust security features, and enhanced observability out-of-the-box. This increase of interest is also boosted by the fact that Cilium became the first Kubernetes CNI to graduate in the CNCF Landscape.
In this blog post, we’ll cover the step-by-step process of migrating from the traditional OpenShiftSDN (default CNI pre-4.12) or OVN-Kubernetes (default CNI from 4.12) to Cilium, exploring the advantages and considerations along the way.
If you need to understand more about the default CNI options in Red Hat OpenShift first, then I highly recommend this blog post, as pre-reading before going through this walkthrough.
Cilium Overview
For those of you who have not heard of Cilium, or maybe just the name and know there’s a buzz about it. In short Cilium, is a cloud native networking solution to provide security, networking and observability at a software level.
The reason why the buzz is so huge is due to being implemented using eBPF, a new way of interacting and programming with the kernel layer of the OS. This implementation opens a whole new world of options.
I’ll leave you with these two short videos from Thomas Graf, co-founder of Isovalent, the creators of Cilium.
Does Red Hat support this migration?
Cilium has achieved the Red Hat OpenShift Container Network Interface (CNI) certification by completing the operator certification and passing end-to-end testing. Red Hat will support Cilium installed and running in a Red Hat OpenShift cluster, and collaborate as needed with the ecosystem partner to troubleshoot any issues, as per their third-party software support statements. This would be a great reason to look at Isovalent Enterprise for Cilium, rather than using Cilium OSS, to get support from both vendors.
However, when it comes to performing a CNI migration for an active existing OpenShift cluster, Red Hat provides no guidance, unless it’s migrating from OpenShiftSDN to OVN-Kubernetes.
This means CNI migration to a third party CNI in an existing running Red Hat OpenShift Cluster is a grey area.
I’d recommend speaking to your Red Hat account team before performing any migration like this in your production environments. I have known large customers to take on this work/burden/supportability themselves and be successful.
Follow along with this video!
If you prefer watching a video or seeing things live and following along, like I do at times, then I’ve got you covered with the below video that covers the content from this blog post.
Pre-requisites and OpenShift Cluster configuration
As per the above, understand this process in detail, and if you follow it, you do so at your own risk.
For this walkthrough, I’ve deployed a OpenShift 4.13 cluster with OVN-Kubernetes, with a sample application (see below). You can see these posts I’ve written for deployments of OpenShift, or follow the official documentation.
OpenShift Container Platform defaults to using an in-tree (non-CSI) plug-in to provision vSphere storage.
What’s New?
In OpenShift 4.9, the out-of-the-box installation of the vSphere CSI driver was tech preview. This has now moved to GA!
This means during an Installer-Provisioned-Installation cluster bring up, the vSphere CSI driver will be enabled.
This is part of the future “journey” of OpenShift to CSI drivers. As you may be aware, the original storage implementations “in-tree” drivers will be removed from future versions of Kubernetes, making way for the CSI Drivers, a better storage integration implementation.
Therefore, the Red Hat team have been working with the upstream native vSphere CSI Driver, which is open-source and VMware Storage team, to integrating into the OpenShift installation.
The aim here is two-fold, take further advantage of the VMware platform, and to enable CSI Migration. So that is easier for customers to migrate their existing persistent data from in-tree provisioned storage constructs to CSI provisioned constructs.
Recently, I was involved in some work to assist the VMware Tanzu Observability team to assist them in updating their deliverables for OpenShift. Now it’s generally available, I found some time to test it out in my lab.
For this blog post, I am going to pull in metrics from my VMware Cloud on AWS environment and the Red Hat OpenShift Cluster which is deployed upon it.
What is Tanzu Observability?
We should probably start with what is Observability, I could re-create the wheel, but instead VMware has you covered with this helpful page.
As a developer you want to focus on developing the application, but you also do need to understand the rest of the stack to a point. In the middle, you have a Site Reliability Engineer (SRE), who covers the platform itself, and availability to ensure the app runs as best it can. And finally, we have the platform owner, where the applications and other services are located.
Somewhere in the middle, when it comes to tooling, you need to cover an example of the areas listed below:
Application Observability & Root Cause Analysis
App-aware Troubleshooting & Root Cause Analysis
Distributed Tracing
CI/CD Monitoring
Analytics with Query Language and high reliability, granularity, cardinality, and retention
Full-Stack Apps & Infra Telemetry as a Service
Infra Monitoring
Performance Optimization
Capacity and Cost Optimization
Configuration and Compliance
So now you are thinking, OK, but VMware has vRealize Operations that gives me a lot of data, so why is there a new product for this?
vRealize Operations and Tanzu Observability come together – delivering full stack monitoring and observability from both the infra-up and app-down perspective, equipping both teams in the org to meet common goals.
It is about the right tool for the right team and bringing together harmony between them. Which is why at VMware, the focus has been on covering the needs of team across the two products.
vRealize Operations is going to give you SLA metrics for your infrastructure and even application awareness. However Tanzu Observability brings more application focused features to allow you as a business, report on Application Experience of your end users/customers, at an SLA/SLO/KPI approach with extensibility to provide an Experience Level Agreement (XLA) type capability.
VMware Tanzu Observability by Wavefront delivers enterprise-grade observability and analytics at scale. Monitor everything from full-stack applications to cloud infrastructures with metrics, traces, event logs, and analytics.
I was honoured to be a guest on the “Ask an OpenShift Admin” webinar recently. Where I had the chance to talk about OpenShift on VMware, always a hot topic, and how we co-innovate and work together on solutions.
You can watch the full session below. Keep reading to see the content I didn’t get to cover on a separate recording I’ve produced.
Ask an OpenShift Admin (Ep 54): OpenShift on VMware and the vSphere Kubernetes Drivers Operator
However, I had a number of topics and demo’s planned, that we never got time to visit. So here is the full content I had prepared.
Some of the areas in this webinar and my additional session we covered were:
Answering questions live from the views (anything on the table)
OpenShift together with VMware
Common issues and best practices for deploying OpenShift on VMware vSphere
Consuming your vSphere Storage in OpenShift
Integrating with the VMware Network stack
Infrastructure Up Monitoring
OpenShift on VMware – Integrating with vSphere Storage, Networking and Monitoring
