Description of problem: According to this CNV Jira ticket: CNV-10213 Expose an HCO configuration to set VDDK image location, On CNV-4.8.0+ the vddk-init-image configuration had changed, compared to CNV-2.6.x. There is also a MTV-2.1 Doc Jira ticket for this: MTV-74 [Doc] Update VDDK section with HCO config * For CNV-2.6 It was by: # oc -n openshift-cnv edit cm v2v-vmware Listing: apiVersion: v1 data: kubevirt-vmware-image: brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/container-native-virtualization/kubevirt-vmware:v2.1.0-6 kubevirt-vmware-image-pull-policy: IfNotPresent v2v-conversion-image: registry-proxy.engineering.redhat.com/rh-osbs/container-native-virtualization-kubevirt-v2v-conveversion:v2.1.0-10 vddk-init-image: <registry_route_or_server_path>/vddk:<tag> kind: ConfigMap metadata: creationTimestamp: 2019-10-24T11:40:26Z name: v2v-vmware namespace: openshift-cnv resourceVersion: "3652730" selfLink: /api/v1/namespaces/openshift-cnv/configmaps/v2v-vmware uid: 1272cd5a-f653-11e9-bd31-5254000a752d * For CNV-4.8 It is by Edit the HyperConverged CR in the openshift-cnv project and add the vddkInitImage line as follows: $ oc edit hco -n openshift-cnv kubevirt-hyperconverged Add the vddkInitImage parameter to the spec stanza: apiVersion: hco.kubevirt.io/v1beta1 kind: HyperConverged metadata: name: kubevirt-hyperconverged namespace: openshift-cnv spec: vddkInitImage: <registry_route_or_server_path>/vddk:<tag> - Once this hco is configured with the vddkInitImage, it's then automatically updates the v2v-vmware configMap with vddk-init-image: <registry_route_or_server_path>/vddk:<tag> - If one configures the vddk-init-image directly in the v2v-vmware configMap, it will be wiped off, till a value for it will be set in the kubevirt-hyperconverged hco. Version-Release number of selected component (if applicable): MTV-2.1 Additional Info: After reviewing in the MTV-2.1 Doc draft, the prerequisites, compared to MTV-2.0, this seems to be the only change in MTV-2.1 that breaks the "backwards compatibility".
Changing this bug to CNV, since this is about data that needs to be preserved during CNV upgrade. This fix should be in the CNV-2.6->CNV4.8 upgrader. MTV-2.0 to MTV-2.1 upgrade flow is: OCP4.7->OCP-4.8, CNV-2.6.6->CNV-4.8.0, MTV-2.0->MTV-2.1 MTV uses the VddkInitImage to migrate VMs from VMware. The VddkInitImage, configured in the CNV-2.6.6 v2v-vmware configMap, will be wiped off once the CNV will be upgraded to CNV-4.8. Therefore, to allow MTV being still functional after upgrade we need to make sure VddkInitImage configuration is preserved.
We think that HCO is already covering this scenario, please see: https://github.com/kubevirt/hyperconverged-cluster-operator/blob/release-1.4/pkg/controller/hyperconverged/hyperconverged_controller.go#L935-L965 and https://github.com/kubevirt/hyperconverged-cluster-operator/blob/release-1.4/pkg/controller/hyperconverged/hyperconverged_controller_test.go#L1614-L1649 Moving to QE to properly ensure it's working as designed.
moving to 4.8.1 but verifying that it should also be working in 4.8.0 if it is not working in 4.8.0 we should move it back to dev to prepare a fix.
Verified as follows: 1) on 2.6.6 updated configmap v2v-vmware, =========== [cnv-qe-jenkins@iuo-dbn-266-2wcd5-executor ~]$ oc -n openshift-cnv get cm v2v-vmware -o yaml apiVersion: v1 data: kubevirt-vmware-image: registry.redhat.io/container-native-virtualization/kubevirt-vmware@sha256:fc5203684ab7f43958f844ce57ba081fc41ae30b85e988ed27e67e231a4f7f61 kubevirt-vmware-image-pull-policy: IfNotPresent v2v-conversion-image: registry.redhat.io/container-native-virtualization/kubevirt-v2v-conversion@sha256:030906e08b380433158b94ecea1f4bd585be59745a4082ae77fc8a554241b8b6 vddk-init-image: cnv-qe-server.rhevdev.lab.eng.rdu2.redhat.com:5000/vddk-images/vddk:v702 =========== 2) Ensured the changes were saved 3) upgraded OCP to 4.8, and cnv to 4.8 4) after upgrade validated configmap: ============== (cnv-tests) [cnv-qe-jenkins@iuo-dbn-266-2wcd5-executor cnv-tests]$ oc -n openshift-cnv get cm v2v-vmware -o yaml apiVersion: v1 data: kubevirt-vmware-image: registry.redhat.io/container-native-virtualization/kubevirt-vmware@sha256:0b555c34b68369398c70fb3fe21e37992cfacb6028a55847ab2528dde64d8389 kubevirt-vmware-image-pull-policy: IfNotPresent v2v-conversion-image: registry.redhat.io/container-native-virtualization/kubevirt-v2v-conversion@sha256:8bfa84f3cf0d625e84921ef6c710b9323de158c72db293985c6d1300428f43d4 vddk-init-image: cnv-qe-server.rhevdev.lab.eng.rdu2.redhat.com:5000/vddk-images/vddk:v702 virtio-win-image: registry.redhat.io/container-native-virtualization/virtio-win@sha256:227e713a26b62310d006f7d517b9673d6fb34ac2edb99563e4a4266cd2ad6ee7 kind: ConfigMap metadata: ================ 5) Checked hco kubevirt-hyperconverged after upgrade: ================ spec: certConfig: ca: duration: 48h0m0s renewBefore: 24h0m0s server: duration: 24h0m0s renewBefore: 12h0m0s featureGates: sriovLiveMigration: false withHostPassthroughCPU: false infra: {} liveMigrationConfig: bandwidthPerMigration: 64Mi completionTimeoutPerGiB: 800 parallelMigrationsPerCluster: 5 parallelOutboundMigrationsPerNode: 2 progressTimeout: 150 scratchSpaceStorageClass: csi-manila-ceph vddkInitImage: cnv-qe-server.rhevdev.lab.eng.rdu2.redhat.com:5000/vddk-images/vddk:v702 version: v4.8.0 ==================
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: OpenShift Virtualization 4.8.1 Images security and bug fix update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2021:3259