Destroying VM fails

[tboyce]

Great plugin, but I am having an issue with destroying VMs. When I destroy, with the VM up, it asks for credentials to remove the computer from the domain as expected, and then it reboots. Vagrant then appears to be sitting and waiting for the machine to shutdown, which never happens.

# vagrant destroy
Are you sure you want to destroy this machine and disconnect from domain.local? (y/n)y
Please enter your domain username: tboyce
Please enter your domain password (output will be hidden):
==> default: "Running Windows Domain Provisioner"
VERBOSE: Performing the operation "Remove-Computer" on target "tboyce-mgc".WARNING: The changes will take effect after you restart the computer
tboyce-mgc.Restarting computer for updates to take effect.
==> default: Attempting graceful shutdown of VM...
==> default: Checking if box 'win81-vs2015' is up to date...
==> default: Clearing any previously set forwarded ports...
==> default: Fixed port collision for 3389 => 3389. Now on port 2200.
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    default: 3389 => 2200 (adapter 1)
    default: 22 => 2222 (adapter 1)
    default: 5985 => 55985 (adapter 1)
    default: 5986 => 55986 (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: WinRM address: 127.0.0.1:55985
    default: WinRM username: vagrant
    default: WinRM transport: plaintext

After waiting for a few minutes vagrant prints this error:

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.

[mefellows]

Thanks @tboyce, could you please provide a Gist containing a debug log for this when it breaks again? Instructions for verbose logging can be found here: https://www.vagrantup.com/docs/other/debugging.html

Also, if you could please provide some detail on your OS version and anything else that might be relevant that would be great. I'm going to guess Windows 8.1 based on that box name though!

[tboyce]

Seems like there might be some potentially sensitive data in the debug log. If I can find the time I will see if I can reproduce in a clean environment. The host and guest OS are both Windows 8.1 and I am using VirtualBox and winrm to communicate.

[mefellows]

Thanks Tim. If it's easier feel free to obfuscate the data.

On Fri, Mar 4, 2016 at 12:59 AM, Timothy Boyce [email protected]
wrote:

Seems like there might be some potentially sensitive data in the debug
log. If I can find the time I will see if I can reproduce in a clean
environment. The host and guest OS are both Windows 8.1 and I am using
VirtualBox and winrm to communicate.

—
Reply to this email directly or view it on GitHub
#10 (comment)
.

Matt Fellows

• http://www.onegeek.com.au/

[mefellows]

Looks to be related to #16