Description of problem: With MTV 2.1.0 / CNV 4.8.z, VMIO blocks the migration of RHV VMs configured with a non-UTC timezone. - lastHeartbeatTime: "2021-08-12T16:02:24Z" lastTransitionTime: "2021-08-12T15:55:43Z" message: VM's timezone is not UTC-compatible. It should have offset of 0 and not observe DST reason: MappingRulesVerificationFailed status: "False" type: MappingRulesVerified The full VirtualMachineImport CR is attached to this bug. With https://github.com/kubevirt/kubevirt/pull/3973, Kubevirt supports setting the timezone in the VirtualMachine spec. This means that during the migration of a virtual machine from RHV, the timezone can and must be kept. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. In RHV, create a virtual machine with a non-UTC timezone. 2. IN MTV, create a plan with the newly created virtual machine. 3. Start the plan. 4. Watch the VirtualMachineImport, Migration and Plan CRs. Actual results: The plan is in running state and the "faulty" virtual machine migration hangs. Expected results: The VirtualMachine CR created by MTV should reflect the timezone of the source virtual machine in RHV. Additional info:
Please verify with mtv-operator-bundle-2.0.0-57 / iib:126435, or later.
verified MTV 2.2.0-63
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 (MTV 2.2.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/RHEA-2021:5066