I also just uploaded a debug file for reference to the debug-incomming directory: foreman-debug-GB7sy.tar.xz

To provide a bit of history on this, we had a semi-working install of foreman 1.7 running. We hit a lot of katello side bugs, but the build process worked ok most of the time. Something changed with the upgrade to 1.8 though, aside from the obvious, since this occurs with all builds I have tested now in different data centers with different networks/port groups, although it is the same vcenter instance.

I rebuilt this foreman/katello server since the old box was a bit of a Frankenstein install, so nothing is in this box yet if we need to poke around a bit more. This box is only a 3 or 4 days old at this point so its all VERY recent data.

As far as the interface match struggles, I have a co-worker who wrote some powershell scripts for the windows side and had similar issues querying interfaces due to the order he queried the vmware switching component. He couldn't directly query for the port group, but had to query for the distributed switch first and work his way down through port groups or he would never get an interface match either. I'm not sure if this is pertinent information at this point, but it is the process we had to go through before for the windows side of the world.

As an FYI, I just upgraded to the latest release and this bug still persists.

The same problem with Foreman 1.9.2 and vCenter 6.0.

I'm also hitting this bug with foreman 1.11.2, 1.12-RC1.

Provisioning exists with:

"2016-07-27 19:17:06 [app] [E] Unprocessable entity Host::Managed (id: new):

 |   Could not find virtual machine network interface matching eth0
 | 
2016-07-27 19:17:06 [app] [I]   Rendered api/v2/errors/unprocessable_entity.json.rabl within api/v2/layouts/error_layout (1.1ms)
2016-07-27 19:17:06 [app] [D] Body: {
 |   "error": {"id":null,"errors":{"base":["Could not find virtual machine network interface matching eth0"]},"full_messages":["Could not find virtual machine network interface matching eth0"]}
 | }
 | 
"

This started after a recent upgrade to vcenter 6.0.

Actually, looks like this works fine in 6.0 vcenter build number 3018524, but not with 6.0 vcenter build number 3634793. I'm not sure where in-between this might have broken. Up until last week we were using the 3018524 build, and provisioning was working fine.

We have found a potential fix for this in our environment (YMMV). It looks like something internal to VCenter changed in our all of our VDS, during the upgrade. Due to this, provisioning against the existing VDS keeps failing. A coworker performed a separate test on a newly created, temporary VDS, and provisioning worked fine against the VLANs defined there.

We're going to do some work internally to create a brand new VDS layout here, move VMs around, and hopefully that will fix this problem.

Hi There,

I ran into the same Problem. Creating a VM in vCenter leads to the error message of this ticket. vCenter-Version is 6.5 an theforman is on Version 1.15.6.

The production.log give the following message:

017-10-24T15:24:44 d7225981 [app] [I] Could not find Vsphere network for {"network"=>"dvportgroup-xxxx", "type"=>"VirtualVmxnet3"}
2017-10-24T15:24:44 d7225981 [app] [I] Started GET "/tasks/ea1944c7-05ea-490d-a512-6cbdbbb1cdfc" for xxx.xxx.xxx.xxx at 2017-10-24 15:24:44 +0200
2017-10-24T15:24:44 d7225981 [app] [I] Processing by TasksController#show as */*

Could you double check that the given network is in the cluster you've selected in Foreman? We don't limit resources according to cluster in Foreman UI which could result in such errors.

Double checked. The Network is available in the selected Cluster.

My problem is fixed with upgrade from 1.15.6. to 1.16.0