PACKER_LOG=1 packer build template.json: https://gist.github.com/amosshapira/6c4af5bc8390108c88c7I'm using bridged vmware network since it's required for enough network performance to let the Homebrew installation script be able to download from Github.
About the content of packer.log gist: I found that the leases file contained a lease with the guest's MAC address and an old IP address (probably from the time before I switched from NAT to Bridged network). The change in error messages happened when I manually edited the leases file to remove the old entries while Packer was still waiting for SSH to be available, it still failed.
I suspect that the problem is that Packer expects to find the guest's IP address in the vmware leases file but it doesn't - it gets its IP from the "real" DHCP server on our LAN.
(I'm referring to the code at https://github.com/mitchellh/packer/blob/master/builder/vmware/common/guest_ip.go)
A possible work around would be to add an option to lookup the guest's MAC address on the host's arp table instead.
It is not really possible to reliably determine the IP of a guest using bridged network. Further more the difference between NAT and bridged network should not be significant. (Unless there are more problems with Fusions NAT)
If you really need bridged network I suggest that you add another NIC in the vmx that uses bridged mode and leave the ethernet0 alone.
I haven't submitted the pr yet because I forgot that I had done this, but see if the following branch fixes it. If it does, I can submit the PR. I just hate writing documentation and unit-tests, heh. ;-)
https://github.com/arizvisa/packer/tree/vmware-iso-extraconfig
It adds a few more configuration options which mostly just get written to the .vmx file. The primary stuff though, is that is actually properly parses both netmap.conf and vmnetdhcp.conf to get the correct addressing info for the host, and then looks through the dhcp leases to get the correct ipv4 and hwaddr for the guest.
netmap.conf is responsible for mapping the network name to it's correct interface. In your case specifying "Bridged" should return the correct interface and addressing info. vmnetdhcp.conf is responsible for getting the correct address for the Host information. Then the mac address inside of the .vmx is used to parse the correct address out of the dhcp leases file vmnetdhcp.leases.
All the extra config options that it adds (if you want to mess with them) are:
network ("nat", "hostonly", or "bridged". These are taken from netmap.conf)
sound (boolean)
usb (boolean)
serial and parallel (see below)
If I recall correctly, serial and parallel are formatted something like TYPE: path where TYPE can be pipe, file, or device. They're implemented in unformat_{parallel,serial} in builder/vmware/iso/step_create_vmx.go if you really want to specify them during your vmware build.
Since guest_ip.go is actually removed in the branch I linked, it might be hard to identify where the work is actually done. Here's some direct links to each function's implementation so that it's easy to see if the logic for determining the correct addressing information for hosts and guests is sane. If at least somebody else approves it, I'll submit a PR using the vmware-iso-extraconfig branch.
GuestAddress -- ethernet address for the guest
https://github.com/arizvisa/packer/blob/release-0.10.0/builder/vmware/common/driver.go#L240
GuestIP -- ipv4 for a guest
https://github.com/arizvisa/packer/blob/release-0.10.0/builder/vmware/common/driver.go#L270
HostAddress -- ethernet address for the host (using net.Interfaces)
https://github.com/arizvisa/packer/blob/release-0.10.0/builder/vmware/common/driver.go#L349
HostIP -- ipv4 for a host
https://github.com/arizvisa/packer/blob/release-0.10.0/builder/vmware/common/driver.go#L394
Thanks @arizvisa but I'm not sure what your code adds - Packer already parses local DHCP lease files to get the guest's address but it's useless in the case I outlined above since the guest gets the DHCP from an external server.
In any case - I got things working with NAT by reducing the MTU. Apparently the vmware handling of NAT doesn't pass through the necessary ICMP traffic to discover the PMTU so it has to be done "manually".
Actually the DHCP lease code that's in packer for returning the guest_ip is still used within the patch at https://github.com/arizvisa/packer/blob/vmware-iso-extraconfig/builder/vmware/common/driver.go#L308. No need to fix stuff that already works. The main thing that the patch provides is the correct mapping from network type to it's interface and any related files. This way all the hwaddrs that are used (Guest or Host) are correct, and the correct dhcp lease file is parsed.
According to https://github.com/mitchellh/packer/blob/master/builder/vmware/iso/step_create_vmx.go#L178, you're not able to specify a connectionType other than "nat" without explicitly including custom .vmx configuration. Nor are you able to configure a serial-port (or parallel port which isn't too important) via the TEMPLATE file. Since you were using a "bridged" network, and packer doesn't have any knowledge of any other network than "nat". I figured that the issue would be related.
But with regards to what my code adds, the parsing of netmap.conf is to work around various issues that packer has when trying to determine where to connect to the right interface. An example is in ssh.go which makes an assumption on what interface/network is being used ("vmnet8") in order to determine the GuestIP. If you use a different network than vmnet8 for nat/host/bridged, this means that ssh.go will parse the wrong file and connect to the wrong address. The parsing of vmnetdhcp.conf provides the hwaddr for the interface that's vmware sets up it's dhcp server on. This is used to search net.Interfaces for the correct interface name on either platform.
Specific to your problem though, with my patch if you specify the vm network type as "bridged" then the correct address information for GuestIP and GuestAddress should be returned for all the code in the vmware builder that wants them such as ssh.go or anything else that someone wants to add.
I'm closing this since it neither describes a bug or a feature request and the original problem have been fixed by using a different MTU.
@arizvisa if you have any enhancements to the vmware builder please open a PR.
@rickard-von-essen The related PR for the VMware builder enhancements has been there for a bit and is at https://github.com/hashicorp/packer/pull/3417. It just needs a review iirc.
@arizvisa Oh yeh that PR is hopefully comming into 1.1.0.
I'm going to lock this issue because it has been closed for _30 days_ โณ. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.