[FEATURE] Add option to select network interface model while importing VM

[votdev]

Problem:
The network interface model of an imported VM is set to "VirtIO" by default.

Solution:
Add the field DefaultNetworkInterfaceModel to VirtualMachineImportSpec and NetworkInterfaceModel to NetworkMapping. With this new fields it is possible to customize the interface models of the VM NICs.

The DefaultNetworkInterfaceModel field is always used when:

• Auto-detection fails (OpenStack source client does not have auto-detection, therefor this field is used for every network interface).
• No network mapping is provided and a "pod-network" is auto-created.
  It defaults to "virtio".

Related Issue:
harvester/harvester#7999

Test plan:
Case 1

1. Create a VM import that looks like this:

apiVersion: migration.harvesterhci.io/v1beta1
kind: VirtualMachineImport
metadata:
  name: cirros-tiny
  namespace: default
spec:
  virtualMachineName: "cirros-tiny"
  networkMapping:
  - sourceNetwork: "shared"
    destinationNetwork: "default/vlan1"
    networkInterfaceModel: e1000a
...

2. Import the YAML file.
3. The following error message should be displayed.

The VirtualMachineImport "cirros-tiny" is invalid: spec.networkMapping[0].networkInterfaceModel: Unsupported value: "e1000a": supported values: "e1000", "e1000e", "ne2k_pci", "pcnet", "rtl8139", "virtio", ""

Case 2

1. Create a VM import that looks like this:

apiVersion: migration.harvesterhci.io/v1beta1
kind: VirtualMachineImport
metadata:
  name: cirros-tiny
  namespace: default
spec:
  virtualMachineName: "cirros-tiny"
  networkMapping:
  - sourceNetwork: "shared"
    destinationNetwork: "default/vlan1"
    networkInterfaceModel: e1000
...

2. Import the YAML file.
3. The VM should be imported. Go to Virtual Machines in the UI and choose Edit YAML. The following code should exist:

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  ...
  name: cirros-tiny
  namespace: default
  ...
spec:
  template:
    spec:
      domain:
        devices:
          interfaces:
            - bridge: {}
              macAddress: fa:16:3e:25:90:74
              model: e1000
              name: migrated-0

The interface migrated-0 with model e1000 should be configured.

Case 3

1. Create a VM import that looks like this:

apiVersion: migration.harvesterhci.io/v1beta1
kind: VirtualMachineImport
metadata:
  name: cirros-tiny
  namespace: default
spec:
  virtualMachineName: "cirros-tiny"
  defaultNetworkInterfaceModel: foo
...

2. Import the YAML file.
3. The following error message should be displayed.

The VirtualMachineImport "cirros-tiny" is invalid: spec.defaultNetworkInterfaceModel: Unsupported value: "foo": supported values: "e1000", "e1000e", "ne2k_pci", "pcnet", "rtl8139", "virtio", ""

Case 4

1. Create a VM import that looks like this:

apiVersion: migration.harvesterhci.io/v1beta1
kind: VirtualMachineImport
metadata:
  name: cirros-tiny
  namespace: default
spec:
  virtualMachineName: "cirros-tiny"
  defaultNetworkInterfaceModel: e1000e
...

2. Import the YAML file.
3. The VM should be imported. Go to Virtual Machines in the UI and choose Edit YAML. The following code should exist:

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  ...
  name: cirros-tiny
  namespace: default
  ...
spec:
  template:
    spec:
      domain:
        devices:
          interfaces:
            - macAddress: 22:e5:2f:6c:b0:1f
              masquerade: {}
              model: e1000e
              name: pod-network

The interface pod-network with model e1000e should be configured.

[w13915984028]

LGTM, thanks.

[w13915984028]

are there default case to process? if above cases are all not hit

[votdev]

No because the processed list of devices can contain other hardware/devices than NICs.

[starbops]

Is there any reason not using the bridge interface here?

[votdev]

Unfortunately, I can't say anything here as I have adopted the code 1:1.

@ibrokethecloud added the origin code. Could you tell use more please?

[ibrokethecloud]

if there is no valid source to destination mapping we default to adding the masquerade network which is the current default behaviour of harvester during vm creation.

[starbops]

Understood. Thanks for clarifying. I was just considering what might be the most compatible configuration :D

[ibrokethecloud]

lgtm. thanks.

[starbops]

LGTM, thank you.