Packer: Builds failing via vmware-iso on Packer 1.2.0

Created on 10 Feb 2018  ยท  31Comments  ยท  Source: hashicorp/packer

  • Packer version from packer version: Packer 1.2.0
  • Host platform: Ubuntu 16.04.3
  • Affected on VMWare Product(s):

    • Workstation 14

    • Workstation 12

Gist link: https://gist.github.com/dustyhorizon/a428dbf75ad6ba98bb2bcb13ed34d7f6


Packer 1.2.0 builds fail using the vmware-iso builder with error "Error detecting host IP: Could not find vmnetdhcp conf file: /etc/vmware/vmnet8/dhcp/dhcpd.conf"

Packer should be looking for the file at /etc/vmware/vmnet8/dhcpd/dhcpd.conf instead(?) as there is no file at /etc/vmware/vmnet8/dhcp/dhcpd.conf

bug buildevmware regression

All 31 comments

Should test for either dhcp/dhcp.conf (workstation 9/10, as noted from VMWare documentation) or dhcpd/dhcpd.conf (workstation > 11?)

Updated the version of workstation that was used, do not have older versions of workstation to check.

Seeing this same issue after using 1.2.0 on Linux VMWare workstation 12.5.5.

thanks for the reports, all. Looks like @dustyhorizon has the answers. cc @arizvisa

Should be fixed by PR #5898. My bad on that.

Fixed in #5898 (thanks @arizvisa!). Would love if someone here can test the patch. I'm happy to make a build if needed.

If you build, I'll give it a whirl.

Oddly enough I cannot find the path referenced by the docs on VMWare Workstation 14 running on Ubuntu 16.04 as referenced by the docs.

kenneth@index:~$ ls /etc/vmware/vmnet8/dhcp/dhcp.conf
ls: cannot access '/etc/vmware/vmnet8/dhcp/dhcp.conf': No such file or directory

But I managed to find the file at /etc/vmware/vmnet8/dhcpd

kenneth@index:/etc/vmware/vmnet8/dhcpd$ ls
dhcpd.conf  dhcpd.leases  dhcpd.leases~

I did managed to find another page in the documentation leading to the above-mentioned path.

https://docs.vmware.com/en/VMware-Workstation-Pro/14.0/com.vmware.ws.using.doc/GUID-39E5440D-181B-45F6-A61D-2D2912C660B8.html

Possibly wrong documentation on VMware's side?

I'm finding conflicting information, too. Is it possible we need to check both /etc/vmware/vmnet8/dhcp/dhcp.conf and /etc/vmware/vmnet8/dhcpd/dhcpd.conf?

Also thinking workstationDhcpLeasesPath needs the same treatment.

It's not possible that the location is dependent on the host system's dhcp server, right?

Ok. Hmm..

So, I got the original path from a friend of mine and so I thought it might've been a Type-O on my part due to the documentation stating otherwise.

But as a result of your guys research, I made a prioritized list of different permutations of those paths and walked through them checking to see if the files exist and returning the first one that was found. Like hopefully there isn't an issue with any leftover files being dead from a previous install of VMWare Workstation.

The proper fix would be to turn these functions into driver methods, and then properly extract the version, and then hand it down which is quite some refactoring. If the leftover files do become a problem, though,maybe we could sort by timestamp..and Iff that doesn't work, then maybe we can consolidate the Workstation driver versions into a single struct somehow.

Anyways, PR #5900 includes the checking of the different permutations of paths for both locating the dhcpd's configuration and its leases.

I'm seeing this issue as well.
Host OS Ubuntu 16.04
VMware workstation 14.1.1 latest version
The lease file lives at /etc/vmware/vmnet8/dhcpd/dhcpd.conf
Once PR #5900 is merged I'll give it a test otherwise seeing failures.

Here's a linux build of #5900 -- can someone test it out and verify for me that it works before we merge?
packer.zip

This seems to resolve the dhcp.conf error.

Now I get:

2018/02/15 13:09:27 ui: ==> vmware-vmx: Waiting for SSH to become available...
2018/02/15 13:09:27 packer: 2018/02/15 13:09:27 Lookup up IP information...
2018/02/15 13:09:27 packer: 2018/02/15 13:09:27 IP lookup failed: couldn't find MAC address in VMX
2018/02/15 13:09:27 packer: 2018/02/15 13:09:27 [DEBUG] Error getting SSH address: IP lookup failed: couldn't find MAC address in VMX

Which I imagine is unrelated.

Per what @nbayle said, @SwampDragons, I can also confirm that it solves the problem. I don't have any of those issues mentioned above, so they shouldn't be related. :)

Okay, I just merged 5900. This fix will be included in the 1.2.1 release.

I am still seeing this issue on centos 7.4 with packer 1.2.2 and workstation 14.

==> vmware-iso: Error detecting host IP: Could not find vmnetdhcp conf file: /etc/vmware/vmnet8/dhcp/dhcp.conf

the file is actually located here /etc/vmware/vmnet8/dhcpd/dhcpd.conf

@warroyo, can you submit your packer log?

@warroyo, is this also still busted in v1.2.1?

@arizvisa just tried with v1.2.1 and got the same error .

here are the relevant logs:

2018/03/29 20:40:42 ui: ==> vmware-iso: Starting HTTP server on port 8927
2018/03/29 20:40:42 packer: 2018/03/29 20:40:42 Looking for available port between 5900 and 6000
2018/03/29 20:40:42 packer: 2018/03/29 20:40:42 Trying port: 5975
2018/03/29 20:40:42 packer: 2018/03/29 20:40:42 Found available VNC port: 5975
2018/03/29 20:40:42 packer: 2018/03/29 20:40:42 Writing VMX to: output-vmware-iso/packer-vmware-iso.vmx
2018/03/29 20:40:42 ui: ==> vmware-iso: Starting virtual machine...
2018/03/29 20:40:42 ui:     vmware-iso: The VM will be run headless, without a GUI. If you want to
    vmware-iso: view the screen of the VM, connect via VNC with the password "WJIGhGvD" to
    vmware-iso: vnc://127.0.0.1:5975
2018/03/29 20:40:42 packer: 2018/03/29 20:40:42 Executing: /bin/vmrun -T player start output-vmware-iso/packer-vmware-iso.vmx nogui
2018/03/29 20:40:43 packer: 2018/03/29 20:40:43 stdout:
2018/03/29 20:40:43 packer: 2018/03/29 20:40:43 stderr:
2018/03/29 20:40:43 ui: ==> vmware-iso: Waiting 10s for boot...
2018/03/29 20:40:53 ui: ==> vmware-iso: Connecting to VM via VNC (127.0.0.1:5975)
2018/03/29 20:40:53 packer: 2018/03/29 20:40:53 Connected to VNC desktop: packer-vmware-iso
2018/03/29 20:40:53 ui error: ==> vmware-iso: Error detecting host IP: Could not find vmnetdhcp conf file: /etc/vmware/vmnet8/dhcp/dhcp.conf
2018/03/29 20:40:53 packer: 2018/03/29 20:40:53 Executing: /bin/vmrun -T player list
2018/03/29 20:40:53 packer: 2018/03/29 20:40:53 stdout: Total running VMs: 1
2018/03/29 20:40:53 packer: /apps/maa/packer-vmware-templates/centos7/output-vmware-iso/packer-vmware-iso.vmx
2018/03/29 20:40:53 packer: 2018/03/29 20:40:53 stderr:
2018/03/29 20:40:53 ui: ==> vmware-iso: Stopping virtual machine...
2018/03/29 20:40:53 packer: 2018/03/29 20:40:53 Executing: /bin/vmrun -T player stop output-vmware-iso/packer-vmware-iso.vmx hard
2018/03/29 20:40:54 packer: 2018/03/29 20:40:54 stdout:
2018/03/29 20:40:54 packer: 2018/03/29 20:40:54 stderr:
2018/03/29 20:40:54 ui: ==> vmware-iso: Deleting output directory...
2018/03/29 20:40:54 [INFO] (telemetry) ending vmware-iso
2018/03/29 20:40:54 ui error: Build 'vmware-iso' errored: Error detecting host IP: Could not find vmnetdhcp conf file: /etc/vmware/vmnet8/dhcp/dhcp.conf
2018/03/29 20:40:54 Builds completed. Waiting on interrupt barrier...
2018/03/29 20:40:54 machine readable: error-count []string{"1"}
2018/03/29 20:40:54 ui error:
==> Some builds didn't complete successfully and had errors:
2018/03/29 20:40:54 machine readable: vmware-iso,error []string{"Error detecting host IP: Could not find vmnetdhcp conf file: /etc/vmware/vmnet8/dhcp/dhcp.conf"}
2018/03/29 20:40:54 ui error: --> vmware-iso: Error detecting host IP: Could not find vmnetdhcp conf file: /etc/vmware/vmnet8/dhcp/dhcp.conf
2018/03/29 20:40:54 ui:
==> Builds finished but no artifacts were created.
2018/03/29 20:40:54 [INFO] (telemetry) Finalizing.
2018/03/29 20:40:54 [WARN] (telemetry) Error finalizing report. This is safe to ignore. Post https://checkpoint-api.hashicorp.com/v1/telemetry/packer: dial tcp 54.204.31.19:443: connect: connection refused
2018/03/29 20:40:54 waiting for all plugin processes to complete...
2018/03/29 20:40:54 /usr/local/bin/packer: plugin process exited
2018/03/29 20:40:54 /usr/local/bin/packer: plugin process exited
2018/03/29 20:40:54 /usr/local/bin/packer: plugin process exited
2018/03/29 20:40:54 /usr/local/bin/packer: plugin process exited
2018/03/29 20:40:54 /usr/local/bin/packer: plugin process exited
2018/03/29 20:40:54 /usr/local/bin/packer: plugin process exited
2018/03/29 20:40:54 /usr/local/bin/packer: plugin process exited

@warroyo, thx. So, it seems like the network name isn't being converted into the device name. I need to add some logs that emit more about what's going on.

I might need you to either build (or I can provide a binary) to help figure that out. Which do you prefer?

Also, there should be a file in /etc/vmware/netmap.conf that contains the mappings from network type to interface name. That should contain something like network2.name = "NAT" and network2.device = "vmnetsomething". Nothing weird about the contents file, right?

@arizvisa i updated the above logs , turn out i broke something else in the process of downgrading to 1.2.1 and the network module was not starting on workstation. so to update... the error is the exact same one 1.2.2 and 1.2.1 . sorry for the confusion.

here is the netmap.conf:

# This file is automatically generated.
# Hand-editing this file is not recommended.
network0.name = "Bridged"
network0.device = "vmnet0"
network1.name = "HostOnly"
network1.device = "vmnet1"
network2.name = "NAT"
network2.device = "vmnet8"

Ok. Yeah, so it looks pretty normal.

Anyways, I created a branch of packer that outputs better logs of how packer determines the network interfaces to choose from at https://github.com/arizvisa/packer/tree/GH-5882. If you can build it, grab logs the same way and include your json template we'll hopefully be able to squash this issue once and for all...

Are you set up to be able to compile packer? Or do you want me to build a binary for you to test with?

@arizvisa sorry for the delay. i built the forked version and have attached the debug log and template.
looking at the logs, this section looks odd..

2018/03/30 15:38:46 packer-debugging: 2018/03/30 15:38:46 Testing vmware driver *common.Workstation10Driver. Success: false
2018/03/30 15:38:46 packer-debugging: 2018/03/30 15:38:46 VMware app path: /bin/vmware
2018/03/30 15:38:46 packer-debugging: 2018/03/30 15:38:46 vmrun path: /bin/vmrun
2018/03/30 15:38:46 packer-debugging: 2018/03/30 15:38:46 vdisk-manager path: /bin/vmware-vdiskmanager
2018/03/30 15:38:46 packer-debugging: 2018/03/30 15:38:46 Testing vmware driver *common.Workstation9Driver. Success: false
2018/03/30 15:38:46 packer-debugging: 2018/03/30 15:38:46 VMware app path: /bin/vmplayer
2018/03/30 15:38:46 packer-debugging: 2018/03/30 15:38:46 vmrun path: /bin/vmrun
2018/03/30 15:38:46 packer-debugging: 2018/03/30 15:38:46 vdisk-manager path: /bin/vmware-vdiskmanager
2018/03/30 15:38:46 packer-debugging: 2018/03/30 15:38:46 qemu-img path:
2018/03/30 15:38:46 packer-debugging: 2018/03/30 15:38:46 Testing vmware driver *common.Player6Driver. Success: false
2018/03/30 15:38:46 packer-debugging: 2018/03/30 15:38:46 VMware app path: /bin/vmplayer
2018/03/30 15:38:46 packer-debugging: 2018/03/30 15:38:46 vmrun path: /bin/vmrun
2018/03/30 15:38:46 packer-debugging: 2018/03/30 15:38:46 vdisk-manager path: /bin/vmware-vdiskmanager
2018/03/30 15:38:46 packer-debugging: 2018/03/30 15:38:46 qemu-img path:
2018/03/30 15:38:46 packer-debugging: 2018/03/30 15:38:46 Testing vmware driver *common.Player5Driver. Success: true

it chose *common.Player5Driver i am running 14 but dont see a test for 14

template.txt

packer-debug.log

Hm, that's strange. In that branch, your packer log should include the following information in the log for whichever driver is used. Did you checkout the GH-5882 branch before you built it?

For workstation (mine):
2018/03/30 17:01:22 packer.exe: 2018/03/30 17:01:22 Located networkmapper configuration file using Workstation: C:/ProgramData/VMware/netmap.conf

For Player it should be similar to:
2018/03/30 17:01:22 packer.exe: 2018/03/30 17:01:22 Located networkmapper configuration file using Player: C:/ProgramData/VMware/netmap.conf

The commit that should do that is here:
https://github.com/arizvisa/packer/commit/646523c5f4e2dd1791160434df557b7427288a09

The branch that I linked should enumerate all the interfaces/devices that match the detected network after pointing out the networkmapper configuration.

Wrt to your statement about the Player5 driver vs your version 14, the Player5 driver is intended for Player version 5 and up due to being interfaced with the same way amongst those versions.

I did build from that branch , i am not sure why it is not logging that. if you prefer you could provide me the binary just to be sure and i will try using that one.

Ok. Sure. Very strange, then.

Here's a binary of GH-5882 for linux/amd64. Checked it with strings just to be sure those logs are in there.
packer-linux_amd64.zip

Should see the first instance of the networkmapper configuration at the "Building and writing VMX file" step. After that we should see where the "nat" interface is being used to locate the vmnetdhcp config.

2018/03/30 17:01:22 ui: ==> vmware-iso: Building and writing VMX file
2018/03/30 17:01:22 packer.exe: 2018/03/30 17:01:22 Searching for file 'C:/ProgramData/VMware/netmap.conf'
2018/03/30 17:01:22 packer.exe: 2018/03/30 17:01:22 Found file 'C:/ProgramData/VMware/netmap.conf'
2018/03/30 17:01:22 packer.exe: 2018/03/30 17:01:22 Located networkmapper configuration file using Workstation: C:/ProgramData/VMware/netmap.conf

ok here are the update logs , i do see that the logs contain the new info.
packer-debug.log

Ok. Can you try the following binary?

packer-linux_amd64.zip

@arizvisa the new binary solved the problem! thank you!

I am seeing another problem however I don't think it is related to this specific issue. the Vm doesn't seem to be enabling SSH when initially booting. I will continue to debug and open an issue if necessary.

any idea on the timeline for this fix being added to the main packer release?

@warroyo, not sure. I don't work at hashicorp or anything and am just a contributor. so, I can only create the PR and wait for them to merge it upstream. They're typically pretty quick for small fixes like this, though.

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.

Was this page helpful?
0 / 5 - 0 ratings