Vagrant Windows timout config setting having no effect

Question

I've been building and using Linux images in Vagrant for while now, but only recently extended coverage to Windows. I've worked images to cater for sysprep, but this has lead to very slow boot times, and subsequent WinRM timeouts have also been problematic. I've tried setting very high timeout values, but they appear to have no effect, i.e. doubled boot timeout but it has dropped

Vagrant.configure(2) do |config|
  config.vm.boot_timeout = 1200
  config.vm.guest = "windows"
  config.vm.communicator = 'winrm'
  config.winrm.timeout = 120
  config.winrm.retry_limit = 10

In this example I have printed of the system time

Mon Mar 20 18:14:21 NZDT 2017

Expecting 20 minute wait time

==> default: Forcing shutdown of VM...
==> default: Destroying VM and associated drives...
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'WindowsDocker'...
==> default: Matching MAC address for NAT networking...
==> default: Setting the name of the VM: cbe_default_1489986988330_5366
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
    default: Adapter 2: hostonly
==> default: Forwarding ports...
    default: 3389 (guest) => 13389 (host) (adapter 1)
    default: 5985 (guest) => 15985 (host) (adapter 1)
    default: 5986 (guest) => 15986 (host) (adapter 1)
    default: 5985 (guest) => 55985 (host) (adapter 1)
    default: 5986 (guest) => 55986 (host) (adapter 1)
    default: 22 (guest) => 2222 (host) (adapter 1)
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: WinRM address: 127.0.0.1:15985
    default: WinRM username: vagrant
    default: WinRM execution_time_limit: PT2H
    default: WinRM transport: negotiate
Timed out while waiting for the machine to boot. This means that
Vagrant was unable to communicate with the guest machine within
the configured ("config.vm.boot_timeout" value) time period.

If you look above, you should be able to see the error(s) that
Vagrant had when attempting to connect to the machine. These errors
are usually good hints as to what may be wrong.

If you're using a custom box, make sure that networking is properly
working and you're able to connect to the machine. It is a common
problem that networking isn't setup properly in these boxes.
Verify that authentication configurations are also setup properly,
as well.

If the box appears to be booting properly, you may want to increase
the timeout ("config.vm.boot_timeout") value.

This has exited after 4 minutes

Mon Mar 20 18:18:42 NZDT 2017

Platform details

Host is Windows 10
Vagrant 1.9.2
VirtualBox 5.1.18
Guest Windows Server 2016

To anyone reading this, you can add `--debug` to the vagrant up command. Not that that's helped in my particular case. — Sridhar Sarnobat, Apr 30 '18 at 21:32

Jules Clements · Accepted Answer · 2018-09-01T22:09:34.567

3

This message was misleading

This means that Vagrant was unable to communicate with the guest machine within the configured ("config.vm.boot_timeout" value) time period

I've changed the WinRM timeout from 120 seconds to 30 minutes and now the guest completes the boot and machine attempts connect.

config.winrm.timeout =   1800 # 30 minutes
config.vm.boot_timeout = 1800 # 30 minutes

edited Sep 01 '18 at 22:09

answered Mar 20 '17 at 20:02

Jules Clements

201
2
8

I assume (and hope) you were able to get past the issues you saw. I would recommend if anyone comes across this to ensure you're running the very latest VirtualBox and Vagrant, as things change so quickly. – blong May 23 '17 at 01:28
3

Sadly VirtualBox and Vagrant updates break more often than they work, so I run use very specific versions. I have a dedicated, bare-metal, host that I use to test each version to vet for issues. – Jules Clements May 24 '17 at 02:47
That's a good point, we should all probably be more careful about the update process. Thanks for the insight! – blong May 24 '17 at 13:19
Yes I know people who are having issues with Virtualbox 5.2 and were advised to try 5.1 – Sridhar Sarnobat Apr 30 '18 at 21:31
This helped, but didn't solve the share problems underlying it. However, it doesn't help much if you don't accompany it with extending the boot timeout: "config.vm.boot_timeout = 1800 # 30 minutes" – George M Reinstate Monica Aug 10 '18 at 16:39

Vagrant Windows timout config setting having no effect

1 Answers1