sysprep_timeout is waiting for customization to complete, but then bootstrapping is happening with a different IP

[Zorrom]

Versions:

• Version of knife-vsphere: 2.0.1
• Version of chef: 12.19.36

Platform Details

• Version of vSphere: 6.5.0
• Version of ESXi: 6.5.0

Scenario:

Trying to spin up the VM and bootstrap it using the following command

knife vsphere vm clone testVM3 --dest-folder Chef_Test --template NewTemplate -f Chef_Test --datastore my_datastore --cips 10.0.0.1/23 --cdnsips 10.0.0.2,10.10.0.3 --cspec win12 --start --sysprep_timeout 360 --bootstrap --winrm-user Adminstrator --winrm-password mypassword

As per the above command the VM is built successfully along with the Ip address and dns settings. However before it could bootstrap I want it to wait for 6 minutes using the sysprep_timeout in order for the customization to complete so that the bootstrap operation can take the correct IP address of the virtual machine.

But in this case the sysprep time started once the vm is cloned and powered on, but instead of waiting for 6 minutes via sysprep, the command went to bootstrap the machine right after the customization is complete.

My vcenter is a bit slow so that it is taking around 30 seconds for the actual Ip to reflect on the Vsphere UI once the cspec customizations are applied. So I want my vm clone command to wait for those 6 minutes irrespective of customization completion, so that it can take the correct IP address of the VM before proceeding with bootstrap.

Please paste the command and output (run with -VV). Don't forget to X out any passwords or sensitive information:

Expected Result:

Sysprep to wait for the mentioned timeout seconds and then proceed with bootstrap

Actual Result:

Bootstrap process initiated right after cspecs are applied

[swalberg]

Hi, if memory serves the timeout is the max time we'll wait, not a forced delay.

How's it getting a different IP address? Ideally the template will boot up with no address at all.

--bootstrap-ipv4 may help here. But ideally any address reported is a good one.

[Zorrom]

Hi Swel, The template was supposed to boot up with no IP, but after cloning the machine restarts again to apply the cspec(which is normal) and at that time when the system comes on it is showing an irrelevant IP address and chef quickly takes it. ##Cough.. Cough... Vcenter magic is strong in this one :( ## Once the wrong Ip is displayed in Vsphere UI it takes about 10 -15 seconds to quickly switch the IP on the machine that is passed using the --cips. So can we do something to force a delay for chef to initate the bootstrap process so that it doesnt take the wrong IP.

[swalberg]

Do you have dynamic DNS? We also have --fqdn so you can pass the FQDN of the node and we'll use whatever's registered in DNS.

[Zorrom]

I don't think we have dynamic DNS. And my bootstrap operation fails when we use hostname because my workstation can only find the hostname if it has an entry for that newly built vm in /etc/hosts. So as of now I have factored my command into three sections.

1. clone the vm
2. sleep for 5 minutes
3. Do the normal bootstrap using knife bootstrap command The above steps are working fine because I am passing the static IP in my knife bootstrap. So now the concern is if we go with the DHCP option (which might come in the near future), would Chef still cause this problem or how is it going to vary. Any thoughts about this. Thanks

[swalberg]

Hi, most of what we do at my job is DHCP and the bootstrapping works well. Instead of passing in an address use dhcp, e.g. --cips dhcp.

Still a bit puzzled as to what's going on with your template. I'll ask around the office -- I wasn't the one that made the Windows template so if I can get some pointers I'll pass them along.

[Zorrom]

Yeah, we have used the dhcp option earlier as well but with this current issue being in place,just wanted to know whether this would cause any problems. Yeah, kindly check with the people over there and share the feedback. You can close this issue after adding your pointers. Thanks a lot for your help. :+1: