Locked .vhdx files after vagrant up

[Naadwo]

Vagrant version

Vagrant 1.9.6 (on 1.9.5 problem was exactly the same)

Host operating system

Windows 10 1703

Guest operating system

Does not matter - checked with several (Ubuntu, CentOS, Suse)

Vagrantfile

Tested with several Vagrantfiles, and this does not matter. Example Vagrantfile:

Vagrant.configure("2") do |config|
  config.vm.provider "hyperv"
  config.vm.box = "generic/debian9"
end

Debug output

Log after VM was destroyed half manually
Log after machine.rb modification
For details about non standard lines "Ommiting (...)" and half manually removing VM refer to actual behavior section.

Expected behavior

VM created only needed .vhdx files (for example .vagrant\machines\default\hyperv\Virtual Hard Disks\generic-debian9-hyperv.vhdx). Both up and destroy should work and all VM data should be easy to remove.

Actual behavior

More files are created during VM reation. All are named randomly (in pattern: [\w]{8}.[\w]{3}.vhdx ). It's not possible to remove those files before restart of whole host. I have made some changes in machine.rb to be able to restart VM (simple added a regexp to ommit those files).
It happens on every .box which was exported in new MS standard (with vmrs and vmcx files instead of old xml). Old boxes are imported properly.
Without my modification in machine.rb, it is not possible to start again a vm only. Even after manual cleanup (see in gist).
I've also checked that file is holded by System process - however it's not visible with PackageExplorer (LockHunter finds this file as locked).
Checked on more than one computer.

Steps to reproduce

1. Find any Hyper-V box which was exported with .vmrs and .vmcx files
2. Run vagrant up
3. Run vagrant destroy
4. On standard vagrant installation you will get an error on this step

rmdir: Directory not empty @ dir_s_rmdir - /.vagrant/machines/default/hyperv/Virtual Hard Disks (Errno::ENOTEMPTY)

5. If you remove all data exeptc extra .vhdx vagrant up will not work
6. If you add to machine.rb an exclusioon to this files both up and destroy works

[Naadwo]

Anyone, anything about this issue? Am I the only one struggling with this problem?

[kpatryk]

We faced the same problem. Omitting the mentioned files during bootstrapping was the only workaround we applied so far.

[dee3sync]

I am running Vagrant 2.1.5 on Win10 Enterprise build 16299.309 and running into the above issue. When trying to run vagrant destroy:

My Vagrantfile is:

Vagrant.configure("2") do |config|
  config.vm.box = "bento/ubuntu-16.04"
  config.ssh.insert_key = false
  config.ssh.username = 'vagrant'
  config.ssh.username ="#{ENV['vagrant_pass']}"
  config.vm.provider "hyperv" do |hyperv|
    hyperv.vmname = "vagrant-hyperv-test"
    hyperv.memory = 4096
    hyperv.cpus = 2
  end
end

The virtual machine is not present in Hyper-V anymore but something is preventing it from being deleted completed, how can I fix this? I noticed @kpatryk mentioned omitting files, I am new to Vagrant, how would I do that?

[chrisroberts]

Are these Vagrant environments being interacted with from WSL at all?

[dee3sync]

@chrisroberts Sorry, I am not sure what WSL stands for? I am using PowerShell and Hyper-V. A vagrant up runs fine, but vagrant destroy throws an error.

[Naadwo]

WSL stands for Windows Subsystem for Linux.
In my case vagrant is installed directly on Windows and the problem is still present on latest Vagrant.

Regarding my modification - this is my version of machine.rb. This is not based on the latest version of machine.rb. Changed part is 343:368. But remember it is not a solution but a dirty workaround.

[dee3sync]

@Owdaan Thank you and understood regarding it being a dirty workaround. That said, I edited my machine.rb located by default at C:\HashiCorp\Vagrant\embedded\gems\2.1.5\gems\vagrant-2.1.5\lib\vagrant with the lines mentioned above and the workaround was successful for Vagrant 2.1.5. I also made sure to comment out the original lines located in the machine.rb from 355-367 in case.

@chrisroberts I am not using a WSL, this is directly on a windows machine.

[chrisroberts]

I spent some time attempting to reproduce this behavior but was unable to. Vagrant was able to cleanly destroy all guests that I created. Some things that may help with being able to reproduce this and determine the underlying cause of the issue:

• Does the behavior persist when the system is fully up-to-date?
• Is Windows Defender running and is real time scanning enabled?
• Is there any other virus scanners running on the system?

Thanks!

[Naadwo]

Yes, I've experienced that on systems that were up to date.

Right now there is Windows Defender running with Real-time protection on and also Cisco AMP. However, I had the same issue without Cisco AMP in background.
I also thought this might be related to scanning of the file, but finally I don't think it is the reason, as:

• the vhdx file is locked until restart (if I work with vagrant longer every time I import a VM I have a new vhdx file that is locked), and scanner should finish scanning after some time (it can last days).
• vhdx are locked only after import with Vagrant - I've never experienced such behavior on normal VMs
• I can't do anything with this files also manually.
  I also thought it might be a problem with boxes we use - but the same happens with other ones.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.