-o kubevirt changes proposed for RHEL-45992

[rwmjones]

https://issues.redhat.com/browse/RHEL-45992

@bkhizgiy @lyarwood

[rwmjones]

Example output after this change:

---
# generated by virt-v2v 2.5.4local,libvirt
apiVersion: kubevirt.io/v1
kind: VirtualMachineInstance
metadata:
  name: fedora-39
  labels:
    libguestfs.org/virt-v2v-version: "2.5.4"
    libguestfs.org/osinfo: fedora39
spec:
  domain:
    os:
      firmware: bios
    resources:
      requests:
        memory: 2048Mi
      features:
        acpi: {}
        apic: {}
        pae: {}
    cpu:
      cores: 1
    devices:
      rng: {}
      disks:
      - disk:
          bus: virtio
        name: disk-0
      interfaces:
      - name: net_default
        masquerade: {}
  volumes:
  - hostDisk:
      path: /home/rjones/d/virt-v2v/./fedora-39-sda
      type: Disk
    name: disk-0
  networks:
  - networkName: default
    name: net_default
  terminationGracePeriodSeconds: 0
  preference:
    name: fedora

[bkhizgiy]

@rwmjones looking good, does it covers all the cases of CNV options?

[bkhizgiy]

btw, can there be a case where the reference field remains empty (from the virt-v2v perspective)?

[lyarwood]

I'm not entirely sure if v2v really needs to use preferences tbh if the VM/VMI output already has the required tuneables such as disk bus, interface model etc configured.

That said I can align the preference names provided by common-instancetypes with libosinfo in the next release if we do decided to use them.

[rwmjones]

@rwmjones looking good, does it covers all the cases of CNV options?

btw, can there be a case where the reference field remains empty (from the virt-v2v perspective)?

I have tried to include every guest type that I know about, but virt-v2v knows about more guest types than can be expressed in the spec -> preference -> name field, and if it's one of those guests that CNV doesn't know about then we omit that field.

See the new kubevirt_instancetype function. If that returns None then the field is omitted.

[rwmjones]

(Update just fixes the test suite)

[rwmjones]

New approach! Let's generate a VirtualMachine (instead of VirtualMachineInstance).

Example output can be found in tests/test-v2v-o-kubevirt-windows.yaml.expected and tests/test-v2v-o-kubevirt-fedora.yaml.expected (after the change is applied).

[lyarwood]

IMHO this is valid from a KubeVirt point of view.

[bkhizgiy]

Looking good. From MTV's perspective, I think it covers all that is needed.