Description of problem: After Windows2012R2 VM import from RHV to CNV, the imported VM boots but goes into Windows repair mode (ask for keyboard layout and propose different repair options). Support inputs: - We did try to repair the boot issue but it still did not work - The same Windows 2012 VM imported from VMware is working Version-Release number of selected component (if applicable): OCP 4.5 and CNV 2.4.2
Windows2012R2 VM was imported via Wizard UI (RHV to CNV) I cannot access to the imported VM console (please see screenshots attached) VM CRD: http://pastebin.test.redhat.com/922595 Using: OCP 4.6.6/CNV 2.5.0 NFS storage class
Created attachment 1735650 [details] rhv_vm_general
Created attachment 1735651 [details] rhv_vm_disk
Created attachment 1735652 [details] cnv_vm_console
The code responsible for setting the bus type is: https://github.com/kubevirt/vm-import-operator/blob/master/pkg/providers/ovirt/mapper/mapper.go#L227-L232 This was introduced by https://github.com/kubevirt/vm-import-operator/pull/110 and it forces VirtIO as the bus type. When we added support for VMware, we followed the same logic and forced Virtio: https://github.com/kubevirt/vm-import-operator/blob/master/pkg/providers/vmware/mapper/mapper.go#L359.
Adding that on customer side, same VM was imported from VMware to CNV successfully. Might be that the virt-v2v could have changed the OS to make it work.
Can you please share the virt-launcher log?
Yes, virt-v2v configures the operating system based on the bus type. This explains why it works for VMware. If CNV supports both VirtIO and VirtIO-SCSI, why not simply keeping the same bus type as in RHV?
https://github.com/kubevirt/vm-import-operator/pull/451
@Fabien, Can this fix be part of 2.5.3 please?
On OCP-4.6/CNV-2.5.1: I reproduced the bug by importing from RHV a windows2012 with VIRTIO-SCSI disk. The imported VM was started suggesting 'Troubleshooting". I then tried a workaround: Edit the VM yaml from "virtio" to "scsi", but this change was not accepted - See change_bug_error.png attached. Also tried to reproduce the bug with Windows 2016 - but it didn't the imported VM started successfully, though the bug was set to virtio on CNV side, and was originally virtio-scsi on RHV.
Created attachment 1740931 [details] change_bus_error.png
Tested om OCP-4.6/CNV hco-v2.5.3-64 Win2019 /virtio-scsi disk VM import from RHV, via CNV UI fail quickly on: "Import error (RHV) win2019 could not be imported. DataVolumeCreationFailed: Error while importing disk image: . admission webhook "virt-template-admission.kubevirt.io" denied the request: virto disk bus type has better performance, install virtio drivers in VM and change bus type: Some of [scsi] are not in [virtio], disk bus has to be either virtio or sata: Some of [scsi] are not in [virtio, sata]" Fabien Dupont reply: The fix was only created at the VMIO level, not in the UI, nor in CDI or HCO. The error you have is from the HCO admission webhook that denies the creation of a disk with scsi bus type. So, this means that HCO won't accept virtual machines that were using virtio-scsi on the RHV side. This also explains why VMIO was enforcing the virtio bus type.
Moving to ON_QA as the bug fix is already submitted + Bug 1912908 is already ON_QA.
Verification is Blocked by a vmimport crashloopback issue: [amastbau@amastbau totp2]$ oc logs pods/importer-win20191-9de75658-e59b-48db-b7ac-06e79087e98c --follow I0121 10:06:22.930567 1 importer.go:52] Starting importer I0121 10:06:22.931242 1 importer.go:121] begin import process E0121 10:06:24.833751 1 importer.go:137] Fault reason is "Operation Failed". Fault detail is "[Cannot transfer Virtual Disk. The relevant Storage Domain's status is Unknown.]". HTTP response code is "409". HTTP response message is "409 Conflict". Error sending transfer image request kubevirt.io/containerized-data-importer/pkg/importer.getTransfer /remote-source/app/pkg/importer/imageio-datasource.go:272 kubevirt.io/containerized-data-importer/pkg/importer.createImageioReader /remote-source/app/pkg/importer/imageio-datasource.go:184 kubevirt.io/containerized-data-importer/pkg/importer.NewImageioDataSource /remote-source/app/pkg/importer/imageio-datasource.go:60 main.main /remote-source/app/cmd/cdi-importer/importer.go:135 runtime.main /usr/lib/golang/src/runtime/proc.go:203 runtime.goexit /usr/lib/golang/src/runtime/asm_amd64.s:1373 [amastbau@amastbau totp2] will link to BZ once opened
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 2.6.0 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:0799