Created attachment 1789313 [details] VirtualMachine CRD Description of problem: Import from rhv/vmware remians VMTemplateMatching: Matching virtual machine template from the controller's log: { "level": "error", "ts": 1623076866.8142014, "logger": "controller", "msg": "Reconciler error", "controller": "virtualmachineimport-controller", "name": "vm-import-v2v-small-disk-44rdc", "namespace": "default", "error": "no kind \"VirtualMachine\" is registered for version \"kubevirt.io/v1\" in scheme \"pkg/runtime/scheme.go:101\"", "stacktrace": "github.com/go-logr/zapr.(*zapLogger).Error\n\t/remote-source/deps/gomod/pkg/mod/github.com/go-logr/zapr.1/zapr.go:128\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler\n\t/remote-source/deps/gomod/pkg/mod/sigs.k8s.io/controller-runtime.2/pkg/internal/controller/controller.go:237\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem\n\t/remote-source/deps/gomod/pkg/mod/sigs.k8s.io/controller-runtime.2/pkg/internal/controller/controller.go:209\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).worker\n\t/remote-source/deps/gomod/pkg/mod/sigs.k8s.io/controller-runtime.2/pkg/internal/controller/controller.go:188\nk8s.io/apimachinery/pkg/util/wait.BackoffUntil.func1\n\t/remote-source/deps/gomod/pkg/mod/k8s.io/apimachinery.6/pkg/util/wait/wait.go:155\nk8s.io/apimachinery/pkg/util/wait.BackoffUntil\n\t/remote-source/deps/gomod/pkg/mod/k8s.io/apimachinery.6/pkg/util/wait/wait.go:156\nk8s.io/apimachinery/pkg/util/wait.JitterUntil\n\t/remote-source/deps/gomod/pkg/mod/k8s.io/apimachinery.6/pkg/util/wait/wait.go:133\nk8s.io/apimachinery/pkg/util/wait.Until\n\t/remote-source/deps/gomod/pkg/mod/k8s.io/apimachinery.6/pkg/util/wait/wait.go:90" } VirtualMachine CRD attached Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
It looks like the VirtualMachine CRD is not present in the cluster.
@fdupont It is actually there (see attached crd)
baseless guess: could it be that vm-import-v2v is expecting a beta version of the api which is now gone?
@fdupont I can confirm this has been reproduced on another env. cc: @istien cc: @dgure
I was able to reproduce this on my local environment finally as well. VMIO was using an out of date version of Kubevirt client-go that only registered v1alpha3. That would have been fine because 4.8 is still compatible with that version, but the Kubevirt common VM templates specify v1. Since VMIO only knew about v1alpha3, deserializing the VM from the processed template would fail. It appears that updating Kubevirt client-go to a version which registers v1 and setting KUBEVIRT_CLIENT_GO_SCHEME_REGISTRATION_VERSION=v1 in the container environments is sufficient to resolve the incompatibility. https://github.com/kubevirt/vm-import-operator/pull/496
Marked blocker ? as this bug is blocking totally MTV-2.1, that will use CNV-4.8.0. It also blocks single VM import from RHV.
Changed to Modified as it is not in the latest build
verified CNV-4.8-433
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.0 Images), 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:2920