Skip to content
This repository has been archived by the owner on Mar 8, 2023. It is now read-only.

vsphere-iso: Support local web server like QEMU builder #108

Closed
shane-kearns opened this issue May 23, 2018 · 6 comments
Closed

vsphere-iso: Support local web server like QEMU builder #108

shane-kearns opened this issue May 23, 2018 · 6 comments
Labels

Comments

@shane-kearns
Copy link

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
Copy link
Contributor

mkuzmin commented May 23, 2018

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
Copy link
Author

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
Copy link
Contributor

mkuzmin commented May 23, 2018

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

@scbjans
Copy link
Contributor

scbjans commented May 29, 2018

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
Copy link
Contributor

mkuzmin commented Dec 23, 2018

Implemented in #116.

@mkuzmin mkuzmin closed this as completed Dec 23, 2018
@mkuzmin
Copy link
Contributor

mkuzmin commented Dec 23, 2018

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Development

No branches or pull requests

3 participants