Win 2019 vsphere-ISO build "waiting for IP" / build process question

Packer
1

Hey all, first time post. I’ve been looking into docker this week, my initial impression is that it’s great! I was able to build a new Win 2019 instance, but I did run into one issue i’ve seen reported on the forums a few times. Where the build completed, but the packer.exe process stays in a “waiting for IP” state for 30 mins, times out, then deletes the VM.

All the scripts process correctly, and VM tools installs without issue

If the build is complete, what are the steps are actually performed once windows is installed? is it just to finish writing the log file and/or converting the VM to a template ? I don’t really care about either of these steps , is there a way to just tell packer to stop “waiting for the IP”

Else, what should I be looking at to fix the “Waiting for IP” issue? WinRM is up/running on the correct port

Here’s my redacted config:

{
“variables”: {
“os_iso_path”: “[vSan] Files/SERVER_2019.ISO”,
“vm-cpu-num”: “2”,
“vm-disk-size”: “40960”,
“vm-mem-size”: “4096”,
“vm-name”: “win2019-gold-packer”,
“vsphere-cluster”: “vSan”,
“vsphere-datacenter”: “My Home Datacenter”,
“vsphere-datastore”: “vSan”,
“vsphere-folder”: “Gold Images”,
“vsphere-network”: “VM Network”,
“vsphere-password”: “EurovisonSongContest123”,
“vsphere-server”: “vc.mydomain.loc”,
“vsphere-user”: “administrator@vc.mydomain.loc”,
“winadmin-password”: “EurovisonSongContest123”
},

“sensitive-variables”: [“vsphere_password”,“winadmin_password”],

“builders”: [
{
“CPUs”: “{{user vm-cpu-num}}”,
“RAM”: “{{user vm-mem-size}}”,
“RAM_reserve_all”: true,
“cluster”: “{{user vsphere-cluster}}”,
“communicator”: “winrm”,
“winrm_username”: “madminister”,
“winrm_password”: “{{user winadmin-password}}”,
“convert_to_template”: “false”,
“datacenter”: “{{user vsphere-datacenter}}”,
“datastore”: “{{user vsphere-datastore}}”,
“disk_controller_type”: “lsilogic-sas”,
“firmware”: “bios”,
“folder”: “{{user vsphere-folder}}”,
“guest_os_type”: “windows9Server64Guest”,
“insecure_connection”: “true”,

  "iso_paths": [
    "{{user `os_iso_path`}}",

“[vSan] Files/vmwaretools.iso”
],

“floppy_files”: [
“autounattend.xml”,
“scripts/disable-network-discovery.cmd”,
“scripts/enable-rdp.cmd”,
“scripts/enable-winrm.ps1”,
“scripts/install-vm-tools.cmd”,
“scripts/set-temp.ps1”
],

  "network_adapters": [
    {
      "network": "{{user `vsphere-network`}}",
      "network_card": "vmxnet3"
    }
  ],
  "password": "{{user `vsphere-password`}}",
  "storage": [
    {
      "disk_size": "{{user `vm-disk-size`}}",
      "disk_thin_provisioned": true
    }
  ],
  "type": "vsphere-iso",
  "username": "{{user `vsphere-user`}}",
  "vcenter_server": "{{user `vsphere-server`}}",
  "vm_name": "{{user `vm-name`}}"
}

],

“provisioners”: [
{
“type”: “windows-shell”,
“inline”: [“ipconfig”]
}
]
}

2

Additional reboot between the steps?

There are some problems regarding “winrm” and “waiting for ip” here in the forum. I think I have read that an additional reboot should remedy the situation. Windows style.

3

Thanks for your reply !

I can add a reboot for sure. Would it be right after the vmware tools is installed or once the final script runs? Enabling winrm is the final step in my autounattend post build script calls

4

I would give it a try. :+1:

5

Will do , but where would I place the reboot ? End of the install or right after vmware tools install ?

6

After VMware tools, i would guess.

7

Hey ! Good news!

After your post regarding a reboot, I decided to look into another issue I noted on vsphere, where it was stating that the VMWARE tools service wasn’t running, despite the drivers being installed on the shell. Sure enough, I checked, and the “VMWARE Tools” window service is not installed, even after a 2nd reboot!

Checking vmware forums/reddit etc, this is known issue going back years. The fix is to run an un-install/re-install manually or use a script that re-installs vmware tools when it fails to install cleanly the first time

This one for instance will do it:

https://scriptech.io/automatically-reinstalling-vmware-tools-on-server2016-after-the-first-attempt-fails-to-install-the-vmtools-service/

The above script has one prompt for the un-install piece, i’ll post something to my own GIT HUB soon that handles the vmware tools uninstall to make the entire process seamless

My build is now complete, and i’m a very happy camper!

2 Likes
8

Nice! I knew there were issues regarding this, but without the daily routine it’s hard to give the right advise. Now there is a workaround. Thank you!

1 Like
9

New script is live!

3 Likes