We gained a ton of improvemnts to WinRM error handling in
https://github.com/mitchellh/vagrant/pull/4943, but we also got one bug.
The new code raises an exception when `winrm_info` does not return right
away. This was preventing us from catching the retry/timout logic that's
meant to wait until boot_timeout for the WinRM communicator to be ready.
This restores the proper behavior by rescuing the WinRMNotReady
exception and continuing to retry until the surrounding timeout fires.
Adds a configurable value for WinRm and the elevated permission shell ExecutionTimeLimit.
Please see mitchellh/vagrant#5506
Ex: config.winrm.execution_time_limit = "P1D"
Windows offers no out-of-the-box rsync utility. By far, the most
commonly used external utilities for Windows rsync are built with the
GNU Cygwin libraries. The cost for this convenience is that rsync on
Windows has to be provided paths that begin “/cygdrive/c” rather than
“c:/“ like other Windows-API utilities. Compounding the situation,
rsync doesn’t create paths/to/sub/targets and so the vagrant plugin
code, when performing an rsync, is responsible for creating
intermediate directories in guest paths if there are any. Furthermore,
the mkdir utility in Windows is not another Cygwin utility like rsync
but the routine mkdir of Windows command.com. Therefore, while rsync
needs the /cygwin paths, mkdir uses the Windows paths. Later, the
chef_solo.rp provisioner running within the guest will expect to find
Windows-style paths in its solo.rb configuration file. Due to all this,
vagrant has to keep track of both the original, possibly dirty Windows
guest path and the cygwin-scrubbed guest path.
When the network's type is :dhcp, the :ip option is used to derive the DHCP server configuration, and it doesn't actually indicate the IP that will be received by the VM(s).
This fixes error for Win 10 Enterprise:
An error occurred while executing a PowerShell script. This error
is shown below. Please read the error message and see if this is
a configuration error with your system. If it is not, then please
report a bug.
Script: get_vm_status.ps1
Error:
C:\HashiCorp\Vagrant\embedded\gems\gems\vagrant-1.7.4\plugins\providers\hyperv\scripts\get_vm_status.ps1 : Unable to
find type [Microsoft.HyperV.PowerShell.VirtualizationOperationFailedException].
At line:1 char:1
+ &('C:\HashiCorp\Vagrant\embedded\gems\gems\vagrant-1.7.4\plugins\prov ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (Microsoft.Hyper...FailedException:TypeName) [get_vm_status.ps1], Ru
ntimeException
+ FullyQualifiedErrorId : TypeNotFound,get_vm_status.ps1
This allows Vagrant to calculate if a container's arguments (such as the run
arguments) have changed in the Vagrantfile since the original run.
Fixes GH-3055
When provisioning multiple machines in sequence (the default vagrant
behaviour), it doesn't make sense to require to provide the private ssh
key(s) via the custom ansible inventory script/file.
To align with the handling of multiple ssh keys per machine, we won't
rely any longer on `--private-key` command line argument, but only pass
the keys via `ANSIBLE_SSH_ARGS` environment variable.
Note that when vagrant generates the ansible inventory and that only one
key is associated to a VM, this step would be redundant, and therefore
won't be applied.
This change fixes the breaking change introduced by 3d62a91.
