Uploaded image for project: 'Migration Toolkit for Virtualization'
  1. Migration Toolkit for Virtualization
  2. MTV-3534

Selecting "Network for data transfer" fails validation if unreachable from Pod network.

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Undefined Undefined
    • None
    • 2.9.4
    • Controller
    • Incidents & Support
    • False
    • Hide

      None

      Show
      None
    • False
    • Moderate

      Description of problem:

      The controller tries to validate the ESXi hosts with the IP/FQDN configured on the data transfer network, but it doesn't do the validation *from* the migration network configured on OCP side, it does from the Pod network. If the network is isolated, it doesn't reach.
      
      Consider the following scenario:
      * 2 networks, A and B
      * A: where OCP lives, Pod network is inside this and so is VMware
      * B: dedicated high speed network accessible from OCP and VMware (i.e. some other VLAN)
      * A and B are isolated at network level (different VLANs with no routing)
      
      Now:
      1. Configure the OCP-V provider to use NAD B for migration
      2. Add VMware provider via the vCenter address in network A
      3. forklift-controller reaches VMware via A to retrieve inventory etc. Also retrieves the list of networks for all ESXi hosts all good.
      4. User goes to the UI and selects the ESXi hosts to use network B.
      
      Problem:
      * The virt-controller tries the host validation test from its own Pod network towards the ESXi address on B, which fails, as the networks are not connected.
      
      It would need to do the host validation tests from the NAD in network B which was configured in step 1, not from the Pod network.
      
      These validations probably need to be offloaded to a new Pod which is connected to the right NAD, so it uses the correct source network as well in case its isolated networks.
      
      Let me give an example with a simple test
      
      The controller can reach the provider endpoint from the network, but not ESXi data transfer network
      
      See the provider is fine and ready, inventory loaded, as the endpoint is reachable via Pod network.
      
      apiVersion: forklift.konveyor.io/v1beta1
      kind: Provider
      metadata:
        name: esxi
        namespace: openshift-mtv
      spec:
        settings:
          sdkEndpoint: esxi
          vddkInitImage: synology.home.arpa:50000/vddk:latest
        type: vsphere
        url: https://vmware-esxi-1.virt.home.arpa/sdk
      status:
        conditions:
        - category: Warn
          lastTransitionTime: "2025-09-29T02:10:11Z"
          message: TLS is susceptible to machine-in-the-middle attacks when certificate
            verification is skipped.
          reason: SkipTLSVerification
          status: "True"
          type: ConnectionInsecure
        - category: Required
          lastTransitionTime: "2025-09-29T02:10:11Z"
          message: Connection test, succeeded.
          reason: Tested
          status: "True"
          type: ConnectionTestSucceeded
        - category: Advisory
          lastTransitionTime: "2025-09-29T02:10:11Z"
          message: Validation has been completed.
          reason: Completed
          status: "True"
          type: Validated
        - category: Required
          lastTransitionTime: "2025-10-09T01:02:09Z"
          message: The inventory has been loaded.
          reason: Completed
          status: "True"
          type: InventoryCreated
        - category: Required
          lastTransitionTime: "2025-10-09T01:02:09Z"
          message: The provider is ready.
          status: "True"
          type: Ready
        fingerprint: 35:A3:15:32:26:C7:73:14:D8:49:79:4B:0A:94:07:D6:5A:F0:C6:04
        observedGeneration: 1
        phase: Ready
      
      Note the different IP configured for the host, this is on the isolated network.
      
      apiVersion: forklift.konveyor.io/v1beta1
      kind: Host
      metadata:
        name: esxi-ha-host-config
        namespace: openshift-mtv
      spec:
        id: ha-host
        ipAddress: 192.168.100.1    <--- isolated network not reachable from controller Pod
        provider:
          name: esxi
          namespace: openshift-mtv
        secret:
          name: esxi-ha-host-bnwqr
          namespace: openshift-mtv
      
      Since these validations run inside the controller, they run on the Pod network, which may have zero connectivity with the actual transfer network configured on both sides.
      
      {"level":"error","ts":"2025-10-09 01:08:46.925","logger":"host|v4rb7","msg":"Reconcile failed.","host":{"name":"esxi-ha-host-config","namespace":"openshift-mtv"},"error":"failed to get TLS certificate: dial tcp 192.168.100.1:443: i/o timeout","stacktrace":"github.com/kubev2v/forklift/pkg/controller/base.(*Reconciler).Ended\n\t/app/pkg/controller/base/controller.go:64\ngithub.com/kubev2v/forklift/pkg/controller/host.Reconciler.Reconcile.func1\n\t/app/pkg/controller/host/controller.go:129\ngithub.com/kubev2v/forklift/pkg/controller/host.Reconciler.Reconcile\n\t/app/pkg/controller/host/controller.go:155\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller[...]).Reconcile\n\t/app/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller/controller.go:119\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller[...]).reconcileHandler\n\t/app/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller/controller.go:334\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Co...

      Version-Release number of selected component (if applicable):

      2.9.4

      How reproducible:

      Always
      

      Steps to Reproduce:

      1. Configure separate isolated network for data transfer only
      2. Set the ESXi hosts to use that data transfer network.
      

      Actual results:

      Migration fails.

      Expected results:

      Use the correct network to validate the host

              gcheresh@redhat.com Genadi Chereshnya
              rhn-support-gveitmic Germano Veit Michel
              Votes:
              8 Vote for this issue
              Watchers:
              5 Start watching this issue

                Created:
                Updated: