Key Concepts and Best Practices for OpenShift Virtualization

The default instance type for the fedora data source is u1.medium, which specifies 1 CPU and 4 GiB of memory. Below that, the default preference is the VirtualMachineClusterPreference (VMCP) field, a custom resource that allows you to define cluster-wide preferences for deploying virtual machines. It acts as a centralized configuration point for the VM attributes you want to apply by default to all VMs created within the cluster unless overridden by individual VM specifications.

You can check the cluster-wide VM preferences as follows:

$ oc get vmcps
NAME                  AGE
alpine                7h41m
centos.7              7h41m
centos.7.desktop      7h41m
centos.stream8        7h41m
centos.stream8.desktop   7h41m
centos.stream9        7h41m
centos.stream9.desktop   7h41m
cirros                7h41m
fedora                7h41m
[........]

$ oc get vmcps fedora -o yaml
apiVersion: instancetype.kubevirt.io/v1beta1
kind: VirtualMachineClusterPreference
metadata:
  annotations:
 iconClass: icon-fedora
 [.....................]
  generation: 1
  labels:
 app.kubernetes.io/component: templating
 app.kubernetes.io/managed-by: ssp-operator
     [......................]
  name: fedora
  resourceVersion: "42107926"
  uid: b1b262d1-680d-4fbf-9829-33ad30be40fd
spec:
  devices:
 preferredDiskBus: virtio
 preferredInterfaceModel: virtio
 preferredNetworkInterfaceMultiQueue: true
 preferredRng: {}
  features:
 preferredSmm: {}
  firmware:
 preferredUseEfi: true
 preferredUseSecureBoot: true
  requirements:
    cpu:
    guest: 1
    memory:
   guest: 2Gi

This provides us with much more insight into the low-level details of the virtual machine, such as the use of a virtio disk bus and the preferred type of firmware (EFI).

Creating a virtual machine manifest

We’ll use the above information to create a virtual machine manifest using the virtctl utility. We’ll also create an SSH key pair to access our virtual machine, convert it into a secret, and inject it into the VM manifest. 

To create an SSH key pair, run this command:

$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/wartortle/.ssh/id_rsa):
Created directory '/home/wartortle/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/wartortle/.ssh/id_rsa.
Your public key has been saved in /home/wartortle/.ssh/id_rsa.pub.

Let’s create a secret in our current project using the public key from this pair:

$ oc create secret generic myfedora-ssh --from-file=.ssh/id_rsa.pub

Create the manifest file for the Fedora virtual machine using virtctl:

$ virtctl create vm --name my-fedora-1 --instancetype u1.medium --infer-preference --volume-datasource name:root,src:openshift-virtualization-os-images/fedora,size:30Gi > myfedora.yaml

This command creates a manifest for a virtual machine named my-fedora-1 using the predefined instance type u1.medium. It leverages the preconfigured Fedora image from the openshift-virtualization-os-images project and allocates 30 GB of storage for the VM’s root filesystem.

The –infer-preference option tells virtctl to automatically infer the VM configuration preferences based on the provided information in the VMCP resource.

Before creating the VM, we’ll need to add some things to our manifest file. First, we must add a service creation label to expose the VM via the NodePort service:

$ vi myfedora.yaml
[.....]
  instancetype:
 name: u1.medium
  preference:
 inferFromVolume: root
  runStrategy: Always
  template:
 metadata:
     labels:
         myvm: fedora
[......]

Second, we must add the credentials to access our virtual machine. For this purpose, we’ll embed the secret containing the public SSH key we created earlier and define a username/password combination:

$ vi myfedora.yaml
[.....]
   volumes:
   - dataVolume:
          name: root
       name: root
   - cloudInitConfigDrive:
          userData: |
         #cloud-config
           user: fedora
           password: Fedora123
           chpasswd:
               expire: false
       name: cloudinitdisk
   accessCredentials:
     - sshPublicKey:
         propagationMethod:
           configDrive: {}
         source:
           secret:
             secretName: myfedora-ssh

We’ve now added our public key as the secret myfedora-ssh and created a cloud-init config drive. The cloud-init utility configures virtual machine instances during system boot. Major cloud providers also use it to bootstrap Linux compute instances in cloud environments. A config drive is presented to the virtual machine as a read-only drive, and the virtual machine can read files from it. We’ve added a username/password combination as user data in the config drive.

Our final manifest looks as follows:

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  creationTimestamp: null
  name: my-fedora-1
spec:
  dataVolumeTemplates:
  - metadata:
      creationTimestamp: null
      name: root
    spec:
      sourceRef:
        kind: DataSource
        name: fedora
        namespace: openshift-virtualization-os-images
      storage:
        resources:
          requests:
            storage: 30Gi
  instancetype:
    name: u1.medium
  preference:
    inferFromVolume: root
  runStrategy: Always
  template:
    metadata:
      labels:
        myvm: fedora
    spec:
      domain:
        devices: {}
        resources: {}
      volumes:
      - dataVolume:
          name: root
        name: root
      - cloudInitConfigDrive:
          userData: |
            #cloud-config
            user: fedora
            password: Fedora123
            chpasswd:
              expire: false
        name: cloudinitdisk
      accessCredentials:
      - sshPublicKey:
          propagationMethod:
            configDrive: {}
          source:
            secret:
              secretName: myfedora-ssh

Creating the virtual machine

Let’s apply the finishing touches and create the VM.

$ oc create -f myfedora.yaml
virtualmachine.kubevirt.io/my-fedora-1 created
$ oc get vm
NAME          AGE   STATUS   READY
my-fedora-1   25s   Running   True

There you have it—the virtual machine is up and running. 

Let’s use the embedded SSH key to access our VM using virtctl:

$ virtctl ssh fedora@my-fedora-1 -i .ssh/id_rsa
The authenticity of host 'vmi/my-fedora-1.project1 ()' can't be established.
ECDSA key fingerprint is SHA256:EzRdrmAuIbfQgjsbI2r93tn1BGjSh1qwi0DYCJUIcBk.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'vmi/my-fedora-1.project1' (ECDSA) to the list of known hosts.
[fedora@my-fedora-1 ~]$

You can connect to the virtual machine’s VNC console using the virtctl utility. As shown below, use the username/password combination that you defined in the manifest file:

$ virtctl  console my-fedora-1
Successfully connected to my-fedora-1 console. The escape sequence is ^]

my-fedora-1 login: fedora
Password:
Last login: Sun Jun 16 13:52:28 on ttyS0
[fedora@my-fedora-1 ~]$

Using virtctl to access the VM is fairly simple, but for high-traffic scenarios, consider exploring alternative approaches, such as services, that distribute the load more efficiently.

Let’s create a service for our VM:

$ virtctl expose vm my-fedora-1 --name fedorasvc --type NodePort --port 22
Service fedorasvc successfully exposed for vm my-fedora-1
$ oc get svc
NAME     TYPE    CLUSTER-IP    EXTERNAL-IP   PORT(S)    AGE
fedorasvc  NodePort   172.30.232.201       22:30825/TCP   8s

Find the node on which the VM is running and SSH it into the node via the corresponding port:

$ oc get vmi
NAME          AGE   PHASE   IP         NODENAME           READY
my-fedora-1   11m   Running 10.130.0.31   worker2.ovn.com   True

$ ssh -i .ssh/id_rsa [email protected] -p 30825
Last login: Sun Jun 16 13:52:50 2024
[fedora@my-fedora-1 ~]$

As you can see, the native service object works just as well for VMs.

Best practices for running virtualization workloads in OpenShift

Here are some recommended practices to get the most out of running virtual machines in OpenShift.

• Standardize VM configurations: Use VMCPs and templates to ensure consistent configurations for your VMs, simplifying management and reducing errors.
• Use Red Hat golden images: Take advantage of preconfigured virtual machine images provided by Red Hat. These secure images have undergone thorough testing, making the virtual machine setup process faster and more efficient.
• Monitor resource usage: Monitor virtual machine CPU, memory, and storage consumption to identify potential bottlenecks and optimize resource allocation if necessary.
• Enforce security: OpenShift enforces several security policies for virtualization workloads, such as not allowing virtual machines to run with root privileges. You can further utilize security context constraints (SCCs) to define security policies for virtual machines.
• Perform backups: Implement a comprehensive backup and disaster recovery strategy for your virtual machines to ensure data protection and quick recovery in case of an incident. Consider using solutions such as Trilio for this purpose.