Using Virtual Machine Templates
Virtual Machine Templates
RHOCP provides resources to help create and administer workload objects in a cluster.
One of these resources is preconfigured templates.
Templates contain default parameters that you can customize according to your needs.
RHOCP provides templates for several resource types, including network interfaces, PVs, and VMs.
Red Hat OpenShift Virtualization provides a catalog of preconfigured templates to create a virtual machine and its resources.
Templates are available for different versions of Red Hat Enterprise Linux, CentOS, Fedora, Microsoft Windows 10 and 11, and Microsoft Windows Servers.
Red Hat provides virtual machine templates that are preconfigured with the operating system image, default settings for the operating system, workload type, and flavor, which specifies CPU and memory resources.
Preconfigured templates include changeable fields to meet your VM's needs.
The default parameters suggest a basic configuration that works with any VM.
However, if you customize the VM configuration, then some important considerations apply:
- Boot Source
This field indicates the source of the image to create your VM, and includes the following options:
PVC (clone PVC): Clone an existing PVC in the cluster to create a PVC.
Registry (creates PVC): Create a PVC by importing content from a container registry.
URL (creates PVC): Create a PVC by importing content from a URL with an HTTP or an S3 endpoint.
Upload (Upload a new file to a PVC): Create a PVC by uploading a new file to a PVC.
Blank: Create a blank PVC.
- CPU | Memory
This field indicates the flavor, or size, of your VM in terms of CPU and memory.
Templates from Red Hat indicate the size of the provisioned VM with the following options:
Tiny: Creates a VM with 1 CPU and 1 GiB memory; recommended for testing VM creation.
Small: Creates a VM with 1 CPU and 2 GiB memory; this option is the default for any preconfigured template.
Medium: Creates a VM with 1 CPU and 4 GiB memory; appropriate for code testing or to store basic application resources.
Large: Creates a VM with 2 CPU and 8 GiB memory; recommended for systems that require heavy resource consumption.
Custom: Specify custom values of CPU and memory for your VM.
Note
In templates from Red Hat OpenShift Virtualization, you can no longer change the flavor.
The template designations for usage and size determine how much memory and CPU are provisioned and can be changed when configuring parameters.
- Instance Types
Three instance types are available on Red Hat OpenShift, each with its own variations of CPU and memory:
cx1.~: The CX Series provides exclusive compute resources for compute-intensive applications.
CX is the abbreviation of "Compute Exclusive".
The exclusive resources are given to the compute threads of the VM.
To ensure these exclusive compute resources, some additional cores (depending on the number of disks and NICs) are requested to offload the I/O threading from cores that are dedicated to the workload.
In addition, in this series, the NUMA topology of the used cores is provided to the VM.
gn1.~: The GN Series provides instance types for VMs with attached NVIDIA GPU resources.
GN is the abbreviation of "GPU NVIDIA".
This series is intended for VMs that consume GPUs from the NVIDIA GPU Operator, which is available on OpenShift via OperatorHub.
m1.~: The M Series provides resources for memory-intensive applications.
M is the abbreviation of "Memory".
Navigate to → to view all the available instance types on Red Hat OpenShift.
- Workload
This field indicates the workload type for your VM, and includes the following options:
Desktop: A configuration for a desktop system that prioritizes VM density over guaranteed VM performance.
Red Hat recommends VMs with this configuration.
Server: The default option for any preconfigured template, and compatible with various server workloads.
This option balances performance and prioritizes VM density over VM performance.
High-Performance: Optimized for high-performance or high-consumption workloads.
This option prioritizes guaranteed VM performance over VM density.
- Disks
A preconfigured Linux-based template has two partitions by default, cloud-init and root disk.
However, you can configure additional disks.
Each field has several available options for customizing your template:
Source: You can create or import a disk from an existing or blank PVC, from an external source such as a container registry or URL, or by using a container in a registry that is accessible from the cluster.
Type: You can customize the storage type, such as a disk or CD-ROM, according to the needs of your VM.
Interface: You can select the communication interface of your disk based on compatibility standards and the intended performance of your VM.
The available options are virtio, SATA, or SCSI.
Storage Class: Select the storage class for the disk.
The storage profile sets the optimized access mode and the volume mode for the storage class.
Access mode: You can customize the disk's access mode, and override the default storage profile settings.
The available access modes are Single user (RWO), Shared access (RWX), or Read only (ROX).
Volume mode: You can choose between Filesystem and Block storage volume modes for your VM, depending on the selected storage class.
Note
VMs must have a PVC with a shared ReadWriteMany (RWX) access mode to enable live migration.
- Network interfaces
Red Hat provides templates with a default network interface that is connected to the pod network.
You can configure additional network interfaces for your VM.
For each field, you have several options available to customize your template:
Interface model: You can choose either virtio or e1000e, based on your VM's needs and required performance.
The virtio model is optimized for performance, and most Linux distributions support it.
Additional drivers are needed for Windows VMs.
Although most operating systems, including Windows, support the e1000e model, its performance is slower than the virtio model.
Network: You can select from a list of available network attachment definitions to connect to additional networks.
Additional networks must use the bridge binding method.
Type: You can select from a list of binding methods.
You must use the masquerade binding method on the default pod network.
Additional networks must use the bridge binding method.
MAC Address: You can specify a custom MAC address for the network interface.
MAC addresses are automatically assigned unless you specify a custom address.
- Scripts
In this field, you configure cloud-init on compatible systems, add authorized SSH keys, or configure Sysprep for Microsoft Windows machines.
Both cloud-init and sysprep install tools and packages, configure users and passwords, and manage system applications.
The Containerized Data Importer (CDI) is an add-on that manages persistent storage for VMs in OpenShift Virtualization.
With CDI, you can import, upload, and clone existing PVCs for your VMs.
CDI provides a custom resource definition (CRD) for DataVolume objects that orchestrate the import, clone, and upload operations that are associated with an underlying PVC.
Data volumes are integrated into your OpenShift cluster when you install the OpenShift Virtualization operator, and prevent a VM from starting until its underlying PVC is ready.
With OpenShift Virtualization, you can create a VM from a data volume, including cloning an existing PVC as a new data volume or uploading a local disk image.
You can use a data volume template to create a VM from an existing PVC by using the OpenShift web console or from the command line.
Cloning the PVC of an existing VM in a different namespace produces the following configuration for a new VM:
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
name: vm-clone-pvc 
labels:
kubevirt.io/vm: vm-clone-pvc
namespace: backup-vms 
spec:
running: false
template:
metadata:
labels:
kubevirt.io/vm: vm-clone-pvc
spec:
domain:
cpu:
cores: 1
devices:
disks:
- disk:
bus: virtio
name: root-disk
resources:
requests:
memory: 2Gi
terminationGracePeriodSeconds: 0
volumes:
- dataVolume:
name: new-pvc-from-clone 
name: root-disk
dataVolumeTemplates: 
- apiVersion: cdi.kubevirt.io/v1beta1
metadata:
name: new-pvc-from-clone 
spec:
pvc:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 10Gi 
source:
pvc:
namespace: storage-vm 
name: database-storage-pvc 
| Name of the new VM. |
| Namespace where the new VM is created. |
| Name of the new PVC that is created from the original PVC. |
| Data volume template to specify the new PVC to create. |
| If your PVC uses the Filesystem volume mode, the requested storage must be larger than the storage source to account for file system overhead data. |
| Source namespace where the original VM and PVC exists. |
| Name of the source PVC to create the VM. |
You can apply the completed YAML manifest to you cluster with the oc create -f or oc apply -f commands.
[user@host ~]$ oc create -f virtualmachine-vm-example-clone.yaml
virtualmachine.kubevirt.io/vm-clone-pvc created
Create a Virtual Machine with a Template
You can create VMs from preconfigured templates in the OpenShift web console.
The templates provide default parameters that suggest a basic configuration for your VM's guest operating system.
The following example shows how to create a Red Hat Enterprise Linux 8.0 VM from the web console by using a preconfigured template:
From the web console, navigate to → , and click the Red Hat Enterprise Linux 8.0 VM template.
Click Customize VirtualMachine.
Complete the form and provide a name for your VM.
Select the URL (creates PVC) option in the Disk source list.
For RHEL, click the link below the Image URL input box, log in with your credentials, and then copy the URL of the KVM Guest image download.
Leave the Cloud-init form fields under Optional parameters with their default values.
Note
A username and password are created by default.
After creating the VM, you can examine the credentials that the cloud-init service generates, by navigating to → .
Click the Console tab and then click Guest login credentials above your VM console.
Click Customize VirtualMachine parameters.
Confirm that the default interface is connected to Pod networking with a Masquerade bonding method in Network interfaces.
Leave the disks with their default values.
Review the settings of your VM and click Create VirtualMachine.
Navigate to → and click the name of your VM to see its status.
