Closed davebirch closed 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. :)
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
Hi @athak
Can you please run the command in debug mode and put the output in a Gist?
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 :(
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:
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.