Open alandsidel opened 1 year ago
@nywilken @lbajolet-hashicorp - wouldn't this be an upstream issue for packer-plugin-sdk
?
I can still reproduce this with packer 1.10.3 and vSphere 7. Running this in Windows's WSL picks up the IP of the nested VM, not from the actual physical host - as overwriting http_ip
doesn't work, the entire process fails as it uses the WSL IP.
I'm testing Packer the first time. Any guidance where this issue might better belong to? Unfortunately it's still a issue and issue seems to be closed by now.
EDIT: It also fails using natively on Windows. It picks some other weird Windows virtual NIC instead (maybe some OpenVPN interface) and renders the entire process failing.
I love it. Issue persists, languishes here for a year, then just gets closed without explanation.
@alandsidel - You can follow the thread above and as the OP can even reopen it if you like.
However, I'm fairly certain that this is not specific to the plugin (see labels) and is an issue with the Packer SDK that provides the http layer.
@tenthirtyam There are better responses than just.. closing a ticket.
At a bare minimum, the documentation should be updated to state that the provided configuration knob does not work as advertised. Going beyond the literal bare minimum, I would expect that since Packer is also a Hashicorp project, that an issue be opened there by someone who is in a position to confirm (or even suspect) that that is the actual issue, before closing this one, and that that new issue be mentioned here.
From my perspective as an end user, this is the right place for the bug report. This is where the incorrect behavior manifests and is experienced, regardless of the root cause.
I don't have any confidence that just reopening the ticket, if I even can, would lead to anything productive other than it being closed again with just as little explanation or action.
@alandsidel I've reopened the issue the issue for you and have assigned it to the Packer leads at HashiCorp.
Ryan Johnson Distinguished Engineer, VMware by Broadcom
Thank you very much @tenthirtyam! Should anything be needed, I'm happy to assist as well.
Overview of the Issue
Neither of the mentioned config settings,
http_interface
orhttp_bind_address
work quite as expected. As documented in this "feature request" issue: https://github.com/hashicorp/packer-plugin-vsphere/issues/245 the functionality of both of these configuration options seem to be broken in common but perhaps not the majority of cases.My test/development VM has two interfaces with RFC1918 addresses. vmx0, the local ethernet interface, and tun0, a tunnel to the remote environment where vcenter is running.
http_bind_address
: When I specify the address oftun0
this option correctly binds to the specified ipv4 address according tonetstat -anl
, however the message it prints statingHTTP server is working at a.b.c.d
prints the address ofvmx0
, which is incorrect and unreachable by the remote network. That incorrect address is sent to the remote end for it to connect back to, which I determined with tcpdump.http_interface
: When this option is set totun0
instead of setting the address as above, which I would prefer since the addresses are dynamic, Packer listens on all interfaces according tonetstat -anl
, but only on the ipv6 tcp socket. The address printed in the message is incorrect as above, showing the ipv4 address ofvmx0
rather than the specifiedtun0
.Reproduction Steps
Attempt to use either of the above settings using the "second" (or higher) locally discovered interface.
Packer Version
1.8.5
Plugin Version and Builders
Please provide the plugin version.
n/a or unknown.
Please select the builder.
vsphere-iso
vsphere-clone
VMware vSphere Version
Please provide the VMware vSphere version.
6.7.0, 19997733
Guest Operating System
Ubuntu 20.04 LTS x64
Simplified Packer Buildfile
https://gist.github.com/alandsidel/8fdad97624aa34087a1d3b11d0c9b6f2