Timeout while waiting for WinRM with packer 0.12.1

[ProloG-Shaman]

Hello,
When building a windows 10 64 bit machine with malboxes, I get a timeout while waiting for WinRM. When looking at the machine, it seems to install and boot normally, but no tools are installed and WinRM never becomes available. The command I am running is:

malboxes build win10_64_analyst

I am running Ubuntu 16.04 LTS 64-bit with Packer version 0.12.1, VirtualBox version 5.0.30 r112061 and Vagrant version 1.8.1. The error output is the following:

==> virtualbox-iso: Starting the virtual machine...
    virtualbox-iso: The VM will be run headless, without a GUI. If you want to
    virtualbox-iso: view the screen of the VM, connect via VRDP without a password to
    virtualbox-iso: 127.0.0.1:5947
==> virtualbox-iso: Waiting 10s for boot...
==> virtualbox-iso: Typing the boot command...
==> virtualbox-iso: Waiting for WinRM to become available...
==> virtualbox-iso: Timeout waiting for WinRM.
==> virtualbox-iso: Unregistering and deleting virtual machine...
==> virtualbox-iso: Deleting output directory...
Build 'virtualbox-iso' errored: Timeout waiting for WinRM.

==> Some builds didn't complete successfully and had errors:
--> virtualbox-iso: Timeout waiting for WinRM.

==> Builds finished but no artifacts were created.
----------------------------------
packer completed with return code: 1
Packer failed. Build failed. Exiting...

[Svieg]

@ProloG-Shaman, you didnt ask for @obilodeau help yesterday? Did you try to check the open ports on your machine and see which port packer is trying to communicate with. hashicorp/packer#2399 seems to indicate it could be a problem but that it also should be fixed. Vagrant's output generally include forwarded ports, can you paste the full output here. Also, I had problems with the official repos version of Vagrant that were corrected by downloading the package straight from their site.

[ProloG-Shaman]

@Svieg, I looked at the packer issue you linked, and adding the port for WinRM in the builder_virtualbox_windows.json file seems to have fixed the issue.
I added this line to "vboxmanage":

["modifyvm", "{{.Name}}", "--natpf1", "guestwinrm,tcp,127.0.0.1,5985,,5985"]

[Svieg]

That's okay if your host is Linux but might be a problem if your on a windows host and winrm is enabled so the ports will collide if I'm not mistaken. I suggest adding this line with the port 55985 and add the winrm port in the template like mentioned here with winrm_port @obilodeau ?

[obilodeau]

The VirtualBox NAT rule should be automatically created for you. The bug has been fixed and locked upstream so it shouldn't require weird workarounds from our end.

Here are my NAT mappings in one of my VMs:

$ VBoxManage showvminfo maldoc | grep "NIC.*Rule"
NIC 1 Rule(0):   name = ssh, protocol = tcp, host ip = 127.0.0.1, host port = 2222, guest ip = , guest port = 22
NIC 1 Rule(1):   name = winrm, protocol = tcp, host ip = 127.0.0.1, host port = 2200, guest ip = , guest port = 5985
NIC 1 Rule(2):   name = winrm-ssl, protocol = tcp, host ip = 127.0.0.1, host port = 55986, guest ip = , guest port = 5986

Can you remove your work-around and run the same command as above when your VM is in Waiting for WinRM to become available... state? Replace maldoc with the VM name generated by packer. The VM name can be found with VBoxManage list vms. You can do all this through the GUI if this feels more familiar to you.

My feeling is that you already have something on port 2200 on your host or something like that. packer should pick an available port but maybe for WinRM they don't. We'll see once we have the info.

[ProloG-Shaman]

I removed the work-around and ran the command:

$ VBoxManage showvminfo packer-virtualbox-iso-1482871446 | grep "NIC.*Rule"
NIC 1 Rule(0):   name = packercomm, protocol = tcp, host ip = 127.0.0.1, host port = 2350, guest ip = , guest port = 5985

The host port changes each time I run a build.

[obilodeau]

While trying to reproduce, I found that this is an upstream regression in packer 0.12.1: hashicorp/packer#4310

I think this is fixed with this PR (which has not been released yet): hashicorp/packer#4321

Avoid packer 0.12.1 for the time being. I ran a successful malboxes build win10_64_analyst from an Ubuntu 16.04 machine with packer 0.12.0.

[obilodeau]

This should be fixed in packer 0.12.2, released a few days ago, according to the changelog. Can you try to reproduce?

[ProloG-Shaman]

I updated to packer 0.12.2 and I can confirm the issue is fixed for me.

[obilodeau]

Excellent. Thanks!