I’ve found an edge case where the fix for bug #19623 isn’t working. This may also relate to bug #11106. The error message is a closer fit to #11106, but the root cause looks like a variation on #19623.

As far as I can tell, the issue is caused by collisions between the id/key and ref attributes of two vCenter network objects. Our environment matches the conditions in the original bug where we’re post-vCenter migration with legacy id ref’s on the distributed virtual switches. It looks like we have an object where the ref matches the id of another object’s key.

The select_nic function in FogExtensions::Vsphere::Server (app/models/concerns/fog_extensions/vsphere/server.rb) calls all_networks.detect first with the nic_attrs structure which looks like it matches against network._ref. IE:

vm_network = all_networks.detect { |network| network._ref == nic_attrs['network'] }

Only if that doesn’t match anything would the check below it which checks for network.key execute:

vm_network ||= all_networks.detect { |network| nic_attrs['network'] && [network.name, network.try(:key)].include?(nic_attrs['network']) }

In our environment, this makes a false positive match due to one object having a ref attribute that matches the desired object’s key. I’m pretty sure the check a few lines later that compares the vm_network.name and vm_network.key nil’s out selected_nic, ultimately returning nil to match_macs_to_nics in Orchestration::Compute which then fails with “Orchestration::Compute: Could not match network interface.”

In my environment, I was able to fix the issue by reversing the search by name & key and the search for nic_attrs as in the attached patch.

I think this should be a safe change in the other cases where #19623 applies, but I’m nowhere near familiar enough with the Foreman codebase to be certain of that.