Bug 2162331

Summary: In -o kubevirt mode, 'cpu' field appears at the wrong place in the yaml
Product: Red Hat Enterprise Linux 9 Reporter: mxie <mxie>
Component: virt-v2vAssignee: Richard W.M. Jones <rjones>
Status: CLOSED ERRATA QA Contact: mxie <mxie>
Severity: low Docs Contact:
Priority: low    
Version: 9.2CC: chhu, hongzliu, juzhou, lersek, mzhan, rjones, tyan, tzheng, vwu, xiaodwan
Target Milestone: rcKeywords: Triaged
Target Release: ---Flags: pm-rhel: mirror+
Hardware: x86_64   
OS: Unspecified   
Whiteboard:
Fixed In Version: virt-v2v-2.2.0-5.el9 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-05-09 07:45:47 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description mxie@redhat.com 2023-01-19 11:25:11 UTC
Description of problem:
Should correct some data format for yaml file which is converted in v2v kubevirt mode

Version-Release number of selected component (if applicable):
virt-v2v-2.2.0-1.el9.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Convert a guest from VMware to '-o kubevirt' mode by v2v
# virt-v2v -ic vpx://root.212.149/data/10.73.212.36/?no_verify=1  -it vddk -io vddk-libdir=/home/vddk8.0.0 -io vddk-thumbprint=D1:03:96:7E:11:3D:7C:4C:B6:50:28:1B:63:74:B5:40:5F:9D:9F:94 -ip /home/passwd  esx8.0-rhel8.8-x86_64 -o kubevirt -os /home/esx8.0-rhel8.8-x86_64-kubervirt

2. Copy the files which is converted in above step to OCP env, then try to create VMI

2.1 # kubectl apply -f /home/esx8.0-rhel8.8-x86_64-kubervirt/esx8.0-rhel8.8-x86_64.yaml
error: error validating "/home/esx8.0-rhel8.8-x86_64-kubervirt/esx8.0-rhel8.8-x86_64.yaml": error validating data: ValidationError(VirtualMachineInstance.spec.domain.resources): unknown field "cpu" in io.kubevirt.v1.VirtualMachineInstance.spec.domain.resources; if you choose to ignore these errors, turn validation off with --validate=false

2.2 According to above error, the format of CPU and feature data are wrong, correct and try again

Before:
spec:
  domain:
    devices:
      disks:
      - disk:
          bus: virtio
        name: disk-0
    resources:
      requests:
        memory: 2048Mi
      cpu:
        cores: 1
      features:

After:
....
spec:
  domain:
    devices:
      disks:
      - disk:
          bus: virtio
        name: disk-0
    resources:
      requests:
        memory: 2048Mi
    cpu:
      cores: 1
    features:
....

# kubectl apply -f /home/esx8.0-rhel8.8-x86_64-kubervirt/esx8.0-rhel8.8-x86_64.yaml
The VirtualMachineInstance "esx8.0-rhel8.8-x86_64" is invalid: metadata.name: Invalid value: "esx8.0-rhel8.8-x86_64": a lowercase RFC 1123 subdomain must consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*')

2.3 According to above error, edit vm name and try again

Before:
....
metadata:
  name: esx8.0-rhel8.8-x86_64
....

After :
....
metadata:
  name: esx8.0-rhel8.8-x86-64
....

# oc apply -f /home/esx8.0-rhel8.8-x86_64-kubervirt/esx8.0-rhel8.8-x86_64.yaml 
virtualmachineinstance.kubevirt.io/esx8.0-rhel8.8-x86-64 created

Actual results:
As above description

Expected results:
yaml data format is correct after v2v converting to kubevirt mode

Additional info:

Comment 1 Richard W.M. Jones 2023-01-19 11:41:01 UTC
Thanks for this - this used to work so I wonder if they changed the
format of the yaml?  Anyway it's an easy fix.

Comment 3 mxie@redhat.com 2023-01-30 05:35:41 UTC
Test the bug with virt-v2v-2.2.0-2.el9.x86_64

Steps:
1. Convert a guest from VMware to '-o kubevirt' mode by v2v
#  virt-v2v -ic vpx://administrator%40vsphere.local.213.207/data/10.73.212.38/?no_verify=1 -it vddk -io vddk-libdir=/home/vddk8.0.0 -io  vddk-thumbprint=09:9E:54:CF:C3:36:11:9D:7D:B6:45:E0:85:74:4D:DB:CE:24:7B:46  -ip /home/passwd esx7.0-rhel9.1-x86_64-uefi-enable-secureboot -o kubevirt -os /home/esx7.0-rhel9.1-x86_64-uefi-enable-secureboot
[   0.0] Setting up the source: -i libvirt -ic vpx://administrator%40vsphere.local.213.207/data/10.73.212.38/?no_verify=1 -it vddk esx7.0-rhel9.1-x86_64-uefi-enable-secureboot
[   1.8] Opening the source
[  11.6] Inspecting the source
[  20.5] Checking for sufficient free disk space in the guest
[  20.5] Converting Red Hat Enterprise Linux 9.1 Beta (Plow) to run on KVM
virt-v2v: This guest has virtio drivers installed.
[ 171.8] Mapping filesystem data to avoid copying unused and blank areas
[ 172.8] Closing the overlay
[ 173.0] Assigning disks to buses
[ 173.0] Checking if the guest needs BIOS or UEFI to boot
virt-v2v: This guest requires UEFI on the target to boot.
[ 173.0] Setting up the destination: -o kubevirt -os /home/esx7.0-rhel9.1-x86_64-uefi-enable-secureboot
[ 174.6] Copying disk 1/1
█ 100% [****************************************]
[ 308.1] Creating output metadata
[ 308.1] Finishing off

# cat /home/esx7.0-rhel9.1-x86_64-uefi-enable-secureboot/esx7.0-rhel9.1-x86_64-uefi-enable-secureboot.yaml 
---
# generated by virt-v2v 2.2.0rhel=9,release=2.el9
apiVersion: kubevirt.io/v1
kind: VirtualMachineInstance
metadata:
  name: esx7.0-rhel9.1-x86_64-uefi-enable-secureboot
spec:
  domain:
    devices:
      disks:
      - disk:
          bus: virtio
        name: disk-0
    resources:
      requests:
        memory: 2048Mi
      features:
    cpu:
      cores: 1
  volumes:
  - hostDisk:
      path: /home/esx7.0-rhel9.1-x86_64-uefi-enable-secureboot/esx7.0-rhel9.1-x86_64-uefi-enable-secureboot-sda
      type: Disk
    name: disk-0
  terminationGracePeriodSeconds: 0


2. Copy the files which is converted in above step to OCP env, then try to create VMI
# kubectl apply -f /home/esx7.0-rhel9.1-x86_64-uefi-enable-secureboot/esx7.0-rhel9.1-x86_64-uefi-enable-secureboot.yaml 
The VirtualMachineInstance "esx7.0-rhel9.1-x86_64-uefi-enable-secureboot" is invalid: metadata.name: Invalid value: "esx7.0-rhel9.1-x86_64-uefi-enable-secureboot": a lowercase RFC 1123 subdomain must consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*')

3.Rename the guest name in yaml file and create VMI by kubectl command again
# kubectl apply -f /home/esx7.0-rhel9.1-x86_64-uefi-enable-secureboot/esx7.0-rhel9.1-x86_64-uefi-enable-secureboot.yaml 
virtualmachineinstance.kubevirt.io/esx7.0-rhel9.1-x86-64-uefi-enable-secureboot created

Result:
   In -o kubevirt mode, the format of 'cpu' field is correct in the yaml now

Comment 6 mxie@redhat.com 2023-02-02 07:43:13 UTC
Verify the bug with virt-v2v-2.2.0-3.el9.x86_64

Steps:
1.Convert a guest from VMware to kubevirt mode by v2v
# virt-v2v -ic esx://root.212.36/?no_verify=1  -it vddk -io vddk-libdir=/home/vddk8.0.0 -io vddk-thumbprint=11:97:52:B3:B6:5D:C4:DD:05:D9:D0:43:31:0E:98:CB:73:6E:D6:45  -ip /home/esxpwd  esx8.0-win11-x86_64 -o kubevirt -os /home/v2v-win11-x86_64-kubervirt -on esx8.0-win11-x64
[   0.0] Setting up the source: -i libvirt -ic esx://root.212.36/?no_verify=1 -it vddk esx8.0-win11-x86_64
[   1.3] Opening the source
[  45.6] Inspecting the source
[  53.1] Checking for sufficient free disk space in the guest
[  53.1] Converting Windows 10 Enterprise to run on KVM
virt-v2v: This guest has virtio drivers installed.
[  61.6] Mapping filesystem data to avoid copying unused and blank areas
[  62.9] Closing the overlay
[  63.1] Assigning disks to buses
[  63.1] Checking if the guest needs BIOS or UEFI to boot
[  63.1] Setting up the destination: -o kubevirt -os /home/v2v-win11-x86_64-kubervirt
[  64.6] Copying disk 1/1
█ 100% [****************************************]
[ 420.6] Creating output metadata
[ 420.6] Finishing off

2. Copy the files which is converted in above step to OCP env, then try to create VMI
# oc apply -f /home/v2v-win11-x86_64-kubervirt/esx8.0-win11-x64.yaml 
virtualmachineinstance.kubevirt.io/esx8.0-win11-x64 created

3.Check the VMI on OCP web console, the checkpoints of VMI is passed

Result:
  The bug has been fixed

Comment 8 errata-xmlrpc 2023-05-09 07:45:47 UTC
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 (virt-v2v bug fix and enhancement 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/RHBA-2023:2313