hashicorp / packer-plugin-vsphere

Packer plugin for VMware vSphere Builder
https://www.packer.io/docs/builders/vsphere
Mozilla Public License 2.0
93 stars 91 forks source link

Add support for `http_interface` and `http_bind_address` #247

Open alandsidel opened 1 year ago

alandsidel commented 1 year ago

Overview of the Issue

Neither of the mentioned config settings, http_interface or http_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 of tun0 this option correctly binds to the specified ipv4 address according to netstat -anl, however the message it prints stating HTTP server is working at a.b.c.d prints the address of vmx0, 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 to tun0 instead of setting the address as above, which I would prefer since the addresses are dynamic, Packer listens on all interfaces according to netstat -anl, but only on the ipv6 tcp socket. The address printed in the message is incorrect as above, showing the ipv4 address of vmx0 rather than the specified tun0.

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.

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

tenthirtyam commented 2 months ago

@nywilken @lbajolet-hashicorp - wouldn't this be an upstream issue for packer-plugin-sdk?

patschi commented 2 months ago

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. image image

alandsidel commented 2 months ago

I love it. Issue persists, languishes here for a year, then just gets closed without explanation.

tenthirtyam commented 2 months ago

@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.

alandsidel commented 2 months ago

@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.

tenthirtyam commented 2 months ago

@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

patschi commented 2 months ago

Thank you very much @tenthirtyam! Should anything be needed, I'm happy to assist as well.