Closed lbrigman124 closed 6 years ago
lbrigman124
commented
6 years ago Just checked on something that may have caused the issue but I am not certain. The instance is using DHCP. We are also using Dynamic DNS and the hostname is not registered due to DHCP lease time-out issues.
vancluever
commented
6 years ago Hey @lbrigman124 thanks for submitting the issue and sorry you are having trouble!
From what it sounds like, you might be able to corroborate your findings by setting wait_for_guest_net to false. That will skip the network waiter, which would be causing timeouts if you were having issues getting a routeable address.
Let us know how it goes!
diwu1989
commented
6 years ago i saw a behavior similar to this, will try out the wait_for_guest_net = false tweak and report back if it fixes my situation, thx!
msborrowersfirst
commented
6 years ago Hi!
We have a similar issue. We're using a static IP address, and have set _wait_for_guestnet = false without luck.
terraform-provider-vsphere_v0.4.2_x4
If you'd like a more verbose environment description then please let me know.
Thanks!
vancluever
commented
6 years ago Hey @msborrowersfirst, if you are having issues with this a log would definitely be helpful, or even at least your Terraform output and your configuration if you can share it. Thanks!
diwu1989
commented
6 years ago wait_for_guest_net=false speeds up the creation process for my VMs
vancluever
commented
6 years ago To be clear on the value of wait_for_guest_net: we need to have guest networking available to report a valid address to any provisioners that have been set up on the resource. Further to this, namely on Windows problems can arise where an autoconfiguration IPv4 address shows up before the valid static IP addresses that have either been set up in the resource, or possibly a valid DHCP address, which is why we wait for an address that can reach the internet (by checking that it has a valid link-local gateway).
wait_for_guest_net=false allows you to skip this process, speeding up deploy time, but more than likely means your IP address information will be incomplete and you may run into issues when trying to use provisioners and what not. So keep that in mind when using the setting!
diwu1989
commented
6 years ago Okay, do u mind if I submit a PR against the documentation for wait_for_guest_net to include some of this nuanced information? That would make it more obvious how this flag is supposed to be used/abused.
DustinChaloupka
commented
6 years ago Having similar problems using a static IP. Just setting wait_for_guest_net = false does not get around the problem:
Terraform Resource
resource "vsphere_virtual_machine" "machine" {
count = "1"
# If this is set to false, then the host to the connections needs set
# wait_for_guest_net = false
dns_servers = ["10.10.10.53"]
name = "test.com"
memory = "4096"
vcpu = "2"
disk {
datastore = "some_datastore"
template = "template0"
}
disk {
datastore = "some_datastore"
size = "20"
name = "test"
}
network_interface {
label = "VLAN"
ipv4_address = "10.10.10.96"
ipv4_gateway = "10.10.10.254"
ipv4_prefix_length = "24"
}
connection {
# This needs set if wait_for_guest_net is false
# host = "10.10.10.96"
user = "user"
private_key = "${file("path/to/private/key")}"
agent = false
}
provisioner "remote-exec" {
inline = [
"echo 'Connected!'"
]
}
}The reason the host needs set in the connection block I believe is because the provider does not find everything it needs (unsure where it sets this in the code).
If wait_for_guest_net = true then the resource will timeout waiting for a routeable IP. The machine does come up fine and does have a configured interface:
eth0 Link encap:Ethernet HWaddr 00:50:56:ad:8e:04
inet addr:10.10.10.96 Bcast:10.10.10.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:22545 errors:0 dropped:22 overruns:0 frame:0
TX packets:14431 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:44165721 (44.1 MB) TX bytes:1142266 (1.1 MB)I did find some boot logs on the machine where it mentioned the full network configuration step had failed, but I wasn't able to find anything in logs to figure out why.
I also added some of my own logging in the code where it waits for the guest network, but all I found was that in the events that came in, the IP route config was empty:
2017-10-31T09:33:24.838-0500 [DEBUG] plugin.terraform-provider-vsphere_v0.4.2_x4: 2017/10/31 09:33:24 [INFO] <<< VAL: {[{{} %!s(*types.NetDnsConfigInfo=&{{} false test vsphere.local [10.10.10.53] [vsphere.local]}) %!s(*types.NetIpRouteConfigInfo=&{{} []}) [] %!s(*types.NetDhcpConfigInfo=<nil>)}]}
2017-10-31T09:33:24.838-0500 [DEBUG] plugin.terraform-provider-vsphere_v0.4.2_x4: 2017/10/31 09:33:24 [INFO] <<< GUEST STACK INFO: {DynamicData:{} DnsConfig:0xc421beeb40 IpRouteConfig:0xc4204a29c0 IpStackConfig:[] DhcpConfig:<nil>}
2017-10-31T09:33:24.838-0500 [DEBUG] plugin.terraform-provider-vsphere_v0.4.2_x4: 2017/10/31 09:33:24 [INFO] <<< IP ROUTE CONFIG: +&{{} []}Though in the added logs, at least it is finding the assigned static IP address:
2017-10-31T09:33:24.838-0500 [DEBUG] plugin.terraform-provider-vsphere_v0.4.2_x4: 2017/10/31 09:33:24 [INFO] <<< VAL: {[{{} VLAN [10.10.10.96] 00:50:56:ad:8e:04 %!s(bool=true) %!s(int32=4000) %!s(*types.NetDnsConfigInfo=<nil>) %!s(*types.NetIpConfigInfo=&{{} [{{} 10.10.10.96 24 preferred <nil>}] <nil> <nil>}) <nil>}]}
2017-10-31T09:33:24.838-0500 [DEBUG] plugin.terraform-provider-vsphere_v0.4.2_x4: 2017/10/31 09:33:24 [INFO] <<< GUEST NIC INFO: {DynamicData:{} Network:VLAN IpAddress:[10.10.10.96] MacAddress:00:50:56:ad:8e:04 Connected:true DeviceConfigId:4000 DnsConfig:<nil> IpConfig:0xc420794ab0 NetBIOSConfig:<nil>}
2017-10-31T09:33:24.838-0500 [DEBUG] plugin.terraform-provider-vsphere_v0.4.2_x4: 2017/10/31 09:33:24 [INFO] <<< IP CONFIG: &{DynamicData:{} IpAddress:[{DynamicData:{} IpAddress:10.10.10.96 PrefixLength:24 Origin: State:preferred Lifetime:<nil>}] Dhcp:<nil> AutoConfigurationEnabled:<nil>}
2017-10-31T09:33:24.838-0500 [DEBUG] plugin.terraform-provider-vsphere_v0.4.2_x4: 2017/10/31 09:33:24 [INFO] <<< IP ADDRESS: {DynamicData:{} IpAddress:10.10.10.96 PrefixLength:24 Origin: State:preferred Lifetime:<nil>}
2017-10-31T09:33:24.838-0500 [DEBUG] plugin.terraform-provider-vsphere_v0.4.2_x4: 2017/10/31 09:33:24 [INFO] <<< IP: 10.10.10.96, V4GW: <nil>, V6GW: <nil>, MASK: ffffff00
2017-10-31T09:33:24.838-0500 [DEBUG] plugin.terraform-provider-vsphere_v0.4.2_x4: 2017/10/31 09:33:24 [INFO] <<< IP CONFIG: &{DynamicData:{} IpAddress:[{DynamicData:{} IpAddress:10.10.10.96 PrefixLength:24 Origin: State:preferred Lifetime:<nil>}] Dhcp:<nil> AutoConfigurationEnabled:<nil>}
2017-10-31T09:33:24.838-0500 [DEBUG] plugin.terraform-provider-vsphere_v0.4.2_x4: 2017/10/31 09:33:24 [INFO] <<< IP ADDRESS: {DynamicData:{} IpAddress:10.10.10.96 PrefixLength:24 Origin: State:preferred Lifetime:<nil>}
2017-10-31T09:33:24.838-0500 [DEBUG] plugin.terraform-provider-vsphere_v0.4.2_x4: 2017/10/31 09:33:24 [INFO] <<< IP: 10.10.10.96, V4GW: <nil>, V6GW: <nil>, MASK: ffffff00There was already an issue created about the gateway ip not getting set, so wondering if that is the case here.
For the workaround using the wait_for_guest_net = false though, since the host does not get set by the provider, it explicitly needs given in the connection block. The other downside is that there appears to be an issue with the provider storing the ipv4_address so if you want to reference the the machine's IP address in a different resource (ie to create a DNS record), it will also need to be explicitly set there. For us this isn't too bad since we pass in the static IP address into a variable, but unsure how it affects non-static IP addresses getting assigned to machines.
vancluever
commented
6 years ago Hey @DustinChaloupka, what guest OS are you running this with?
If this is a Linux box, you can find the customization log at /var/log/vmware-imc/toolsDeployPkg.txt. You should hopefully be able to find the source of your issue there.
Thanks!
DustinChaloupka
commented
6 years ago @vancluever It is Linux that we are using. I've provided the logs of /var/log/vmware-imc/toolsDeployPkg.log below, which nothing in it looks suspect to me, but I'm also not entirely sure what I should be looking for.
lynic
commented
6 years ago I have the same issue here, I use terraform v0.10.8 with vsphere provider v0.4.2 under macos. terraform apply hangs on "still creating". But I can see the IP address on vcenter and I can ssh to VM. There must some bug in finding the IP address of the VM in provider.
lynic
commented
6 years ago BTW setting wait_for_guest_net = false didn't work for me, it still hangs on "still creating" and then error with timeout.
vancluever
commented
6 years ago @lynic - have you tried setting `wait_for_customization_timeout to -1 well? This will disable all waiters.
kdunn-pivotal
commented
6 years ago I saw this issue when the template VM didn't already have VMWare Guest Tools installed and set to autostart.
vancluever
commented
6 years ago Hey all, #470 has now been merged which allows you to control the routable behaviour of the network waiter. Keep an eye out for 1.4.1 which will probably be out this week!
terraform -v Terraform v0.10.7 uname -a Linux lbrigman-e32 2.6.32-696.3.2.el6.x86_64 #1 SMP Mon Jun 19 11:23:31 CDT 2017 x86_64 x86_64 x86_64 GNU/Linux
terraform providers . └── provider.vsphere find .terraform .terraform .terraform/plugins .terraform/plugins/linux_amd64 .terraform/plugins/linux_amd64/lock.json .terraform/plugins/linux_amd64/terraform-provider-vsphere_v0.4.2_x4
Expected Behavior
Terraform should complete when the instance is created and configured.
Actual Behavior
Was 'Still creating...' after 8 minutes. vsphere_virtual_machine.gsm1: Still creating... (8m0s elapsed) ^CInterrupt received. Please wait for Terraform to exit or data loss may occur. Gracefully shutting down... stopping apply operation... vsphere_virtual_machine.gsm1: Still creating... (8m10s elapsed) vsphere_virtual_machine.gsm1: Still creating... (8m20s elapsed) vsphere_virtual_machine.gsm1: Still creating... (8m30s elapsed) vsphere_virtual_machine.gsm1: Still creating... (8m40s elapsed) vsphere_virtual_machine.gsm1: Still creating... (8m50s elapsed) vsphere_virtual_machine.gsm1: Still creating... (9m0s elapsed) vsphere_virtual_machine.gsm1: Still creating... (9m10s elapsed) vsphere_virtual_machine.gsm1: Still creating... (9m20s elapsed) vsphere_virtual_machine.gsm1: Still creating... (9m30s elapsed) vsphere_virtual_machine.gsm1: Still creating... (9m40s elapsed) vsphere_virtual_machine.gsm1: Still creating... (9m50s elapsed) vsphere_virtual_machine.gsm1: Still creating... (10m0s elapsed) vsphere_virtual_machine.gsm1: Still creating... (10m10s elapsed)
Apply complete! Resources: 0 added, 0 changed, 0 destroyed.
Steps to Reproduce
Please list the steps required to reproduce the issue, for example:
terraform applyImportant Factoids
Terraform 0.10.4 and provider v0.2.2_x4 worked but took almost double the actual instance creation time (1m:20s for terraform, watching Vsphere Center client - complete in about 20 seconds).