`vsphere-iso`: multiple NICs; only one NIC with IP reachability

[hc-github-team-packer]

This issue was originally opened by @heitmanr in hashicorp/packer#11409 and has been migrated to this repository. The original issue description is below.

---

Building a VM with two NICs mapped to their vSphere-Portgroups works just fine.

Description

In my Setup, only one Portgroup contains a DHCP-Server.

• the 2nd NIC doesn't get an IP-Address (by design)
• the 2nd Portgroup would be in an isolated IP-Range
  • so an SSH-Connection to n IP-Address at this 2nd-NIC wouldn't be possible anyway.

Right now, the whole build-process gets stuck, in "Waiting for IP"
=> I assume, the script looks to the "wrong" NIC [which doesn't get an IP]
=> or it wait's, until all NICs got an IP-Address

Use Case(s)

Any dual-homed Server connecting different "network security zones, perimeter networks, etc."

Potential configuration

I'd suggest the possibility, to flag one or more NICs as "management"-Interface usable for packer.
//of course, defaulting to "true" would make sense to avoid changes to standard, single-homed setups.

  network_adapters {
    network_card = "vmxnet3"
    network      = "LAB.Management"
    management = true
  }
 network_adapters {
    network_card = "vmxnet3"
    network      = "isolated LAN without DHCPd"
   management = false
  }

Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request.
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request.
If you are interested in working on this issue or have submitted a pull request, please leave a comment.

[tenthirtyam]

@heitmanr - are both NICs required for the build processes? Typically one would add the additional NICs and configuration at time of provisioning. For example, deploying using the Terraform provider.

Ryan

[tenthirtyam]

If such a feature is required, I’d instead suggest a connected state bool that defaults to true and allow the ability to define which NIC is used by the Packer host for communications.

network_adapters {
    network_card = "vmxnet3"
    network      = "Blue"
    connected = false
  }
 network_adapters {
    network_card = "vmxnet3"
    network      = "Green"
    connected = true
  }

Ryan

[heitmanr]

@heitmanr - are both NICs required for the build processes? Typically one would add the additional NICs and configuration at time of provisioning. For example, deploying using the Terraform provider.

Ryan

@tenthirtyam for the build-process itself only the first nic is required.

Right now i'm using this in a terraform workflow, kicking packer using local-exec/powershell to directly build VMs [with packer/convert_to_template:=false].

Since this is part of a separate self-written terraform-module in my setup, adding the additional NIC after the build-process has been completed - this could be a valid "workaround".

[tenthirtyam]

This does sound like a good workaround process, in my opinion.

Ryan

[lindhe]

If such a feature is required, I’d instead suggest a connected state bool that defaults to true and allow the ability to define which NIC is used by the Packer host for communications.

network_adapter_index = 1      // vmnic1
network_adapters {
    network_card = "vmxnet3"
    network      = "Blue"
    connected = false
  }
 network_adapters {
    network_card = "vmxnet3"
    network      = "Green"
    connected = true
  }

Ryan

I cannot find network_adapter_index or connected in the documentation. Are they undocumented features, or am I looking at the wrong place?

EDIT: Adding them did not do me much good:

[tenthirtyam]

I cannot find network_adapter_index or connected in the documentation. Are they undocumented features, or am I looking at the wrong place?

Those were hypothetical enhancements.

[tenthirtyam]

I took a look at this one today and ran some reproduction cases. So far, I only see the issue occur if an IP is set on the image build on one of the NICs. However, if one of the NICs is on a DHCP-enabled network it will progress as soon as the IP is obtained.

More review is needed but this is the current state of review.