Tech ONTAP Blogs

Live Migration of VMs with OpenShift Virtualization on ROSA and Amazon FSx for NetApp ONTAP

banusundhar
NetApp
446 Views

Authors: Banu Sundhar, NetApp

Mayur Shetty, Red Hat

   

 

We are often faced with innovative technologies that challenge the existing paradigms. OpenShift Virtualization, built on the upstream KubeVirt project, is one such technology.

 

OpenShift Virtualization allows organizations to run traditional Virtual Machines (VMs) alongside containerized applications in a unified platform. This is particularly valuable for enterprises with legacy applications that need modernization without a complete overhaul. Using Kubernetes as a control plane provides significant benefits, such as scalability, self-healing, and management consistency. For organizations already invested in OpenShift, this integration simplifies operations, as teams can leverage existing tools and workflows.

 

OpenShift Virtualization is included with OpenShift at no additional licensing or subscription cost. On AWS, it runs on Red Hat OpenShift Service on AWS (ROSA), leveraging its orchestration capabilities to manage VMs alongside containerized applications. This integration allows teams to utilize the same management tools and practices for both VMs and containers, streamlining operations and enhancing efficiency.

 

The approach of running VMs on a container orchestrator addresses the growing need for flexibility in application deployment. Organizations can choose to run both VMs and containers based on specific workload requirements, without the need to manage separate infrastructure environments.

 

Amazon FSx for NetApp ONTAP (FSxN) provides fully managed shared storage in AWS Cloud with the popular data access and management capabilities of ONTAP. One key benefit of FSxN is that it is a true first party AWS offering just like EBS, meaning customers can retire their committed spend with AWS and get support directly from them as well. FSxN can be consumed by applications and VMs running on OpenShift using NetApp Trident as the storage orchestrator.

 

Solution overview

Below we will look into setting up FSxN as the default Storage Class for the ROSA cluster, and then create a VM that will leverage FSxN storage for its volumes. We will also look into connecting to the VM using the guest credentials and follow that by performing a live migration of the VM from the current node to a new node.

 

 

Prerequisites:

 

This diagram shows the ROSA cluster deployed in multiple AZs. ROSA cluster’s master nodes, infrastructure nodes are in Red Hat’s VPC, while the worker nodes are in a VPC in the customer's account. Some of the worker nodes are metal instance type to support OpenShift Virtualization. FSxN file system is deployed within the same VPC. NetApp Trident provisioner is installed in the ROSA cluster, allowing all the subnets of this VPC to connect to the file system. OpenShift Virtualization is installed using the operator from the OperatorHub.

banusundhar_0-1730218313489.png

1. Initial Setup

Ensure default Storage Class is set to trident-csi.

The following yaml was used to create the storage class

 

apiVersion: storage.k8s.io/v1

kind: StorageClass

metadata:

  name: trident-csi

provisioner: csi.trident.netapp.io

parameters:

  backendType: "ontap-nas"

  fsType: "ext4"

allowVolumeExpansion: True

reclaimPolicy: Retain

Screenshot 2024-10-29 at 3.01.50 PM.png

Note: Prior to creating the Storage class, the following yaml files were used to create a secret and the backend object using ontap-nas driver.

 

apiVersion: v1

kind: Secret

metadata:

  name: backend-fsx-ontap-nas-secret

  namespace: trident

type: Opaque

stringData:

  username: vsadmin

  password: <SVM password configured while creating FSxN>

 

 

apiVersion: trident.netapp.io/v1

kind: TridentBackendConfig

metadata:

  name: backend-fsx-ontap-nas

  namespace: trident

spec:

  version: 1

  backendName: fsx-ontap

  storageDriverName: ontap-nas

  managementLIF: <Management DNS name>

  dataLIF: <NFS DNS name>

  svm: <SVM NAME>

  credentials:

    name: backend-fsx-ontap-nas-secret

 

Ensure default VolumeSnapShotClasses is set as shown

The following yaml was used to create the VolumeSnapshotClass

kind: VolumeSnapshotClass

metadata:

  name: fsx-snapclass

driver: csi.trident.netapp.io

deletionPolicy: Delete

Screenshot 2024-10-29 at 3.04.56 PM.png

If the defaults are not set, you can set it up either from the console or from command line

 

$ oc patch storageclass trident-csi -p '{"metadata": {"annotations": {"storageclass.kubernetes.io/is-default-class": "true"}}}'

 

$ oc patch VolumeSnapshotClasses fsx-snapclass -p '{"metadata": {"annotations": {"snapshot.storage.kubernetes.io/is-default-class": "true"}}}'

 

1. Create a VM from the template

 

Use the web console to create a VM from a template.

From the RedHat OpenShift Service on AWS console, create a VM.

There are templates available on the cluster that can be used to create the VM.

I am choosing fedora VM template from this list. Give the VM a name, and then click on Customize Virtual Machine. Select the Disks tab and click on Add disks. Change the name of the disk, preferably to something meaningful, ensure that trident-csi is selected for storage class. Click on Save. Click on Create VirtualMachine.

 

After a few minutes, the VM is in the running state

Screenshot 2024-10-29 at 3.08.30 PM.png

Screenshot 2024-10-29 at 3.09.06 PM.png

Screenshot 2024-10-29 at 3.09.37 PM.png

Screenshot 2024-10-29 at 3.09.55 PM.png

Screenshot 2024-10-29 at 3.10.14 PM.png

Screenshot 2024-10-29 at 3.10.34 PM.png

2. Review all the objects created for the VM

 

The storage disks.

banusundhar_3-1730229142023.png

The file systems of the VM will show the Partitions, File system type and the Mount points.

banusundhar_4-1730229159349.png

2 PVCs are created for the VM, one from the boot disk and one for the hot plug disk.

banusundhar_5-1730229159352.png

The PVC for the boot disk shows that the Access mode is ReadWriteMany, and the Storage Class is trident-csi.

banusundhar_6-1730229213718.png

Similarly, the PVC for the hot-plug disk shows that the Access mode is ReadWriteMany, and the Storage Class is trident-csi.

banusundhar_7-1730229231725.png

In the screenshot below we can see that the pod for the VM has a Status of Running.

banusundhar_8-1730229242553.png

Here we can see the two Volumes associated with the VM pod and the 2 PVCs associated with them.

Screenshot 2024-10-29 at 3.15.13 PM.png

Screenshot 2024-10-29 at 3.16.11 PM.png

Screenshot 2024-10-29 at 3.16.31 PM.png

Issue the following commands:

 

$ df (to display information about the disk space usage on a file system).

$ dd if=/dev/urandom of=random.dat bs=1M count=10240 (to create a file called random.dat in the home dir and fill it with random data).

 

The disk is filled with 11 GB of data.

Screenshot 2024-10-29 at 3.17.44 PM.png

Use vi to create a sample text file that we will use to test.

Screenshot 2024-10-29 at 3.18.27 PM.png

4. Restart the virtual machine

banusundhar_9-1730229580846.png

The VM comes back to the running state with the exact same filesystems, PVCs and files in the filesystems

Screenshot 2024-10-29 at 3.20.45 PM.png

 

banusundhar_11-1730229681356.png

 

5. Live migration

Live migration refers to the process of moving a running VM from one physical host to another host without disrupting normal operations or causing any downtime, or other adverse effects for the end user.

Live migration is considered a major step in Virtualization. It allows an entire VM to be moved with a running operating system (OS), Memory, storage, and network connectivity from their current node to the destination.

Below we will see how to perform a Live Migration of the VM from the current node to a new node.

Note the node on which the VM is running.

Screenshot 2024-10-29 at 3.26.02 PM.png

Screenshot 2024-10-29 at 3.26.56 PM.png

On the Overview page, you can see that the migration has succeeded, and the Status has changed to Succeeded.

Screenshot 2024-10-29 at 3.27.38 PM.png

After the completion of the Live Migration, the VM is now on a different node.

Screenshot 2024-10-29 at 3.28.32 PM.png

Open the web console and view the contents of the disks. It still has the same 2 files that we previously created before Live Migration.

banusundhar_12-1730230144329.png

banusundhar_13-1730230144331.png

The storage for the VM on the new node still shows the same disks.

Screenshot 2024-10-29 at 3.33.05 PM.png

Also, the PVCs are the same.

Screenshot 2024-10-29 at 3.33.39 PM.png

Volumes associated with the VM pod are also the same (2 PVCs) as before.

Screenshot 2024-10-29 at 3.34.35 PM.png

Conclusion:

Combining OpenShift Virtualization with FSx for NetApp ONTAP creates a powerful solution for organizations seeking to optimize their hybrid cloud environments. OpenShift Virtualization allows users to manage both VMs and containerized applications within a unified Kubernetes platform, enhancing operational efficiency and flexibility. Meanwhile, FSx for NetApp ONTAP provides scalable, high-performance storage that seamlessly integrates with OpenShift, ensuring that data is readily accessible and protected.

This combination empowers businesses to modernize their applications while efficiently managing legacy workloads. With the ability to run diverse workloads in a single environment, teams can streamline their operations, reduce complexity, and improve resource utilization. Together, OpenShift Virtualization and FSx for NetApp ONTAP deliver a robust infrastructure that meets the demands of today's dynamic enterprise landscape, enabling innovation and growth.

For more information about Trident, refer to the NetApp Trident documentation. See the Red Hat OpenShift Virtualization section in the NetApp Solutions documentation for additional information and videos. If you’d like to clean up the solution set up in this post, follow the instructions in the github repository.

 

 

 

Public