hashicorp / vagrant

Vagrant is a tool for building and distributing development environments.
https://www.vagrantup.com
Other
26.27k stars 4.43k forks source link

Regular VBoxManage error on vagrant destroy #3612

Closed davebirch closed 10 years ago

davebirch commented 10 years ago

I've seen this issue intermittently since I started using vagrant, but I'm pretty convinced that it's appearing more regularly in recent weeks. The error displayed is always very similar to:

==> centosminion3: Forcing shutdown of VM...
==> centosminion3: Destroying VM and associated drives...
There was an error while executing `VBoxManage`, a CLI used by Vagrant
for controlling VirtualBox. The command and stderr is shown below.

Command: ["unregistervm", "4eff2be3-ea34-4c3b-b4fc-54783ad7be2f", "--delete"]

Stderr: 0%...10%...20%...30%...
Progress state: VBOX_E_INVALID_OBJECT_STATE
VBoxManage.exe: error: Machine delete failed
VBoxManage.exe: error: Medium 'C:\Users\username\VirtualBox VMs\centos-64-x64-vbox4210\box-disk1_5.vmdk' is locked for reading by another task
VBoxManage.exe: error: Details: code VBOX_E_INVALID_OBJECT_STATE (0x80bb0007), component Medium, interface IMedium
VBoxManage.exe: error: Context: "int __cdecl handleUnregisterVM(struct HandlerArg *)" at line 166 of file VBoxManageMisc.cpp

Retrying the vagrant destroy command after seeing the error shows a ""VM not created. Moving on.." message for that VM, so it seems that despite the failure, the destroy command is successfully completing in the background.

Currently using: vagrant 1.5.4 VirtualBox 4.3.10 r93012 Windows 7

No real idea of specific steps to reproduce this one, but I've seen it very regularly recently when shutting down multi-machine vagrant instances (every couple of attempts to destroy a 2-3 machine

I had assumed that it was just some process on the VM accessing the disk that was causing the issue, although strangely, I've even seen the error once or twice when destroying suspended VMs, which I would have thought would have precluded any disk access.

Sorry for the rather vague bug report, please let me know if there's anything else I can do to give you more info on the problem.

mitchellh commented 10 years ago

I would need a repro case, sorry. As you're probably aware, VirtualBox is the most popular use case for Vagrant. The fact I haven't heard of this sooner means it is MOST LIKELY (but not definitively) an environmental issue with your specific setup. I'd like to be able to detect and handle that, but I would need you to do a bit more digging. :)

athak commented 9 years ago

Hi, I'm running against this issue too. Currently using: vagrant 1.7.0 VirtualBox 4.3.20 Mac OS 10.10.1

Plugins used: sahara (0.0.17) vagrant-serverspec (0.1.0) vagrant-share (1.1.3, system) vagrant-vmware-fusion (3.1.2)

Environment is a multi-machine vagrant but usually only one VM is up at a time.

ERROR warden: Error occurred: There was an error while executing `VBoxManage`, a CLI used by Vagrant for controlling VirtualBox. The command and stderr is shown below.

Command: ["unregistervm", "24d2b440-b79f-4e4c-a9a6-52936074d787", "--delete"]

Stderr: 0%...10%...20%...30%...40%...
Progress state: VBOX_E_INVALID_OBJECT_STATE
VBoxManage: error: Machine delete failed
VBoxManage: error: Medium '/Users/athak/VirtualBox VMs/tests_debian-6_1419001552693_23745/packer-virtualbox-debian-6-disk1.vmdk' is locked for reading by another task
VBoxManage: error: Details: code VBOX_E_INVALID_OBJECT_STATE (0x80bb0007), component Medium, interface IMedium
VBoxManage: error: Context: "int handleUnregisterVM(HandlerArg*)" at line 166 of file VBoxManageMisc.cpp

Output is repeated multiple times. As stated in the original report, the VM is successfully destroyed.

Any additional details I can provide, more than happy to.

Thanks, Atha

sethvargo commented 9 years ago

Hi @athak

Can you please run the command in debug mode and put the output in a Gist?

matt-richardson commented 9 years ago

We are also finding this happening frequently now. Using vagrant 1.7.2, Virtualbox 4.3.20 r96997.

We've only just started seeing it, and it happened just after we upgraded to the latest versions.

Its not consistent though - if we re-run the job (its only happening on our CI agents (which are Win2008R2)) it usually passes.

Just re-ran on the same CI agent, and it passed, with no change :(