HTTP server IP discovery issues

[nferch]

It looks like there's an issue in the way the HTTP server's IP discovery is implemented (#58 )

As I understand, typeBootCommandOverVNC will invoke tart ip to discover the guest host's IP address, and derive the HTTP server from the gateway of the subnet the IP address is using. I don't see how this could work, as the host will not get to the point of obtaining and setting an IP address until it has fully booted.

I'm guessing some logic/ordering more akin to what the QEMU builder in https://github.com/hashicorp/packer-plugin-qemu/blob/main/builder/qemu/step_http_ip_discover.go will be necessary.

But maybe I'm totally misunderstanding how this is intended to work, could you help @edigaryev

[edigaryev]

I don't see how this could work, as the host will not get to the point of obtaining and setting an IP address until it has fully booted.

It will get the IP if running macOS (even when running with--recovery), but in the case of automated Linux installation I guess you're right. Is this what you're trying to do?

The reason we retrieve the VM's IP-address first is that it's the most reliable way to find out the bridge interface that the vmnet.framework is using. And from that bridged interface it's easy to derive the gateway IP.

[edigaryev]

On a second thought, even if we skip the tart ip ... part, how would a VM connect to the HTTP server running on host without obtaining the IP address for itself from the DHCP server first?

Packer plugin for Tart only officially supports shared (NAT) network, and that implies the DHCP usage by the guest.

[nferch]

Yes, automated Linux Ubuntu installation is what I'm trying to do. Had totally forgotten about macOS, makes so much more sense now. :/

The HTTP server's address is needed to pass as a parameter to the GRUB bootloader. It isn't actually used until networking is up and an IP address is obtained from DHCP.

It should be safe to assume that shared (NAT) network is being used, so I guess the question is how to reliably determine what interface is used for that. Could try and mirror what tart is doing with VZNetworkDeviceAttachment and get the address through that somehow. Alternatively, a config option to set it manually would be fine for my purposes.

[edigaryev]

The HTTP server's address is needed to pass as a parameter to the GRUB bootloader. It isn't actually used until networking is up and an IP address is obtained from DHCP.

I've just tried running Ubuntu Server and preventing it from going past GRUB (by pressing Esc) and it turns out that the Virtualization.Framework didn't even create a bridge* interface that we use to determine the {{ .HTTPIP }}.

Anyway, I think you can already accomplish this:

Alternatively, a config option to set it manually would be fine for my purposes.

...by setting the http_bind_address option to a value other than 0.0.0.0 in your Packer template for Tart plugin, see:

packer-plugin-tart/builder/tart/step_run.go

Lines 236 to 238 in eb96164

	if config.HTTPAddress != "" {
	return config.HTTPAddress, nil
	}

(yes, we currently bypass the guest IP/interface resolution logic if this option if not empty as opposed to not equal to 0.0.0.0, but that's subject to change)

[nferch]

The HTTP server's address is needed to pass as a parameter to the GRUB bootloader. It isn't actually used until networking is up and an IP address is obtained from DHCP.

I've just tried running Ubuntu Server and preventing it from going past GRUB (by pressing Esc) and it turns out that the Virtualization.Framework didn't even create a bridge* interface that we use to determine the {{ .HTTPIP }}.

Good catch, I either didn't notice that or had something holding bridge100 open.

Anyway, I think you can already accomplish this:

Alternatively, a config option to set it manually would be fine for my purposes.

...by setting the http_bind_address option to a value other than 0.0.0.0 in your Packer template for Tart plugin, see:

packer-plugin-tart/builder/tart/step_run.go

Lines 236 to 238 in eb96164

	if config.HTTPAddress != "" {
	return config.HTTPAddress, nil
	}

(yes, we currently bypass the guest IP/interface resolution logic if this option if not empty as opposed to not equal to 0.0.0.0, but that's subject to change)

That doesn't quite work for me, I had to move the commonsteps.HTTPServerFromHTTPConfig before stepCreateLinuxVM, I'm guessing because of the port number selection?

[edigaryev]

That doesn't quite work for me, I had to move the commonsteps.HTTPServerFromHTTPConfig before stepCreateLinuxVM, I'm guessing because of the port number selection?

Good catch! This should be fixed as a part of the new 1.3.0 release, the HTTP server is now started before the installation takes place.

[nferch]

Thanks so much, confirmed it is working with the workaround.

Longer term a better option might be to dynamically create an ISO or floppy similar to QEMU builder but this works for my manual invocations. Would require some sort of hack to get it working with CI though, I'd guess.