Chapter 11. Virtual machine templates

11.1. Creating virtual machine templates

11.1.1. About virtual machine templates

Preconfigured Red Hat virtual machine templates are listed in the Virtualization → Templates page. These templates are available for different versions of Red Hat Enterprise Linux, Fedora, Microsoft Windows 10, and Microsoft Windows Servers. Each Red Hat virtual machine template is preconfigured with the operating system image, default settings for the operating system, flavor (CPU and memory), and workload type (server).

The Templates page displays four types of virtual machine templates:

  • Red Hat Supported templates are fully supported by Red Hat.
  • User Supported templates are Red Hat Supported templates that were cloned and created by users.
  • Red Hat Provided templates have limited support from Red Hat.
  • User Provided templates are Red Hat Provided templates that were cloned and created by users.

You can use the filters in the template Catalog to sort the templates by attributes such as boot source availability, operating system, and workload.

You cannot edit or delete a Red Hat Supported or Red Hat Provided template. You can clone the template, save it as a custom virtual machine template, and then edit it.

You can also create a custom virtual machine template by editing a YAML file example.

11.1.2. About virtual machines and boot sources

Virtual machines consist of a virtual machine definition and one or more disks that are backed by data volumes. Virtual machine templates enable you to create virtual machines using predefined virtual machine specifications.

Every virtual machine template requires a boot source, which is a fully configured virtual machine disk image including configured drivers. Each virtual machine template contains a virtual machine definition with a pointer to the boot source. Each boot source has a predefined name and namespace. For some operating systems, a boot source is automatically provided. If it is not provided, then an administrator must prepare a custom boot source.

Provided boot sources are updated automatically to the latest version of the operating system. For auto-updated boot sources, persistent volume claims (PVCs) are created with the cluster’s default storage class. If you select a different default storage class after configuration, you must delete the existing data volumes in the cluster namespace that are configured with the previous default storage class.

To use the boot sources feature, install the latest release of OpenShift Virtualization. The namespace openshift-virtualization-os-images enables the feature and is installed with the OpenShift Virtualization Operator. Once the boot source feature is installed, you can create boot sources, attach them to templates, and create virtual machines from the templates.

Define a boot source by using a persistent volume claim (PVC) that is populated by uploading a local file, cloning an existing PVC, importing from a registry, or by URL. Attach a boot source to a virtual machine template by using the web console. After the boot source is attached to a virtual machine template, you create any number of fully configured ready-to-use virtual machines from the template.

11.1.3. Creating a virtual machine template in the web console

You create a virtual machine template by editing a YAML file example in the OpenShift Container Platform web console.

Procedure

  1. In the web console, click Virtualization → Templates in the side menu.
  2. Optional: Use the Project drop-down menu to change the project associated with the new template. All templates are saved to the openshift project by default.
  3. Click Create Template.
  4. Specify the template parameters by editing the YAML file.

  5. Click Create.

    The template is displayed on the Templates page.

  6. Optional: Click Download to download and save the YAML file.

11.1.4. Adding a boot source for a virtual machine template

A boot source can be configured for any virtual machine template that you want to use for creating virtual machines or custom templates. When virtual machine templates are configured with a boot source, they are labeled Source available on the Templates page. After you add a boot source to a template, you can create a new virtual machine from the template.

There are four methods for selecting and adding a boot source in the web console:

  • Upload local file (creates PVC)
  • URL (creates PVC)
  • Clone (creates PVC)
  • Registry (creates PVC)

Prerequisites

  • To add a boot source, you must be logged in as a user with the os-images.kubevirt.io:edit RBAC role or as an administrator. You do not need special privileges to create a virtual machine from a template with a boot source added.
  • To upload a local file, the operating system image file must exist on your local machine.
  • To import via URL, access to the web server with the operating system image is required. For example: the Red Hat Enterprise Linux web page with images.
  • To clone an existing PVC, access to the project with a PVC is required.
  • To import via registry, access to the container registry is required.

Procedure

  1. In the OpenShift Container Platform console, click Virtualization → Templates from the side menu.
  2. Click the options menu beside a template and select Edit boot source.
  3. Click Add disk.
  4. In the Add disk window, select Use this disk as a boot source.
  5. Enter the disk name and select a Source, for example, Blank (creates PVC).
  6. Enter a value for Persistent Volume Claim size to specify the PVC size that is adequate for the uncompressed image and any additional space that is required.
  7. Select a Type, for example, Disk.

  8. Optional: Click Storage class and select the storage class that is used to create the disk. Typically, this storage class is the default storage class that is created for use by all PVCs.

    Note

    Provided boot sources are updated automatically to the latest version of the operating system. For auto-updated boot sources, persistent volume claims (PVCs) are created with the cluster’s default storage class. If you select a different default storage class after configuration, you must delete the existing data volumes in the cluster namespace that are configured with the previous default storage class.

  9. Optional: Clear Apply optimized StorageProfile settings to edit the access mode or volume mode.

  10. Select the appropriate method to save your boot source:

    1. Click Save and upload if you uploaded a local file.
    2. Click Save and import if you imported content from a URL or the registry.
    3. Click Save and clone if you cloned an existing PVC.

Your custom virtual machine template with a boot source is listed on the Catalog page. You can use this template to create a virtual machine.

11.1.4.1. Virtual machine template fields for adding a boot source

The following table describes the fields for Add boot source to template window. This window displays when you click Add source for a virtual machine template on the Virtualization → Templates page.

NameParameterDescription

Boot source type

Upload local file (creates PVC)

Upload a file from your local device. Supported file types include gz, xz, tar, and qcow2.

URL (creates PVC)

Import content from an image available from an HTTP or HTTPS endpoint. Obtain the download link URL from the web page where the image download is available and enter that URL link in the Import URL field. Example: For a Red Hat Enterprise Linux image, log on to the Red Hat Customer Portal, access the image download page, and copy the download link URL for the KVM guest image.

PVC (creates PVC)

Use a PVC that is already available in the cluster and clone it.

Registry (creates PVC)

Specify the bootable operating system container that is located in a registry and accessible from the cluster. Example: kubevirt/cirros-registry-dis-demo.

Source provider

 

Optional field. Add descriptive text about the source for the template or the name of the user who created the template. Example: Red Hat.

Advanced Storage settings

StorageClass

The storage class that is used to create the disk.

Access mode

Access mode of the persistent volume. Supported access modes are Single User (RWO), Shared Access (RWX), Read Only (ROX). If Single User (RWO) is selected, the disk can be mounted as read/write by a single node. If Shared Access (RWX) is selected, the disk can be mounted as read-write by many nodes. The kubevirt-storage-class-defaults config map provides access mode defaults for data volumes. The default value is set according to the best option for each storage class in the cluster.

Note

Shared Access (RWX) is required for some features, such as live migration of virtual machines between nodes.

Volume mode

Defines whether the persistent volume uses a formatted file system or raw block state. Supported modes are Block and Filesystem. The kubevirt-storage-class-defaults config map provides volume mode defaults for data volumes. The default value is set according to the best option for each storage class in the cluster.

11.1.5. Additional resources

11.2. Editing virtual machine templates

You can edit a virtual machine template in the web console.

Note

You cannot edit a template provided by the Red Hat Virtualization Operator. If you clone the template, you can edit it.

11.2.1. Editing a virtual machine template in the web console

You can edit a virtual machine template by using the OpenShift Container Platform web console or the command line interface.

Editing a virtual machine template does not affect virtual machines already created from that template.

Procedure

  1. Navigate to Virtualization → Templates in the web console.
  2. Click the kebab Options menu beside a virtual machine template and select the object to edit.

  3. To edit a Red Hat template, click the kebab Options menu, select Clone to create a custom template, and then edit the custom template.

    Note

    Edit boot source reference is disabled if the template’s data source is managed by the DataImportCron custom resource or if the template does not have a data volume reference.

  4. Click Save.

11.2.1.1. Adding a network interface to a virtual machine template

Use this procedure to add a network interface to a virtual machine template.

Procedure

  1. Click Virtualization → Templates from the side menu.
  2. Select a virtual machine template to open the Template details page.
  3. On the Network interfaces tab, click Add Network Interface.
  4. In the Add Network Interface window, specify the Name, Model, Network, Type, and MAC Address of the network interface.
  5. Click Add.

11.2.1.2. Adding a virtual disk to a virtual machine template

Use this procedure to add a virtual disk to a virtual machine template.

Procedure

  1. Click Virtualization → Templates from the side menu.
  2. Select a virtual machine template to open the Template details page.
  3. On the Disks tab, click Add disk.

  4. Specify the Source, Name, Size, Type, Interface, and Storage Class.

    1. Optional: You can enable preallocation if you use a blank disk source and require maximum write performance when creating data volumes. To do so, select the Enable preallocation checkbox.
    2. Optional: You can clear Apply optimized StorageProfile settings to change the Volume Mode and Access Mode for the virtual disk. If you do not specify these parameters, the system uses the default values from the kubevirt-storage-class-defaults config map.
  5. Click Add.

11.3. Enabling dedicated resources for virtual machine templates

Virtual machines can have resources of a node, such as CPU, dedicated to them to improve performance.

11.3.1. About dedicated resources

When you enable dedicated resources for your virtual machine, your virtual machine’s workload is scheduled on CPUs that will not be used by other processes. By using dedicated resources, you can improve the performance of the virtual machine and the accuracy of latency predictions.

11.3.2. Prerequisites

  • The CPU Manager must be configured on the node. Verify that the node has the cpumanager = true label before scheduling virtual machine workloads.

11.3.3. Enabling dedicated resources for a virtual machine template

You enable dedicated resources for a virtual machine template in the Details tab. Virtual machines that were created from a Red Hat template can be configured with dedicated resources.

Procedure

  1. In the OpenShift Container Platform console, click Virtualization → Templates from the side menu.
  2. Select a virtual machine template to open the Template details page.
  3. On the Scheduling tab, click the edit icon beside Dedicated Resources.
  4. Select Schedule this workload with dedicated resources (guaranteed policy).
  5. Click Save.

11.4. Deploying a virtual machine template to a custom namespace

Red Hat provides preconfigured virtual machine templates that are installed in the openshift namespace. The ssp-operator deploys virtual machine templates to the openshift namespace by default. Templates in the openshift namespace are publicly available to all users. These templates are listed on the Virtualization → Templates page for different operating systems.

11.4.1. Creating a custom namespace for templates

You can create a custom namespace that is used to deploy virtual machine templates for use by anyone who has permissions to access those templates. To add templates to a custom namespace, edit the HyperConverged custom resource (CR), add commonTemplatesNamespace to the spec, and specify the custom namespace for the virtual machine templates. After the HyperConverged CR is modified, the ssp-operator populates the templates in the custom namespace.

Prerequisites

  • Install the OpenShift Container Platform CLI oc.
  • Log in as a user with cluster-admin privileges.

Procedure

  • Use the following command to create your custom namespace: 

    $ oc create namespace <mycustomnamespace>

11.4.2. Adding templates to a custom namespace

The ssp-operator deploys virtual machine templates to the openshift namespace by default. Templates in the openshift namespace are publicly availably to all users. When a custom namespace is created and templates are added to that namespace, you can modify or delete virtual machine templates in the openshift namespace. To add templates to a custom namespace, edit the HyperConverged custom resource (CR) which contains the ssp-operator.

Procedure

  1. View the list of virtual machine templates that are available in the openshift namespace. 

    $ oc get templates -n openshift

  2. Edit the HyperConverged CR in your default editor by running the following command: 

    $ oc edit hco -n openshift-cnv kubevirt-hyperconverged

  3. View the list of virtual machine templates that are available in the custom namespace. 

    $ oc get templates -n customnamespace

  4. Add the commonTemplatesNamespace attribute and specify the custom namespace. Example: 

    apiVersion: hco.kubevirt.io/v1beta1
kind: HyperConverged
metadata:
  name: kubevirt-hyperconverged
spec:
  commonTemplatesNamespace: customnamespace 1
    1
    The custom namespace for deploying templates.
  5. Save your changes and exit the editor. The ssp-operator adds virtual machine templates that exist in the default openshift namespace to the custom namespace.

11.4.2.1. Deleting templates from a custom namespace

To delete virtual machine templates from a custom namespace, remove the commonTemplateNamespace attribute from the HyperConverged custom resource (CR) and delete each template from that custom namespace.

Procedure

  1. Edit the HyperConverged CR in your default editor by running the following command: 

    $ oc edit hco -n openshift-cnv kubevirt-hyperconverged

  2. Remove the commonTemplateNamespace attribute. 

    apiVersion: hco.kubevirt.io/v1beta1
kind: HyperConverged
metadata:
  name: kubevirt-hyperconverged
spec:
  commonTemplatesNamespace: customnamespace 1
    1
    The commonTemplatesNamespace attribute to be deleted.

  3. Delete a specific template from the custom namespace that was removed. 

    $ oc delete templates -n customnamespace <template_name>

Verification

  • Verify that the template was deleted from the custom namespace. 

    $ oc get templates -n customnamespace

11.4.2.2. Additional resources

11.5. Deleting virtual machine templates

You can delete customized virtual machine templates based on Red Hat templates by using the web console.

You cannot delete Red Hat templates.

11.5.1. Deleting a virtual machine template in the web console

Deleting a virtual machine template permanently removes it from the cluster.

Note

You can delete customized virtual machine templates. You cannot delete Red Hat-supplied templates.

Procedure

  1. In the OpenShift Container Platform console, click Virtualization → Templates from the side menu.
  2. Click the Options menu kebab of a template and select Delete template.
  3. Click Delete.

11.6. Creating and using boot sources

A boot source contains a bootable operating system (OS) and all of the configuration settings for the OS, such as drivers.

You use a boot source to create virtual machine templates with specific configurations. These templates can be used to create any number of available virtual machines.

Quick Start tours are available in the OpenShift Container Platform web console to assist you in creating a custom boot source, uploading a boot source, and other tasks. Select Quick Starts from the Help menu to view the Quick Start tours.

11.6.1. About virtual machines and boot sources

Virtual machines consist of a virtual machine definition and one or more disks that are backed by data volumes. Virtual machine templates enable you to create virtual machines using predefined virtual machine specifications.

Every virtual machine template requires a boot source, which is a fully configured virtual machine disk image including configured drivers. Each virtual machine template contains a virtual machine definition with a pointer to the boot source. Each boot source has a predefined name and namespace. For some operating systems, a boot source is automatically provided. If it is not provided, then an administrator must prepare a custom boot source.

Provided boot sources are updated automatically to the latest version of the operating system. For auto-updated boot sources, persistent volume claims (PVCs) are created with the cluster’s default storage class. If you select a different default storage class after configuration, you must delete the existing data volumes in the cluster namespace that are configured with the previous default storage class.

To use the boot sources feature, install the latest release of OpenShift Virtualization. The namespace openshift-virtualization-os-images enables the feature and is installed with the OpenShift Virtualization Operator. Once the boot source feature is installed, you can create boot sources, attach them to templates, and create virtual machines from the templates.

Define a boot source by using a persistent volume claim (PVC) that is populated by uploading a local file, cloning an existing PVC, importing from a registry, or by URL. Attach a boot source to a virtual machine template by using the web console. After the boot source is attached to a virtual machine template, you create any number of fully configured ready-to-use virtual machines from the template.

11.6.2. Importing a RHEL image as a boot source

You can import a Red Hat Enterprise Linux (RHEL) image as a boot source by specifying a URL for the image.

Prerequisites

  • You must have access to a web page with the operating system image. For example: Download Red Hat Enterprise Linux web page with images.

Procedure

  1. In the OpenShift Container Platform console, click Virtualization → Templates from the side menu.
  2. Identify the RHEL template for which you want to configure a boot source and click Add source.
  3. In the Add boot source to template window, select URL (creates PVC) from the Boot source type list.
  4. Click RHEL download page to access the Red Hat Customer Portal. A list of available installers and images is displayed on the Download Red Hat Enterprise Linux page.
  5. Identify the Red Hat Enterprise Linux KVM guest image that you want to download. Right-click Download Now, and copy the URL for the image.
  6. In the Add boot source to template window, paste the URL into the Import URL field, and click Save and import.

Verification

  1. Verify that the template displays a green checkmark in the Boot source column on the Templates page.

You can now use this template to create RHEL virtual machines.

11.6.3. Adding a boot source for a virtual machine template

A boot source can be configured for any virtual machine template that you want to use for creating virtual machines or custom templates. When virtual machine templates are configured with a boot source, they are labeled Source available on the Templates page. After you add a boot source to a template, you can create a new virtual machine from the template.

There are four methods for selecting and adding a boot source in the web console:

  • Upload local file (creates PVC)
  • URL (creates PVC)
  • Clone (creates PVC)
  • Registry (creates PVC)

Prerequisites

  • To add a boot source, you must be logged in as a user with the os-images.kubevirt.io:edit RBAC role or as an administrator. You do not need special privileges to create a virtual machine from a template with a boot source added.
  • To upload a local file, the operating system image file must exist on your local machine.
  • To import via URL, access to the web server with the operating system image is required. For example: the Red Hat Enterprise Linux web page with images.
  • To clone an existing PVC, access to the project with a PVC is required.
  • To import via registry, access to the container registry is required.

Procedure

  1. In the OpenShift Container Platform console, click Virtualization → Templates from the side menu.
  2. Click the options menu beside a template and select Edit boot source.
  3. Click Add disk.
  4. In the Add disk window, select Use this disk as a boot source.
  5. Enter the disk name and select a Source, for example, Blank (creates PVC).
  6. Enter a value for Persistent Volume Claim size to specify the PVC size that is adequate for the uncompressed image and any additional space that is required.
  7. Select a Type, for example, Disk.

  8. Optional: Click Storage class and select the storage class that is used to create the disk. Typically, this storage class is the default storage class that is created for use by all PVCs.

    Note

    Provided boot sources are updated automatically to the latest version of the operating system. For auto-updated boot sources, persistent volume claims (PVCs) are created with the cluster’s default storage class. If you select a different default storage class after configuration, you must delete the existing data volumes in the cluster namespace that are configured with the previous default storage class.

  9. Optional: Clear Apply optimized StorageProfile settings to edit the access mode or volume mode.

  10. Select the appropriate method to save your boot source:

    1. Click Save and upload if you uploaded a local file.
    2. Click Save and import if you imported content from a URL or the registry.
    3. Click Save and clone if you cloned an existing PVC.

Your custom virtual machine template with a boot source is listed on the Catalog page. You can use this template to create a virtual machine.

11.6.4. Creating a virtual machine from a template with an attached boot source

After you add a boot source to a template, you can create a virtual machine from the template.

Procedure

  1. In the OpenShift Container Platform web console, click Virtualization → Catalog in the side menu.
  2. Select the updated template and click Quick create VirtualMachine.

The VirtualMachine details is displayed with the status Starting.

11.6.5. Additional resources

11.7. Managing automatic boot source updates

Manage automatic boot source updates.

11.7.1. About automatic boot source updates

Boot sources can make virtual machine (VM) creation more accessible and efficient for users. If automatic boot source updates are enabled, the Containerized Data Importer (CDI) imports, polls, and updates the images so that they are ready to be cloned for new VMs. By default, CDI automatically updates the system-defined boot sources that OpenShift Virtualization provides.

You can opt out of automatic updates for all system-defined boot sources by disabling the enableCommonBootImageImport feature gate. If you disable this feature gate, all DataImportCron objects are deleted. This does not remove previously imported PersistentVolumeClaim (PVC) objects that store operating system images, though administrators can delete them manually.

When the enableCommonBootImageImport feature gate is disabled, DataSource objects are reset so that they no longer point to the original PVCs. An administrator can manually provide a boot source by creating a new PVC for the DataSource object and populating the PVC with an operating system image.

Custom boot sources that are not provided by OpenShift Virtualization are not controlled by the feature gate. You must manage them individually by editing the HyperConverged custom resource (CR). You can also use this method to manage individual system-defined boot sources.

11.7.2. Enable or disable automatic updates for all system boot sources

Control automatic updates for all system-defined boot sources by using the feature gate.

11.7.2.1. Managing automatic updates for all system-defined boot sources

Disabling automatic boot source imports and updates can lower resource usage. In disconnected environments, disabling automatic boot source updates prevents CDIDataImportCronOutdated alerts from filling up logs.

To disable automatic updates for all system-defined boot sources, turn off the enableCommonBootImageImport feature gate by setting the value to false. Setting this value to true re-enables the feature gate and turns automatic updates back on.

Note

Custom boot sources are not affected by this setting.

Procedure

  • Toggle the feature gate for automatic boot source updates by editing the HyperConverged custom resource (CR).

    • To disable automatic boot source updates, set the spec.featureGates.enableCommonBootImageImport field in the HyperConverged CR to false. For example: 

      $ oc patch hco kubevirt-hyperconverged -n openshift-cnv \
  --type json -p '[{"op": "replace", "path": \
  "/spec/featureGates/enableCommonBootImageImport", \
  "value": false}]'

    • To re-enable automatic boot source updates, set the spec.featureGates.enableCommonBootImageImport field in the HyperConverged CR to true. For example: 

      $ oc patch hco kubevirt-hyperconverged -n openshift-cnv \
  --type json -p '[{"op": "replace", "path": \
  "/spec/featureGates/enableCommonBootImageImport", \
  "value": true}]'

11.7.3. Enable automatic updates for custom boot sources

Ensure that your cluster has a default storage class. Then, enable automatic updates for custom boot sources.

11.7.3.1. Configuring a storage class for custom boot source updates

Specify a new default storage class in the HyperConverged custom resource (CR).

Important

Boot sources are created from storage using the default storage class. If your cluster does not have a default storage class, you must define one before configuring automatic updates for custom boot sources.

Procedure

  1. Open the HyperConverged CR in your default editor by running the following command: 

    $ oc edit hco -n openshift-cnv kubevirt-hyperconverged

  2. Define a new storage class by entering a value in the storageClassName field: 

    apiVersion: hco.kubevirt.io/v1beta1
kind: HyperConverged
metadata:
  name: kubevirt-hyperconverged
spec:
  dataImportCronTemplates:
  - metadata:
      name: rhel8-image-cron
    spec:
      template:
        spec:
          storageClassName: <new_storage_class> 1
#...
    1
    Define the storage class.

  3. Remove the storageclass.kubernetes.io/is-default-class annotation from the current default storage class.

    1. Retrieve the name of the current default storage class by running the following command: 

      $ oc get sc

      Example output

      NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
csi-manila-ceph manila.csi.openstack.org Delete Immediate false 11d
hostpath-csi-basic (default) kubevirt.io.hostpath-provisioner Delete WaitForFirstConsumer false 11d 1
...

      1
      In this example, the current default storage class is named hostpath-csi-basic.

    2. Remove the annotation from the current default storage class by running the following command: 

      $ oc patch storageclass <current_default_storage_class> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}' 1
      1
      Replace <current_default_storage_class> with the storageClassName value of the default storage class.

  4. Set the new storage class as the default by running the following command: 

    $ oc patch storageclass <new_storage_class> -p '{"metadata":{"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}' 1
    1
    Replace <new_storage_class> with the storageClassName value that you added to the HyperConverged CR.

11.7.3.2. Enabling automatic updates for custom boot sources

OpenShift Virtualization automatically updates system-defined boot sources by default, but does not automatically update custom boot sources. You must manually enable automatic updates by editing the HyperConverged custom resource (CR).

Prerequisites

  • The cluster has a default storage class.

Procedure

  1. Open the HyperConverged CR in your default editor by running the following command: 

    $ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv

  2. Edit the HyperConverged CR, adding the appropriate template and boot source in the dataImportCronTemplates section. For example:

    Example custom resource

    apiVersion: hco.kubevirt.io/v1beta1
kind: HyperConverged
metadata:
  name: kubevirt-hyperconverged
spec:
  dataImportCronTemplates:
  - metadata:
      name: centos7-image-cron
      annotations:
        cdi.kubevirt.io/storage.bind.immediate.requested: "true" 1
    spec:
      schedule: "0 */12 * * *" 2
      template:
        spec:
          source:
            registry: 3
              url: docker://quay.io/containerdisks/centos:7-2009
          storage:
            resources:
              requests:
                storage: 10Gi
      managedDataSource: centos7 4
      retentionPolicy: "None" 5

    1
    This annotation is required for storage classes with volumeBindingMode set to WaitForFirstConsumer.
    2
    Schedule for the job specified in cron format.
    3
    Use to create a data volume from a registry source. Use the default pod pullMethod and not node pullMethod, which is based on the node docker cache. The node docker cache is useful when a registry image is available via Container.Image, but the CDI importer is not authorized to access it.
    4
    For the custom image to be detected as an available boot source, the name of the image’s managedDataSource must match the name of the template’s DataSource, which is found under spec.dataVolumeTemplates.spec.sourceRef.name in the VM template YAML file.
    5
    Use All to retain data volumes and data sources when the cron job is deleted. Use None to delete data volumes and data sources when the cron job is deleted.
  3. Save the file.

11.7.4. Disable automatic updates for a specific boot source

Disable automatic updates for individual boot sources.

11.7.4.1. Disabling automatic updates for a single boot source

You can disable automatic updates for an individual boot source, whether it is custom or system-defined, by editing the HyperConverged custom resource (CR).

Procedure

  1. Open the HyperConverged CR in your default editor by running the following command: 

    $ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv

  2. Disable automatic updates for an individual boot source by editing the spec.dataImportCronTemplates field.

    Custom boot source
    • Remove the boot source from the spec.dataImportCronTemplates field. Automatic updates are disabled for custom boot sources by default.
    System-defined boot source

    1. Add the boot source to spec.dataImportCronTemplates.

      Note

      Automatic updates are enabled by default for system-defined boot sources, but these boot sources are not listed in the CR unless you add them.

    2. Set the value of the dataimportcrontemplate.kubevirt.io/enable annotation to 'false'.

      For example: 

      apiVersion: hco.kubevirt.io/v1beta1
kind: HyperConverged
metadata:
  name: kubevirt-hyperconverged
spec:
  dataImportCronTemplates:
  - metadata:
      annotations:
        dataimportcrontemplate.kubevirt.io/enable: 'false'
      name: rhel8-image-cron
# ...
  3. Save the file.

11.7.5. Verifying the status of a boot source

You can determine if a boot source is system-defined or custom by viewing the HyperConverged custom resource (CR).

Procedure

  1. View the contents of the HyperConverged CR by running the following command: 

    $ oc get hco -n openshift-cnv kubevirt-hyperconverged -o yaml

    Example output

    apiVersion: hco.kubevirt.io/v1beta1
kind: HyperConverged
metadata:
  name: kubevirt-hyperconverged
spec:
# ...
status:
# ...
  dataImportCronTemplates:
  - metadata:
      annotations:
        cdi.kubevirt.io/storage.bind.immediate.requested: "true"
      name: centos-7-image-cron
    spec:
      garbageCollect: Outdated
      managedDataSource: centos7
      schedule: 55 8/12 * * *
      template:
        metadata: {}
        spec:
          source:
            registry:
              url: docker://quay.io/containerdisks/centos:7-2009
          storage:
            resources:
              requests:
                storage: 30Gi
        status: {}
    status:
      commonTemplate: true 1
# ...
  - metadata:
      annotations:
        cdi.kubevirt.io/storage.bind.immediate.requested: "true"
      name: user-defined-dic
    spec:
      garbageCollect: Outdated
      managedDataSource: user-defined-centos-stream8
      schedule: 55 8/12 * * *
      template:
        metadata: {}
        spec:
          source:
            registry:
              pullMethod: node
              url: docker://quay.io/containerdisks/centos-stream:8
          storage:
            resources:
              requests:
                storage: 30Gi
        status: {}
    status: {} 2
# ...

    1
    Indicates a system-defined boot source.
    2
    Indicates a custom boot source.

  2. Verify the status of the boot source by reviewing the status.dataImportCronTemplates.status field.

    • If the field contains commonTemplate: true, it is a system-defined boot source.
    • If the status.dataImportCronTemplates.status field has the value {}, it is a custom boot source.