vsphere-iso: Support local web server like QEMU builder

[shane-kearns]

Some distributions of Linux* are dropping floppy disk support from the installer ISO.
However both debian-based and redhat-based distributions can load the preseed / kickstart file from a URL provided in the boot command.

The QEMU/KVM builder has a feature to serve a directory as HTTP and pass this to the boot command:
https://www.packer.io/docs/builders/qemu.html#http_directory

It would be useful to have this in vsphere-iso as well, so that the preseed files can be kept close to the packer files without a "deploy to a web server" step required before running "packer build"

(This feature could solve #93 for example.)
Another possible advantage is that vestigial references to the floppy device are left behind in config of the image being built, producing syslog messages on startup of some systems.

*Debian 8/9, Ubuntu 18.04 (though the "alternate" ISO retains floppy support in Ubuntu)

[mkuzmin]

embedded HTTP server works great in desktop hypervisors.
But with remote builds we have more complicated environment, and I don't think it can work reliably. For example, all my Packer builds are running inside Docker containers. This is too difficult to make Packer process available for incoming connections from created VMs.

Will your issue be solved by dynamic creation of ISO images the same way as with floppies?

[shane-kearns]

Whether ISO creation would work depends on the installers themselves.
I know that network based installation works. (provided the VM can get an address from DHCP)
I know that "remastering" to create installation media with the kickstart/preseed included works (but is undesirable)
I don't know the behaviour if you create a second virtual CD-ROM device with a dynamically created ISO, it depends what Debian and others have done in their installers. It would need somebody to test it.

All my packer builds are run on a VM in the same network as the target, so an embedded HTTP server would work. Currently I'm copying files into a non-embedded HTTP server as a workaround.
(If your docker host is in the same network, you can expose ports from containers. I suspect there's reasons you can't do that)

[mkuzmin]

Well, I agree with you here, a good feature request.

[scbjans]

We were already using the HTTP server in the vmware builder for our Windows VM's, since file transfers over WinRM tend to be much slower.
Since this vsphere-iso builder suits our needs much better, I was already trying to get this feature to work (https://github.com/scbjans/packer-builder-vsphere/tree/sander/issue_http).

Shall I take on this feature request?

[mkuzmin]

Implemented in #116.

[mkuzmin]

But I would still prefer floppy approach if possible.
HTTP connection is easy in VirtualBox when Packer and VM are within localhost.

Our scenario is remote, and there are multiple issues:

• Desktop firewall can block incoming connections to Packer process.
• Using Docker containers, Packer is put behind NAT. You can configure port forwarding, but then you have to explicitly announce its IP address.
• When Packer machine has multiple network interfaces, the wrong one may be selected. This could be improved, but requires even more logic.