Upgrade OpenShift CNV to a newer version to avoid datavolume name limit of 55 chars

[moadqassem]

The current cnv version in the Openshift cluster is v2.3.0, which has a cdi data volume webhook that validates the value of the data volume name. If the name of the data volume is longer than 55 characters, the creation of creating/cloning will be rejected thus no proper data volume will be created, thus no virtual machine instance. In order to solve this issue, the cnv should be upgraded to include this kubevirt/containerized-data-importer#1200, which increaseс the limit to 253 instead of 55.

[stoyanr]

/assign @rootfs

[stoyanr]

In addition to the issue reported above, we also encountered the following issue with the current CNV version. This is what we see after the first machine that clones a pre-allocated data volume is created:

shoot--dev--openshift-worker1-z-556bbbd4f8-l7khq  Succeeded  100.0% 100s
shoot--dev--openshift-worker1-z-58ca0 ImportInProgress 47.01% 103s

So basically, there is already a cloned datavolume (and a VMI, and a pod, etc.), even though the import of the pre-allocated data volume hasn't even finished. This machine doesn't join the cluster properly, no console to it, no ssh, etc.

In the logs of the launcher pod there are errors such as the following:

{"component":"virt-launcher","kind":"","level":"error","msg":"Failed to sync vmi","name":"shoot--dev--openshift-worker1-z-556bbbd4f8-l7khq","namespace":"default","pos":"server.go:161","reason":"neither found block device nor regular file for volume datavolumedisk","timestamp":"2020-09-25T10:18:33.932558Z","uid":"e65e7ec6-771b-4363-875d-4dc4c298a861"}`

If this first machine is deleted and a second one is created once the pre-allocated data volume import has finished, the cloning process take place and the machine joins the cluster, etc.

We strongly suspect this is yet another issue with the CDI version used in the current CNV version.

[stoyanr]

The issue reported above is likely caused by kubevirt/containerized-data-importer#1102