ESXi takes a long time to start

28 views
Skip to first unread message

Peter Krefting

unread,
Dec 10, 2018, 8:28:14 AM12/10/18
to packe...@googlegroups.com
Hi!

I am using Packer to create images on an ESXi 6.5 host, and I am having
problems with it taking a very long time to start up. Packer uploads the
ISO file and then stops at "Starting HTTP server on port NNNN" for half
an hour or so. During the time I can see no activity on the ESXi host,
and the VM entry is not available. After half an hour, it (most often)
continues, creates the VM and runs the installer as expected.

Is there any reason for this delay?

This is my configuration file:

{
"builders": [
{
"type": "vmware-iso",
"remote_type": "esx5",
"remote_host": "10.0.31.140",
"remote_username": "builder",
"remote_password": "withheld",
"remote_datastore": "raid5array",
"remote_cache_datastore": "raid5array",
"remote_cache_directory": "ISOs",
"vnc_disable_password": true,
"format": "ovf",
"vm_name": "centos",
"vmdk_name": "centos",
"iso_url": "centos.iso",
"iso_checksum_type": "none",
"ssh_username": "root",
"ssh_password": "withheld",
"ssh_wait_timeout": "30m",
"shutdown_command": "shutdown -P now",
"disk_size": "491520",
"disk_type_id": "thin",
"guest_os_type": "rhel7-64",
"vmx_data": {
"numvcpus": "8",
"memsize": "16384",
"ethernet0.present": "true",
"ethernet0.networkName": "VM Network",
"ethernet0.virtualDev": "vmxnet3",
"ethernet1.present": "true",
"ethernet1.networkName": "Host-Only Network",
"ethernet1.virtualDev": "vmxnet3",
"vmxnet.noOprom": "true",
"vmxnet2.noOprom": "true"
},
"http_directory": "kickstart",
"boot_wait": "0s",
"boot_command": [

"<esc><esc><wait><esc><esc><wait><esc><esc><wait><esc><esc><wait><esc><esc><wait><esc><esc><wait>",
"/isolinux/vmlinuz ",
"inst.ks=http://{{ .HTTPIP }}:{{ .HTTPPort }}/CentOS.cfg ",
"initrd=initrd.img ",
"inst.stage2=hd:LABEL=CentOS ",
"biosdevname=0 net.ifnames=0 ",
"quiet",
"<enter>"
]
}
],
"provisioners": [
{
"type": "file",
"direction": "download",
"source": "/root/anaconda-ks.cfg",
"destination": "anaconda-ks.cfg"
},
{
"type": "file",
"direction": "download",
"source": "/root/original-ks.cfg",
"destination": "original-ks.cfg"
},
{
"type": "file",
"direction": "download",
"source": "/var/log/anaconda/anaconda.log",
"destination": "anaconda.log"
},
{
"type": "file",
"direction": "download",
"source": "/var/log/anaconda/journal.log",
"destination": "journal.log"
},
{
"type": "shell",
"script": "post-install/post-install.sh"
}
]
}

--
\\// Peter - http://www.softwolves.pp.se/

Rickard von Essen

unread,
Dec 11, 2018, 1:08:26 AM12/11/18
to packe...@googlegroups.com
That seems weird. Can you attach the output when running with PACKER_LOG=1.

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.

GitHub Issues: https://github.com/mitchellh/packer/issues
IRC: #packer-tool on Freenode
---
You received this message because you are subscribed to the Google Groups "Packer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to packer-tool...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/packer-tool/86b45277ee0670e1f7de40172a8b78df%40softwolves.pp.se.
For more options, visit https://groups.google.com/d/optout.

Peter Krefting

unread,
Dec 11, 2018, 5:12:58 AM12/11/18
to packe...@googlegroups.com
2018-12-11 07:08 skrev Rickard von Essen:

> That seems weird. Can you attach the output when running with
> PACKER_LOG=1.

Hmm, seems it is looking for which VNC port the VM ended up on:

2018/12/11 09:44:34 packer: 2018/12/11 09:44:34 Trying address:
10.0.31.140:5900...
2018/12/11 09:44:49 packer: 2018/12/11 09:44:49 Timeout connecting to:
10.0.31.140:5900 (check firewall rules)
2018/12/11 09:44:49 packer: 2018/12/11 09:44:49 Trying address:
10.0.31.140:5901...
2018/12/11 09:45:04 packer: 2018/12/11 09:45:04 Timeout connecting to:
10.0.31.140:5901 (check firewall rules)
[...]
2018/12/11 10:06:34 packer: 2018/12/11 10:06:34 Trying address:
10.0.31.140:5988...
2018/12/11 10:06:34 packer: 2018/12/11 10:06:34 Found available VNC
port: 5988
2018/12/11 10:06:34 packer: 2018/12/11 10:06:34 Writing VMX to:
/home/peter/tmp/packer-vmx136814960/centos.vmx

It is supposed to chose a port randomly, so there is no way of
configuring this, is there?

Rickard von Essen

unread,
Dec 11, 2018, 9:53:07 AM12/11/18
to packe...@googlegroups.com
Speculating a bit here, but I think your firewall drop packages and Packer tries to find an available port starting at 5900. Ech attempt times out after 30 seconds. When it reaches 5988 it succeeds but that touch ~ 30 minutes. 

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.

GitHub Issues: https://github.com/mitchellh/packer/issues
IRC: #packer-tool on Freenode
---
You received this message because you are subscribed to the Google Groups "Packer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to packer-tool...@googlegroups.com.

JP Toto

unread,
Dec 11, 2018, 10:01:19 AM12/11/18
to packe...@googlegroups.com
This post https://nickcharlton.net/posts/using-packer-esxi-6.html shows how to have ESXi open the required ports so that the firewall is open to the initial calls.


For more options, visit https://groups.google.com/d/optout.


--
JP Toto   |   james....@gmail.com   |   http://jptoto.jp   |   @jptoto

Rickard von Essen

unread,
Dec 11, 2018, 10:12:03 AM12/11/18
to packe...@googlegroups.com
If you have another range open you should adjust https://packer.io/docs/builders/vmware-iso.html#vnc_port_min and vnc_port_max

Peter Krefting

unread,
Dec 12, 2018, 3:30:38 AM12/12/18
to packe...@googlegroups.com
Hi!

2018-12-11 16:01 skrev JP Toto:

> This post https://nickcharlton.net/posts/using-packer-esxi-6.html shows
> how to have ESXi open the required ports so that the firewall is open
> to the initial calls.

Thanks for pointing me towards this! Performing the firewall changes
mentioned in this post seems to have removed the long waiting period.
Reply all
Reply to author
Forward
0 new messages