Vagrant: "An error occurred while executing `vmrun`, a utility for controlling VMware machines." ServiceImpl_Opener: PID ... Error: The operation was canceled (vmware_fusion provider 4.0.1 and VMWare Fusion 8)

Created on 31 Aug 2015  ยท  11Comments  ยท  Source: hashicorp/vagrant

Strange, strange errors after upgrading to VMware Fusion 8 and the latest Hashicorp fusion plugin.

Tried this in a fresh setup testing directory A:
git clone https://github.com/coreos/coreos-vagrant.git cd coreos-vagrant vagrant up --provider=vmware_fusion

This results in this error:

An error occurred while executing `vmrun`, a utility for controlling
VMware machines. The command and output are below:

Command: ["start", "/Users/karsten/dev/testing/coreos-vagrant/.vagrant/machines/core-01/vmware_fusion/44bdccd5-28fc-4306-8f5e-881645923d32/coreos_production_vagrant_vmware_fusion.vmx", "nogui", {:notify=>[:stdout, :stderr], :timeout=>45}]

Stdout: 2015-08-31T17:57:29.547| ServiceImpl_Opener: PID 5033
Error: The operation was canceled

Stderr:

(detailed Gist debug out here: https://gist.github.com/karstengresch/b1a2688877154c491a47

However, if I download the CoreOS VMWare ova file w/
curl -LO http://alpha.release.core-os.net/amd64-usr/current/coreos_production_vmware_ova.ova, I get it easily running within VMWare Fusion in a side directory, both with GUI and with vmrun

Could you please help me out? All of this did not happen directly after the installation of VMware Fusion + the fusion provider, but after the first reboot of the machine (MBP late 2013, 16 GByte). I have no clue what could cause this problem and just want to get Vagrant working again.

Thanks!

bug providevmware

Most helpful comment

@karstengresch: This occurs once in a while, and it helps to kill off all vmware processes:

sudo pkill -f "/Applications/VMware Fusion"

All 11 comments

News: I downgraded to Fusion 7.0 (could find the license key to not being forced following VMWare's absolutely bizarre and not understandable downgrade process) and to Vagrant 1.7.3 and the fusion provider 3.0.1. Result: same problem again :-|

So I assume the problem lies w/in my individual configuration . If you guys could have a look at the logfile anyway, I'd be more than happy. Any idea?

Thanks!

@karstengresch sorry to hear about the trouble! The operation was canceled message is unfortunately related to just about every possible thing that could go wrong at the VMware layer.

Is it possible you could gist the vmware.log from inside the machine's dir?

/Users/karsten/dev/testing/coreos-vagrant/.vagrant/machines/core-01/vmware_fusion/44bdccd5-28fc-4306-8f5e-881645923d32/vmware.log

That may point us in the right direction.

@phinze - thanks for the quick reply!

Is it possible you could gist the vmware.log from inside the machine's dir?

Unfortunately I destroyed all the boxes and rm'ed the .vagrant directories before downgrading (and yes - I used the Vagrant uninstall tool for uninstalling Vagrant. Unfortunately there's no such thing for VMWare AFAIK).

Nevertheless: After recognizing downgrading wouldn't help, I decided installing VMWare Fusion and the Vagrant Fusion provider anew, restarted (as around 20 times today) - and it's running again.

Reminds me of days in the far past when dealing w/ Windows driver issues on work machines. I can't believe the workaround for this issue is uninstalling VMWare and Vagrant and removing all traces, then reboot and install again, but at least this worked for me.

@karstengresch: This occurs once in a while, and it helps to kill off all vmware processes:

sudo pkill -f "/Applications/VMware Fusion"

@rrva Thanks for the hint! You mean, killing the process is more efficient than restarting the machine? However, I'll give it a try in case the behaviour occurs again.

Thanks @rrva That did the trick!

sudo pkill -f "/Applications/VMware Fusion"

I had similar problem. I was trying to run another VMWare machine with one already on. Halting running VM solved problem for me. Seems VMWare_Fusion can't run multiple instances.

What worked for me here was rather ruthlessly deleting some lock files that I assume made the VM think it was already running.

ll .../.vagrant/machines/default/vmware_fusion/53c24151-4883-4594-bf6e-98312738d98d/
showed two directories:

564d007c-5bba-0781-48a1-bd830e047645.vmem.lck and disk-cl1.vmdk.lck

I just mved both to another directory (so I had backups) and the VM started fine.

I had this issue even with the currently latest releases of VMware Fusion (10.0.1) and its corresponding Vagrant provider (5.0.1). There was no lock files remaining and restarting the OS or killing processes didn't help. One tiny command did solve it, though:

$ vagrant halt
==> default: Discarding suspended state...

From there on, vagrant up started successfully.

@barneyjackson Removing the lock files was the only thing that worked for me. Thank you!

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

RobertSwirsky picture RobertSwirsky  ยท  3Comments

OtezVikentiy picture OtezVikentiy  ยท  3Comments

rrzaripov picture rrzaripov  ยท  3Comments

DreadPirateShawn picture DreadPirateShawn  ยท  3Comments

hesco picture hesco  ยท  3Comments