[Regression] VMware Image-based and full host boot disk based Provisioning fails with error-: Could not find virtual machine network interface matching <IP>
Description of problem:
VMware Image-based and full host boot disk-based Provisioning fails with the error-: Could not find virtual machine network interface matching <IP>
Version-Release number of selected component (if applicable):
Satellite 6.13.1
rubygem-fog-vsphere-3.6.0-1.el8sat.noarch
How reproducible:
100% (Customer's env)
Steps to Reproduce for Image-based :
1. Deploy a fresh satellite (Version: 6.13.1)
2. Add VMware as compute resource and associate an image to the compute resource().
3. Try to deploy the host using the same image (Provisioning method:cloud-init and user data templates).
Actual results:
Image-based build fails with errors :
-----------------
2023-06-15T12:21:21 [I|app|594918af] Adding Compute instance for client.example.com
2023-06-15T12:21:22 [W|app|594918af] Orchestration::Compute: Could not match network interface #<Nic::Managed id: nil, mac: nil, ip: "xx.xx.xx.xxx", type: "Nic::Managed", name: "client.example.com", host_id: nil, subnet_id: 2, domain_id: 1, attrs: {}, created_at: nil, updated_at: nil, provider: nil, username: nil, password: nil, virtual: false, link: true, identifier: "", tag: "", attached_to: "", managed: true, mode: "balance-rr", attached_devices: "", bond_options: "", primary: true, provision: true, compute_attributes: {"type"=>"VirtualVmxnet3", "network"=>"dvportgroup-xx"}, execution: true, ip6: "", subnet6_id: nil>
2023-06-15T12:21:22 [W|app|594918af] Could not find virtual machine network interface matching xx.xx.xx.xx
Expected results:
Build system without issues
Additional info:
The customer had faced the same issue earlier, and applied the steps from the article [1] to remediate the issue, however after upgrading to 6.13.1 again started seeing the same behavior.
[1]https://access.redhat.com/solutions/6972882
Verified.
Tested on Satellite 6.14 Snap 7.0
rubygem-fog-vsphere-3.6.2-1.el8sat.noarch
Steps followed:
1. Deploy a fresh satellite(6.14)
2. Add VMware as compute resource and create an image.
3. Try to deploy the host using the same image.
Observation:
Image-based provisioning is successful, no issues observed.
The changes in the https://github.com/fog/fog-vsphere/commit/ddbff201ba50462dec7359e34baf5959a819ff34 are present on 6.14 Snap 7.0
Description of problem: VMware Image-based and full host boot disk-based Provisioning fails with the error-: Could not find virtual machine network interface matching <IP> Version-Release number of selected component (if applicable): Satellite 6.13.1 rubygem-fog-vsphere-3.6.0-1.el8sat.noarch How reproducible: 100% (Customer's env) Steps to Reproduce for Image-based : 1. Deploy a fresh satellite (Version: 6.13.1) 2. Add VMware as compute resource and associate an image to the compute resource(). 3. Try to deploy the host using the same image (Provisioning method:cloud-init and user data templates). Actual results: Image-based build fails with errors : ----------------- 2023-06-15T12:21:21 [I|app|594918af] Adding Compute instance for client.example.com 2023-06-15T12:21:22 [W|app|594918af] Orchestration::Compute: Could not match network interface #<Nic::Managed id: nil, mac: nil, ip: "xx.xx.xx.xxx", type: "Nic::Managed", name: "client.example.com", host_id: nil, subnet_id: 2, domain_id: 1, attrs: {}, created_at: nil, updated_at: nil, provider: nil, username: nil, password: nil, virtual: false, link: true, identifier: "", tag: "", attached_to: "", managed: true, mode: "balance-rr", attached_devices: "", bond_options: "", primary: true, provision: true, compute_attributes: {"type"=>"VirtualVmxnet3", "network"=>"dvportgroup-xx"}, execution: true, ip6: "", subnet6_id: nil> 2023-06-15T12:21:22 [W|app|594918af] Could not find virtual machine network interface matching xx.xx.xx.xx Expected results: Build system without issues Additional info: The customer had faced the same issue earlier, and applied the steps from the article [1] to remediate the issue, however after upgrading to 6.13.1 again started seeing the same behavior. [1]https://access.redhat.com/solutions/6972882