-
-
Notifications
You must be signed in to change notification settings - Fork 130
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Soft coding waitForIP #668
Comments
Initial provisioning using ssh would then fail, as would other terraform resourced depending on VM's IPv4 address. It should be easy enough to add an option for the provider to consider any non-loopback ip address good enough, but it seems more like a workaround. The VM at that point would not be fully configured or even accessible. The IP addresses of VM would be practically unusable (link-local), and all dependent resources could not depend on VM. Instead they would have to depend on some resource that configures VM's networking ( It might be more maintainable to have the VM template configure its networking automatically after start. The guest agent would then report final and correct IP address. For Linux VM For Windows VM, there is cloudbase-init, unfortunately it looks like there is some incompatibility thread 1, thread 2 and even requires some patching to make it work with Proxmox "simple" cloud-init configuration. It looks like the main issue is that Proxmox generates wrong contents of cloud init files, but not the cloud init drive itself. Another option is to borrow Place networking configuration in There is also the |
Thanks for the response and ideas @otopetrik. I agree that in most cases waitForIP being set to true is the best option and should remain the default, however my use case only needs to validate that the guest agent is responding. I tried cloudbase-init and ran into the issues you identified, which led me to discover I can talk to the guest agent directly. For simplicity sake I prefer to store my startup scripts in my terraform repository and then use terraform local-exec to call the guest agent api and use file-write/exec to provision new windows vms. For additional context the vms are being deployed to an isolated network and the terraform server will be unable to reach them by IP regardless of how it is set. |
Marking this issue as stale due to inactivity in the past 180 days. This helps us focus on the active issues. If this issue is reproducible with the latest version of the provider, please comment. If this issue receives no comments in the next 30 days it will automatically be closed. If this issue was automatically closed and you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thank you! |
Is your feature request related to a problem? Please describe.
When deploying a sys-prepped Windows image with the QEMU guest agent enabled maximum timeout is reached because it has an APIPA. WaitForIP is currently hard coded here.
Describe the solution you'd like
Allowing waitForIP to be configurable would cover an edge case where the QEMU guest agent is used to configure a VMs interfaces post deployment.
Describe alternatives you've considered
Setting agent/timeout lower than 15 minutes is a workaround, but can lead to false positives causing subsequent provisioning steps to fail.
The text was updated successfully, but these errors were encountered: