-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Packer failing to get IP address on macOS 11 with VMware Fusion 12.0 #10177
Comments
Thanks for opening this -- looks like the VMware team have acknowledged in your post that this is an upstream bug, so I'll follow that issue for guidance too. If they don't get back to you soon I'll reach out internally through HashiCorp's partner channels. |
Ok, so this is not the prettiest workaround in any cases, here it goes:
I am not sure that the "change"/bug correction needs to occur on VMware side or at Packer side (which basically)! |
VMware has acknowledged the issue and I provided a functional solution to them. I imagine their focus is currently on releasing a build for Apple Silicon right now. I also have adopted creating a fake lease while we wait on a resolution. |
You can look up the MAC address in the /var/db/dhcpd_leases (managed by the new Apple DHCP server) on macOS 11 BigSur:
|
Good find yerkanian! My recommendation is to update the packer code that searches for the IP address to check if the host OS is macOS version 11 or greater. If so then take the known mac address and search this /var/db/dhcpd_leases for the lease and related IP address. Also it's highly likely that other builders that start using hypervisor.framework will also benefit from this update. |
The mac address will need to be zero-padded on BigSur before searching the file (/usr/sbin/arp also uses the same format for its output), not sure about the previous versions though. |
I made a PR that seems to fix this issue. I was able to use Packer on my MBP with MacOS BigSur to generate a machine image. |
Thanks for the PR Pyrrvs! I have built packer with this PR and confirmed it's working for me. Host os is macOS 11.1RC. Here is the relevan log from my run. https://gist.github.com/trodemaster/45c4d3bca4f0cc331520e043b1e6d8a3 |
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. |
Overview of the Issue
When using packer on macOS with VMware Fusion hypervisor the /var/db/vmware/vmnet-dhcpd-vmnet8.leases file is used to provide the guest OS IP address. Due to changes in macOS 11 (in beta as of today) VMware has adopted Apple provided hypervisor.framework and related networking stack. The end result with Fusion 12.0 is that the /var/db/vmware/vmnet-dhcpd-vmnet8.leases file is not populated and packer cant extract the needed IP address to configure the communicators.
I have opened a bug with VMware on this issue and waiting for details on how they will handle this change. Once I have guidance I will update this bug. If the dhcpd.conf file is going to be populated in a future version of Fusion then this issue will only exist for Fusion 12.0 on macOS 11. If going forward that file will not be used another method to determine the guest OS IP will be needed.
Reproduction Steps
Setup macOS 11 and install packer 1.6.4 and VMware Fusion 12.0. Use packer to build any template that uses ssh/winrm communicator. Note that the build hangs waiting for the vmnet-dhcpd-vmnet8.leases file to be populated. If you copy valid data into that file the packer build will continue as expected.
Packer version
1.6.4
Simplified Packer Buildfile
Confirmed the issue using this packer template https://github.com/trodemaster/packer-macOS-11 however any simple template that uses ssh or winrm will show the issue. This issue is not specific to any guest OS or template.
Operating system and Environment details
Host: macOS 11 Beta 10
Forum post noting this issue https://communities.vmware.com/thread/644271
The text was updated successfully, but these errors were encountered: