VMWare Fusion: Error detecting host IP: Could not find vmnetdhcp conf file: /Library/Preferences/VMware Fusion/vmnet0/dhcpd.conf #6745
Comments
|
Hmm. I wonder if version 10 has changed the path to the leases file. Any chance you can kick off a build and poke around in your OS somewhere around Meanwhile I'll try to track down version 10 myself. |
|
I'll also take a look at the differences between 1.2.2. and the current one. |
|
This is weird. The pathing for this file hasn't changed inside of Packer since before v 1.2.2. |
|
Hello, using Packer I also built a centos 7 vmx image from bento and could also ssh to it. ❯ ls /Library/Preferences/VMware\ Fusion/
lastLocationUsed networking vmnet1
license-fusion-100-e3-201704 thnuclnt vmnet8build file:{
"variables": {
"sw_version": "1.0",
"installer_version": "1.0",
"hardware_version": "10",
"vmx_name": "1.0",
"ova_name": "1.0",
"output_dir": "packer-ubuntu-14.04-amd64-vmware-vmx-output",
"ovftool_path": "/Applications/VMware OVF Tool/ovftool",
"source_vmx": "/Users/azr/go/src/github.com/chef/bento/builds/packer-centos-7.5-x86_64-vmware/centos-7.5-x86_64.vmx"
},
"provisioners": [
{
"type": "shell",
"inline": [
"pwd && ls"
]
}
],
"builders": [
{
"type": "vmware-vmx",
"source_path": "{{user `source_vmx`}}",
"ssh_username": "vagrant",
"ssh_password": "vagrant",
"ssh_port": "22",
"ssh_wait_timeout": "1000s",
"shutdown_command": "sudo shutdown -P now",
"vm_name": "{{user `vmx_name`}}",
"output_directory": "{{user `output_dir`}}",
"vmx_data": {
"ethernet0.virtualdev": "vmxnet3",
"ethernet0.present": "TRUE",
"ethernet0.connectionType": "nat",
"ethernet0.startConnected": "TRUE",
"ethernet0.addressType": "generated",
"ethernet0.wakeonpcktrcv": "true",
"displayname": "Test.{{user `sw_version`}}.HW:{{user `hardware_version`}}",
"annotation": "Test OVA {{user `sw_version`}} Hardware version: {{user `hardware_version`}}"
},
"vmx_data_post": {
"memsize": "32767",
"numvcpus": "8",
"virtualhw.version": "{{user `hardware_version`}}",
"ide1:0.startConnected": "FALSE",
"ide1:0.clientDevice": "TRUE",
"ide1:0.fileName": "emptyBackingString",
"ethernet0.virtualDev": "vmxnet3",
"ethernet0.connectionType": "bridged"
}
}
],
"post-processors": [
{
"type": "shell-local",
"inline": [
"{{user `ovftool_path`}} -dm=thin {{user `output_dir`}}/{{user `vmx_name`}}.vmx {{user `output_dir`}}/{{user `ova_name`}}.ova"
]
}
]
}output log:Edit: trying to think of reasons 🙂 |
|
Is there any more information you can give us on this one? We're at a loss because the relevant code doesn't seem to have changed between versions, and we can't reproduce. |
|
Thanks for looking into this, the only thing I can think of is that they're using the trial version of VMware Fusion Pro. I'll attempt to use a base ubuntu vmx image as @azr has done above and see what happens. |
|
Hello @dfrsol, did it work ? 🙂 |
|
Hey @azr, sorry for the delayed response I'm just getting back from vacation. I'll reach out to my guys to see if this worked. |
|
Just as another data point, I have the same issue here:
Packer 1.2.1 was the last version that didn't have the issue. Using the same Packer template, but with the |
|
@mvermaes can you share your full debug logs? As far as I can see, the code in v1.2.1 is the same a the code in use today. |
|
Sorry, 1.2.3 is where it first started happening - 1.2.2 is OK. Logs uploaded to https://gist.github.com/mvermaes/f01e03f4b2ef3b78cde01b63f7868518 It seems to be due to the interface being assigned to the VMware bridged network instead of NAT. The source vmx for the but the Bento box does not. Changing the source vmx to use Maybe this is related to 72da7cb (case-insensitivity of the |
|
Reading a bit more, it looks like prior to 72da7cb, I think it might have something to do with packer/builder/vmware/vmx/step_clone_vmx.go Line 101 in fb1be8b but not being updated to have the "nat" value by the time this runs: packer/builder/vmware/common/driver.go Lines 501 to 503 in a261060 |
|
@arizvisa I think at this point you're more familiar with the vmware code than me. Any insights? |
|
The case-sensitivity patch was because another committer did some work (while the PR was being reviewed) which switched .vmx interaction to use So the missing file path is simply that, the file was not found. By default (to remain backwards compatible with previous versions of templates) it falls back to "nat" since versions of packer prior to that assumed nat for everything (because previous versions of packer didn't actually support any of the other network types). So even if you don't specify a network type or it can't figure out what you're trying to tell it, it should follow the same semantics as earlier versions of packer. However, using "vmx_data" to explicitly set network options or disk devices is the _wrong_ way to specify any of those things because packer doesn't have any knowledge of the meaning of Generally it's a good habit to avoid using |
|
Also after looking at how Although I think it's important to distinguish this in that packer is used for building the base template with an OS, and is to be used combined with another tool in order to add specific hardware configurations and things before deployment. I had a hard time distinguishing that at first as other devops tools were at the point of maturing, and I just wanted to use packer for everything. Although maybe But, using it to switch to one hardware configuration for doing the os install, and then another configuration before deployment is using it in a way that it wasn't originally written for (since none of the other builders have started out supporting those configuration options). But yeah, again...just a matter of opinion. |
|
@dfrsol if you launch a build and look in "/Library/Preferences/VMware Fusion/" are there any directories that contain a "dhcpd.conf" or similarly named file? |
|
@SwampDragons, I made an example PR #6856 which takes the functionality of Like afaict, the reason why dhcpd.conf is being searched for is because Packer is trying to determine the host/network to connect to. This is because "vmx_data" is being used to switch the network connection type and packer removes any options that begin with "ethernet*". If a user tampers with any of them, then the user might actually prevent packer from reverting them. The vmware builder (and a few others) remove all the ethernet interfaces and floppy disks before actually exporting it. So, using Maybe someone should add to the documentation for |
|
Thanks! I'll look at the PR and at making the docs clearer. Maybe we can add some kind of an override warning during validation, where we check the vmx data for dangerous-to-override values that could cause Packer to break. |
|
@SwampDragons, I'll leave it open as a PR and give you access to the branch since it's really more of an example of shifting these Users have been mis-using But yeah, don't actually merge that PR. Especially not until you get a chance to take a look at it and tweak it. I'm not even sure if it actually works or if I'm doing it the correct way. In the post-processor hook, I walk through all of the files associated with an artifact and then modify it directly. I wasn't sure if I was supposed to make a copy of the artifact's file and give it the same name, or it it's even okay to modify directly. I think a post-processor will also need to be made for virtualbox as well. But feel free to close the PR whenever you're done with it or if you lose interest ;). I think drawing this line between building and post-processing will prevent a lot of issues in the future and is important enough so that devers can avoid having to parse all the things available within a .vmx file (since the meaning of some parts of .vmx can change depending on the VMware version). |
|
Awesome, thanks. |
|
@dfrsol did any of the suggestions on this issue help you solve your problem? |
|
I'm going to close this since we've been waiting for a reply for over a month. If anyone is still experiencing this and can help us reproduce, we can reopen. |
|
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. |
ghost
locked and limited conversation to collaborators
Packer:
>= 1.2.5Host: MacOS High Sierra 10.13.4
VMware: Fusion 10.1.3
We're currently on-boarding new team members and told them to download the latest version of Packer, but unfortently we're currently running into a blocking issue when using VMware Fusion 10.1.3 with any version of Packer
>= 1.2.5to build OVAs.This error does not occur when using Packer version
1.2.2.Error detecting host IP: Could not find vmnetdhcp conf file: /Library/Preferences/VMware Fusion/vmnet0/dhcpd.conf
�[1;32m==> vmware-vmx: Cloning source VM...�[0m
�[1;32m==> vmware-vmx: Starting virtual machine...�[0m
�[1;32m==> vmware-vmx: Waiting 10s for boot...�[0m
�[1;32m==> vmware-vmx: Connecting to VM via VNC (127.0.0.1:5940)�[0m
�[1;31m==> vmware-vmx: Error detecting host IP: Could not find vmnetdhcp conf file: /Library/Preferences/VMware Fusion/vmnet0/dhcpd.conf�[0m
�[1;32m==> vmware-vmx: Stopping virtual machine...�[0m
�[1;32m==> vmware-vmx: Deleting output directory...�[0m
�[1;31mBuild 'vmware-vmx' errored: Error detecting host IP: Could not find vmnetdhcp conf file: /Library/Preferences/VMware Fusion/vmnet0/dhcpd.conf�[0m
==> Some builds didn't complete successfully and had errors:
--> vmware-vmx: Error detecting host IP: Could not find vmnetdhcp conf file: /Library/Preferences/VMware Fusion/vmnet0/dhcpd.conf
==> Builds finished but no artifacts were created.
Gist for build:
https://gist.github.com/dfrsol/fad4672d2624fd7d5c6daa9a903c3e7b
Gist for template (ssh user and pass removed):
https://gist.github.com/dfrsol/5e76aba3fd0c1a419654773ccae858aa
The text was updated successfully, but these errors were encountered: