Vagrant destroy does not clean the VM directory in virtualbox

Vagrant
1

Hi,
I like to use vagrant destroy -f to clean a VM.

I use VirtualBox as provider and Windows 10 as host OS. Recently I upgraded my Windows 10 host build version and also vagrant and virtualbox. I also had to update the guest Ubuntu OS from 16 to 20. But now, when I do a vagrant destroy -f, I cannot do a vagrant up because there’s a left-over directory with a log file (VboxUI.log) until I remove that directory. My guess is that this is changed behavior of the provider, but it would be nice if vagrant could have a flag to actually force a complete clean. Is there such a flag?

Thanks

2

Does anyone have any clue for how to fix this behavior?

3

I too am facing this issue. It seems like a Virtualbox bug.

The following results in many “virtualbox Headless Frontend” procs that never close…

vagrant init
for (( c=1; c<=10; c++ )); do
vagrant up || break
vagrant destroy -f || break
sleep 10
done

I tried replacing “vagrant destroy -f” with the following…
PNAME=My-VM-name
VBoxManage controlvm “$PNAME” poweroff
VBoxManage unregistervm “$PNAME” --delete

Same, same, no different.

That seems to indicate that it is Virtualbox and not Vagrant that is at fault.

gl, kendal

1 Like
4

Thanks Kendal.
I opened the question here instead of on GitHub issues, because I thought I was doing something wrong.
Following your analysis, should virtualbox be the right forum for this discussion?
My impression would be that the newer version of virtualbox may have new API options for completely cleaning the directory (including that log), and that vagrant is not using it for the destroy option.

5

what happens if you precede “vagrant destroy” with the following?

vagrant halt
sleep 5

6

My testing does point to Virtualbox being the problem.

I have been working a few tests today.

rather than “vagrant destroy -f” I am going to start using the following…

vagrant halt
sleep 5
vagrant destroy -f

I have yet to fully test this, but other testing has been leading me towards it.

regards

7

another thing to try together with “vagrant halt” is the following…

config.vm.provider “virtualbox” do |vb|
vb.gui = true
end

this forces the gui which causes vagrant to not run VirtualboxHeadless.exe
Perhaps the non-headless code does not share the same flaw as the
headless stuff.

8

Thanks Kendal. I’ll do some tests with your suggestions.
I would still like to see a cleaner answer coming from Vagrant/VirtualBox, as work-arounds are just as annoying as deleting the left over directory.