This is back in 2.6.6.41


+++ This bug was initially created as a clone of Bug #1969272 +++

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:

--- Additional comment from Fabien Dupont on 2021-06-09 06:58:25 UTC ---

It looks like the VirtualMachine CRD is not present in the cluster.

--- Additional comment from Amos Mastbaum on 2021-06-09 07:52:43 UTC ---

@fdupont 
It is actually there (see attached crd)

--- Additional comment from Dan Kenigsberg on 2021-06-18 13:50:33 UTC ---

baseless guess: could it be that vm-import-v2v is expecting a beta version of the api which is now gone?

--- Additional comment from Amos Mastbaum on 2021-06-21 12:59:12 UTC ---

@fdupont
I can confirm this has been reproduced  on another env.
cc: @istien
cc: @dgure

--- Additional comment from Sam Lucidi on 2021-06-21 14:38:14 UTC ---

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

--- Additional comment from Ilanit Stein on 2021-06-28 07:35:41 UTC ---

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.

--- Additional comment from Daniel Gur on 2021-06-28 11:56:48 UTC ---

Changed to Modified  as it is not in the latest build

--- Additional comment from Amos Mastbaum on 2021-06-29 15:05:12 UTC ---

verified CNV-4.8-433