vagrant cannot clean-up machines

[akostadinov]

As evident by status below vagrant lists some machines. But cannot destroy them. Looks like if machine did not go up as expected, it cannot be destroyed. This is only one example but I've used vagrant a couple of times and I had issues destroying machines always.

Vagrant 1.7.2

As a reference the machine in question is launched from https://github.com/openshift/origin repo.

[origin@origin3 origin]$ vagrant global-status 
id       name              provider  state     directory                                       
-----------------------------------------------------------------------------------------------
48b2654  openshiftdev      libvirt   running   /home/origin/go/src/github.com/openshift/origin 
02438c1  minion-2          openstack preparing /home/origin/go/src/github.com/openshift/origin 
b8cdd92  minion-1          openstack preparing /home/origin/go/src/github.com/openshift/origin 
c0ad47e  master            openstack preparing /home/origin/go/src/github.com/openshift/origin 
a811fd5  akostadi-minion-2 openstack preparing /home/origin/go/src/github.com/openshift/origin 
95a5b75  akostadi-master   openstack preparing /home/origin/go/src/github.com/openshift/origin 
4bf84fe  akostadi-minion-1 openstack preparing /home/origin/go/src/github.com/openshift/origin 

The above shows information about all known Vagrant environments
on this machine. This data is cached and may not be completely
up-to-date. To interact with any of the machines, you can go to
that directory and run Vagrant, or you can use the ID directly
with Vagrant commands from any directory. For example:
"vagrant destroy 1a2b3c4d"
[origin@origin3 origin]$ vagrant destroy 48b2654
/home/origin/go/src/github.com/openshift/origin/Vagrantfile:12: warning: already initialized constant VAGRANTFILE_API_VERSION
/home/origin/go/src/github.com/openshift/origin/Vagrantfile:12: warning: previous definition of VAGRANTFILE_API_VERSION was here
/home/origin/go/src/github.com/openshift/origin/Vagrantfile:42: warning: already initialized constant OPENSTACK_CRED_FILE
/home/origin/go/src/github.com/openshift/origin/Vagrantfile:42: warning: previous definition of OPENSTACK_CRED_FILE was here
/home/origin/go/src/github.com/openshift/origin/Vagrantfile:43: warning: already initialized constant OPENSTACK_BOX_URL
/home/origin/go/src/github.com/openshift/origin/Vagrantfile:43: warning: previous definition of OPENSTACK_BOX_URL was here
/home/origin/go/src/github.com/openshift/origin/Vagrantfile:44: warning: already initialized constant AWS_CRED_FILE
/home/origin/go/src/github.com/openshift/origin/Vagrantfile:44: warning: previous definition of AWS_CRED_FILE was here
/home/origin/go/src/github.com/openshift/origin/Vagrantfile:45: warning: already initialized constant AWS_BOX_URL
/home/origin/go/src/github.com/openshift/origin/Vagrantfile:45: warning: previous definition of AWS_BOX_URL was here
/home/origin/go/src/github.com/openshift/origin/Vagrantfile:46: warning: already initialized constant VM_NAME_PREFIX
/home/origin/go/src/github.com/openshift/origin/Vagrantfile:46: warning: previous definition of VM_NAME_PREFIX was here
There are errors in the configuration of this machine. Please fix
the following errors and try again:

vm:
* A box must be specified.

[mauricios]

The same happen when removing Vagrant file or directory of the Vagrantfile while the machine is active, the machine can not be destroyed. I have to recreate the Vagrantfile with the same virtual machine name, then start the machine and destroy it.

Is there an option to prune or force destroy a machine?

The force argument of the command destroy only destroys the machine without confirmation

[akostadinov]

Ideal would be if vagrant caches all necessary information needed to destroy machine from backend so that VMs can always be destroyed.
What would be still very useful though and should be easy is to have an option to remove virtual machine from any vagrant records and let user destroy actual VM from the backend manually. At the moment I'm pruning .vagrant and ~/.vagrant to recover from such issues. This is suboptimal as I need to restore boxes and plug-ins. If that additional hassle is avoided it would be of a great help.

[sethvargo]

Hi @akostadinov @mauricios

Vagrant's global-status is a cache of machines. What happens if you run:

vagrant global-status --prune

[mauricios]

@akostadinov --prune works just fine, by removing the invalid entries. Sorry for overlooking that option.

[akostadinov]

It didn't work for me. I used libvirt and openstack backends if that matters.

[mitchellh]

Closing, --prune works.

[akostadinov]

--prune works not in all situations and this causes severe confusion.

[mitchellh]

Please reproduce the issue without any plugins (libvirt/openstack are both plugins) and give us clear reproduction steps and I'll reopen. I apologize I only read the comment above yours and didn't see the other.

[akostadinov]

I think that to be user friendly, vagrant should be able to recover from some plug-in oddities. e.g. clear particular machine metadata without nuking the all metadata and without relying on the plug-ins.
Next time I have a chance to play with it, I'll report issues with the respective plug-ins, but in any case, core vagrant could be more resilient.

[mitchellh]

@akostadinov I agree, but I just want to be able to reproduce it cleanly. :)

[akostadinov]

It might not be reproducible without plug-ins. If that works for you I can try to define a reproducer with some of the plug-ins and report back.