This alert fires when DataImportCron cannot poll or import the latest disk
image versions.
DataImportCron polls disk images, checking for the latest versions, and
imports the images into persistent volume claims (PVCs) or VolumeSnapshots. This
process ensures that these sources are updated to the latest version so that
they can be used as reliable clone sources or golden images for virtual machines
(VMs).
For golden images, latest refers to the latest operating system of the distribution. For other disk images, latest refers to the latest hash of the image that is available.
Note: If the status of a DataImportCron PVC is Pending because there is no
default storage class, the CDIDataImportCronOutdated alert is suppressed and the
CDINoDefaultStorageClass alert is triggered.
VMs might be created from outdated disk images.
VMs might fail to start because no boot source is available for cloning.
$ kubectl get sc -o jsonpath='{.items[?(.metadata.annotations.storageclass\.kubernetes\.io\/is-default-class=="true")].metadata.name}'
Check the cluster for a default virtualization storage class:
$ kubectl get sc -o jsonpath='{.items[?(.metadata.annotations.storageclass\.kubevirt\.io\/is-default-virt-class=="true")].metadata.name}'
The output displays the default (Kubernetes and/or virtualization) storage
class. You must either set a default storage class on the cluster, or ask for
a specific storage class in the DataImportCron specification, in order for
the DataImportCron to poll and import golden images. If the default
storage class does not exist, the created import DataVolume and PVC will be
in Pending phase.
List the DataImportCron objects that are not up-to-date:
$ kubectl get dataimportcron -A -o jsonpath='{range .items[*]}{.status.conditions[?(@.type=="UpToDate")].status}{"\t"}{.metadata.namespace}{"/"}{.metadata.name}{"\n"}{end}' | grep False
If a default storage class is not defined on the cluster, check the
DataImportCron specification for a DataVolume template storage class:
$ kubectl -n <namespace> get dataimportcron <dataimportcron> -o jsonpath='{.spec.template.spec.storage.storageClassName}{"\n"}'
Obtain the name of the DataVolume associated with the DataImportCron
object:
$ kubectl -n <namespace> get dataimportcron <dataimportcron> -o jsonpath='{.status.lastImportedPVC.name}{"\n"}'
Check the DataVolume status:
$ kubectl -n <namespace> get dv <datavolume> -o jsonpath-as-json='{.status}'
Set the CDI_NAMESPACE environment variable:
$ export CDI_NAMESPACE="$(kubectl get deployment -A -o jsonpath='{.items[?(.metadata.name=="cdi-operator")].metadata.namespace}')"
Check the cdi-deployment log for error messages:
$ kubectl logs -n $CDI_NAMESPACE deployment/cdi-deployment
Set a default storage class, either on the cluster or in the DataImportCron
specification, to poll and import golden images. The updated Containerized Data
Importer (CDI) should resolve the issue within a few seconds.
If the issue does not resolve itself, or, if you have changed the default storage class in the cluster, you must delete the existing boot sources (data volumes or volume snapshots) in the cluster namespace that are configured with the previous default storage class. The CDI will recreate the data volumes with the newly configured default storage class.
If your cluster is installed in a restricted network environment, disable the
enableCommonBootImageImport feature gate in order to opt out of automatic
updates:
$ kubectl patch hco kubevirt-hyperconverged -n $CDI_NAMESPACE --type json -p '[{"op": "replace", "path": "/spec/featureGates/enableCommonBootImageImport", "value": false}]'
See the HCO cluster configuration documentation for more information.
If you cannot resolve the issue, see the following resources: