[BUG] VM Import Webhook (vSphere) Doesn't Reject Object if NetworkMapping is incorrect
Describe the bug The webhook isn't rejecting VirtualMachineImport object (in this case used vSphere):
apiVersion: migration.harvesterhci.io/v1beta1
kind: VirtualMachineImport
metadata:
name: mr-leap1
namespace: default
spec:
virtualMachineName: "mr-leap1"
networkMapping:
- sourceNetwork: "NetWorkDoesntExist"
destinationNetwork: "default/vlan9"
sourceCluster:
name: mike-vcsim
namespace: default
kind: VmwareSource
apiVersion: migration.harvesterhci.io/v1beta1
Where, in this instance both:
-
sourceNetwork -
destinationNetwork
Neither NetWorkDoesntExist and default/vlan9 -> they're not in existence.
To Reproduce Steps to reproduce the behavior:
- Build a VirtualMachineImport with bogus/incorrect
sourceNetwork&destinationNetwork - It just in this case, puts it on "management Network"
- VM Import is successful
Expected behavior Webhook rejections of sorts.
Environment
- Harvester ISO version: v1.3.2-rc2
- Underlying Infrastructure: bare-metal
Additional context
Workaround
- User is responsible for determining NetworkMapping
- User can "reconfigure" Networks for VM imported
this is expected behavior as we favor getting the disks across and allow network configuration later. This is already mentioned in the docs
https://docs.harvesterhci.io/v1.3/advanced/addons/vmimport
Would it makes sense to do some checks in the preflight phase and log them as warnings? In this way, we at least make the attentive user aware that something is wrong in the network configuration.
A preflight phase would be great -> If there was the capcity to:
- make an outbound call w/ like gophercloud (openstack) to check if the sourceNetwork existed
- and a Harvester API call to just audit to see if the destination network existed
@ibrokethecloud @votdev -maybe I should change this as an "enhancment" rather than a bug?
Pre Ready-For-Testing Checklist
-
[ ] If labeled: require/HEP Has the Harvester Enhancement Proposal PR submitted? The HEP PR is at:
-
[x] Where is the reproduce steps/test steps documented? The reproduce steps/test steps are at: https://github.com/harvester/vm-import-controller/pull/46
-
[ ] Is there a workaround for the issue? If so, where is it documented? The workaround is at:
-
[x] Have the backend code been merged (harvester, harvester-installer, etc) (including
backport-needed/*)? The PR is at: https://github.com/harvester/vm-import-controller/pull/46-
[x] Does the PR include the explanation for the fix or the feature?
-
[x] Does the PR include deployment change (YAML/Chart)? If so, where are the PRs for both YAML file and Chart? The PR for the YAML change is at: The PR for the chart change is at: https://github.com/harvester/charts/pull/301
-
-
[ ] If labeled: area/ui Has the UI issue filed or ready to be merged? The UI issue/PR is at:
-
[ ] If labeled: require/doc, require/knowledge-base Has the necessary document PR submitted or merged? The documentation/KB PR is at:
-
[ ] If NOT labeled: not-require/test-plan Has the e2e test plan been merged? Have QAs agreed on the automation test case? If only test case skeleton w/o implementation, have you created an implementation issue?
- The automation skeleton PR is at:
- The automation test case PR is at:
-
[ ] If the fix introduces the code for backward compatibility Has a separate issue been filed with the label
release/obsolete-compatibility? The compatibility issue is filed at:
Automation e2e test issue: harvester/tests#1556
Got feedback that the checks seem to incorrectly show everything being fine, the network mapping code might need to log a descriptive error
I think until it is ironed out that more descriptive logs are included along with acknowledging the debug flag for more verbose information.
Since this check breaks a use-case for when the dvswitch 'summary' field is a very long hexadecimal name, I think it's best the preflight check for network does NOT fail, only warn. Especially since it has a default path already when the network mapping does not work.
This:
- https://github.com/harvester/vm-import-controller/pull/70
Is still open and will be implemented 😄 👍
But I feel we can close this out based around the testing w/ the YAML manifests of on v1.5.0-rc1:
---
apiVersion: migration.harvesterhci.io/v1beta1
kind: VirtualMachineImport
metadata:
name: cirros-tiny1
namespace: default
spec:
virtualMachineName: "cirros-tiny"
networkMapping:
- sourceNetwork: "shared"
destinationNetwork: "default/vlan2"
sourceCluster:
name: mike-demo-2024-stable
namespace: default
kind: OpenstackSource
apiVersion: migration.harvesterhci.io/v1beta1
---
#---
apiVersion: migration.harvesterhci.io/v1beta1
kind: VirtualMachineImport
metadata:
name: cirros-tiny-uuidnew1
namespace: default
spec:
virtualMachineName: "a944a663-293c-49ad-a4d7-9c8a448ebe59"
networkMapping:
- sourceNetwork: "foo"
destinationNetwork: "default/vlan2011"
sourceCluster:
name: mike-demo-2024-stable
namespace: default
kind: OpenstackSource
apiVersion: migration.harvesterhci.io/v1beta1
---
apiVersion: migration.harvesterhci.io/v1beta1
kind: VirtualMachineImport
metadata:
name: mr-test2new
namespace: default
spec:
virtualMachineName: "mr-test2"
folder: "gmehta"
networkMapping:
- sourceNetwork: "bad-vm-network-nonexist"
destinationNetwork: "default/vlan2011"
sourceCluster:
name: mike-vcsim
namespace: default
kind: VmwareSource
apiVersion: migration.harvesterhci.io/v1beta1
As with the logs getting spit back helping end-user see that the source || destination networks have issues in:
time="2025-03-17T00:17:08Z" level=info msg="Running preflight checks ..." name=cirros-tiny1 namespace=default spec.virtualMachineName=cirros-tiny
time="2025-03-17T00:17:08Z" level=error msg="Failed to get destination network 'default/vlan2': network-attachment-definitions.k8s.cni.cncf.io \"vlan2\" not found" name=cirros-tiny1 namespace=default spec.sourcecluster.kind=OpenstackSource
time="2025-03-17T00:17:08Z" level=error msg="The preflight checks failed: network-attachment-definitions.k8s.cni.cncf.io \"vlan2\" not found" name=cirros-tiny1 namespace=default spec.virtualMachineName=cirros-tiny
time="2025-03-17T00:17:08Z" level=error msg="The VM import spec is invalid" name=cirros-tiny1 namespace=default spec.virtualMachineName=cirros-tiny
time="2025-03-17T00:17:08Z" level=info msg="Running preflight checks ..." name=cirros-tiny-uuidnew1 namespace=default spec.virtualMachineName=a944a663-293c-49ad-a4d7-9c8a448ebe59
time="2025-03-17T00:17:09Z" level=info msg="Checking the source network as part of the preflight checks" name=cirros-tiny-uuidnew1 namespace=default sourceNetwork=foo
time="2025-03-17T00:17:09Z" level=error msg="Failed to perform source cluster specific preflight checks: source network 'foo' not found" name=cirros-tiny-uuidnew1 namespace=default spec.sourcecluster.kind=OpenstackSource
time="2025-03-17T00:17:09Z" level=error msg="The preflight checks failed: source network 'foo' not found" name=cirros-tiny-uuidnew1 namespace=default spec.virtualMachineName=a944a663-293c-49ad-a4d7-9c8a448ebe59
time="2025-03-17T00:17:09Z" level=error msg="The VM import spec is invalid" name=cirros-tiny-uuidnew1 namespace=default spec.virtualMachineName=a944a663-293c-49ad-a4d7-9c8a448ebe59
time="2025-03-17T00:17:35Z" level=info msg="Running preflight checks ..." name=mr-test2new namespace=default spec.virtualMachineName=mr-test2
time="2025-03-17T00:17:35Z" level=info msg="Checking the source network as part of the preflight checks" name=mr-test2new namespace=default sourceNetwork=bad-vm-network-nonexist
time="2025-03-17T00:17:35Z" level=error msg="Failed to perform source cluster specific preflight checks: error getting source network 'bad-vm-network-nonexist': network '/PG Devlab/network/bad-vm-network-nonexist' not found" name=mr-test2new namespace=default spec.sourcecluster.kind=VmwareSource
time="2025-03-17T00:17:35Z" level=error msg="The preflight checks failed: error getting source network 'bad-vm-network-nonexist': network '/PG Devlab/network/bad-vm-network-nonexist' not found" name=mr-test2new namespace=default spec.virtualMachineName=mr-test2
time="2025-03-17T00:17:35Z" level=error msg="The VM import spec is invalid" name=mr-test2new namespace=default spec.virtualMachineName=mr-test2
cc: @votdev @ibrokethecloud